सेवा जाळी वापर परिस्थिती

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

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

*नोट भाषांतर.: येथे आणि पुढे लेखात नेमके हे भाषांतर (“सेवा जाळी”) अजूनही नवीन टर्म सर्व्हिस मेशसाठी वापरले जाईल.

परंतु प्रथम मला काही टिप्पण्या करायच्या आहेत:

• मी कधीही सर्व्हिस मेशसह काम केले नाही किंवा माझ्या स्वतःच्या शिक्षणासाठी सुरू केलेल्या प्रकल्पांच्या बाहेर त्यांचा वापर केला नाही. दुसरीकडे, 2015 मध्ये Twitter च्या अंतर्गत सेवा जाळीसाठी दस्तऐवजांचा गुच्छ लिहिणारा मीच होतो (त्याला तेव्हा "सर्व्हिस मेश" देखील म्हटले जात नव्हते) आणि वेबसाइट आणि दस्तऐवजीकरणाच्या विकासात भाग घेतला होता. लिंकर्ड, तर याचा अर्थ काहीतरी आहे.
• माझी यादी अंदाजे आणि अपूर्ण आहे. माझ्यासाठी अज्ञात वापर प्रकरणे असू शकतात आणि तंत्रज्ञान विकसित होत असताना आणि त्याची लोकप्रियता वाढत असताना नवीन पर्याय तयार होण्याची शक्यता आहे.
• त्याच वेळी, प्रत्येक विद्यमान सेवा जाळी अंमलबजावणी सर्व सूचीबद्ध वापर प्रकरणांना समर्थन देत नाही. म्हणून, माझी विधाने जसे की "सेवा जाळी करू शकते..." "वैयक्तिक, आणि कदाचित सर्व लोकप्रिय सेवा जाळी अंमलबजावणी करू शकतात..." म्हणून वाचले पाहिजे.
• उदाहरणांच्या क्रमाने काही फरक पडत नाही.

छोटी यादी:

• सेवा शोध;
• एनक्रिप्शन;
• प्रमाणीकरण आणि अधिकृतता;
• भार संतुलन;
• सर्किट ब्रेकिंग;
• ऑटोस्केलिंग;
• कॅनरी उपयोजन;
• निळा-हिरवा उपयोजन;
• आरोग्य तपासणी;
• लोडशेडिंग;
• रहदारी मिररिंग;
• इन्सुलेशन;
• विनंती दर मर्यादित करणे, पुन्हा प्रयत्न करणे आणि कालबाह्य होणे;
• टेलिमेट्री;
• हिशेब तपासणी
• व्हिज्युअलायझेशन

1. सेवा शोध

TL;DR: साधी नावे वापरून नेटवर्कवरील इतर सेवांशी कनेक्ट करा.

सेवा पुरेशी नावे वापरून एकमेकांना आपोआप "शोधण्यात" सक्षम असावी - उदाहरणार्थ, service.api.production, pets/staging किंवा cassandra. मेघ वातावरण लवचिक आहे आणि एकच नाव सेवेची अनेक उदाहरणे लपवू शकते. हे स्पष्ट आहे की अशा परिस्थितीत सर्व IP पत्ते हार्डकोड करणे शारीरिकदृष्ट्या अशक्य आहे.

शिवाय, जेव्हा एका सेवेला दुसरी सेवा सापडते, तेव्हा ती त्या सेवेला विनंत्या पाठवण्यास सक्षम असावी या भीतीशिवाय ती त्याच्या तुटलेल्या उदाहरणाच्या इनपुटवर संपेल. दुसऱ्या शब्दांत, सर्व्हिस मेशने सर्व सेवा उदाहरणांच्या आरोग्यावर लक्ष ठेवले पाहिजे आणि होस्टची यादी शक्य तितकी अद्ययावत ठेवली पाहिजे.

प्रत्येक सेवा जाळी सेवा शोध यंत्रणा वेगळ्या पद्धतीने लागू करते. या क्षणी, कुबर्नेट्स डीएनएस सारख्या बाह्य प्रक्रियांना सोपविणे हा सर्वात सामान्य मार्ग आहे. भूतकाळात Twitter वर आम्ही यासाठी नामकरण प्रणाली वापरली होती फिनागल. याव्यतिरिक्त, सेवा जाळी तंत्रज्ञान सानुकूल नामकरण यंत्रणा उदयास येणे शक्य करते (जरी मी अद्याप अशा कार्यक्षमतेसह कोणतीही SM अंमलबजावणी पाहिली नाही).

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

