Mikroservisy। जावा उदाहरणों के साथ विकास और रिफैक्टिंग पैटर्न

नमस्कार, हेब्र!

हम क्रिस रिचर्डसन की पुस्तक माइक्रोसर्विसेज पैटर्न का अनुवाद करना शुरू कर रहे हैं । जावा में उदाहरणों के साथ । यह रूसी में प्रीमियर से आधे साल पहले किया गया है, लेकिन हम आपको बेन नडेल की इस पुस्तक की एक तरह की संक्षिप्त समीक्षा की पेशकश करना चाहते हैं, जो MEAP संस्करण पढ़ते हैं। समीक्षा सक्रिय रूप से रिचर्डसन के किंडल संस्करण के पाठ को उद्धृत करती है।



बिल्ली के लिए आपका स्वागत है!

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

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

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

मैं शुरू से ही रिचर्डसन के लिए हर विस्तार में व्यावहारिक होने की उम्मीद कर रहा था। पुस्तक का एक भी पहलू "चांदी की गोली" या "एकमात्र समाधान" के रूप में प्रस्तुत नहीं किया गया है। हर जगह हम एक परिकलित विकल्प देखते हैं, स्पष्ट रूप से परिभाषित समझौता का एक सेट। उदाहरण के लिए, लेखक इस नस में माइक्रोसर्विस के विचार को भी प्रस्तुत करता है: माइक्रोसर्विस आर्किटेक्चर को हमेशा उन मामलों में छोड़ देना चाहिए, जहां यह बिल्कुल आवश्यक है:

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

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

माइक्रोसर्विस प्रतिमान पर चलते हुए, आपको अपनी वास्तुकला, अपने संगठन और विकास प्रक्रियाओं को बदलने के लिए मजबूर किया जाता है। हालांकि, अंत में, काम करने का माहौल बदल जाता है, जिन स्थितियों में लोग काम करते हैं, और लोग, जैसा कि पहले ही उल्लेख किया गया है, भावनात्मक हैं। यदि मानवीय भावनाओं को नजरअंदाज किया जाता है, तो एक संगठन में माइक्रोसर्विस की शुरूआत एक खड़ी मार्ग में बदल सकती है। (जलाने का संस्करण, पता 718)

लेखक द्वारा बताई गई रणनीतियां पूरे व्यवसाय की चिंता करती हैं, प्रबंधकों और अधिकारियों को प्रभावित करती हैं जो एक बड़ी रीफैक्टरिंग शुरू करने की हिम्मत नहीं कर सकते हैं, इससे मूल्यवान संसाधन ले सकते हैं, जो लोग नई सुविधाओं को सक्रिय रूप से विकसित कर सकते हैं:

माइक्रोसैस आर्किटेक्चर की ओर कदम-दर-चरण रिफ्लेक्टरिंग का एक महत्वपूर्ण लाभ यह है कि इस तरह की रणनीति तुरंत भुगतान करना शुरू कर देती है। यह बिल्कुल भी स्थिति नहीं है जब "ओवरहॉलिंग" एक कोड है जो पूरी तरह से पूरा होने तक कोई लाभ नहीं लाता है ...

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

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

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

ईमानदारी से, मैं अभी परीक्षण अध्यापकों पर दो अध्यायों के माध्यम से फ़्लिप करता हूँ और एक अध्याय पर एक अध्याय को तैनात करता हूँ। मुझे यकीन है कि लेखक ने इन विषयों पर पूरी तरह से काम किया है, लेकिन मुझे लगता है कि मुझे पचाने की तुलना में अधिक जानकारी थी। मेरे लिए तैनाती एक जरूरी दैनिक कार्य नहीं है। उन्होंने अपने जीवन में कई परीक्षण लिखे।
इस प्रकार, मैं अपनी अस्पष्ट गुफा चेतना में अन्य सभी अध्यायों से सामग्री डालने के लिए पर्याप्त स्थान छोड़ना चाहता था: विषय-उन्मुख डिजाइन (डीडीडी), इंटरप्रोसेस संचार, और डेटा सिंक्रनाइज़ेशन पर।

उन अनुभागों में से एक जो मुझे विशेष रूप से प्रभावित करता है कि किस सेवा के लिए एक विशेष प्रकार के अनुरोधों को संभालना चाहिए, अर्थात्: उपयोगकर्ता के वर्तमान नेटवर्क के पास उपयुक्त रेस्तरां खोजें:

हालांकि, उन अनुरोधों को भी लागू करना मुश्किल हो सकता है जो किसी विशेष सेवा के संदर्भ में स्थानीय हैं। यह कई कारणों से संभव है। सबसे पहले, क्योंकि (जैसा कि नीचे वर्णित है), डेटा का स्वामित्व रखने वाली सेवा में अनुरोध को लागू करना कभी-कभी अनुचित होता है। एक और कारण यह है कि कभी-कभी सेवा डेटाबेस (या डेटा मॉडल) कुशलता से अनुरोध का समर्थन नहीं कर सकता (जलाने का संस्करण, पता 5659)

