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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

यह आधुनिक सर्विस मेश से किस प्रकार भिन्न है?

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

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

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

आधुनिक सर्विस मेश ऐसी समस्याओं से निपटने में बेहतर हैं। सबसे पहले, वे जाँचते हैं कि कनेक्शन रूट किए गए हैं स्रोत में. तार्किक प्रवाह वही है: клиент → меш → сервис, लेकिन अब जाल स्थानीय रूप से काम करता है और दूरस्थ नोड्स पर नहीं, इसलिए कनेक्शन клиент → меш स्थानीय और बहुत तेज़ है (मिलीसेकंड के बजाय माइक्रोसेकंड)।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

इस्तियो ऐसे काम करता है! लेकिन कुछ अंतरों के साथ:

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

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

दूत प्रॉक्सी

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

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

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

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

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

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

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

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

सेवा पते

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

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

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

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

अतिरिक्त तामझाम

इस्तियो एमटीएलएस (म्यूचुअल टीएलएस) के माध्यम से एंड-टू-एंड एन्क्रिप्शन और प्रमाणीकरण भी प्रदान करता है। घटक को बुलाया गया गढ़.

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

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

विकसित करें या खरीदें

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

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

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

क्या चुनें: इस्तियो, लिंकरड या कॉन्सल कनेक्ट?

अभी तक हमने केवल इस्तियो के बारे में बात की है, लेकिन यह एकमात्र सेवा जाल नहीं है। लोकप्रिय विकल्प है लिंकरड, लेकिन और भी बहुत कुछ है कौंसल कनेक्ट.

क्या चुनने के लिए?

ईमानदारी से कहूं तो मुझे नहीं पता. फिलहाल मैं खुद को इस सवाल का जवाब देने में सक्षम नहीं मानता हूं. कुछ हैं दिलचस्प सामग्री इन उपकरणों की तुलना के साथ भी मानक.

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

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

स्रोत: www.habr.com