🥇NDС लंदन सम्मेलन। माइक्रोसर्विस आपदा को रोकना। भाग 1

आपने अपने मोनोलिथ को माइक्रोसर्विसेज में फिर से डिज़ाइन करने में कई महीने बिताए हैं, और आखिरकार हर कोई स्विच को फ्लिप करने के लिए एक साथ आया है। आप पहले वेब पेज पर जाएँ... और कुछ नहीं होता। आप इसे पुनः लोड करें - और फिर भी कुछ भी अच्छा नहीं है, साइट इतनी धीमी है कि यह कई मिनटों तक प्रतिक्रिया नहीं देती है। क्या हुआ?

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

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

उन्हें सभी ऑर्डर, बिक्री, रिटर्न, उत्पाद कैटलॉग और ग्राहक आधार को प्रबंधित करने के लिए एक प्रणाली बनाने की आवश्यकता थी, इसलिए उन्होंने उस समय सबसे आम मेनफ्रेम समाधान चुना। इस विशाल प्रणाली में कंपनी के बारे में हर संभव जानकारी शामिल थी, और हर लेनदेन इस मेनफ्रेम के माध्यम से किया जाता था। उन्होंने अपने सारे अंडे एक टोकरी में रख दिए और उन्हें लगा कि यह सामान्य बात है। एकमात्र चीज जो यहां शामिल नहीं है वह है मेल ऑर्डर कैटलॉग और फोन द्वारा ऑर्डर देना।

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

प्रारंभिक डिज़ाइन बहुत अच्छा लग रहा था और इसमें एक शीर्ष-स्तरीय साइट बेल.कॉम और व्यक्तिगत अनुप्रयोगों के लिए कई उपडोमेन शामिल थे: कैटलॉग.बेल.कॉम, अकाउंट्स.बेल.कॉम, ऑर्डर्स.बेल.कॉम, उत्पाद खोज सर्च.बेल। com. प्रत्येक उपडोमेन ने ASP.Net 1.0 फ्रेमवर्क और अपने स्वयं के डेटाबेस का उपयोग किया, और वे सभी सिस्टम बैकएंड से बात करते थे। हालाँकि, सभी आदेशों को एक ही विशाल मेनफ्रेम के भीतर संसाधित और निष्पादित किया जाता रहा, जिसमें सारा कचरा रहता था, लेकिन सामने का अंत अलग-अलग एप्लिकेशन और अलग-अलग डेटाबेस वाली अलग-अलग वेबसाइटें थीं।

इसलिए सिस्टम का डिज़ाइन व्यवस्थित और तार्किक लग रहा था, लेकिन वास्तविक सिस्टम अगली स्लाइड में दिखाया गया था।

सभी तत्वों ने एक-दूसरे को कॉल को संबोधित किया, एक्सेस किए गए एपीआई, एम्बेडेड थर्ड-पार्टी डीएलएस, और इसी तरह। अक्सर ऐसा होता था कि संस्करण नियंत्रण प्रणालियाँ किसी और के कोड को पकड़ लेती थीं, उसे प्रोजेक्ट के अंदर डाल देती थीं और फिर सब कुछ टूट जाता था। MS SQL सर्वर 2005 में लिंक सर्वर की अवधारणा का उपयोग किया गया था, और हालाँकि मैंने स्लाइड पर तीर नहीं दिखाए थे, प्रत्येक डेटाबेस ने एक-दूसरे से बात भी की थी, क्योंकि कई डेटाबेस से प्राप्त डेटा के आधार पर तालिकाएँ बनाने में कुछ भी गलत नहीं है।

चूँकि अब सिस्टम के विभिन्न तार्किक क्षेत्रों के बीच कुछ अलगाव हो गया है, यह गंदगी के वितरित बूँदें बन गए हैं, कचरे का सबसे बड़ा टुकड़ा अभी भी मेनफ्रेम बैकएंड में शेष है।

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

मौजूदा एप्लिकेशन 15 वर्षों से उत्पादन में था, जो ASP.Net-आधारित अनुप्रयोगों के लिए एक रिकॉर्ड है। सेवा ने दुनिया भर से ऑर्डर स्वीकार किए, और इस एकल एप्लिकेशन से वार्षिक राजस्व एक अरब डॉलर तक पहुंच गया। लाभ का एक महत्वपूर्ण हिस्सा बेल.कॉम वेबसाइट द्वारा उत्पन्न किया गया था। ब्लैक फ्राइडे पर, साइट के माध्यम से दिए गए ऑर्डर की संख्या कई मिलियन तक पहुंच गई। हालाँकि, मौजूदा वास्तुकला ने किसी भी विकास की अनुमति नहीं दी, क्योंकि सिस्टम तत्वों के कठोर अंतर्संबंध व्यावहारिक रूप से सेवा में कोई बदलाव करने की अनुमति नहीं देते थे।

