माइक्रोस्कोप संरचना दृष्टिकोण

Question

मेरे पास माइक्रोस्कोप समुदाय के लिए एक प्रश्न है। मैं शैक्षिक क्षेत्र से एक उदाहरण दूंगा लेकिन यह हर माइक्रोस्कोप आर्किटेक्चर पर लागू होता है।

चलो कहते हैं कि मैं एक व्यवसाय की आवश्यकता है कि छात्रों की संख्या के लिए एक लाइसेंस के द्वारा सीमित है साथ छात्र-सेवा और लाइसेंस सेवा करते हैं। इसलिए हर बार एक छात्र को एक लाइसेंसिंग चेक बनाया जाता है। कई प्रकार के लाइसेंस हैं इसलिए लाइसेंस के प्रकार को ऑपरेशन में शामिल करना होगा।

1. एक समग्र सेवा है कि 2 सेवाओं कॉल बिल्ड
2. युग्मन लाइसेंस सेवा करने के लिए छात्र-सेवा इतनी है कि जब createStudent कहा जाता है:

   मेरा प्रश्न जो दृष्टिकोण आप पाया है व्यवहार में बेहतर है छात्र-सेवा लाइसेंस-सेवा को फोन करेगा और केवल जब कि पूरा करता है छात्र बनाया जाएगा

3. एक घटना आधारित वास्तुकला

Peop का प्रयोग करें सूक्ष्म सेवा आर्किटेक्चर के बारे में ली पदानुक्रम की तुलना में ग्राफ की तरह अधिक है और विकल्प 1 किडा इसे एक पदानुक्रम में बदल देता है जहां आप तेजी से मोटे कंपोजिट प्राप्त करते हैं। अन्य डाउनसाइड्स यह भ्रम पैदा करता है कि किस सेवा क्लाइंट का वास्तव में उपयोग करना चाहिए और कुछ डुप्लिकेशंस चल रहा है क्योंकि कंपोजिट एपीआई को डाउनस्ट्रीम सेवाओं को कॉल करने के लिए आवश्यक सभी पैरामीटर शामिल करना होगा। इसका एक बड़ा लाभ होता है क्योंकि यह आपको असफलता, कोरियोग्राफी और स्थिरता को संभालने के लिए एक प्राकृतिक स्थान देता है।

विकल्प 2 लगता है जैसे कि यह नुकसान भी है:

• लाइसेंस की एपीआई ताकि आप लाइसेंस प्रतिबंध निर्दिष्ट कर सकते छात्र एपीआई में लीक करने के लिए होगा।

• यह छात्र-सेवा पर बोझ का एक बहुत डालता है, क्योंकि यह निर्भर सेवाएं

• के रूप में और अधिक सेवाओं प्रतिक्रिया करने के लिए जब एक छात्र बनाई गई है मैं निर्भरता ग्राफ जल्दी से देख सकते हैं की जरूरत के सभी भर में स्थिरता को संभालने के लिए है नियंत्रण से बाहर निकलना और सेवा को विद्यार्थियों के प्रबंधन के लिए अपने तर्क से एक के अलावा उस जटिलता को संभालना होगा।

विकल्प 3 जबकि स्वर्ग decoupling किया जा रहा है, मैं वास्तव में नहीं लगता क्योंकि यह सब एक यूआई से शुरू हो रहा है और लोगों को वास्तव में "इस नए छात्र दिखाता है जब तक कुछ और जाने के लिए उपयोग नहीं किया जाता काम करेगा "दृष्टिकोण।

आप

Answer 1

ऐप्लिकेशन लाइसेंसिंग धन्यवाद और बनाने छात्रों ओर्थोगोनल इसलिए विकल्प 2 मतलब नहीं है कर रहे हैं।

विकल्प 1 अधिक समझदार है लेकिन मैं एक और सेवा बनाने की कोशिश नहीं करता। इसके बजाय मैं लाइसेंसिंग मिडलवेयर के माध्यम से छात्र सेवा में कॉल "फिल्टर" करने का प्रयास करूंगा।

इस तरह आप अन्य सेवा कॉल के लिए इस मिडलवेयर का उपयोग कर सकते हैं (उदा।कक्षा सेवा) और दोनों लाइसेंसिंग और छात्रों के एपीआई में परिवर्तन स्वतंत्र रूप से किया जा सकता है क्योंकि ये चीजें वास्तव में स्वतंत्र हैं। ऐसा होता है कि लाइसेंसिंग छात्रों की संख्या का उपयोग कर रही है लेकिन यह आसानी से बदल सकती है।

