बुक बिल्डिंग माइक्रोसर्विसेज ने अपने उत्तर में @RogerAlsing द्वारा वर्णित शैलियों का विस्तार से वर्णन किया है।
आर्केस्ट्रा बनाम कोरियोग्राफी के तहत पेज 43 पर किताब कहती है:
जैसा कि हम अधिक से अधिक जटिल तर्क देना शुरू करते हैं, हमें व्यक्तिगत प्रक्रियाओं की सीमा में खिंचाव वाली व्यावसायिक प्रक्रियाओं के प्रबंधन की समस्या से निपटना होगा। और microservices के साथ, हम इस सीमा को जल्द से जल्द मार देंगे। [...] जब वास्तव में इस प्रवाह को लागू करने की बात आती है, तो वास्तुकला की दो शैलियाँ हैं जिनका हम अनुसरण कर सकते हैं। ऑर्केस्ट्रेशन के साथ, हम एक केंद्रीय मस्तिष्क पर निर्भर करते हैं कि इस प्रक्रिया को निर्देशित करने और ड्राइव करने के लिए, बहुत कुछ एक ऑर्केस्ट्रा में कंडक्टर की तरह। कोरियोग्राफी के साथ, हम इसकी नौकरी के सिस्टम के प्रत्येक भाग को सूचित करते हैं और इसे विवरण का काम करने देते हैं, जैसे नर्तक सभी अपने रास्ते में प्रवेश करते हैं और एक बैले में उनके आसपास दूसरों पर प्रतिक्रिया करते हैं।
पुस्तक फिर दो शैलियों की व्याख्या करने के लिए आगे बढ़ती है। ऑर्केस्ट्रेशन शैली, ऑर्केस्ट्रेशन / कार्य सेवाओं के एसओए विचार से अधिक मेल खाती है , जबकि कोरियोग्राफी शैली डंब पाइप और मार्टिन फाउलर के लेख में उल्लिखित स्मार्ट एंडपॉइंट से मेल खाती है ।
आर्केस्ट्रा स्टाइल
इस शैली के अंतर्गत, उपर्युक्त पुस्तक:
आइए इस प्रवाह के लिए एक ऑर्केस्ट्रेशन समाधान कैसा दिखेगा। यहां, शायद सबसे सरल बात यह होगी कि हमारे ग्राहक सेवा केंद्रीय मस्तिष्क के रूप में कार्य करेंगे। निर्माण पर, यह अनुरोध / प्रतिक्रिया कॉल की एक श्रृंखला के माध्यम से वफादारी अंक बैंक, ईमेल सेवा और डाक सेवा [...] से बात करता है। ग्राहक सेवा स्वयं ट्रैक कर सकती है कि ग्राहक इस प्रक्रिया में कहां है। यह देखने के लिए जांचें कि क्या ग्राहक का खाता स्थापित किया गया है, या भेजे गए ईमेल, या वितरित किए गए पोस्ट। हम फ्लोचार्ट [...] लेने के लिए और इसे सीधे कोड में मॉडल करते हैं। हम टूलींग का उपयोग भी कर सकते हैं जो हमारे लिए इसे लागू करता है, शायद एक उपयुक्त नियम इंजन का उपयोग कर। व्यावसायिक उपकरण मॉडलिंग प्रक्रिया सॉफ्टवेयर के रूप में इस उद्देश्य के लिए वाणिज्यिक उपकरण मौजूद हैं। यह मानते हुए कि हम समकालिक अनुरोध / प्रतिक्रिया का उपयोग करते हैं, हम यह भी जान सकते हैं कि क्या प्रत्येक चरण ने काम किया है [...] इस ऑर्केस्ट्रेशन दृष्टिकोण के लिए नकारात्मक पक्ष यह है कि ग्राहक सेवा एक केंद्रीय शासी प्राधिकरण की बहुत अधिक बन सकती है। यह एक वेब और एक केंद्रीय बिंदु के बीच में केंद्र बन सकता है जहां तर्क रहने लगता है। मैंने इस दृष्टिकोण को स्मार्ट "भगवान" सेवाओं की एक छोटी संख्या में देखा है जो एनीमिक सीआरयूडी-आधारित सेवाओं को बता रहा है कि क्या करना है।
नोट: मुझे लगता है कि जब लेखक टूलींग का उल्लेख करता है, तो वह BPM (जैसे गतिविधि , अपाचे ODE , कैमुंडा ) का उल्लेख कर रहा है । तथ्य की बात के रूप में, वर्कफ़्लो पैटर्न वेबसाइट में इस तरह के ऑर्केस्ट्रेशन को करने के लिए पैटर्न का एक भयानक सेट है और यह विभिन्न विक्रेता टूल का मूल्यांकन विवरण भी प्रदान करता है जो इसे इस तरह लागू करने में मदद करते हैं। मुझे नहीं लगता कि लेखक का मतलब है कि एकीकरण की इस शैली को लागू करने के लिए इनमें से किसी एक उपकरण का उपयोग करना आवश्यक है, हालांकि, अन्य हल्के ऑर्केस्ट्रेशन फ्रेमवर्क का उपयोग किया जा सकता है जैसे स्प्रिंग इंटीग्रेशन , अपाचे ऊंट या खच्चर ESB
हालाँकि, अन्य पुस्तकें जो मैंने माइक्रोसॉर्विस के विषय पर पढ़ी हैं और सामान्य तौर पर मैंने वेब में जितने लेख पाए हैं उनमें से अधिकांश में ऑर्केस्ट्रेशन के इस दृष्टिकोण को महसूस किया गया है और इसके बजाय अगले एक का उपयोग करने का सुझाव दिया गया है।
कोरियोग्राफी की शैली
कोरियोग्राफी की शैली में लेखक कहता है:
कोरियोग्राफ किए गए दृष्टिकोण के साथ, हम इसके बजाय ग्राहक सेवा को एक अतुल्यकालिक तरीके से एक घटना का उत्सर्जन कर सकते हैं, ग्राहक ने कहा। ईमेल सेवा, डाक सेवा, और वफादारी अंक बैंक तो बस इन घटनाओं की सदस्यता लें और तदनुसार प्रतिक्रिया दें [...] यह दृष्टिकोण काफी अधिक जटिल है। यदि किसी ग्राहक के निर्माण तक पहुंचने के लिए कुछ अन्य सेवा की आवश्यकता होती है, तो उसे केवल घटनाओं की सदस्यता लेने और जरूरत पड़ने पर अपना काम करने की आवश्यकता होती है। नकारात्मक पक्ष यह है कि हम जिस व्यवसाय प्रक्रिया में देखते हैं, उसका स्पष्ट दृश्य [वर्कफ़्लो] अब केवल अंतर्निहित रूप से हमारे सिस्टम में परिलक्षित होता है [...] इसका मतलब यह है कि यह सुनिश्चित करने के लिए अतिरिक्त कार्य की आवश्यकता है कि आप सही चीज़ों की निगरानी और ट्रैक कर सकें। हो गई। उदाहरण के लिए, क्या आप जानते हैं कि अगर वफादारी अंक बैंक में बग था और किसी कारण से सही खाता नहीं बना था? इससे निपटने के लिए मुझे जो एक दृष्टिकोण पसंद है, वह है एक मॉनिटरिंग सिस्टम का निर्माण करना, जो स्पष्ट रूप से [वर्कफ़्लो] में व्यावसायिक प्रक्रिया के दृश्य से मेल खाता हो, लेकिन तब ट्रैक करता है कि प्रत्येक सेवा स्वतंत्र संस्थाओं के रूप में क्या करती है, आपको अजीब अपवादों को देखने देती है। अधिक स्पष्ट प्रक्रिया प्रवाह। [फ़्लोचार्ट] [...] ड्राइविंग बल नहीं है, लेकिन सिर्फ एक लेंस जिसके माध्यम से हम देख सकते हैं कि सिस्टम कैसे व्यवहार कर रहा है। सामान्य तौर पर, मैंने पाया है कि कोरियोग्राफ किए गए दृष्टिकोण की ओर अधिक रुझान रखने वाले सिस्टम अधिक शिथिल युग्मित होते हैं, और बदलने के लिए अधिक लचीले और उत्तरदायी होते हैं। हालाँकि, आपको सिस्टम सीमाओं पर प्रक्रियाओं को मॉनिटर करने और ट्रैक करने के लिए अतिरिक्त काम करने की आवश्यकता है। मैंने परिवर्तन की अधिक लागत के साथ, अत्यधिक भंगुर होने के लिए सबसे भारी ऑर्केस्ट्रेटेड कार्यान्वयन पाया है। इस बात को ध्यान में रखते हुए, मैं एक कोरियोग्राफ प्रणाली के लिए दृढ़ता से लक्ष्य करना पसंद करता हूं, जहां प्रत्येक सेवा पूरे नृत्य में अपनी भूमिका को समझने के लिए पर्याप्त स्मार्ट है।
नोट: आज तक मुझे यकीन नहीं है कि अगर कोरियोग्राफ़ी इवेंट-संचालित आर्किटेक्चर (EDA) का दूसरा नाम है , लेकिन अगर EDA इसे करने का सिर्फ एक तरीका है, तो अन्य तरीके क्या हैं? (यह भी देखें कि "इवेंट-ड्रिवेन" से आपका क्या मतलब है? और इवेंट-मीनिंग आर्किटेक्चर का मतलब )। इसके अलावा, ऐसा लगता है कि CQRS और EventSourcing जैसी चीजें इस वास्तुकला शैली के साथ बहुत कुछ प्रतिध्वनित करती हैं, है ना?
अब, इसके बाद मजा आता है। माइक्रोसर्विसेज की पुस्तक यह नहीं मानती है कि आरईएस के साथ माइक्रोसर्विसेज लागू होने जा रहे हैं। पुस्तक में अगले भाग में तथ्य की बात के रूप में, वे आरपीसी और एसओए-आधारित समाधानों और अंत में आरईएसटी पर विचार करने के लिए आगे बढ़ते हैं। यहाँ एक महत्वपूर्ण बात यह है कि माइक्रोसिस्टम्स REST का अर्थ नहीं लगाता है।
तो, HATEOAS के बारे में क्या? (अनुप्रयोग राज्य के इंजन के रूप में हाइपरमीडिया)
अब, यदि हम Restful दृष्टिकोण का पालन करना चाहते हैं तो हम HATEOAS या रॉय फील्डिंग को नजरअंदाज नहीं कर सकते हैं, तो अपने ब्लॉग में यह कहते हुए बहुत खुशी होगी कि हमारा समाधान वास्तव में REST नहीं है। REST API पर उनकी ब्लॉग पोस्ट देखें हाइपरटेक्स्ट संचालित :
मैं किसी HTTP- आधारित इंटरफ़ेस को REST API कहने वाले लोगों की संख्या से निराश हो रहा हूं। अन्य वास्तुशिल्प शैली को इस धारणा पर स्पष्ट करने के लिए क्या किया जाना चाहिए कि हाइपरटेक्स्ट एक बाधा है? दूसरे शब्दों में, यदि एप्लिकेशन स्टेट (और इसलिए API) का इंजन हाइपरटेक्स्ट द्वारा संचालित नहीं किया जा रहा है, तो यह RESTful नहीं हो सकता है और REST API नहीं हो सकता है। अवधि। क्या कहीं कुछ टूटा हुआ मैनुअल है जिसे ठीक करने की आवश्यकता है?
इसलिए, जैसा कि आप देख सकते हैं, क्षेत्ररक्षण को लगता है कि HATEOAS के बिना आप वास्तव में Restful अनुप्रयोगों का निर्माण नहीं कर रहे हैं। क्षेत्ररक्षण के लिए, HateOAS सेवाओं को ऑर्केस्ट्रेट करने के लिए जाने का रास्ता है। मैं सिर्फ यह सब सीख रहा हूं, लेकिन मेरे लिए, HATEOAS स्पष्ट रूप से परिभाषित नहीं करता है कि वास्तव में लिंक के पीछे ड्राइविंग बल कौन है या क्या है। एक यूआई में जो उपयोगकर्ता हो सकता है, लेकिन कंप्यूटर-से-कंप्यूटर इंटरैक्शन में, मुझे लगता है कि उच्च स्तर की सेवा द्वारा किया जाना चाहिए।
HATEOAS के अनुसार, केवल API उपभोक्ता को सही मायने में जानने की जरूरत है वह है जो सर्वर के साथ संचार शुरू करता है (जैसे POST / आदेश)। इस बिंदु से, आरईएसटी प्रवाह का संचालन करने जा रहा है, क्योंकि, इस समापन बिंदु की प्रतिक्रिया में, लौटे संसाधन में अगले संभावित राज्यों के लिंक होंगे। एपीआई उपभोक्ता तब यह तय करता है कि आवेदन को अगले राज्य में किस चरण पर चलना है और किस दिशा में जाना है।
यह कितना अच्छा लगता है, इसके बावजूद, क्लाइंट को यह जानने की जरूरत है कि क्या लिंक को POSTed, PUTed, GETed, PATCHed इत्यादि होना चाहिए और क्लाइंट को अभी भी यह तय करने की आवश्यकता है कि पेलोड को क्या पारित करना है। क्लाइंट को अभी भी पता होना चाहिए कि क्या करना है अगर वह विफल हो जाता है (पुन: प्रयास, क्षतिपूर्ति, रद्द करें, आदि)।
मैं यह सब करने के लिए काफी नया हूं, लेकिन मेरे लिए, HATEOAs के नजरिए से, यह ग्राहक, या एपीआई उपभोक्ता एक उच्च क्रम सेवा है। यदि हम इसे मानव के दृष्टिकोण से सोचते हैं, तो आप एक वेब पेज पर एंड-यूज़र की कल्पना कर सकते हैं, यह तय करने के लिए कि लिंक का पालन क्या करना है, लेकिन फिर भी, वेब पेज के प्रोग्रामर को यह तय करना था कि लिंक को लागू करने के लिए किस पद्धति का उपयोग करना है, और क्या पेलोड पारित करने के लिए। इसलिए, मेरी बात में, कंप्यूटर-से-कंप्यूटर इंटरैक्शन में, कंप्यूटर एंड-यूज़र की भूमिका लेता है। एक बार और यह वह है जिसे हम ऑर्केस्ट्रेशन सेवा कहते हैं।
मुझे लगता है कि हम या तो ऑर्केस्ट्रेशन या कोरियोग्राफी के साथ HATEOAS का उपयोग कर सकते हैं।
एपीआई गेटवे पैटर्न
एक और दिलचस्प पैटर्न क्रिस रिचर्डसन द्वारा सुझाया गया है, जिसने एक एपीआई गेटवे पैटर्न को भी प्रस्तावित किया था ।
एक अखंड वास्तुकला में, एप्लिकेशन के क्लाइंट, जैसे कि वेब ब्राउज़र और देशी एप्लिकेशन, एक समान बेलेंस के माध्यम से एप्लिकेशन के एन समान उदाहरणों में HTTP अनुरोध करते हैं। लेकिन एक माइक्रोसिस्टवर्क वास्तुकला में, मोनोलिथ को सेवाओं के संग्रह से बदल दिया गया है। नतीजतन, एक महत्वपूर्ण सवाल जिसका हमें जवाब देने की जरूरत है कि ग्राहक क्या बातचीत करते हैं?
एक एप्लिकेशन क्लाइंट, जैसे कि एक देशी मोबाइल एप्लिकेशन, व्यक्तिगत सेवाओं के लिए Restful HTTP अनुरोध कर सकता है [...] सतह पर यह आकर्षक लग सकता है। हालांकि, ग्राहकों द्वारा आवश्यक व्यक्तिगत सेवाओं और डेटा के एपीआई के बीच बारीकियों में एक महत्वपूर्ण बेमेल होने की संभावना है। उदाहरण के लिए, एक वेब पेज प्रदर्शित करना संभावित रूप से बड़ी संख्या में सेवाओं के लिए कॉल की आवश्यकता हो सकती है। उदाहरण के लिए, Amazon.com
बताता है कि कैसे कुछ पृष्ठों को 100+ सेवाओं के लिए कॉल की आवश्यकता होती है। एक हाई-स्पीड इंटरनेट कनेक्शन पर भी कई अनुरोध करते हुए, अकेले-कम बैंडविड्थ, उच्च-विलंबता मोबाइल नेटवर्क, को बहुत ही अक्षम और एक खराब उपयोगकर्ता अनुभव के परिणामस्वरूप।
ग्राहकों के लिए प्रति पृष्ठ बहुत कम संख्या में अनुरोध करने के लिए एक बेहतर तरीका है, शायद एक इंटरनेट पर, एक एपीआई गेटवे के रूप में जाना जाने वाला फ्रंट-एंड सर्वर पर।
एपीआई गेटवे एप्लिकेशन के ग्राहकों और माइक्रोसिस्टर्स के बीच बैठता है। यह API प्रदान करता है जो क्लाइंट के अनुरूप होता है। एपीआई गेटवे मोबाइल ग्राहकों को एक मोटे अनाज वाला एपीआई और उच्च प्रदर्शन वाले नेटवर्क का उपयोग करने वाले डेस्कटॉप ग्राहकों को महीन अनाज वाला एपीआई प्रदान करता है। इस उदाहरण में, डेस्कटॉप ग्राहक एक उत्पाद के बारे में जानकारी प्राप्त करने के लिए कई अनुरोध करते हैं, जबकि एक मोबाइल ग्राहक एक ही अनुरोध करता है।
एपीआई गेटवे उच्च प्रदर्शन लैन पर कुछ संख्या में माइक्रोसर्विसेस से अनुरोध करके आने वाले अनुरोधों को संभालता है। उदाहरण के लिए, नेटफ्लिक्स,
वर्णन करता है
कि प्रत्येक अनुरोध के प्रशंसक औसत छह बैकएंड सेवाओं पर कैसे काम करते हैं। इस उदाहरण में, डेस्कटॉप क्लाइंट से ठीक-ठाक अनुरोध केवल संबंधित सेवा के लिए अनुमानित है, जबकि मोबाइल क्लाइंट से प्रत्येक मोटे-मोटे अनुरोध को कई सेवाओं को कॉल करने के परिणामों को एकत्रित करके नियंत्रित किया जाता है।
न केवल एपीआई गेटवे क्लाइंट और एप्लिकेशन के बीच संचार का अनुकूलन करता है, बल्कि यह माइक्रोसिस्टर्स के विवरण को भी एन्क्रिप्ट करता है। यह ग्राहकों को प्रभावित किए बिना माइक्रोसर्विसेज को विकसित करने में सक्षम बनाता है। उदाहरण के लिए, दो microservices विलय किया जा सकता है। एक और माइक्रोसिस्ट सेवा को दो या अधिक सेवाओं में विभाजित किया जा सकता है। इन परिवर्तनों को प्रतिबिंबित करने के लिए केवल एपीआई गेटवे को अद्यतन करने की आवश्यकता है। ग्राहक अप्रभावित हैं।
अब जब हमने देखा है कि एपीआई गेटवे एप्लिकेशन और उसके ग्राहकों के बीच कैसे मध्यस्थता करता है, तो आइए अब देखते हैं कि क्रॉसओवर के बीच संचार को कैसे लागू किया जाए।
यह ऊपर उल्लिखित ऑर्केस्ट्रेशन शैली के समान सुंदर लगता है, बस थोड़ा अलग इरादे के साथ, इस मामले में, यह सभी के प्रदर्शन और बातचीत के सरलीकरण के बारे में लगता है।
।