वितरित सिस्टम। डिजाइन पैटर्न। पुस्तक की समीक्षा

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



अच्छा पढ़ा है।

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

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

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

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

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

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

मुझे लगता है कि बर्न्स पूरी तरह से पूरे माइक्रोसॉर्स्क परिदृश्य के "सपने" को स्पष्ट करने में सक्षम थे:

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

टीम के आकार को कम करने से इसकी गतिविधियों को बनाए रखने की लागत भी कम हो जाती है।

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

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

(रूसी अनुवाद में 79 ९-79०)

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

अंत में, मैं FaaS अवधारणा पर स्पर्श करना चाहूंगा - "सेवाओं के रूप में कार्य"। अमेजन की लैंबडा सर्विस जैसे सिस्टम मुझे मिश्रित महसूस कराते हैं। एक अत्यंत सारगर्भित अर्थ में, मैं इस तरह की प्रणालियों को पसंद करता हूं, लेकिन मुझे नहीं पता कि वे एक विशेष अनुप्रयोग में खुद को कैसे प्रकट करते हैं। भाग II में FaaS पर "डिजाइनिंग सर्विंग सिस्टम के पैटर्न" को स्पर्श किया गया है, लेकिन दुर्भाग्य से यह मेरे लिए Faas समस्या को पूरी तरह से स्पष्ट नहीं करता है।

मुझे वास्तव में पसंद आया कि बर्न्स ज्ञात मुद्दों के केवल सबसेट को हल करने के लिए FaaS का उपयोग करने की सलाह देते हैं:

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

(रूसी अनुवाद में पी। 135)

इसके अलावा, FaaS का उपयोग करते समय आने वाली कठिनाइयों का उल्लेख करने के लिए उन्हें बहुत धन्यवाद:

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

(रूसी अनुवाद में 136-137)

फिर से, मैं इस तथ्य से हैरान था कि अधिकांश फास-सिस्टम उन कार्यों को हल करने के लिए बहुत अच्छे नहीं हैं जिन्हें सक्रिय प्रसंस्करण की आवश्यकता होती है:

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

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

(रूसी अनुवाद में 139-140)

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

मैं इन मुद्दों से बेहतर तरीके से निपटने की उम्मीद करता हूं जब मुझे व्यवहार में एफएएएस तकनीकों का उपयोग करने के लिए मिलता है।

FaaS के साथ कुछ भ्रम के अलावा, मुझे वास्तव में पुस्तक पसंद आई। यह जल्दी से पढ़ा जाता है, आसानी से माना जाता है। यह एक बार फिर हमें अनुप्रयोग विकास के सभी स्तरों पर घटकों के बीच संबंध को कमजोर करने की विशाल क्षमता की याद दिलाता है। अंत में, अब मेरे लिए "सिडकार कंटेनर" जैसे विषयों पर अपने सहयोगियों के साथ बातचीत जारी रखना बहुत आसान हो जाएगा।