TL;DR: सेवांमधील एन्क्रिप्टेड रहदारीपासून मुक्त व्हा आणि ही प्रक्रिया स्वयंचलित आणि स्केलेबल बनवा.

हल्लेखोर तुमच्या अंतर्गत नेटवर्कमध्ये प्रवेश करू शकत नाहीत हे जाणून आनंद झाला. फायरवॉल हे उत्तम काम करतात. पण हॅकर आत गेल्यास काय होईल? इंट्रा-सर्व्हिस ट्रॅफिकसह त्याला हवे ते करू शकेल का? शेवटी असे होणार नाही अशी आशा करूया. ही परिस्थिती टाळण्यासाठी, तुम्ही शून्य-विश्वास नेटवर्क लागू केले पाहिजे ज्यामध्ये सेवांमधील सर्व रहदारी कूटबद्ध केली जाते. बर्‍याच आधुनिक सेवा मेश हे परस्परांद्वारे साध्य करतात TLS (म्युच्युअल TLS, mTLS). काही प्रकरणांमध्ये, mTLS संपूर्ण ढग आणि क्लस्टर्समध्ये कार्य करते (मला वाटते की आंतरग्रहीय संप्रेषणे कधीतरी अशीच व्यवस्था केली जातील).

अर्थात, mTLS सेवा जाळीसाठी पर्यायी. प्रत्येक सेवा स्वतःच्या TLS ची काळजी घेऊ शकते, परंतु याचा अर्थ असा की तुम्हाला प्रमाणपत्रे व्युत्पन्न करण्याचा मार्ग शोधावा लागेल, ते सर्व सेवा होस्टवर वितरित करावे लागतील आणि फायलींमधून ही प्रमाणपत्रे लोड करणार्‍या अनुप्रयोगामध्ये कोड समाविष्ट करावा लागेल. होय, नियमित अंतराने या प्रमाणपत्रांचे नूतनीकरण करण्यास विसरू नका. सारख्या सिस्टीमसह सेवा mTLS स्वयंचलित करते SPIFFE, जे, यामधून, प्रमाणपत्रे जारी करण्याची आणि फिरवण्याची प्रक्रिया स्वयंचलित करते.

3. प्रमाणीकरण आणि अधिकृतता

TL;DR: विनंतीकर्ता कोण आहे हे स्थापित करा आणि विनंती सेवेपर्यंत पोहोचण्यापूर्वी त्यांना काय करण्याची परवानगी आहे ते परिभाषित करा.

सेवा अनेकदा जाणून घेऊ इच्छित कोण विनंती (प्रमाणीकरण) करते आणि ही माहिती वापरून निर्णय घेते की दिलेल्या घटकाला (अधिकृतीकरण) करण्याची परवानगी आहे. या प्रकरणात, सर्वनाम "कोण" लपवू शकते:

1. इतर सेवा. याला "प्रमाणीकरण" म्हणतात समवयस्क" उदाहरणार्थ, सेवा web सेवेत प्रवेश करू इच्छित आहे db. सर्व्हिस मेश सहसा mTLS वापरून अशा समस्या सोडवतात: या प्रकरणात प्रमाणपत्रे आवश्यक ओळखकर्ता म्हणून कार्य करतात.
2. काही मानवी वापरकर्ते. याला "प्रमाणीकरण" म्हणतात विनंती" उदाहरणार्थ, वापरकर्ता haxor69 नवीन दिवा विकत घ्यायचा आहे. सेवा जाळी विविध यंत्रणा प्रदान करतात, उदा. जेएसओएन वेब टोकन.

   आपल्यापैकी अनेकांनी हे ऍप्लिकेशन कोडमध्ये केले आहे. एक विनंती येते, आम्ही टेबल पाहतो users, वापरकर्ता शोधा आणि पासवर्डची तुलना करा, नंतर स्तंभ तपासा permissions इ. सेवा जाळीच्या बाबतीत, विनंती सेवेपर्यंत पोहोचण्यापूर्वीच हे घडते.

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

4. लोड बॅलन्सिंग

TL;DR: एका विशिष्ट पॅटर्ननुसार सर्व सेवा उदाहरणांमध्ये लोड वितरित करा.

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

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

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

TL;DR: समस्याग्रस्त सेवेकडे रहदारी थांबवा आणि सर्वात वाईट परिस्थितीत नुकसान नियंत्रित करा.

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

