इंटरनेट पर सेवा जाल पर बहुत सारे लेख हैं , और यहाँ एक और एक है। हुर्रे! लेकिन क्यों? फिर, जो मैं अपनी राय व्यक्त करना चाहता हूं, वह बेहतर होगा अगर 10 साल पहले सर्विस मेशर्स डॉकटर और कुबेरनेट्स जैसे कंटेनर प्लेटफार्मों के उद्भव से पहले दिखाई दें। मैं यह दावा नहीं करता कि मेरा दृष्टिकोण दूसरों की तुलना में बेहतर या बुरा है, लेकिन चूंकि सेवा जाल काफी जटिल जानवर हैं, इसलिए दृष्टिकोण की बहुलता उन्हें बेहतर ढंग से समझने में मदद करेगी।

मैं डॉटक्लाउड प्लेटफॉर्म के बारे में बात करूंगा, जो सौ से अधिक माइक्रोसर्विस पर बनाया गया था और कंटेनरों में हजारों अनुप्रयोगों का समर्थन करता था। मैं इसके विकास और लॉन्च के दौरान आने वाली समस्याओं के बारे में बताऊंगा, और सेवा जाल कैसे मदद कर सकता है (या नहीं कर सकता)।

डॉटक्लाउड का इतिहास

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

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

होस्ट किए गए एप्लिकेशन के लिए ट्रैफ़िक रूटिंग

डॉटक्लाउड एप्लिकेशन HTTP और TCP एंडपॉइंट प्रदान कर सकते हैं।

HTTP एंडपॉइंट्स को गतिशील रूप से हिपैच लोड बैलेंसर क्लस्टर कॉन्फ़िगरेशन में जोड़ा जाता है। यह कुबेरनेट्स इनग्रेडेशन संसाधनों और ट्रैफिक जैसे लोड बैलेंसर के समान है ।

ग्राहक अपने संबंधित डोमेन के माध्यम से HTTP एंडपॉइंट से कनेक्ट होते हैं, बशर्ते कि डोमेन नाम डॉटक्लोड लोड बैलेन्कर्स को इंगित करता है। कुछ खास नहीं।

टीसीपी एंडपॉइंट एक पोर्ट संख्या के साथ जुड़ा हुआ है, जो तब पर्यावरण चर के माध्यम से इस ढेर के सभी कंटेनरों को पारित किया जाता है।

ग्राहक उचित होस्टनाम (गेटवे-X.dotcloud.com जैसे कुछ) और पोर्ट नंबर का उपयोग करके टीसीपी के समापन बिंदुओं से जुड़ सकते हैं।

यह होस्ट नाम "nats" सर्वर क्लस्टर ( NATS से संबंधित नहीं) है, जो आने वाले टीसीपी कनेक्शनों को सही कंटेनर (या लोड-संतुलित सेवाओं के मामले में, सही कंटेनरों के लिए) तक ले जाएगा।

यदि आप कुबेरनेट्स से परिचित हैं, तो यह संभवतः आपको NodePort सेवाओं की याद दिलाएगा।

डॉटक्लाउड प्लेटफॉर्म पर ClusterIP सेवाओं के बराबर नहीं था: सादगी के लिए, सेवाओं तक पहुंच प्लेटफॉर्म के अंदर और बाहर दोनों से समान थी।

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

मौजूदा कोड की व्यापक रिफैक्टिंग की आवश्यकता नहीं थी। विशेष रूप से, 12-कारक अनुप्रयोग सीधे पर्यावरण चर के माध्यम से प्राप्त पते का उपयोग कर सकते हैं।

यह आधुनिक सेवा जाल से कैसे भिन्न है?

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

न केवल परिचालन के दृष्टिकोण से (समस्याओं के निवारण में मदद करने के लिए) दृश्यता महत्वपूर्ण है, बल्कि जब नई सुविधाएँ जारी की जाती हैं। यह एक सुरक्षित नीले-हरे रंग की तैनाती और कैनरी की तैनाती के बारे में है ।

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

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

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

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

