इंटरनेट मध्ये एक घड लेख о सेवा जाळी (सेवा जाळी), आणि येथे आणखी एक आहे. हुर्रे! पण का? मग, मला माझे मत व्यक्त करायचे आहे की डॉकर आणि कुबर्नेट्स सारख्या कंटेनर प्लॅटफॉर्मच्या आगमनापूर्वी 10 वर्षांपूर्वी सर्व्हिस मेश दिसले असते तर ते चांगले झाले असते. मी असे म्हणत नाही की माझा दृष्टिकोन इतरांपेक्षा चांगला किंवा वाईट आहे, परंतु सर्व्हिस मेश हे बरेच जटिल प्राणी असल्याने, त्यांना अधिक चांगल्या प्रकारे समजून घेण्यास अनेक दृष्टिकोन मदत करतील.

मी डॉटक्लाउड प्लॅटफॉर्मबद्दल बोलेन, जे शंभरहून अधिक मायक्रो सर्व्हिसेसवर तयार केले गेले होते आणि हजारो कंटेनराइज्ड अॅप्लिकेशन्सना सपोर्ट करते. ते विकसित आणि लॉन्च करताना आम्हाला कोणकोणत्या आव्हानांचा सामना करावा लागला आणि सर्व्हिस मेश कशा प्रकारे मदत करू शकतात (किंवा करू शकत नाहीत) हे मी समजावून सांगेन.

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

मी डॉटक्लाउडच्या इतिहासाबद्दल आणि या प्लॅटफॉर्मसाठी आर्किटेक्चरच्या निवडीबद्दल लिहिले आहे, परंतु मी नेटवर्क लेयरबद्दल जास्त बोललो नाही. वाचनात डुबकी मारायची नसेल तर शेवटचा लेख डॉटक्लाउड बद्दल, येथे थोडक्यात सारांश आहे: हा एक PaaS प्लॅटफॉर्म-ए-ए-सर्व्हिस आहे जो ग्राहकांना डेटाच्या विस्तृत श्रेणीसाठी समर्थनासह विस्तृत अनुप्रयोग (Java, PHP, Python...) चालविण्यास अनुमती देतो. सेवा (MongoDB, MySQL, Redis...) आणि Heroku सारखा वर्कफ्लो: तुम्ही तुमचा कोड प्लॅटफॉर्मवर अपलोड करता, ते कंटेनर इमेज बनवते आणि त्यांना तैनात करते.

डॉटक्लाउड प्लॅटफॉर्मवर रहदारी कशी निर्देशित केली गेली ते मी तुम्हाला सांगेन. ते विशेषतः थंड होते म्हणून नाही (जरी सिस्टमने त्याच्या वेळेसाठी चांगले काम केले!), परंतु मुख्यत्वे आधुनिक साधनांसह अशा डिझाइनची अंमलबजावणी एखाद्या माफक टीमद्वारे सहजपणे केली जाऊ शकते, जर त्यांना एका गुच्छ दरम्यान रहदारी मार्गी लावण्यासाठी मार्ग हवा असेल. मायक्रोसर्व्हिसेस किंवा अनुप्रयोगांचा समूह. अशा प्रकारे, आपण पर्यायांची तुलना करू शकता: आपण सर्वकाही स्वतः विकसित केल्यास किंवा विद्यमान सेवा जाळी वापरल्यास काय होईल. मानक निवड म्हणजे ते स्वतः बनवणे किंवा ते विकत घेणे.

होस्ट केलेल्या अनुप्रयोगांसाठी रहदारी मार्ग

डॉटक्लाउडवरील अनुप्रयोग HTTP आणि TCP एंडपॉइंट्स उघड करू शकतात.

HTTP अंत्यबिंदू लोड बॅलन्सर क्लस्टर कॉन्फिगरेशनमध्ये गतिशीलपणे जोडले हिपाचे. हे आजच्या संसाधनांसारखेच आहे प्रवेश Kubernetes मध्ये आणि लोड बॅलन्सर सारखे ट्रॅफिक.