... अगर FTGO में रेस्तरां के बारे में जानकारी [कुछ अन्य] डेटाबेस में संग्रहीत की जाती है, तो findAvailableRestaurant() क्वेरी का कार्यान्वयन बहुत अधिक जटिल है। रेस्तरां डेटा की प्रतिकृति को ऐसे रूप में संग्रहीत किया जाना चाहिए जो भू-स्थानिक प्रश्नों का समर्थन करता है। उदाहरण के लिए, एक एप्लिकेशन डायनेमोडीबी के लिए जियोस्पेशियल इंडेक्सिंग लाइब्रेरी का उपयोग कर सकता है, जहां तालिका को जियोस्पेशियल इंडेक्स के रूप में उपयोग किया जाता है। वैकल्पिक: एप्लिकेशन पूरी तरह से अलग प्रकार के डेटाबेस में रेस्तरां डेटा की प्रतिकृति को स्टोर कर सकता है। एक समान स्थिति तब होती है जब हम पाठ खोज के लिए डेटाबेस के साथ पाठ प्रश्नों का उपयोग करते हैं। (किंडल संस्करण, पता 5675)

... इस मामले में, यह सलाह दी जाती है (कम से कम पहली नज़र में) अनुरोध सेवा को उसी सेवा द्वारा कार्यान्वित किया जाता है जो डेटा का मालिक है। हालांकि, डेटा स्वामित्व के अलावा, अन्य कारकों पर विचार करना होगा।

कर्तव्यों के पृथक्करण की आवश्यकता को ध्यान में रखना और बहुत अधिक सुविधाओं के साथ ओवरलोडिंग सेवाओं से बचने के लिए भी आवश्यक है। उदाहरण के लिए, रेस्तरां सेवा विकसित करने वाली टीम की मुख्य ज़िम्मेदारी रेस्तरां प्रबंधकों को प्रतिष्ठान के काम को पूरा करने में मदद करना है। यह कार्य उस योजना के लिए बिल्कुल नहीं है जो बड़ी मात्रा में डेटा के साथ काम करने के लिए एक महत्वपूर्ण अनुरोध का कार्यान्वयन करता है। इसके अलावा, अगर विकास टीम findAvailableRestaurants() ऑपरेशन के लिए ज़िम्मेदार थी, तो वह लगातार ऐसे बदलावों से डरती रहेगी, जो उपभोक्ताओं को ऑर्डर देने से रोक सकते हैं। (किंडल संस्करण, पता 5675)

यहां, मेरे मस्तिष्क में थोड़ा विस्फोट हुआ क्योंकि मैंने पहली बार एक सेवा देखी थी जिसका एकमात्र कार्य किसी विशिष्ट कार्य को करने के लिए किसी अन्य सेवा के डेटा का अनुकूलन करना था। हालांकि, जैसा कि रिचर्डसन बताते हैं, यह बहुत ही विचार का एक सामान्यीकृत अमूर्त है जो पूर्ण-पाठ खोज को रेखांकित करता है, उदाहरण के लिए, अपाचे ल्यूसिन में (यह उपकरण एक अन्य डेटा वेयरहाउस के शीर्ष पर पूर्ण-पाठ अनुक्रमण प्रदान करता है)।

मुझे संदेह है - या बल्कि, मैं आशा करना चाहता हूं - कि, जिम्मेदारियों के ऐसे विभाजन को देखकर, पाठक सेवाओं के बीच एक नई रेखा खींचना शुरू कर देगा। वह न केवल "डेटा स्वामित्व" के बारे में सोचेगा, बल्कि "व्यापार के अवसरों" को भी ध्यान में रखना शुरू कर देगा - अर्थात, वास्तविक मूल्य का एक कारक, ताकि डेटाबेस केवल उस स्थान पर नहीं लगता जहां राज्य संग्रहीत है।

इस चर्चा में प्रकाश डाला गया एक अन्य पहलू है डेटा सिंक्रनाइज़ेशन और प्रतिकृति का पूर्ण महत्व, साथ ही साथ माइक्रोसॉफ़्ट वास्तुकला में अतुल्यकालिक संदेश। यह विषय पूरे रिचर्डसन की पुस्तक के साथ एक लाल धागे से चलता है, चाहे वे किसी भी विषय पर बात करते हों: खरोंच से एक माइक्रोसर्विस का निर्माण या एक मोनोलिथ को माइक्रोसर्विस (एक अलग अध्याय इस विषय के लिए समर्पित) में क्रमिक रूप से फिर से भरना। वह यह स्पष्ट करता है कि तुल्यकालन वह रीढ़ की हड्डी का बल है जो वास्तव में कई चीजों को महसूस करने की अनुमति देता है।

मैं बहुत सी रोचक बातों का उल्लेख कर सकता था। उदाहरण के लिए, क्या तथ्य है कि रिचर्डसन एक वितरित प्रणाली में प्रमाणीकरण और प्राधिकरण के बारे में ठीक से बात करते हैं? मुझे लगता है कि इस विषय को अभी तक पूरी तरह से खोजा नहीं गया है, इसे हल्के ढंग से रखने के लिए। लेखक विषय-उन्मुख डिज़ाइन को सबसे सुलभ तरीके से समझाता है। वह यह भी प्रदर्शित करता है कि बहुत ही सरल वर्गों का भी व्यवहार हो सकता है।

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