प्लेटफ़ॉर्म सर्विसेज के लिए ट्रैफ़िक रूटिंग

ठीक है, हमने अनुप्रयोगों के बीच ट्रैफ़िक पर चर्चा की, लेकिन डॉटक्लाउड प्लेटफ़ॉर्म के बारे में क्या?

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

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

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

इन सेवाओं को एक सरल और कच्चे तरीके से उजागर किया गया था: उनके नाम और पते YAML फ़ाइल में सूचीबद्ध थे; और प्रत्येक क्लाइंट को परिनियोजन के लिए इस YAML फ़ाइल की एक प्रति लेनी थी।

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

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

(यह भी टीएलएस कनेक्शनों में ट्रैफ़िक को एनकैप्सुलेट करने और रिसीविंग साइड पर एक और प्रॉक्सी सर्वर लगाने की योजना बनाई गई थी, साथ ही साथ टीएलएस सर्टिफिकेट्स को प्राप्त करने वाले सेवा की भागीदारी के बिना जाँचें, जिसे केवल localhost पर कनेक्शन स्वीकार करने के लिए कॉन्फ़िगर किया गया है। इस पर बाद में)

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

मैं व्यक्तिगत रूप से स्मार्टस्टैक को इस तरह के सिस्टम के पूर्ववर्तियों में से एक के रूप में मानता हूं जैसे कि इस्तियो, लिंकरड और कौंसल कनेक्ट, क्योंकि वे सभी एक ही पैटर्न का पालन करते हैं:

• प्रत्येक नोड पर चल रहा है।
  
• ग्राहक प्रॉक्सी से जुड़ते हैं।
  
• बैकएंड बदलते समय प्रबंधन विमान प्रॉक्सी कॉन्फ़िगरेशन को अपडेट करता है।
  
• ... लाभ!

एक सेवा जाल का आधुनिक कार्यान्वयन

यदि हमें आज एक समान ग्रिड को लागू करने की आवश्यकता है, तो हम समान सिद्धांतों का उपयोग कर सकते हैं। उदाहरण के लिए, 127.0.0.0/8 में पते के लिए सेवा नामों को मैप करके आंतरिक DNS ज़ोन को कॉन्फ़िगर करें। फिर क्लस्टर के प्रत्येक नोड पर HAProxy चलाएं, प्रत्येक सेवा पते (इस सबनेट में 127.0.0.0/8 ) को कनेक्शन स्वीकार करते हुए और लोड को संबंधित बैकेंड पर पुनर्निर्देशित / संतुलित करता है। HAProxy कॉन्फ़िगरेशन को confd द्वारा नियंत्रित किया जा सकता है, जिससे आप Incd या Consul में बैकएंड जानकारी संग्रहीत कर सकते हैं और आवश्यक होने पर अपडेट किए गए कॉन्फ़िगरेशन को HAProxy पर स्वचालित रूप से पुश कर सकते हैं।

यह कैसे काम करता है! लेकिन कुछ मतभेदों के साथ:

• HAProxy के बजाय Envoy प्रॉक्सी का उपयोग करता है।
  
• कॉर्डनेट या कॉन्सुल के बजाय कुबेरनेट्स एपीआई के माध्यम से बैकएंड कॉन्फ़िगरेशन को बचाता है।
  
• सेवाओं को 127.0.0.0/8 के बजाय आंतरिक सबनेट (Kubernetes ClusterIP पतों) पर पते आवंटित किए जाते हैं।
  
• क्लाइंट और सर्वर के बीच पारस्परिक TLS प्रमाणीकरण जोड़ने के लिए इसका एक वैकल्पिक घटक (गढ़) है।
  
• नई सुविधाएँ जैसे सर्किट ब्रेकिंग, डिस्ट्रीब्यूटेड ट्रेसिंग, कैनरीज़ की तैनाती, आदि।