क्लायंट योग्य डोमेनद्वारे HTTP एंडपॉईंटशी कनेक्ट होतात, जर डोमेन नाव डॉटक्लाउड लोड बॅलन्सर्सकडे निर्देशित करते. खास काही नाही.

TCP अंतिम बिंदू पोर्ट क्रमांकाशी संबंधित, जे नंतर त्या स्टॅकमधील सर्व कंटेनरला पर्यावरण व्हेरिएबल्सद्वारे पाठवले जाते.

क्लायंट योग्य होस्टनाव (गेटवे-X.dotcloud.com सारखे काहीतरी) आणि पोर्ट नंबर वापरून TCP एंडपॉइंटशी कनेक्ट करू शकतात.

हे होस्टनाव “nats” सर्व्हर क्लस्टरचे निराकरण करते (याशी संबंधित नाही NATS), जे येणारे TCP कनेक्शन योग्य कंटेनरवर (किंवा, लोड-संतुलित सेवांच्या बाबतीत, योग्य कंटेनरवर) रूट करेल.

जर तुम्ही कुबर्नेट्सशी परिचित असाल, तर हे तुम्हाला सेवांची आठवण करून देईल नोडपोर्ट.

डॉटक्लाउड प्लॅटफॉर्मवर कोणतीही समतुल्य सेवा नव्हती क्लस्टरआयपी: साधेपणासाठी, प्लॅटफॉर्मच्या आतून आणि बाहेरून अशाच प्रकारे सेवांमध्ये प्रवेश केला गेला.

सर्व काही अगदी सोप्या पद्धतीने आयोजित केले गेले होते: HTTP आणि TCP रूटिंग नेटवर्कची सुरुवातीची अंमलबजावणी कदाचित प्रत्येक पायथनच्या काही शंभर ओळींची होती. साधे (मी निरागस म्हणेन) अल्गोरिदम जे प्लॅटफॉर्म वाढले आणि अतिरिक्त आवश्यकता दिसू लागल्या तसे परिष्कृत केले गेले.

विद्यमान कोडचे विस्तृत रिफॅक्टरिंग आवश्यक नव्हते. विशेषतः, 12 घटक अॅप्स पर्यावरण व्हेरिएबल्सद्वारे प्राप्त केलेला पत्ता थेट वापरू शकतो.

हे आधुनिक सेवा जाळीपेक्षा वेगळे कसे आहे?

मर्यादित दृश्यमानता. आमच्याकडे TCP राउटिंग जाळीसाठी कोणतेही मेट्रिक्स नव्हते. जेव्हा HTTP राउटिंगचा विचार केला जातो तेव्हा, नंतरच्या आवृत्त्यांनी त्रुटी कोड आणि प्रतिसाद वेळेसह तपशीलवार HTTP मेट्रिक्स सादर केले, परंतु आधुनिक सेवा मेश आणखी पुढे जातात, उदाहरणार्थ, Prometheus सारख्या मेट्रिक्स संकलन प्रणालीसह एकत्रीकरण प्रदान करते.

दृश्यमानता केवळ ऑपरेशनल दृष्टीकोनातून (समस्यांचे निराकरण करण्यात मदत करण्यासाठी) नाही तर नवीन वैशिष्ट्ये जारी करताना देखील महत्त्वाची आहे. हे सुरक्षित बद्दल आहे निळा-हिरवा उपयोजन и कॅनरी उपयोजन.