सेवा जाळे केवळ आपल्याला परिभाषित करण्याची परवानगी देत ​​​​नाहीत जेव्हा शटडाउन अनुसरण करेल आणि की हे अनुसरण करेल. या प्रकरणात, "केव्हा" मध्ये निर्दिष्ट पॅरामीटर्सचे कोणतेही संयोजन समाविष्ट केले जाऊ शकते: विशिष्ट कालावधीसाठी विनंत्यांची एकूण संख्या, समांतर कनेक्शनची संख्या, प्रलंबित विनंत्या, सक्रिय पुन्हा प्रयत्न इ.

तुम्ही कदाचित सर्किट ब्रेकिंगचा गैरवापर करू इच्छित नाही, परंतु आपत्कालीन परिस्थितीत तुमच्याकडे बॅकअप योजना आहे हे जाणून आनंद झाला.

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

TL;DR: निर्दिष्ट निकषांवर अवलंबून सेवा उदाहरणांची संख्या वाढवा किंवा कमी करा.

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

उदाहरणार्थ, कुबर्नेट्स पॉड्सच्या CPU आणि मेमरी वापरावर आधारित सेवा मोजतात (आमचा अहवाल पहा"Kubernetes मध्ये ऑटोस्केलिंग आणि संसाधन व्यवस्थापन"- अंदाजे. अनुवाद.), परंतु तुम्ही इतर कोणत्याही मेट्रिकच्या आधारे मोजण्याचे ठरविल्यास (आमच्या बाबतीत, रहदारीशी संबंधित), तुम्हाला विशेष मेट्रिकची आवश्यकता असेल. व्यवस्थापन यासारखे हे कसे करायचे ते दाखवते दूत, इस्टिओ и Prometheus, परंतु प्रक्रिया स्वतःच खूप क्लिष्ट आहे. आम्हाला सेवा जाळीने "सेवा उदाहरणांची संख्या वाढवा" सारख्या अटी सेट करण्याची परवानगी देऊन हे सोपे करावे असे आम्हाला वाटते auth, जर प्रलंबित विनंत्यांची संख्या एका मिनिटात थ्रेशोल्ड ओलांडली असेल."

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

TL;DR: वापरकर्त्यांच्या उपसंचावर नवीन वैशिष्ट्ये किंवा सेवा आवृत्त्यांची चाचणी करा.

समजा तुम्ही SaaS उत्पादन विकसित करत आहात आणि त्याची नवीन आवृत्ती आणण्याचा तुमचा विचार आहे. तुम्ही त्याची स्टेजिंगमध्ये चाचणी केली आणि ते छान काम केले. परंतु वास्तविक परिस्थितीत तिच्या वर्तनाबद्दल अजूनही काही चिंता आहेत. दुसऱ्या शब्दांत, तुम्हाला वापरकर्त्याच्या विश्वासाला धोका न देता वास्तविक समस्यांवर नवीन आवृत्तीची चाचणी घेण्याची आवश्यकता आहे. यासाठी कॅनरी तैनाती उत्तम आहेत. ते तुम्हाला वापरकर्त्यांच्या उपसंचासाठी नवीन वैशिष्ट्य प्रदर्शित करण्याची परवानगी देतात. या उपसंचामध्ये सर्वात निष्ठावान वापरकर्ते किंवा उत्पादनाच्या विनामूल्य आवृत्तीसह कार्य करणारे किंवा "गिनीपिग" बनण्याची इच्छा व्यक्त केलेल्या वापरकर्त्यांचा समावेश असू शकतो.

सर्व्हिस मेश हे तुम्हाला निकष निर्दिष्ट करण्याची परवानगी देऊन अंमलात आणतात जे अनुप्रयोगाची कोणती आवृत्ती पाहतील हे निर्धारित करतात आणि त्यानुसार रहदारी मार्गी लावतात. तथापि, स्वतः सेवांसाठी काहीही बदलत नाही. सेवेची आवृत्ती 1.0 विश्वास ठेवते की सर्व विनंत्या वापरकर्त्यांकडून येतात ज्यांनी ती पाहावी आणि आवृत्ती 1.1 त्याच्या वापरकर्त्यांसाठी समान विश्वास ठेवते. दरम्यान, तुम्ही जुन्या आणि नवीन आवृत्त्यांमधील रहदारीची टक्केवारी बदलू शकता, वापरकर्त्यांची वाढती संख्या नवीनकडे पुनर्निर्देशित करू शकता जर ते स्थिरपणे कार्य करत असेल आणि तुमचे "गिनीपिग" पुढे जातील.