सबसे गंभीर समस्या एक देश से ऑर्डर देने, दूसरे में भुगतान करने और तीसरे को भेजने में असमर्थता थी, इस तथ्य के बावजूद कि वैश्विक कंपनियों में ऐसी ट्रेडिंग योजना बहुत आम है। मौजूदा वेबसाइट इस तरह की किसी भी चीज़ की अनुमति नहीं देती थी, इसलिए उन्हें इन आदेशों को स्वीकार करना पड़ा और फ़ोन पर देना पड़ा। इससे कंपनी आर्किटेक्चर को बदलने के बारे में तेजी से सोचने लगी, विशेष रूप से माइक्रोसर्विसेज पर स्विच करने के बारे में।

उन्होंने अन्य कंपनियों को देखकर यह जानने का स्मार्ट काम किया कि उन्होंने इसी तरह की समस्या को कैसे हल किया है। इन समाधानों में से एक नेटफ्लिक्स सेवा आर्किटेक्चर था, जिसमें एक एपीआई और एक बाहरी डेटाबेस के माध्यम से जुड़े माइक्रोसर्विसेज शामिल हैं।

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

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

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

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

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

इस आरेख में हरा रंग एक अर्धवृत्त दिखाता है जिसमें सेवाएँ एक दूसरे को कॉल करती हैं - सेवा A सेवा B को कॉल करती है, सेवा B सेवा C को कॉल करती है, और यह सेवा A को फिर से कॉल करती है। परिणामस्वरूप, हमें एक "वितरित गतिरोध" मिलता है। एक एकल अनुरोध ने एक हजार नेटवर्क एपीआई कॉल बनाए, और चूंकि सिस्टम में अंतर्निहित गलती सहनशीलता और लूप सुरक्षा नहीं थी, इसलिए यदि इनमें से एक भी एपीआई कॉल विफल हो गई तो अनुरोध विफल हो जाएगा।

हमने कुछ गणित किया. प्रत्येक एपीआई कॉल का एसएलए 150 एमएस से अधिक नहीं था और 99,9% अपटाइम था। एक अनुरोध के कारण 200 अलग-अलग कॉलें आईं और सर्वोत्तम स्थिति में, पृष्ठ 200 x 150 एमएस = 30 सेकंड में दिखाया जा सकता था। स्वाभाविक रूप से, यह अच्छा नहीं था। 99,9% अपटाइम को 200 से गुणा करने पर हमें 0% उपलब्धता प्राप्त हुई। इससे पता चलता है कि यह वास्तुकला शुरू से ही विफलता के लिए अभिशप्त थी।

हमने डेवलपर्स से पूछा कि 18 महीने के काम के बाद वे इस समस्या को पहचानने में कैसे असफल रहे? यह पता चला कि उन्होंने केवल अपने द्वारा चलाए गए कोड के लिए SLA की गणना की, लेकिन यदि उनकी सेवा किसी अन्य सेवा को कॉल करती है, तो उन्होंने उस समय को अपने SLA में नहीं गिना। एक प्रक्रिया के भीतर लॉन्च की गई हर चीज़ 150 एमएस के मान का पालन करती है, लेकिन अन्य सेवा प्रक्रियाओं तक पहुंच ने कुल विलंब को कई गुना बढ़ा दिया है। इससे सीखा गया पहला सबक यह था: "क्या आप अपने एसएलए के नियंत्रण में हैं, या एसएलए आपके नियंत्रण में है?" हमारे मामले में, यह बाद वाला था।

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

यदि आप पिछली तस्वीर में सेवा सीमाओं को देखें, तो आप देख सकते हैं कि वे सभी गलत हैं। ऐसे बहुत से स्रोत हैं जो सलाह देते हैं कि सेवा सीमाओं को कैसे परिभाषित किया जाए, और अधिकांश इसे गलत करते हैं, जैसे कि अगली स्लाइड में Microsoft।

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

यहां दो वेब सर्वरों के बीच ट्रैफिक वितरित करने के लिए एक लोड बैलेंसर आता है, एक कैश वेब सेवा और बिजनेस लॉजिक के बीच स्थित होता है, और दूसरा कैश बिजनेस लॉजिक और डेटाबेस के बीच स्थित होता है। यह बिल्कुल वैसा ही आर्किटेक्चर है जिसका उपयोग बेल ने 2000 के दशक के मध्य में अपने लोड संतुलन और नीले/हरे परिनियोजन अनुप्रयोग के लिए किया था। कुछ समय तक सब कुछ ठीक रहा, क्योंकि यह योजना एक अखंड संरचना के लिए बनाई गई थी।

निम्न चित्र दिखाता है कि कैसे एमएस एक मोनोलिथ से माइक्रोसर्विसेज की ओर बढ़ने की सलाह देता है - बस प्रत्येक मुख्य सेवा को अलग-अलग माइक्रोसर्विसेज में विभाजित करें। इस योजना के क्रियान्वयन के दौरान ही बेल से गलती हो गयी.

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

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