राउटिंग कार्यक्षमता देखील मर्यादित आहे. डॉटक्लाउड रूटिंग मेशमध्ये, सर्व रहदारीला समर्पित राउटिंग नोड्सच्या क्लस्टरमधून जावे लागले. याचा अर्थ संभाव्यपणे एकाधिक AZ (उपलब्धता क्षेत्र) सीमा ओलांडणे आणि लक्षणीयरीत्या विलंबता वाढवणे. मला समस्यानिवारण कोड आठवतो जो प्रति पृष्ठ शंभर SQL क्वेरी करत होता आणि प्रत्येक क्वेरीसाठी SQL सर्व्हरशी नवीन कनेक्शन उघडत होता. स्थानिक पातळीवर चालत असताना, पृष्ठ त्वरित लोड होते, परंतु डॉटक्लाउडमध्ये लोड होण्यास काही सेकंद लागतात कारण प्रत्येक TCP कनेक्शन (आणि त्यानंतरची SQL क्वेरी) दहापट मिलिसेकंद घेते. या विशिष्ट प्रकरणात, सतत कनेक्शनने समस्या सोडवली.

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

आधुनिक सेवा मेशे देखील स्मार्ट लोड बॅलेंसिंग अल्गोरिदम लागू करतात. बॅकएंडच्या आरोग्यावर लक्ष ठेवून, ते अधिक ट्रॅफिक जलद बॅकएंडवर पाठवू शकतात, परिणामी एकूण कामगिरी सुधारते.

सुरक्षा चांगले देखील. डॉटक्लाउड राउटिंग जाळी पूर्णपणे EC2 क्लासिकवर चालते आणि ट्रॅफिक एन्क्रिप्ट केले नाही (जर कोणी EC2 नेटवर्क ट्रॅफिकवर स्निफर ठेवण्यास व्यवस्थापित केले असेल, तर तुम्ही आधीच मोठ्या अडचणीत असाल या गृहितकावर आधारित). आधुनिक सेवा मेश आमच्या सर्व रहदारीचे पारदर्शकपणे संरक्षण करतात, उदाहरणार्थ, परस्पर TLS प्रमाणीकरण आणि त्यानंतरच्या एन्क्रिप्शनसह.

प्लॅटफॉर्म सेवांसाठी राउटिंग रहदारी

ठीक आहे, आम्ही ऍप्लिकेशन्समधील रहदारीबद्दल चर्चा केली आहे, परंतु डॉटक्लॉड प्लॅटफॉर्मचे काय?

प्लॅटफॉर्ममध्येच विविध कार्यांसाठी जबाबदार असलेल्या सुमारे शंभर मायक्रो सर्व्हिसेसचा समावेश होता. काहींनी इतरांकडून विनंत्या स्वीकारल्या आणि काही पार्श्वभूमी कामगार होते जे इतर सेवांशी जोडलेले होते परंतु स्वतः कनेक्शन स्वीकारले नाहीत. कोणत्याही परिस्थितीत, प्रत्येक सेवेला जोडण्यासाठी आवश्यक असलेल्या पत्त्यांचे अंतिम बिंदू माहित असणे आवश्यक आहे.

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

या निम्न-स्तरीय, मिशन-गंभीर सेवा काही प्रमुख नोड्सवर थेट कंटेनर चालवून तैनात केल्या गेल्या. या प्रकरणात, मानक प्लॅटफॉर्म सेवा वापरल्या गेल्या नाहीत: लिंकर, शेड्यूलर आणि धावपटू. आपण आधुनिक कंटेनर प्लॅटफॉर्मशी तुलना करू इच्छित असल्यास, हे नियंत्रण विमान चालवण्यासारखे आहे docker run कुबर्नेट्सला कार्य सोपवण्याऐवजी थेट नोड्सवर. हे संकल्पनेत तेही समान आहे स्थिर मॉड्यूल (शेंगा), जे ते वापरते kubeadm किंवा bootkube स्टँडअलोन क्लस्टर बूट करताना.

या सेवा सोप्या आणि क्रूड पद्धतीने उघड केल्या गेल्या: YAML फाइलमध्ये त्यांची नावे आणि पत्ते सूचीबद्ध आहेत; आणि प्रत्येक क्लायंटला या YAML फाइलची एक प्रत तैनातीसाठी घ्यावी लागली.

