सर्विस मेश: हॉटेस्ट टेक्नोलॉजी के बारे में हर सॉफ्टवेयर इंजीनियर को क्या जानना चाहिए

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

से हास्य सेबस्टियन कैसरेस

परिचय

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

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

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

मैं कौन हूँ?

नमस्ते! मेरा नाम है विलियम मॉर्गन. मैं रचनाकारों में से एक हूं लिंकरड - बहुत पहले सर्विस मेश प्रोजेक्ट और प्रोजेक्ट जो शब्द की उपस्थिति के लिए जिम्मेदार है सेवा जाल जैसे (क्षमा करें दोस्तों!)। (नोट अनुवाद।: वैसे, इस शब्द की उपस्थिति के भोर में, 2,5 साल से अधिक पहले, हम पहले से ही उसी लेखक की प्रारंभिक सामग्री का अनुवाद कर चुके हैं जिसे "" कहा जाता है।सेवा जाल क्या है और मुझे इसकी आवश्यकता क्यों है [माइक्रोसर्विसेज के साथ क्लाउड एप्लिकेशन के लिए]?"।) मैं भी नेतृत्व करता हूं प्रसन्नचित्त एक स्टार्टअप है जो Linkerd और जैसी कूल सर्विस मेश चीजें बनाता है डुबकी.

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

ठीक है, यह व्यवहार पर आगे बढ़ने का समय है।

सेवा जाल क्या है?

सभी प्रचार के बावजूद, सेवा जाल संरचनात्मक रूप से काफी सरल है। यह "सेवाओं के बगल में" स्थित यूजरस्पेस प्रॉक्सी का एक गुच्छा है (हम बाद में "निकट" के बारे में थोड़ी बात करेंगे), साथ ही नियंत्रण प्रक्रियाओं का एक सेट। प्रॉक्सी को सामूहिक रूप से बुलाया जाता है डेटा प्लेन, और नियंत्रण प्रक्रियाओं को कहा जाता है विमान नियंत्रण. डेटा प्लेन सेवाओं के बीच कॉल को स्वीकार करता है और उनके साथ "कुछ अलग" करता है; नियंत्रण तल, क्रमशः, प्रॉक्सी के व्यवहार का समन्वय करता है और आपके लिए पहुँच प्रदान करता है, अर्थात ऑपरेटर, एपीआई के लिए, नेटवर्क को हेरफेर करने और समग्र रूप से मापने की अनुमति देता है।

यह प्रॉक्सी क्या है? यह "परत 7-जागरूक" श्रेणी का एक टीसीपी प्रॉक्सी है (अर्थात् OSI मॉडल की 7वीं परत को "ध्यान में रखते हुए") जैसे हैप्रोक्सी और एनजीआईएनएक्स। आप अपनी पसंद के अनुसार प्रॉक्सी चुन सकते हैं; Linkerd एक रस्ट प्रॉक्सी का उपयोग करता है, जिसका नाम सरल है linkerd-प्रॉक्सी. हमने इसे विशेष रूप से सर्विस मेश के लिए संकलित किया है। अन्य जाल अन्य परदे के पीछे पसंद करते हैं (दूत एक सामान्य पसंद है)। हालाँकि, प्रॉक्सी चुनना केवल कार्यान्वयन की बात है।

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

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

नीचे Linkerd में कंट्रोल प्लेन और डेटा प्लेन का आरेख है। जैसा कि आप देख सकते हैं, नियंत्रण विमान में कई अलग-अलग घटक शामिल हैं, जिसमें प्रोमेथियस उदाहरण शामिल है जो प्रॉक्सी सर्वर से मेट्रिक्स एकत्र करता है, साथ ही साथ अन्य घटक जैसे destination (सेवा खोज), identity (सर्टिफिकेट अथॉरिटी, सीए) और public-api (वेब और सीएलआई के लिए अंतिम बिंदु)। इसके विपरीत, डेटा प्लेन एप्लिकेशन इंस्टेंस के बगल में एक साधारण लिंकर-प्रॉक्सी है। यह सिर्फ एक लॉजिक डायग्राम है; एक वास्तविक दुनिया परिनियोजन में, आपके पास डेटा प्लेन में प्रत्येक कंट्रोल प्लेन घटक की तीन प्रतिकृतियां और सैकड़ों या हजारों प्रॉक्सी हो सकते हैं।

(इस चित्र में नीले बॉक्स कुबेरनेट्स पॉड्स की सीमाओं का प्रतिनिधित्व करते हैं। आप देख सकते हैं कि लिंकरड-प्रॉक्सी वाले कंटेनर उसी पॉड में हैं जिसमें एप्लिकेशन कंटेनर हैं। इस योजना को इस रूप में जाना जाता है साइडकार कंटेनर.)

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

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

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

सामान्य तौर पर, सर्विस मेश इस तरह दिखता है (कम से कम एक विहंगम दृश्य से): आप यूजरस्पेस प्रॉक्सी का एक समूह तैनात करते हैं जो आंतरिक, इंटर-सर्विस ट्रैफिक के साथ "कुछ करते हैं", और उनकी निगरानी और प्रबंधन के लिए कंट्रोल प्लेन का उपयोग करते हैं।

यह सवाल का समय है "क्यों?"

सेवा जाल किसके लिए है?

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

इस प्रश्न के उत्तर के दो भाग हैं। सबसे पहले, पारिस्थितिकी तंत्र में होने वाले कुछ बदलावों के कारण इन प्रॉक्सी को तैनात करने से जुड़ी लेनदेन लागत को काफी कम किया जा सकता है (इस पर बाद में)।

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

उदाहरण के लिए, Linkerd में (अधिकांश मेश में) कार्यक्षमता मुख्य रूप से HTTP कॉल पर केंद्रित है, जिसमें HTTP/2 और gRPC* शामिल हैं। कार्यक्षमता काफी समृद्ध है - इसे तीन वर्गों में विभाजित किया जा सकता है:

1. संबंधित विशेषताएं विश्वसनीयता. पुन: प्रयास अनुरोध, टाइमआउट, कैनरी दृष्टिकोण (यातायात विभाजन/रीडायरेक्ट), आदि।
2. संबंधित विशेषताएं निगरानी. प्रत्येक सेवा या अलग-अलग गंतव्यों के लिए सफलता दर, देरी और अनुरोध मात्रा का एकत्रीकरण; सेवाओं के सामयिक मानचित्रों का निर्माण, आदि।
3. संबंधित विशेषताएं सुरक्षा. म्युचुअल टीएलएस, अभिगम नियंत्रण, आदि।

* लिंकरड के दृष्टिकोण से, जीआरपीसी व्यावहारिक रूप से एचटीटीपी/2 से अलग नहीं है: यह केवल पेलोड में प्रोटोबॉफ़ का उपयोग करता है। एक डेवलपर के दृष्टिकोण से, ये दोनों चीजें निश्चित रूप से अलग हैं।

इनमें से कई तंत्र अनुरोध स्तर पर काम करते हैं (इसलिए "L7 प्रॉक्सी")। उदाहरण के लिए, यदि सेवा फू सेवा बार के लिए एक HTTP कॉल करता है, तो फू की ओर से लिंकरड-प्रॉक्सी समझदारी से लोड-बैलेंस कर सकता है और देखे गए विलंबता के आधार पर फू से बार उदाहरणों को रूट कर सकता है; यदि आवश्यक हो तो यह अनुरोध दोहरा सकता है (और यदि यह बेकार है); वह प्रतिक्रिया कोड और टाइमआउट रिकॉर्ड कर सकता है, और इसी तरह। इसी तरह, बार साइड पर लिंकर-प्रॉक्सी एक अनुरोध को अस्वीकार कर सकता है यदि इसकी अनुमति नहीं है या यदि अनुरोध सीमा पार हो गई है; अपनी ओर से देरी को ठीक कर सकता है, आदि।

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

* "मित्र का मित्र" का अर्थ है कि ग्राहक का प्रमाणपत्र भी सत्यापित है (पारस्परिक टीएलएस)। "क्लासिक" टीएलएस में, उदाहरण के लिए, एक ब्राउज़र और एक सर्वर के बीच, आमतौर पर केवल एक तरफ (सर्वर) का प्रमाण पत्र सत्यापित होता है।

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

यह सर्विस मेश द्वारा प्रदान की जाने वाली सुविधाओं का सेट है। सवाल उठता है: उन्हें सीधे आवेदन में लागू क्यों नहीं किया जाता? और एक प्रॉक्सी के साथ खिलवाड़ क्यों?

सर्विस मेश क्यों एक अच्छा विचार है

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

आइए इस प्रस्ताव का विश्लेषण करें।

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

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

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

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

संक्षेप में, सेवा जाल न केवल महत्वपूर्ण कार्यक्षमता प्रदान करता है, बल्कि यह वैश्विक, समान और अनुप्रयोग-स्वतंत्र तरीके से ऐसा करता है। और इसलिए, जबकि सेवा जाल की कार्यक्षमता सेवा कोड में लागू की जा सकती है (उदाहरण के लिए, प्रत्येक सेवा के साथ शामिल एक पुस्तकालय के रूप में), यह दृष्टिकोण एकरूपता और स्वतंत्रता प्रदान नहीं करेगा जो सेवा जाल के मामले में बहुत मूल्यवान है .

और आपको बस इतना करना है कि प्रॉक्सी का एक गुच्छा जोड़ें! मैं वादा करता हूं, बहुत जल्द हम इन प्रॉक्सी को जोड़ने से जुड़ी परिचालन लागतों को देखेंगे। लेकिन पहले, आइए रुकें और स्वतंत्रता के इस विचार को विभिन्न दृष्टिकोणों से देखें लोग.

सर्विस मेश किसकी मदद करता है?

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

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

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

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

प्लेटफार्मों और सेवाओं के मालिकों के बीच इस तरह के विभाजन के संगठनात्मक मूल्य को कम करके आंका नहीं जा सकता है। मुझे लगता है कि वह योगदान करती है मुख्य सेवा जाल के मूल्य में योगदान।

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

संक्षेप में, सेवा जाल तकनीकी समाधान नहीं है, बल्कि है सामाजिक तकनीकी समस्याओं। (धन्यवाद सिंडी श्रीधरन इस शब्द को पेश करने के लिए।

क्या सेवा जाल मेरी सभी समस्याओं का समाधान करेगा?

हाँ। मेरा मतलब है नहीं!

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

सर्विस मेश द्वारा पेश किए जाने वाले इन क्षेत्रों में सुविधाओं का एक सबसेट संबंधित है मंच सुविधाएँ. इससे मेरा तात्पर्य ऐसे कार्यों से है जो:

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

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

सेवा जाल क्षमताओं के उदाहरण

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

सर्विस मेश अभी लोकप्रिय क्यों हो गया है?

आप शायद अभी सोच रहे हैं: ठीक है, अगर सर्विस मेश इतना अच्छा है, तो हमने दस साल पहले स्टैक पर लाखों प्रॉक्सी तैनात करना क्यों शुरू नहीं किया?

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

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

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

इस प्रकार, दस साल पहले न केवल माइक्रोसर्विसेज थे, बल्कि विशेष प्रोटो-सर्विस-मेश लाइब्रेरी भी थीं, जो उन्हीं समस्याओं को हल करती थीं, जो आज सर्विस मेश हल करती हैं। हालाँकि, सेवा जाल स्वयं तब मौजूद नहीं था। उनके आने से पहले एक और पारी होनी थी।

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

आइए वर्तमान में चलते हैं। आज ऐसे स्टार्टअप हैं जहां डेवलपर्स के लिए माइक्रोसर्विसेज का अनुपात 5: 1 (या यहां तक ​​​​कि 10:1), और इसके अलावा, वे सफलतापूर्वक उनका सामना करते हैं! यदि 5 लोगों का एक स्टार्टअप बिना तनाव के 50 माइक्रोसर्विसेज संचालित करने में सक्षम है, तो कुछ स्पष्ट रूप से उनके कार्यान्वयन की लागत को कम कर देता है।

मोन्जो में 1500 माइक्रोसर्विसेज; प्रत्येक पंक्ति एक निर्धारित नेटवर्क नियम है जो यातायात की अनुमति देता है

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

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

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

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

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

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

सर्विस मेश के बारे में इतनी चर्चा क्यों है?

चेतावनी: इस खंड में, मैं सभी प्रकार की धारणाओं, अनुमानों, मनगढ़ंत बातों और आंतरिक सूचनाओं का सहारा लेता हूं।

"सेवा जाल" की खोज करने से पुनर्नवीनीकरण, कम कैलोरी सामग्री, विषम परियोजनाओं और एक प्रतिध्वनि कक्ष के योग्य विकृति का एक बहुरूपदर्शक बन जाएगा। किसी भी आधुनिक नई तकनीक में यह है, लेकिन सेवा जाल के मामले में समस्या विशेष रूप से तीव्र है। क्यों?

खैर, यह आंशिक रूप से मेरी गलती है। मैंने इस तरह के अनगिनत ब्लॉग पोस्ट और लेखों के माध्यम से हर अवसर पर लिंकरड और सेवा जाल को बढ़ावा देने की पूरी कोशिश की है। लेकिन मैं इतना शक्तिशाली नहीं हूँ। वास्तव में इस प्रश्न का उत्तर देने के लिए, हमें सामान्य स्थिति के बारे में थोड़ी बात करने की आवश्यकता है। और एक परियोजना का उल्लेख किए बिना इसके बारे में बात करना असंभव है: Istio Google, IBM और Lyft द्वारा संयुक्त रूप से विकसित एक ओपन सोर्स सर्विस मेश है।

(उन तीन कंपनियों की बहुत अलग भूमिकाएँ हैं: Lyft की भागीदारी केवल नाम तक सीमित प्रतीत होती है; वे Envoy को लिखते हैं लेकिन Istio के विकास में शामिल नहीं हैं या उपयोग नहीं करते हैं। IBM Istio के विकास में शामिल है और इसका उपयोग करता है। Google भारी है Istio के विकास में शामिल है, लेकिन जहाँ तक मैं बता सकता हूँ, वास्तव में इसका उपयोग नहीं करता है।)

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

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

ऐसा क्यों हुआ, इसके बारे में अपने सिद्धांतों को छोड़कर, मेरा मानना ​​है कि सेवा जाल के चारों ओर ऑफ-स्केल प्रचार Google की भागीदारी के कारण है। अर्थात्, निम्नलिखित तीन कारकों का एक संयोजन:

1. Google द्वारा इस्तियो का जुनूनी प्रचार;
2. परियोजना के प्रति उचित अस्वीकृति, आलोचनात्मक रवैया;
3. कुबेरनेट्स की हाल की आसमान छूती लोकप्रियता, जिसकी यादें अभी भी ताज़ा हैं।

साथ में, ये कारक एक प्रकार के नशीले, अनॉक्सी वातावरण में विलीन हो जाते हैं जिसमें तर्कसंगत निर्णय लेने की क्षमता कम हो जाती है, केवल एक विचित्र किस्म की ट्यूलिप उन्माद.

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

लिंकरड की ओर से, हमारी रणनीति यह रही है कि शोर को अनदेखा किया जाए, समुदाय में वास्तविक समस्याओं को हल करने पर ध्यान केंद्रित किया जाए, और अनिवार्य रूप से प्रचार के कम होने की प्रतीक्षा की जाए। आखिरकार प्रचार कम हो जाएगा और हम शांति से काम करना जारी रख सकते हैं।

तब तक हम सभी को धैर्य रखना होगा।

क्या सेवा जाल मेरे लिए उपयोगी होगा, एक मामूली सॉफ्टवेयर इंजीनियर?

निम्नलिखित प्रश्नावली इस प्रश्न का उत्तर देने में मदद करेगी:

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

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

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

क्या आप मोनोलिथ्स के साथ काम करने वाली कंपनी के प्लेटफॉर्म के प्रभारी हैं? इस मामले में, आपको संभवतः सर्विस मेश की आवश्यकता नहीं है। यदि आप मोनोलिथ (या यहां तक ​​कि मोनोलिथ के संग्रह) के साथ काम कर रहे हैं, जिसमें अच्छी तरह से परिभाषित और शायद ही कभी बदलते इंटरैक्शन पैटर्न हैं, तो सर्विस मेश के पास आपको पेश करने के लिए बहुत कम है। तो आप इसे अनदेखा कर सकते हैं और उम्मीद कर सकते हैं कि यह एक बुरे सपने की तरह गायब हो जाएगा...

निष्कर्ष

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

मैं चाहता हूं कि आप लिंकरड को आजमाएं - इसे कुबेरनेट्स क्लस्टर (या यहां तक ​​कि लैपटॉप पर मिनिक्यूब) में स्थापित करें लगभग 60 सेकंड लगते हैंऔर आप खुद देख सकते हैं कि मैं किस बारे में बात कर रहा हूं।

सामान्य प्रश्न

- अगर मैं सर्विस मेश को अनदेखा कर दूं, तो क्या यह गायब हो जाएगा?
- मुझे आपको निराश करना चाहिए: सेवा जाल लंबे समय से हमारे साथ है।

- लेकिन मैं सर्विस मेश का उपयोग नहीं करना चाहता!
- ठीक है, यह जरूरी नहीं है! यह देखने के लिए ऊपर दी गई मेरी प्रश्नावली को पढ़ें कि क्या आपको कम से कम इसकी मूल बातों से परिचित होना चाहिए।

- क्या यह नए सॉस के साथ अच्छा पुराना ईएसबी/मिडलवेयर नहीं है?
- सर्विस मेश ऑपरेशनल लॉजिक से संबंधित है, सिमेंटिक नहीं। यह मुख्य कमी थी उद्यम सेवा बस (ESB). इस अलगाव को बनाए रखने से सर्विस मेश को उसी भाग्य से बचने में मदद मिलती है।

- सर्विस मेश एपीआई गेटवे से कैसे अलग है?
इस विषय पर एक लाख लेख हैं। बस गूगल।

क्या दूत एक सेवा जाल है?
- नहीं, Envoy एक सर्विस मेश नहीं है, यह एक प्रॉक्सी सर्वर है। इसका उपयोग सेवा जाल को व्यवस्थित करने के लिए किया जा सकता है (और भी बहुत कुछ - यह एक सामान्य प्रयोजन प्रॉक्सी है)। लेकिन अपने आप में, यह एक सर्विस मेश नहीं है।

- नेटवर्क सर्विस मेश - क्या यह सर्विस मेश है?
- नहीं। नाम के बावजूद, यह एक सेवा जाल नहीं है (आपको मार्केटिंग के चमत्कार कैसे पसंद हैं?)

- क्या संदेश कतार के आधार पर सेवा जाल मेरी प्रतिक्रियाशील अतुल्यकालिक प्रणाली के साथ मदद करेगा?
- नहीं, सर्विस मेश आपकी मदद नहीं करेगा।

- मुझे किस सर्विस मेश का उपयोग करना चाहिए?
- लिंकरड, बिल्कुल आसान।

- लेख बेकार है! / लेखक - साबुन पर!
— कृपया इसका लिंक अपने सभी दोस्तों के साथ साझा करें ताकि उन्हें इस बात का यकीन हो सके!

स्वीकृतियाँ

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

जबकि मैं खुद को "लिंकरड डेवलपर" कहना पसंद करता हूं, वास्तविकता यह है कि मैं एक प्रोजेक्ट में README.md फ़ाइल का अनुरक्षक हूं। आज लिंकरड पर काम कर रहा हूं बहुत, बहुत, बहुत много लोग, और यह परियोजना योगदानकर्ताओं और उपयोगकर्ताओं के अद्भुत समुदाय के बिना संभव नहीं होती।

और अंत में, Linkerd के निर्माता को विशेष धन्यवाद, ओलिवर गोल्ड (प्राइमस इंटर पारेस), जिन्होंने कई साल पहले मेरे साथ सर्विस मेश के साथ इस सारे झंझट में सिर झुकाया था।

अनुवादक से पी.एस

हमारे ब्लॉग पर भी पढ़ें:

• «सेवा जाल क्या है और मुझे इसकी आवश्यकता क्यों है [माइक्रोसर्विसेज के साथ क्लाउड एप्लिकेशन के लिए]?";
• «ट्रैफिक 2.0: टीसीपी सपोर्ट और नए वेब इंटरफेस के साथ सर्विस मेश अपडेट";
• «Maesh - Traefik के लेखकों से कुबेरनेट्स के लिए एक नया सरल सेवा जाल";
• «इस्तियो के साथ माइक्रोसर्विसेज पर वापस जाएं। भाग ---- पहला";
• «कंड्यूट - कुबेरनेट्स के लिए हल्का सर्विस मेश'.

स्रोत: www.habr.com