8. निळ्या-हिरव्या तैनाती

TL;DR: एक छान नवीन वैशिष्ट्य रोल आउट करा, परंतु सर्वकाही त्वरित परत घेण्यासाठी तयार रहा.

याचा अर्थ निळा-हिरवा उपयोजन एक नवीन "ब्लू" सेवा रोल आउट करणे आहे, ती जुन्या "हिरव्या" च्या समांतर लाँच करणे. जर सर्व काही सुरळीत चालले आणि नवीन सेवा चांगली कामगिरी करत असेल तर जुनी हळूहळू अक्षम केली जाऊ शकते. (अरे, एखाद्या दिवशी ही नवीन “ब्लू” सेवा “हिरव्या” च्या नशिबाची पुनरावृत्ती करेल आणि अदृश्य होईल...) ब्लू-ग्रीन डिप्लॉयमेंट कॅनरी सेवांपेक्षा भिन्न आहे ज्यामध्ये नवीन फंक्शन समाविष्ट आहे प्रत्येकजण एकाच वेळी वापरकर्ते (भाग नाही); येथे मुद्दा असा आहे की काहीतरी चूक झाल्यास "सुरक्षित हार्बर" तयार असणे आवश्यक आहे.

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

नोंद. अनुवाद: तुम्ही Kubernetes मधील विविध उपयोजन धोरणांबद्दल अधिक वाचू शकता (उल्लेखित कॅनरी, निळा/हिरवा आणि इतरांसह) हा लेख.

9. आरोग्य तपासणी

TL;DR: कोणती सेवा उदाहरणे कार्यरत आहेत याचा मागोवा ठेवा आणि जे यापुढे कार्य करत नाहीत त्यांना प्रतिसाद द्या.

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

अशा प्रकारे, आरोग्य तपासणी ही एकट्याने वापरण्याचे प्रकरण नाही, परंतु सामान्यतः इतर उद्दिष्टे साध्य करण्यासाठी वापरली जाते. तसेच, आरोग्य तपासणीच्या परिणामांवर अवलंबून, इतर सेवा जाळी लक्ष्यांसाठी बाह्य क्रिया आवश्यक असू शकतात: उदाहरणार्थ, स्थिती पृष्ठ अद्यतनित करणे, GitHub वर समस्या निर्माण करणे किंवा JIRA तिकीट भरणे. आणि सेवा जाळी हे सर्व स्वयंचलित करण्यासाठी एक सोयीस्कर यंत्रणा देते.

10. लोडशेडिंग

TL;DR: वापरामध्ये तात्पुरत्या वाढीच्या प्रतिसादात रहदारी पुनर्निर्देशित करा.

जर एखादी विशिष्ट सेवा रहदारीने ओव्हरलोड झाली असेल, तर तुम्ही तात्पुरते या ट्रॅफिकपैकी काही ट्रॅफिक दुसर्‍या स्थानावर पुनर्निर्देशित करू शकता (म्हणजे, "डंप", "हस्तांतरण" (शेड) तो तेथे आहे). उदाहरणार्थ, बॅकअप सेवा किंवा डेटा सेंटर किंवा कायमस्वरूपी पल्सर विषय. परिणामी, सेवा क्रॅश होण्याऐवजी आणि सर्वकाही पूर्णपणे प्रक्रिया करणे थांबवण्याऐवजी काही विनंत्यांवर प्रक्रिया करणे सुरू ठेवेल. सर्किट तोडण्यापेक्षा लोडशेडिंग श्रेयस्कर आहे, परंतु तरीही त्याचा गैरवापर करणे योग्य नाही. हे कॅस्केडिंग अपयश टाळण्यास मदत करते ज्यामुळे डाउनस्ट्रीम सेवा क्रॅश होतात.

11. वाहतूक समांतरीकरण/मिररिंग

TL; DR: एकाच वेळी अनेक ठिकाणी एक विनंती पाठवा.

काहीवेळा एकाच वेळी अनेक सेवांना विनंती (किंवा विनंत्यांची काही निवड) पाठवण्याची गरज असते. उत्पादन रहदारीचा काही भाग स्टेजिंग सेवेकडे पाठवणे हे एक सामान्य उदाहरण आहे. मुख्य उत्पादन वेब सर्व्हर डाउनस्ट्रीम सेवेला विनंती पाठवतो products.production आणि फक्त त्याला. आणि सेवा जाळी हुशारीने ही विनंती कॉपी करते आणि पाठवते products.staging, ज्याची वेब सर्व्हरला देखील माहिती नाही.

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