एकीकडे, ते अत्यंत विश्वासार्ह आहे कारण त्याला बाह्य की/मूल्य स्टोअरच्या समर्थनाची आवश्यकता नाही जसे की Zookeeper (लक्षात ठेवा, etcd किंवा Consul त्यावेळी अस्तित्वात नव्हते). दुसरीकडे, सेवा हलविणे कठीण झाले. प्रत्येक वेळी हलवल्यानंतर, सर्व क्लायंटना अपडेट केलेली YAML फाइल प्राप्त होईल (आणि संभाव्य रीबूट). फार आरामदायक नाही!

त्यानंतर, आम्ही एक नवीन योजना लागू करण्यास सुरुवात केली, जिथे प्रत्येक क्लायंट स्थानिक प्रॉक्सी सर्व्हरशी कनेक्ट झाला. पत्ता आणि पोर्ट ऐवजी, त्याला फक्त सेवेचा पोर्ट नंबर माहित असणे आवश्यक आहे आणि त्याद्वारे कनेक्ट करणे आवश्यक आहे localhost. स्थानिक प्रॉक्सी हे कनेक्शन हाताळते आणि ते वास्तविक सर्व्हरकडे पाठवते. आता, बॅकएंडला दुसर्‍या मशीनवर हलवताना किंवा स्केलिंग करताना, सर्व क्लायंट अद्यतनित करण्याऐवजी, आपल्याला फक्त या सर्व स्थानिक प्रॉक्सी अद्यतनित करण्याची आवश्यकता आहे; आणि यापुढे रीबूट आवश्यक नाही.

(TLS कनेक्शनमधील रहदारी एन्कॅप्स्युलेट करणे आणि प्राप्त करणार्‍या बाजूला दुसरा प्रॉक्सी सर्व्हर ठेवणे, तसेच प्राप्त करणार्‍या सेवेच्या सहभागाशिवाय TLS प्रमाणपत्रे सत्यापित करणे देखील योजले होते, जे केवळ कनेक्शन स्वीकारण्यासाठी कॉन्फिगर केलेले आहे. localhost. याबद्दल अधिक नंतर).

हे अगदी सारखे आहे स्मार्टस्टॅक Airbnb कडून, परंतु महत्त्वाचा फरक असा आहे की SmartStack कार्यान्वित केला जातो आणि उत्पादनासाठी तैनात केला जातो, जेव्हा dotCloud डॉकर बनले तेव्हा dotCloud ची अंतर्गत राउटिंग प्रणाली बंद करण्यात आली होती.

Istio, Linkerd आणि Consul Connect सारख्या सिस्टीमच्या पूर्ववर्तीपैकी एक म्हणून मी व्यक्तिशः SmartStack ला मानतो कारण ते सर्व समान पद्धतीचे अनुसरण करतात:

• प्रत्येक नोडवर प्रॉक्सी चालवा.
• क्लायंट प्रॉक्सीशी कनेक्ट होतात.
• बॅकएंड बदलल्यावर कंट्रोल प्लेन प्रॉक्सी कॉन्फिगरेशन अपडेट करते.
• ... नफा!

सेवा जाळीची आधुनिक अंमलबजावणी

आज आम्हाला समान ग्रिड लागू करण्याची आवश्यकता असल्यास, आम्ही समान तत्त्वे वापरू शकतो. उदाहरणार्थ, स्पेसमधील पत्त्यांवर सेवेची नावे मॅप करून अंतर्गत DNS झोन कॉन्फिगर करा 127.0.0.0/8. नंतर क्लस्टरमधील प्रत्येक नोडवर HAProxy चालवा, प्रत्येक सेवा पत्त्यावर कनेक्शन स्वीकारा (त्या सबनेटमध्ये 127.0.0.0/8) आणि योग्य बॅकएंडवर लोड पुनर्निर्देशित/संतुलित करणे. HAProxy कॉन्फिगरेशन नियंत्रित केले जाऊ शकते confd, तुम्हाला बॅकएंड माहिती etcd किंवा Consul मध्ये संग्रहित करण्याची परवानगी देते आणि आवश्यकतेनुसार अपडेट केलेले कॉन्फिगरेशन HAProxy वर आपोआप पुश करते.

