सेवा जाल उपयोग परिदृश्य

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

आज सेवा जाल - सॉफ्टवेयर इंजीनियरिंग के क्षेत्र में सबसे चर्चित विषयों में से एक (और यह सही भी है!)। मुझे लगता है कि यह तकनीक अविश्वसनीय रूप से आशाजनक है और मैं इसे व्यापक होते देखना चाहता हूं (निश्चित रूप से जब यह समझ में आता है)। हालाँकि, अधिकांश लोगों के लिए यह अभी भी रहस्य की आभा से घिरा हुआ है। साथ ही, वे भी जो प्रसिद्ध इसके साथ, इसके फायदे और वास्तव में यह क्या है (वास्तव में आपका भी शामिल है) तैयार करना मुश्किल होता है। इस लेख में मैं विभिन्न को सूचीबद्ध करके स्थिति को ठीक करने का प्रयास करूंगा बक्सों का इस्तेमाल करें "सर्विस मेश"*.

* टिप्पणी अनुवाद: यहां और लेख में आगे बिल्कुल इसी अनुवाद ("सर्विस मेश") का उपयोग अभी भी नए शब्द सर्विस मेश के लिए किया जाएगा।

लेकिन पहले मैं कुछ टिप्पणियाँ करना चाहता हूँ:

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

संक्षिप्त सूची:

• सेवा खोज;
• कूटलेखन;
• सत्यापन और प्राधिकरण;
• भार का संतुलन;
• सर्किट टूटना;
• ऑटोस्केलिंग;
• कैनरी तैनाती;
• नीली-हरी तैनाती;
• स्वास्थ्य जांच;
• बिजली की कटौती;
• यातायात प्रतिबिम्बन;
• इन्सुलेशन;
• अनुरोध दर सीमित करना, पुनः प्रयास करना और टाइमआउट करना;
• टेलीमेट्री;
• अंकेक्षण;
• विज़ुअलाइज़ेशन.

1. सेवा खोज

टीएल;डीआर: सरल नामों का उपयोग करके नेटवर्क पर अन्य सेवाओं से कनेक्ट करें।

सेवाओं को पर्याप्त नामों का उपयोग करके स्वचालित रूप से एक-दूसरे को "ढूंढने" में सक्षम होना चाहिए - उदाहरण के लिए, service.api.production, pets/staging या cassandra. क्लाउड वातावरण लोचदार होते हैं, और एक ही नाम किसी सेवा के कई उदाहरण छिपा सकता है। यह स्पष्ट है कि ऐसी स्थिति में सभी आईपी पतों को हार्डकोड करना शारीरिक रूप से असंभव है।

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

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

2. एन्क्रिप्शन

टीएल;डीआर: सेवाओं के बीच अनएन्क्रिप्टेड ट्रैफ़िक से छुटकारा पाएं और इस प्रक्रिया को स्वचालित और स्केलेबल बनाएं।

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

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

3. प्रमाणीकरण और प्राधिकरण

टीएल;डीआर: स्थापित करें कि अनुरोधकर्ता कौन है और अनुरोध के सेवा तक पहुंचने से पहले परिभाषित करें कि उन्हें क्या करने की अनुमति है।

सेवाएँ अक्सर जानना चाहती हैं कौन अनुरोध (प्रमाणीकरण) निष्पादित करता है, और इस जानकारी का उपयोग करके निर्णय लेता है कि किसी दी गई इकाई को (प्राधिकरण) करने की अनुमति है। इस मामले में, सर्वनाम "कौन" छिपा सकता है:

1. अन्य सेवाएं। इसे "प्रमाणीकरण" कहा जाता है समकक्ष" उदाहरण के लिए, सेवा web सेवा तक पहुँच प्राप्त करना चाहता है db. सर्विस मेश आमतौर पर एमटीएलएस का उपयोग करके ऐसी समस्याओं का समाधान करते हैं: इस मामले में प्रमाणपत्र आवश्यक पहचानकर्ता के रूप में कार्य करते हैं।
2. कुछ मानव उपयोगकर्ता. इसे "प्रमाणीकरण" कहा जाता है अनुरोध" उदाहरण के लिए, उपयोगकर्ता haxor69 एक नया लैंप खरीदना चाहता है. सर्विस मेश विभिन्न तंत्र प्रदान करते हैं, जैसे JSON वेब कैम.

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

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

4. भार संतुलन

टीएल;डीआर: एक विशिष्ट पैटर्न के अनुसार लोड को सेवा उदाहरणों में वितरित करें।

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

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

5. सर्किट ब्रेकिंग

टीएल;डीआर: समस्याग्रस्त सेवा पर ट्रैफ़िक रोकें और सबसे खराब स्थिति में क्षति को नियंत्रित करें।

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

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

आप शायद सर्किट ब्रेकिंग का दुरुपयोग नहीं करना चाहेंगे, लेकिन यह जानकर अच्छा लगा कि आपातकालीन स्थिति में आपके पास बैकअप योजना है।