आइए कुछ अंतरों पर एक नज़र डालें।

दूत छंद

Enftoy Proxy टैक्सी मार्केट में Lyft [Uber प्रतियोगी द्वारा लिखा गया था - लगभग। ट्रांस।]। यह कई मायनों में अन्य प्रॉक्सियों के समान है (उदाहरण के लिए, HAProxy, Nginx, Traefik ...), लेकिन Lyft ने खुद लिखा क्योंकि उन्हें ऐसे कार्यों की आवश्यकता थी जो अन्य प्रॉक्सी में नहीं हैं, और मौजूदा को विस्तारित करने की तुलना में एक नया बनाना अधिक उचित लगा।

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

लेकिन एनवॉय एक सेवा जाल के लिए डेटा प्लेन के रूप में भी काम करने में सक्षम है। इसका मतलब यह है कि इस सेवा जाल के लिए, Envoy अब नियंत्रण विमान द्वारा कॉन्फ़िगर किया गया है।

नियंत्रण विमान

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

मामले के बीच : मुझे व्यक्तिगत रूप से यह कुबेरनेट्स एपीआई विवरण उपयोगी लगा , जिसमें लिखा है:

कुबेरनेट्स एपीआई सर्वर एक "डंब सर्वर" है जो एपीआई संसाधनों के भंडारण, संस्करण, सत्यापन, अद्यतन, और शब्दार्थ प्रदान करता है।

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

सेवा संबोधन

इस्तियो क्लस्टरिप के पते पर निर्भर करता है जिसे कुबेरनेट आवंटित करता है, इसलिए इस्तियो सेवाओं को एक आंतरिक पता मिलता है (सीमा 127.0.0.0/8 में नहीं)।

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

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

कुबेरनेट्स डीएनएस के साथ एकीकृत होने पर, इसका मतलब है कि हमारा कोड सेवा के नाम से जुड़ सकता है, और सब कुछ "बस काम करता है।" दूसरे शब्दों में, हमारे कोड में http://api/v1/users/4242 जैसे अनुरोध जारी होते हैं, फिर api 10.97.105.48 अनुरोध को हल करता है, iptables नियम 10.97.105.48 से अवरोधन कनेक्शनों को जोड़ता है और उन्हें स्थानीय एनवॉय प्रॉक्सी पर रीडायरेक्ट करता है, और यह स्थानीय प्रॉक्सी को निर्देशित करेगा। वास्तविक बैकएंड एपीआई के लिए अनुरोध। ओह!

अतिरिक्त छोटी चीजें

Istio mTLS (म्यूचुअल टीएलएस) के माध्यम से एंड-टू-एंड एन्क्रिप्शन और प्रमाणीकरण भी प्रदान करता है। इसके लिए Citadel नामक घटक जिम्मेदार है।

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

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

विकसित या खरीदना

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

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

लेकिन अगर हमारे पास उन्नत आवश्यकताएं हैं, तो एक सेवा जाल "खरीदना" एक बेहतर विकल्प लगता है। (यह हमेशा एक "खरीद" नहीं है, क्योंकि इस्तियो ओपन सोर्स कोड के साथ आता है, लेकिन हमें अभी भी इसके काम को समझने, इसे तैनात करने और प्रबंधित करने के लिए इंजीनियरिंग समय का निवेश करने की आवश्यकता है)।

क्या चुनें: Istio, Linkerd या Consul कनेक्ट?

अब तक हमने केवल Istio के बारे में बात की है, लेकिन यह एकमात्र सेवा मेष नहीं है। एक लोकप्रिय विकल्प लिंकरड है , और कॉन्सुल कनेक्ट भी है।

क्या चुनना है?

ईमानदारी से, मुझे पता नहीं है। फिलहाल, मैं इस सवाल का जवाब देने के लिए खुद को सक्षम नहीं मानता। इन उपकरणों और यहां तक ​​कि बेंचमार्क की तुलना में कुछ दिलचस्प लेख हैं ।

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

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