हे Istio कसे कार्य करते ते खूपच जास्त आहे! परंतु काही फरकांसह:

• वापरते दूत प्रॉक्सी HAProxy ऐवजी.
• etcd किंवा Consul ऐवजी Kubernetes API द्वारे बॅकएंड कॉन्फिगरेशन स्टोअर करते.
• सेवांना 127.0.0.0/8 ऐवजी अंतर्गत सबनेट (Kubernetes ClusterIP पत्ते) वर पत्ते वाटप केले जातात.
• क्लायंट आणि सर्व्हर दरम्यान परस्पर TLS प्रमाणीकरण जोडण्यासाठी अतिरिक्त घटक (सिटाडेल) आहे.
• सर्किट ब्रेकिंग, डिस्ट्रिब्युटेड ट्रेसिंग, कॅनरी डिप्लॉयमेंट इत्यादी नवीन वैशिष्ट्यांना सपोर्ट करते.

चला काही फरकांवर एक द्रुत नजर टाकूया.

दूत प्रॉक्सी

Envoy Proxy हे Lyft [टॅक्सी मार्केटमधील Uber चे स्पर्धक - अंदाजे. लेन]. हे इतर प्रॉक्सी (उदा. HAProxy, Nginx, Traefik...) सारखेच आहे, परंतु Lyft ने ते लिहिले कारण त्यांना इतर प्रॉक्सी नसलेल्या वैशिष्ट्यांची आवश्यकता होती आणि विद्यमान प्रॉक्सी वाढवण्याऐवजी नवीन बनवणे अधिक हुशार वाटले.

दूत स्वतः वापरता येतो. माझ्याकडे एखादी विशिष्ट सेवा असेल ज्याला इतर सेवांशी कनेक्ट करण्याची आवश्यकता असेल, तर मी ती एन्वॉयशी कनेक्ट होण्यासाठी कॉन्फिगर करू शकतो आणि नंतर डायनॅमिकली कॉन्फिगर करू शकतो आणि इतर सेवांच्या स्थानासह एंवॉय पुन्हा कॉन्फिगर करू शकतो, त्याचवेळी दृश्यमानता सारखी बरीच अतिरिक्त कार्यक्षमता मिळते. कस्टम क्लायंट लायब्ररीऐवजी किंवा कोडमध्ये कॉल ट्रेस इंजेक्ट करण्याऐवजी, आम्ही ट्रॅफिक एन्वॉयला पाठवतो आणि ते आमच्यासाठी मेट्रिक्स गोळा करते.

पण दूत म्हणून काम करण्यास सक्षम आहे डेटा प्लेन सेवा जाळीसाठी (डेटा प्लेन). याचा अर्थ दूत आता या सेवा जाळीसाठी कॉन्फिगर केले आहे नियंत्रण विमान (नियंत्रण विमान).

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

कंट्रोल प्लेनसाठी, Istio Kubernetes API वर अवलंबून आहे. हे confd वापरण्यापेक्षा फार वेगळे नाही, जे डेटा स्टोअरमधील की चा संच पाहण्यासाठी etcd किंवा Consul वर अवलंबून असते. Istio Kubernetes संसाधनांचा संच पाहण्यासाठी Kubernetes API वापरते.

या दरम्यान आणि नंतर: मला वैयक्तिकरित्या हे उपयुक्त वाटले Kubernetes API वर्णनजे वाचते:

कुबर्नेट्स एपीआय सर्व्हर हा एक “मूक सर्व्हर” आहे जो API संसाधनांसाठी स्टोरेज, आवृत्ती, प्रमाणीकरण, अपडेटिंग आणि अर्थशास्त्र ऑफर करतो.