6. ऑटोस्केलिंग

टीएल;डीआर: निर्दिष्ट मानदंडों के आधार पर सेवा उदाहरणों की संख्या बढ़ाएं या घटाएं।

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

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

7. कैनरी तैनाती

टीएल;डीआर: उपयोगकर्ताओं के एक उपसमूह पर नई सुविधाओं या सेवा संस्करणों का परीक्षण करें।

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

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

8. नीली-हरी तैनाती

टीएल;डीआर: एक शानदार नई सुविधा शुरू करें, लेकिन सब कुछ तुरंत वापस लेने के लिए तैयार रहें।

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

सर्विस मेश "नीली" सेवा का परीक्षण करने और समस्याओं के मामले में तुरंत काम करने वाली "हरी" सेवा पर स्विच करने का एक बहुत ही सुविधाजनक तरीका प्रदान करते हैं। इस तथ्य का उल्लेख नहीं करने के लिए कि रास्ते में वे "ब्लू" के काम के बारे में बहुत सारी जानकारी (नीचे "टेलीमेट्री" देखें) प्रदान करते हैं, जो यह समझने में मदद करती है कि क्या यह पूर्ण संचालन के लिए तैयार है।

टिप्पणी। अनुवाद।: आप कुबेरनेट्स (उल्लिखित कैनरी, ब्लू/ग्रीन और अन्य सहित) में विभिन्न तैनाती रणनीतियों के बारे में अधिक पढ़ सकते हैं यह लेख.

9. स्वास्थ्य जांच

टीएल;डीआर: इस बात पर नज़र रखें कि कौन सी सेवा इंस्टेंसेस क्रियाशील हैं और उन पर प्रतिक्रिया दें जो अब क्रियाशील नहीं हैं।

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

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

10. लोड शेडिंग

टीएल;डीआर: उपयोग में अस्थायी वृद्धि के जवाब में ट्रैफ़िक को पुनर्निर्देशित करें।

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

11. यातायात समानांतरीकरण/मिररिंग

टीएल;डीआर: एक अनुरोध को एक साथ कई स्थानों पर भेजें।

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

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

12. इन्सुलेशन

टीएल;डीआर: अपने सेवा जाल को मिनी-नेटवर्क में तोड़ें।

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

इसके अलावा, लाभ संगठनात्मक भी हो सकते हैं। हो सकता है कि आप अपनी कंपनी की संरचना के आधार पर अपनी सेवाओं को सबनेट करना चाहें और डेवलपर्स को संपूर्ण सेवा जाल को ध्यान में रखने के संज्ञानात्मक भार से राहत देना चाहें।

13. अनुरोध दर सीमित करना, पुनः प्रयास करना और टाइमआउट करना

टीएल;डीआर: अब आपको अपने कोडबेस में विस्तृत अनुरोध प्रबंधन कार्यों को शामिल करने की आवश्यकता नहीं है।

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

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

14. टेलीमेट्री

टीएल;डीआर: सेवाओं से सभी आवश्यक (और बिल्कुल नहीं) जानकारी एकत्र करें।

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

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

• सीएलआई में एक निश्चित सेवा से टेल लॉग;
• सर्विस मेश डैशबोर्ड से अनुरोधों की मात्रा की निगरानी करें;
• वितरित अंश एकत्र करें और उन्हें जैगर जैसे सिस्टम पर अग्रेषित करें।

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

15. लेखापरीक्षा

टीएल;डीआर: जो लोग इतिहास के सबक भूल जाते हैं वे उन्हें दोहराने के लिए अभिशप्त होते हैं।

ऑडिटिंग किसी सिस्टम में महत्वपूर्ण घटनाओं का अवलोकन करने की कला है। सेवा जाल के मामले में, इसका मतलब यह हो सकता है कि किसने विशिष्ट सेवाओं के लिए विशिष्ट समापन बिंदुओं पर अनुरोध किया, या पिछले महीने में कितनी बार सुरक्षा से संबंधित कोई घटना हुई।

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

16. विज़ुअलाइज़ेशन

टीएल;डीआर: लंबे समय तक जीवित रहने वाले रिएक्ट.जेएस - फैंसी इंटरफेस का एक अटूट स्रोत।

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

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

सूची में शामिल नहीं थे

मूल रूप से मेरा इरादा सूची में कुछ और उपयोग के मामलों को शामिल करने का था, लेकिन फिर मैंने ऐसा न करने का निर्णय लिया। मेरे निर्णय के कारणों सहित वे यहां हैं:

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

निष्कर्ष

अभी के लिए इतना ही! फिर, यह सूची बहुत मनमानी है और संभवतः अधूरी है। अगर आपको लगता है कि मुझसे कुछ छूट गया है या कुछ गलत हो गया है, तो कृपया मुझसे ट्विटर पर संपर्क करें (@luckerkins). कृपया शालीनता के नियमों का सम्मान करें।

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

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

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

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

स्रोत: www.habr.com