12. इन्सुलेशन

TL;DR: तुमची सेवा जाळी मिनी-नेटवर्कमध्ये खंडित करा.

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

याव्यतिरिक्त, फायदे संघटनात्मक देखील असू शकतात. तुम्ही तुमच्या कंपनीच्या संरचनेवर आधारित तुमच्या सेवा सबनेट करू इच्छित असाल आणि विकासकांना संपूर्ण सेवा जाळी लक्षात ठेवण्याच्या संज्ञानात्मक भारापासून मुक्त करा.

13. विनंती दर मर्यादित करणे, पुन्हा प्रयत्न करणे आणि कालबाह्य होणे

TL;DR: तुम्हाला यापुढे तुमच्या कोडबेसमध्ये निटी-ग्रिटी रिक्वेस्ट मॅनेजमेंट टास्क समाविष्ट करण्याची गरज नाही.

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

ही कार्ये सेवा जाळीवर ऑफलोड करणे म्हणजे सेवा विकसकांना त्यांच्याबद्दल विचार करण्याची गरज नाही तर ते अधिक जागतिक पद्धतीने पाहिले जाऊ शकतात. सेवांची जटिल साखळी वापरली असल्यास, A -> B -> C -> D -> E म्हणा, विनंतीचे संपूर्ण जीवनचक्र विचारात घेतले पाहिजे. सेवा C मध्ये कालबाह्यता वाढवण्याचे कार्य असल्यास, हे सर्व एकाच वेळी करणे तर्कसंगत आहे, भागांमध्ये नाही: सेवा कोड अद्यतनित करून आणि पुल विनंती स्वीकारेपर्यंत प्रतीक्षा करा आणि CI सिस्टम अद्यतनित सेवा तैनात करेपर्यंत.

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

TL;DR: सेवांमधून सर्व आवश्यक (आणि पूर्णतः नाही) माहिती गोळा करा.

टेलीमेट्री ही एक सामान्य संज्ञा आहे ज्यामध्ये मेट्रिक्स, वितरित ट्रेसिंग आणि लॉग समाविष्ट आहेत. सर्व्हिस मेश हे तिन्ही प्रकारचा डेटा गोळा करण्यासाठी आणि त्यावर प्रक्रिया करण्यासाठी यंत्रणा देतात. येथेच गोष्टी थोड्या अस्पष्ट होतात कारण संभाव्य पर्यायांची संख्या खूप मोठी आहे. मेट्रिक्स गोळा करण्यासाठी आहे Prometheus आणि इतर साधने जी लॉग गोळा करण्यासाठी वापरली जाऊ शकतात अस्खलित, लोकी, वेक्टर आणि इतर. (उदाहरणार्थ ClickHouse सह आमच्या लॉगहाऊस K8s साठी - अंदाजे. अनुवाद.), वितरित ट्रेसिंगसाठी आहे जागर आणि असेच. प्रत्येक सेवा जाळी काही साधनांना समर्थन देऊ शकते आणि इतरांना नाही. प्रकल्प शक्य आहे की नाही हे पाहणे मनोरंजक असेल टेलीमेट्री उघडा काही अभिसरण प्रदान करा.

या प्रकरणात, सेवा जाळी तंत्रज्ञानाचा फायदा असा आहे की साइडकार कंटेनर, तत्त्वतः, त्यांच्या सेवांमधून वरील सर्व डेटा गोळा करू शकतात. दुसऱ्या शब्दांत, तुमच्याकडे एकच टेलिमेट्री कलेक्शन सिस्टम आहे आणि सर्व्हिस मेश या सर्व माहितीवर विविध प्रकारे प्रक्रिया करू शकते. उदाहरणार्थ:

• CLI मधील विशिष्ट सेवेकडून टेल लॉग;
• सर्व्हिस मेश डॅशबोर्डवरील विनंत्यांच्या आवाजाचे निरीक्षण करा;
• वितरित ट्रेस गोळा करा आणि ते जेगर सारख्या प्रणालीकडे पाठवा.