उनका मानना था कि माइक्रोसर्विसेज में जाना उनके आंतरिक एन-टियर भौतिक परत के बुनियादी ढांचे को लेने और उस पर डॉकर को चिपकाने जितना आसान था। आइए देखें कि पारंपरिक एन-स्तरीय वास्तुकला कैसी दिखती है।

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

मैंने इस वास्तुकला में परिवर्तन के विभिन्न क्षेत्रों, जिम्मेदारी के विभिन्न क्षेत्रों को देखने का प्रयास किया। एक विशिष्ट एन-स्तरीय अनुप्रयोग में, परिवर्तन के विभिन्न क्षेत्रों को वर्गीकृत किया जाता है जो संरचना में ऊपर से नीचे तक लंबवत रूप से व्याप्त होते हैं। ये कैटलॉग, अलग-अलग कंप्यूटरों पर निष्पादित कॉन्फिग सेटिंग्स और चेकआउट चेक हैं, जिन्हें मेरी टीम द्वारा नियंत्रित किया गया था।

इस योजना की ख़ासियत यह है कि परिवर्तन के इन क्षेत्रों की सीमाएँ न केवल व्यावसायिक तर्क स्तर को प्रभावित करती हैं, बल्कि डेटाबेस तक भी विस्तारित होती हैं।

आइए देखें कि सेवा होने का क्या अर्थ है। सेवा परिभाषा के 6 विशिष्ट गुण हैं - यह सॉफ्टवेयर है जो:

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

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

आइए अब माइक्रोसर्विसेज की परिभाषा देखें:

एक माइक्रोसर्विस आकार में छोटी होती है और एक विशिष्ट समस्या को हल करने के लिए डिज़ाइन की जाती है;
माइक्रोसर्विस स्वायत्त है;
माइक्रोसर्विस आर्किटेक्चर बनाते समय, टाउन प्लानिंग रूपक का उपयोग किया जाता है। यह सैम न्यूमैन की पुस्तक, बिल्डिंग माइक्रोसर्विसेज की परिभाषा है।

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

सीधे शब्दों में कहें तो, एक Bounded Context उस दायरे को दर्शाता है जिसमें एक विशेष मॉड्यूल का उपयोग किया जा सकता है। इस संदर्भ में एक तार्किक रूप से एकीकृत मॉडल है जिसे उदाहरण के लिए, आपके व्यावसायिक डोमेन में देखा जा सकता है। यदि आप ऑर्डर में शामिल कर्मियों से पूछते हैं कि "ग्राहक कौन है", तो आपको एक परिभाषा मिलेगी, यदि आप बिक्री में शामिल लोगों से पूछते हैं, तो आपको दूसरी मिलेगी, और निष्पादक आपको तीसरी परिभाषा देंगे।

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

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

इसलिए हमने बेल कंप्यूटर्स के लोगों से कहा, "आपने जो अराजकता पैदा की है, उसे हम ठीक नहीं कर सकते क्योंकि आपके पास इसे करने के लिए पैसे नहीं हैं, लेकिन हम इसे पूरा करने के लिए केवल एक सेवा को ठीक कर देंगे।" समझ।" इस बिंदु पर, मैं आपको यह बताकर शुरुआत करूंगा कि हमने अपनी एकमात्र सेवा को कैसे ठीक किया ताकि वह साढ़े नौ मिनट से भी अधिक तेजी से अनुरोधों का जवाब दे सके।

22:30 मि

बहुत जल्द जारी रखा जाएगा...

थोड़ा विज्ञापन

हमारे साथ रहने के लिए धन्यवाद। क्या आप हमारे लेख पसंद करते हैं? अधिक रोचक सामग्री देखना चाहते हैं? आदेश देकर या मित्रों को अनुशंसा करके हमारा समर्थन करें, डेवलपर्स के लिए क्लाउड VPS $4.99 से शुरू, प्रवेश स्तर के सर्वरों का एक अनूठा एनालॉग, जिसका आविष्कार हमने आपके लिए किया था: VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps के बारे में पूरी सच्चाई $19 से या सर्वर कैसे साझा करें? (RAID1 और RAID10 के साथ उपलब्ध, 24 कोर तक और 40GB DDR4 तक)।

एम्स्टर्डम में इक्विनिक्स टियर IV डेटा सेंटर में Dell R730xd 2x सस्ता है? केवल यहां 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 टीवी $199 से नीदरलैंड में! डेल R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 से! के बारे में पढ़ा इन्फ्रास्ट्रक्चर कॉर्प का निर्माण कैसे करें। एक पैसा के लिए 730 यूरो मूल्य के डेल R5xd E2650-4 v9000 सर्वर के उपयोग के साथ वर्ग?

स्रोत: www.habr.com

एनडीसी लंदन सम्मेलन। माइक्रोसर्विस आपदा को रोकना। भाग ---- पहला

थोड़ा विज्ञापन

एक टिप्पणी जोड़ें उत्तर रद्द