मुझे यकीन नहीं है कि विकल्प 3, एक ईवेंट-आधारित दृष्टिकोण यहां कैसे मदद कर सकता है। हालांकि यह अन्य समस्याओं को हल कर सकता है।

Answer 2

आईएमएचओ, मैं विकल्प 2 के साथ जाऊंगा। विचार करने के लिए कुछ चीजें। यदि आप एसओए में पूर्ण खरीद रहे हैं और माइक्रोस्कोर्विसेज के अलावा, आप किसी भी सेवा को किसी अन्य सेवा से संपर्क करने की आवश्यकता होने पर हर बार फ्लिंच नहीं कर सकते हैं। इसके साथ आराम करो .... याद रखें कि यह बात है। मुझे विकल्प 2 के बारे में वास्तव में क्या पसंद है यह है कि एक सफल छात्र सेवा प्रतिक्रिया तब तक नहीं भेजी जाती जब तक कि लाइसेंस-सेवा अनुरोध सफल नहीं हो जाता। लाइसेंस-सेवा को किसी अन्य बाहरी सेवा के रूप में देखें, जहां आप क्लाइंट ऑब्जेक्ट में लाइसेंस-सेवा को लपेट सकते हैं जिसे लाइसेंस-सेवा जेएआर द्वारा प्रकाशित किया जा सकता है।

• लाइसेंसिंग के एपीआई को छात्र एपीआई में रिसाव करना होगा ताकि आप लाइसेंसिंग प्रतिबंध निर्दिष्ट कर सकें।

हां लाइसेंस-सेवा API का उपयोग किया जाएगा। आप इसे रिसाव (किसी को इसका उपयोग करना होगा) या encapsulation कह सकते हैं ताकि ग्राहक सेवा के लिए अनुरोध करने वाले ग्राहक को लाइसेंसिंग के बारे में चिंता न करें।

• यह छात्र-सेवा पर बोझ का एक बहुत डालता है, क्योंकि यह निर्भर सेवाएं

कुछ सेवा इस बोझ पर लेने के लिए है के सभी भर में स्थिरता को संभालने के लिए है। लेकिन मैं इसे व्यवस्थित रूप से प्रबंधित करूंगा। हम एक और सेवा की जरूरत के बारे में बात कर रहे हैं। यदि यह बढ़ता है और ठोस रूप से परेशान हो जाता है तो एक रिफैक्टरिंग किया जा सकता है। यदि छात्र सेवा की सेवाओं की संख्या बढ़ने की आवश्यकता है, तो मुझे लगता है कि इसे सुंदर ढंग से दोहराया जा सकता है और शायद छात्र सेवा समग्र सेवा बन जाती है और स्वतंत्र रूप से उपयोग की जाने वाली सेवाओं के समूह को यदि आवश्यक हो तो नई सेवाओं में समेकित किया जा सकता है। लेकिन यदि छात्र सेवा का उपयोग करने वाली निर्भरता सेवाओं की सूची केवल छात्र सेवा द्वारा उपयोग की जाती है, तो मुझे नहीं पता कि क्या यह उनके स्वयं के सेवा में उन्हें समूहित करने के लायक है। मुझे लगता है कि बोझ और रिसाव के बजाय आप इसे encapsulation और स्वामित्व के रूप में देख सकते हैं .... जहां छात्र सेवा उस बोझ का मालिक है, इसलिए इसे अन्य ग्राहकों/सेवाओं को रिसाव की आवश्यकता नहीं है।

• के रूप में और अधिक सेवाओं प्रतिक्रिया करने के लिए जब एक छात्र मैं निर्भरता ग्राफ जल्दी से नियंत्रण से बाहर हो रही है और सेवा के छात्रों के प्रबंधन के लिए अपने स्वयं के तर्क से एक के साथ ही उस जटिलता को संभाल करने के लिए होता देख सकते हैं बनाई गई है की जरूरत है।

विकल्प विभिन्न समग्र सेवाएं होगी। पिछले बुलेट प्वाइंट के लिए मेरी प्रतिक्रिया की तरह, अगर यह वास्तविक समस्या के रूप में सामने आता है तो इसे सुंदर ढंग से निपटाया जा सकता है।