Istio कुबर्नेट्ससह कार्य करण्यासाठी डिझाइन केलेले आहे; आणि जर तुम्हाला ते Kubernetes च्या बाहेर वापरायचे असेल, तर तुम्हाला Kubernetes API सर्व्हरचे (आणि etcd मदतनीस सेवा) एक उदाहरण चालवावे लागेल.

सेवा पत्ते

Istio ClusterIP पत्त्यांवर अवलंबून आहे जे कुबर्नेट्सने वाटप केले आहे, म्हणून Istio सेवांना अंतर्गत पत्ता प्राप्त होतो (श्रेणीमध्ये नाही 127.0.0.0/8).

Istio शिवाय Kubernetes क्लस्टरमधील विशिष्ट सेवेसाठी ClusterIP पत्त्यावरील ट्रॅफिक kube-proxy द्वारे रोखले जाते आणि त्या प्रॉक्सीच्या बॅकएंडवर पाठवले जाते. तुम्हाला तांत्रिक तपशीलांमध्ये स्वारस्य असल्यास, kube-proxy क्लस्टरआयपी पत्त्यावर जाणाऱ्या कनेक्शनचे गंतव्य IP पत्ते पुन्हा लिहिण्यासाठी iptables नियम (किंवा IPVS लोड बॅलन्सर्स, ते कसे कॉन्फिगर केले आहे यावर अवलंबून) सेट करते.

एकदा Istio Kubernetes क्लस्टरवर स्थापित केल्यानंतर, तो कंटेनर सादर करून दिलेल्या ग्राहकासाठी किंवा अगदी संपूर्ण नेमस्पेससाठी स्पष्टपणे सक्षम होईपर्यंत काहीही बदलत नाही. sidecar सानुकूल शेंगा मध्ये. हा कंटेनर एंवॉयचा एक प्रसंग फिरवेल आणि इतर सेवांकडे जाणार्‍या रहदारीला रोखण्यासाठी iptables नियमांचा एक संच सेट करेल आणि त्या ट्रॅफिकला दूताकडे पुनर्निर्देशित करेल.

Kubernetes DNS सह समाकलित केल्यावर, याचा अर्थ आमचा कोड सेवेच्या नावाने कनेक्ट होऊ शकतो आणि सर्वकाही "फक्त कार्य करते." दुस-या शब्दात, आमचा कोड यासारख्या प्रश्नांची समस्या करतो http://api/v1/users/4242मग api साठी विनंती सोडवा 10.97.105.48, iptables नियम 10.97.105.48 पासून कनेक्शन्समध्ये व्यत्यय आणतील आणि त्यांना स्थानिक दूत प्रॉक्सीकडे अग्रेषित करतील आणि स्थानिक प्रॉक्सी विनंती वास्तविक बॅकएंड API कडे पाठवेल. ओफ्फ!

अतिरिक्त फ्रिल्स

Istio mTLS (म्युच्युअल TLS) द्वारे एंड-टू-एंड एन्क्रिप्शन आणि प्रमाणीकरण देखील प्रदान करते. एक घटक म्हणतात किल्ला.

एक घटक देखील आहे मिक्सर, ज्यासाठी दूत विनंती करू शकतात प्रत्येक हेडर, बॅकएंड लोड इ. सारख्या विविध घटकांवर अवलंबून त्या विनंतीबद्दल विशेष निर्णय घेण्याची विनंती... (काळजी करू नका: मिक्सर चालू ठेवण्याचे अनेक मार्ग आहेत, आणि तो क्रॅश झाला तरीही, दूत काम करत राहतील प्रॉक्सी म्हणून ठीक आहे).

आणि, अर्थातच, आम्ही दृश्यमानतेचा उल्लेख केला आहे: वितरित ट्रेसिंग प्रदान करताना दूत मोठ्या प्रमाणात मेट्रिक्स गोळा करतो. मायक्रोसर्व्हिसेस आर्किटेक्चरमध्ये, जर एकच API विनंती मायक्रोसर्व्हिसेस A, B, C आणि D मधून जाणे आवश्यक असेल, तर लॉग इन केल्यावर, वितरित ट्रेसिंग विनंतीमध्ये एक अद्वितीय अभिज्ञापक जोडेल आणि या सर्व मायक्रोसर्व्हिसेससाठी सब-रिक्वेस्टद्वारे हा आयडेंटिफायर संचयित करेल. सर्व संबंधित कॉल कॅप्चर केले जातील. विलंब इ.