लक्ष द्या, व्यक्तिनिष्ठ निर्णय: सर्वसाधारणपणे, टेलीमेट्री हे एक क्षेत्र आहे ज्यामध्ये सेवा जाळीचा मजबूत हस्तक्षेप अवांछित आहे. प्राथमिक माहिती गोळा करणे आणि ऑन-द-फ्लाय काही सोनेरी मेट्रिक्स जसे की विनंतीचा यशाचा दर आणि लेटन्सीचा मागोवा घेणे हे ठीक आहे, परंतु आपण अशी आशा करूया की फ्रँकेन्स्टाईन स्टॅक तयार होताना दिसत नाहीत जे विशेष प्रणाली पुनर्स्थित करण्याचा प्रयत्न करतात, ज्यापैकी काहींनी आधीच स्वतःला सिद्ध केले आहे आणि त्यांचा चांगला अभ्यास केला आहे. .

15. ऑडिट

TL; DR: जे इतिहासाचे धडे विसरतात ते त्यांची पुनरावृत्ती करण्यासाठी नशिबात असतात.

ऑडिटिंग ही प्रणालीतील महत्त्वाच्या घटनांचे निरीक्षण करण्याची कला आहे. सर्व्हिस मेशच्या बाबतीत, याचा अर्थ असा असू शकतो की विशिष्ट सेवांसाठी विशिष्ट एंडपॉइंट्सवर कोणी विनंत्या केल्या किंवा गेल्या महिन्यात काही सुरक्षा-संबंधित घटना किती वेळा घडल्या याचा मागोवा घेणे.

हे स्पष्ट आहे की ऑडिटिंगचा टेलीमेट्रीशी खूप जवळचा संबंध आहे. फरक असा आहे की टेलिमेट्री सहसा उत्पादकता आणि तांत्रिक अखंडता यासारख्या गोष्टींशी संबंधित असते, तर ऑडिटिंग कायदेशीर आणि इतर समस्यांशी संबंधित असू शकते जे कठोरपणे तांत्रिक क्षेत्राच्या पलीकडे जातात (उदाहरणार्थ, GDPR चे अनुपालन - डेटा संरक्षणावरील EU सामान्य नियमन).

16. व्हिज्युअलायझेशन

TL;DR: लाँग लाईव्ह React.js - फॅन्सी इंटरफेसचा एक अक्षय स्रोत.

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

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

यादीत समाविष्ट नव्हते

मी मूळतः सूचीमध्ये आणखी काही वापर प्रकरणे समाविष्ट करण्याचा विचार केला होता, परंतु नंतर न करण्याचा निर्णय घेतला. माझ्या निर्णयाच्या कारणांसह ते येथे आहेत:

• मल्टी-डेटा सेंटर. माझ्या मते, सर्व्हिस मेशेस किंवा सेवा शोध सारख्या फंक्शन्सच्या काही संचाच्या वापराचे अरुंद आणि विशिष्ट क्षेत्र म्हणून हे वापराचे प्रकरण नाही.
• प्रवेश आणि बाहेर पडणे. हे एक संबंधित क्षेत्र आहे, परंतु मी स्वतःला (कदाचित कृत्रिमरित्या) "पूर्व-पश्चिम रहदारी" वापर प्रकरणात मर्यादित केले आहे. प्रवेश आणि निर्गमन स्वतंत्र लेखास पात्र आहे.

निष्कर्ष

आतासाठी एवढेच! पुन्हा, ही यादी अतिशय अनियंत्रित आणि बहुधा अपूर्ण आहे. जर तुम्हाला वाटत असेल की माझे काहीतरी चुकले आहे किंवा काहीतरी चुकले आहे, कृपया माझ्याशी Twitter वर संपर्क साधा (@luckerkins). कृपया सभ्यतेच्या नियमांचा आदर करा.

अनुवादकाकडून पुनश्च

लेखाचे शीर्षक चित्र लेखातील प्रतिमेवर आधारित आहे “सर्व्हिस मेश म्हणजे काय (आणि कधी वापरायचे)?"(ग्रेगरी मॅककिनन द्वारे). हे दर्शविते की ऍप्लिकेशन्समधील काही कार्यक्षमता (हिरव्या रंगात) सेवा जाळीवर कशी हलवली गेली आहे जी त्यांच्या दरम्यान (निळ्यामध्ये) इंटरकनेक्शन प्रदान करते.

आमच्या ब्लॉगवर देखील वाचा:

• «सेवा जाळी: प्रत्येक सॉफ्टवेअर अभियंत्यांना सर्वात लोकप्रिय तंत्रज्ञानाबद्दल काय माहित असणे आवश्यक आहे";
• «सर्व्हिस मेश म्हणजे काय आणि मला [मायक्रोसर्व्हिसेससह क्लाउड ऍप्लिकेशनसाठी] याची आवश्यकता का आहे?";
• «Istio सह microservices वर परत. भाग 1».

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