यदि आपके प्रत्येक विकल्प को मजबूर समाधान में बदल दिया जा सकता है। मैं विकल्प 2 के लिए एक राय केस बना रहा हूं।

Answer 3

मुझे पता है कि कुछ समय पहले सवाल पूछा गया है, लेकिन मुझे लगता है कि मेरे पास कुछ कहना है कि यहां मूल्य हो सकता है।
सबसे पहले, आपका दृष्टिकोण आपके अंतिम उत्पाद के समग्र आकार पर निर्भर करेगा। मुझे अंगूठे के नियम के साथ जाना पड़ता है: यदि व्यक्तिगत माइक्रो-सर्विसेज के बीच मुझे बहुत अधिक निर्भरताएं मिलती हैं, तो मैं कुछ ऐसी चीज का उपयोग करता हूं जो सरलतापूर्वक और इन निर्भरताओं को हटा देगा। मैं सेवाओं के मकड़ी-वेब के साथ खत्म नहीं करना चाहता! यहां देखने के लिए एक अच्छी बात संदेश कतार है, उदाहरण के लिए RabbitMQ।
हालांकि, अगर मेरे पास एक-दूसरे से बात करने वाली कुछ सेवाएं हैं, तो मैं उन्हें एक-दूसरे को सीधे कॉल कर दूंगा, क्योंकि आर्किटेक्चर को सरल बनाने के दौरान कोई वैकल्पिक समाधान, कुछ कंप्यूटिंग और इंफ्रास्ट्रक्चर ओवरहेड जोड़ें।

जो भी दृष्टिकोण आप जाने का फैसला करेंगे, Hexagonal architecture में अपनी सेवाओं को दिमाग में डिज़ाइन करें! जब आप एक समाधान से दूसरे समाधान में माइग्रेट करने का निर्णय लेते हैं तो इससे आपको परेशानी होगी। मैं जो करना चाहता हूं वह मेरे डीएओ को "एडेप्टर" के रूप में डिज़ाइन करता है, इसलिए सर्विस ए को कॉल करने वाला डीएओ या तो इसे सीधे तर्क या व्यावसायिक तर्क से स्वतंत्र संदेश कतार के माध्यम से कॉल करेगा। जब मुझे इसे बदलने की ज़रूरत है, तो मैं किसी भी व्यावसायिक तर्क को छूने के बिना, इस डीएओ को किसी अन्य के लिए बदल सकता हूं (दिन के अंत में व्यापार तर्क इस बात पर ध्यान नहीं देता कि यह डेटा कैसे प्राप्त करता है)। हेक्सागोनल आर्किटेक्चर माइक्रो-सर्विस, टीडीडी और ब्लैक-बॉक्स परीक्षण के साथ वास्तव में अच्छी तरह फिट बैठता है।

Answer 4

विकल्प 1 और 2 तंग युग्मन बनाता है जिसे जितना संभव हो सके से बचा जाना चाहिए क्योंकि आप अपनी सेवाओं को स्वतंत्र होना चाहते हैं। तो सवाल बन जाता है:

हम ईवेंट-आधारित आर्किटेक्चर के साथ ऐसा कैसे करते हैं?

1. छात्र सेवा में लाइसेंस सेवा से लाइसेंसिंग जानकारी का ट्रैक रखने के लिए घटनाओं का उपयोग करें, व्यावहारिक रूप से डेटा डुप्लिकेशन। यहां पर दोष हैं: आपके पास केवल अंतिम स्थिरता है क्योंकि डेटा डुप्लिकेशन एसिंक्रोनस है।

2. घटना श्रृंखला को ट्रिगर करने के लिए असीमित घटनाओं का उपयोग करें जो आखिरकार छात्र निर्माण को ट्रिगर करता है। आपके प्रश्न से, ऐसा लगता है कि आपको पहले ही विचार मिल गया है, लेकिन यूआई से निपटने में कोई समस्या है। आपके पास दो संभावित विकल्प हैं: छात्र निर्माण (या विफलता) ईवेंट की थोड़ी सी मात्रा के साथ प्रतीक्षा करें, या (ईवेंट बेहतर), आपको सिस्टम को पूरी तरह प्रतिक्रियाशील बनाएं (यूआई के लिए सर्वर-क्लाइंट पुश तंत्र का उपयोग करें)।