विकत घ्या किंवा विकत घ्या

Istio जटिल असण्याची प्रतिष्ठा आहे. याउलट, मी या पोस्टच्या सुरुवातीला वर्णन केलेले रूटिंग जाळी तयार करणे सध्याच्या साधनांचा वापर करून तुलनेने सोपे आहे. तर, त्याऐवजी तुमची स्वतःची सेवा जाळी तयार करण्यात अर्थ आहे का?

जर आपल्याला माफक गरजा असतील (आम्हाला दृश्यमानता, सर्किट ब्रेकर आणि इतर बारकावे आवश्यक नाहीत), तर आपले स्वतःचे साधन विकसित करण्याचा विचार येतो. परंतु जर आपण कुबर्नेट्स वापरत असाल, तर त्याची गरज भासणार नाही कारण Kubernetes आधीपासून सेवा शोध आणि लोड बॅलन्सिंगसाठी मूलभूत साधने प्रदान करते.

परंतु आमच्याकडे प्रगत आवश्यकता असल्यास, सेवा जाळी "खरेदी करणे" हा एक चांगला पर्याय असल्याचे दिसते. (हे नेहमीच "खरेदी" नसते कारण Istio मुक्त स्त्रोत आहे, परंतु तरीही आम्हाला ते समजून घेण्यासाठी, तैनात करण्यासाठी आणि व्यवस्थापित करण्यासाठी अभियांत्रिकी वेळ घालवावा लागेल.)

मी Istio, Linkerd किंवा Consul Connect निवडावे का?

आतापर्यंत आम्ही फक्त Istio बद्दल बोललो आहे, परंतु ही एकमेव सेवा जाळी नाही. लोकप्रिय पर्याय - लिंकर्ड, आणि अधिक आहे कॉन्सुल कनेक्ट.

काय निवडावे?

प्रामाणिकपणे, मला माहित नाही. या प्रश्नाचे उत्तर देण्याइतपत मी सध्या तरी स्वत:ला सक्षम समजत नाही. काही आहेत मनोरंजक लेख या साधनांच्या तुलनेत आणि अगदी बेंचमार्क.

सारखे साधन वापरणे हा एक आशादायक दृष्टीकोन आहे सुपरग्लू. सेवा जाळ्यांद्वारे उघड झालेल्या APIs सुलभ आणि एकत्रित करण्यासाठी ते एक अमूर्त स्तर लागू करते. वेगवेगळ्या सर्व्हिस मेशचे विशिष्ट (आणि, माझ्या मते, तुलनेने जटिल) API शिकण्याऐवजी, आम्ही सुपरग्लूच्या सोप्या रचनांचा वापर करू शकतो - आणि सहजपणे एकमेकांवर स्विच करू शकतो, जसे की आमच्याकडे HTTP इंटरफेस आणि बॅकएंडचे वर्णन करणारे इंटरमीडिएट कॉन्फिगरेशन स्वरूप आहे. Nginx, HAProxy, Traefik, Apache... साठी वास्तविक कॉन्फिगरेशन तयार करणे

मी Istio आणि SuperGloo सह थोडेसे संपर्क साधला आहे आणि पुढील लेखात मला हे दाखवायचे आहे की SuperGloo वापरून विद्यमान क्लस्टरमध्ये Istio किंवा Linkerd कसे जोडायचे आणि नंतरचे काम कसे केले जाते, म्हणजेच तुम्हाला येथून स्विच करण्याची परवानगी देते. कॉन्फिगरेशन ओव्हरराईट न करता एक सर्व्हिस मेश दुसर्‍यावर.

स्त्रोत: www.habr.com