सेवा जाळी: प्रत्येक सॉफ्टवेअर अभियंत्यांना सर्वात लोकप्रिय तंत्रज्ञानाबद्दल काय माहित असणे आवश्यक आहे

नोंद. अनुवाद: सर्व्हिस मेश ही एक घटना आहे ज्याचे रशियनमध्ये अद्याप स्थिर भाषांतर नाही (2 वर्षांहून अधिक वर्षांपूर्वी आम्ही "सेवांसाठी जाळी" हा पर्याय प्रस्तावित केला होता आणि थोड्या वेळाने काही सहकाऱ्यांनी "सेवा चाळणी" या संयोजनाचा सक्रियपणे प्रचार करण्यास सुरवात केली). या तंत्रज्ञानाबद्दल सतत चर्चा केल्यामुळे अशी परिस्थिती निर्माण झाली आहे ज्यामध्ये विपणन आणि तांत्रिक घटक खूप जवळून एकमेकांशी जोडलेले आहेत. मूळ शब्दाच्या लेखकांपैकी एकाची ही अद्भुत सामग्री अभियंते आणि इतरांसाठी स्पष्टता प्रदान करण्याच्या उद्देशाने आहे.

पासून कॉमिक सेबॅस्टियन कॅसेरेस

परिचय

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

सर्व्हिस मेशचा जन्म क्लाउड नेटिव्ह इकोसिस्टमच्या अस्पष्ट, पक्षपाती पाण्यात झाला. दुर्दैवाने, याचा अर्थ असा आहे की याच्या सभोवतालचे बरेचसे विवाद "कमी-कॅलरी टॉक" पासून - तांत्रिक संज्ञा वापरण्यापर्यंत - पूर्णपणे मूर्खपणाचे आहेत. परंतु जर तुम्ही सर्व आवाज कमी केला तर तुम्हाला आढळेल की सर्व्हिस मेशमध्ये एक अतिशय वास्तविक, परिभाषित आणि महत्त्वपूर्ण कार्य आहे.

या पोस्टमध्ये, मी तेच करण्याचा प्रयत्न करेन: सेवा जाळीसाठी एक प्रामाणिक, सखोल, अभियंता-केंद्रित मार्गदर्शक प्रदान करा. मी फक्त प्रश्नाचे उत्तर देणार नाही: "हे काय आहे?", - पण "का?"आणि "आत्ताच का?". शेवटी, मी (माझ्या मते) या विशिष्ट तंत्रज्ञानामुळे अशी विक्षिप्त हालचाल का झाली आहे हे सांगण्याचा प्रयत्न करेन, जी स्वतःच एक मनोरंजक कथा आहे.

मी कोण आहे?

सर्वांना नमस्कार! माझं नावं आहे विल्यम मॉर्गन. मी निर्मात्यांपैकी एक आहे लिंकर्ड — अगदी पहिला सेवा जाळी प्रकल्प आणि टर्म दिसण्यासाठी दोष देणारा प्रकल्प सेवा जाळी जसे की (माफ करा मित्रांनो!). (नोट अनुवाद.: तसे, 2,5 वर्षांहून अधिक वर्षांपूर्वी, या शब्दाच्या प्रारंभाच्या वेळी, आम्ही त्याच लेखकाच्या सुरुवातीच्या साहित्याचा अनुवाद केला आहे "सर्व्हिस मेश म्हणजे काय आणि मला [मायक्रोसर्व्हिसेससह क्लाउड ऍप्लिकेशनसाठी] याची आवश्यकता का आहे?".) मी पण डोक्यावर उत्साही एक स्टार्टअप आहे जो Linkerd आणि सारख्या छान सेवा जाळीच्या गोष्टी तयार करतो डायव्ह.

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

ठीक आहे, गुडीजकडे जाण्याची वेळ आली आहे.

सेवा जाळी म्हणजे काय?

सर्व हायप असूनही, सेवा जाळीची रचना अगदी सोपी आहे. हा फक्त सेवांच्या “पुढील” असलेल्या वापरकर्त्यांच्या स्पेस प्रॉक्सींचा एक समूह आहे (आम्ही “पुढील” काय आहे याबद्दल थोडे बोलू), तसेच नियंत्रण प्रक्रियांचा संच. प्रॉक्सींना एकत्रितपणे बोलावले जाते डेटा प्लेन, आणि नियंत्रण प्रक्रिया म्हणतात नियंत्रण विमान. डेटा प्लेन सेवांमधील कॉल्स इंटरसेप्ट करते आणि त्यांच्यासोबत "सर्व प्रकारच्या वेगवेगळ्या गोष्टी" करते; नियंत्रण विमान, त्यानुसार, प्रॉक्सीच्या वर्तनाचे समन्वय साधते आणि आपल्यासाठी प्रवेश प्रदान करते, म्हणजे. ऑपरेटर, API ला, नेटवर्कमध्ये फेरफार करण्याची आणि संपूर्णपणे मोजण्याची परवानगी देते.

हा कोणत्या प्रकारचा प्रॉक्सी आहे? ही लेयर 7-जागरूक TCP प्रॉक्सी आहे (म्हणजे OSI मॉडेलचा स्तर 7 "विचारात घेणे") HAProxy आणि NGINX सारखे. तुम्ही तुमच्या आवडीनुसार प्रॉक्सी निवडू शकता; Linkerd रस्ट प्रॉक्सी वापरते, ज्याला फक्त नाव दिले जाते linkerd-प्रॉक्सी. आम्ही ते विशेषतः सर्व्हिस मेशसाठी एकत्र ठेवले. इतर मेश इतर प्रॉक्सींना प्राधान्य देतात (दूत ही एक सामान्य निवड आहे). तथापि, प्रॉक्सी निवडणे ही केवळ अंमलबजावणीची बाब आहे.

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

तर, आम्ही डेटा प्लेनची क्रमवारी लावली आहे. कंट्रोल प्लेन सोपे आहे: हा घटकांचा एक संच आहे जो डेटा प्लेनला सेवा शोध, TLS प्रमाणपत्रे जारी करणे, मेट्रिक एकत्रीकरण इ. समन्वित पद्धतीने ऑपरेट करण्यासाठी आवश्यक असलेले सर्व यांत्रिकी प्रदान करतो. डेटा प्लेन कंट्रोल प्लेनला याची माहिती देतो. त्याचे वर्तन; या बदल्यात, कंट्रोल प्लेन एक API प्रदान करते जे तुम्हाला संपूर्ण डेटा प्लेनचे वर्तन बदलण्यास आणि त्याचे निरीक्षण करण्यास अनुमती देते.

खाली लिंकर्ड मधील कंट्रोल प्लेन आणि डेटा प्लेनचा आकृती आहे. जसे तुम्ही बघू शकता, कंट्रोल प्लेनमध्ये अनेक भिन्न घटक समाविष्ट आहेत, ज्यामध्ये प्रोमिथियस उदाहरण समाविष्ट आहे जे प्रॉक्सी सर्व्हरवरून मेट्रिक्स गोळा करते, तसेच इतर घटक जसे की destination (सेवा शोध), identity (प्रमाणपत्र प्राधिकरण, CA) आणि public-api (वेब आणि CLI साठी एंडपॉइंट). याउलट, डेटा प्लेन हा ऍप्लिकेशनच्या उदाहरणापुढील एक साधा लिंकर्ड-प्रॉक्सी आहे. हे फक्त एक तर्कचित्र आहे; रिअल-वर्ल्ड डिप्लॉयमेंटमध्ये, तुमच्याकडे प्रत्येक कंट्रोल प्लेन घटकाच्या तीन प्रतिकृती आणि डेटा प्लेनमध्ये शेकडो किंवा हजारो प्रॉक्सी असू शकतात.

(या आकृतीतील निळे आयत कुबरनेट पॉड्सच्या सीमांचे प्रतीक आहेत. लिंकर्ड-प्रॉक्सी असलेले कंटेनर हे ऍप्लिकेशन कंटेनर्स सारख्याच पॉडमध्ये असल्याचे तुम्ही पाहू शकता. ही योजना म्हणून ओळखली जाते. साइडकार कंटेनर.)

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

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

1. डेटा प्लेनमध्ये प्रॉक्सी असणे आवश्यक आहे जलद, कारण प्रत्येक कॉलसाठी प्रॉक्सीला दोन कॉल असतात: एक क्लायंटच्या बाजूला, एक सर्व्हरच्या बाजूला.
2. तसेच प्रॉक्सी असावी लहान и हलके. प्रत्येक मेमरी आणि CPU संसाधने वापरेल, आणि हा वापर अनुप्रयोगासह रेखीय वाढेल.
3. मोठ्या संख्येने प्रॉक्सी तैनात आणि अद्यतनित करण्यासाठी आपल्याला एका यंत्रणेची आवश्यकता असेल. ते स्वहस्ते करणे हा पर्याय नाही.

सर्वसाधारणपणे, सेवा जाळी यासारखी दिसते (किमान पक्ष्यांच्या नजरेतून): तुम्ही वापरकर्ता स्पेस प्रॉक्सींचा एक समूह तैनात करता जे अंतर्गत, आंतर-सेवा रहदारीसह "काहीतरी" करतात आणि त्यांचे निरीक्षण आणि व्यवस्थापन करण्यासाठी नियंत्रण विमान वापरतात.

आता "का?" हा प्रश्न विचारण्याची वेळ आली आहे.

सेवा जाळी कशासाठी आहे?

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

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

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

उदाहरणार्थ, Linkerd मध्ये (बहुतेक मेशेप्रमाणे) कार्यक्षमता प्रामुख्याने HTTP/2 आणि gRPC* सह HTTP कॉल्सवर केंद्रित असते. कार्यक्षमता खूप समृद्ध आहे - ती तीन वर्गांमध्ये विभागली जाऊ शकते:

1. संबंधित वैशिष्ट्ये विश्वसनीयता. वारंवार विनंत्या, कालबाह्यता, कॅनरी दृष्टीकोन (रहदारी विभाजन/पुनर्निर्देशन), इ.
2. संबंधित वैशिष्ट्ये देखरेख. प्रत्येक सेवेसाठी किंवा वैयक्तिक दिशानिर्देशांसाठी यश दर, विलंब आणि विनंती खंडांचे एकत्रीकरण; सेवांच्या टोपोलॉजिकल नकाशांचे बांधकाम इ.
3. संबंधित वैशिष्ट्ये सुरक्षा. परस्पर TLS, प्रवेश नियंत्रण इ.

* Linkerd च्या दृष्टिकोनातून, gRPC व्यावहारिकदृष्ट्या HTTP/2 पेक्षा वेगळे नाही: ते फक्त पेलोडमध्ये प्रोटोबफ वापरते. विकसकाच्या दृष्टिकोनातून, दोन गोष्टी अर्थातच वेगळ्या आहेत.

यापैकी अनेक यंत्रणा विनंती स्तरावर कार्य करतात (म्हणून "L7 प्रॉक्सी"). उदाहरणार्थ, जर Foo सेवेने बार सेवेला HTTP कॉल केला, तर Foo बाजूला लिंकर्ड-प्रॉक्सी इंटेलिजेंट लोड बॅलन्सिंग करू शकते आणि निरीक्षण केलेल्या लेटन्सीच्या आधारावर फू ते बारच्या उदाहरणांवर मार्ग कॉल करू शकते; ते आवश्यक असल्यास विनंतीची पुनरावृत्ती करू शकते (आणि जर ते अशक्त असेल तर); ते प्रतिसाद कोड आणि कालबाह्य इत्यादी रेकॉर्ड करू शकते. त्याचप्रमाणे, बार साइडवरील लिंकर्ड-प्रॉक्सी विनंती नाकारू शकते जर त्याला परवानगी नसेल किंवा विनंती मर्यादा ओलांडली असेल; त्याच्या भागावर विलंब नोंदवू शकतो, इ.

प्रॉक्सी कनेक्शन स्तरावर देखील "काहीतरी" करू शकतात. उदाहरणार्थ, फू बाजूला लिंकर्ड-प्रॉक्सी एक TLS कनेक्शन सुरू करू शकते आणि बार साइडवरील लिंकर्ड-प्रॉक्सी ते समाप्त करू शकते आणि दोन्ही बाजू एकमेकांच्या TLS प्रमाणपत्रांची पडताळणी करू शकतात*. हे केवळ सेवांमधील एन्क्रिप्शनच प्रदान करत नाही तर सेवा ओळखण्यासाठी क्रिप्टोग्राफिकदृष्ट्या सुरक्षित मार्ग देखील प्रदान करते: Foo आणि Bar "सिद्ध" करू शकतात की ते म्हणतात ते ते आहेत.

* "मित्राचे म्युच्युअल" म्हणजे क्लायंटचे प्रमाणपत्र देखील सत्यापित केलेले आहे (म्युच्युअल TLS). "क्लासिक" TLS मध्ये, उदाहरणार्थ ब्राउझर आणि सर्व्हर दरम्यान, फक्त एका बाजूचे (सर्व्हर) प्रमाणपत्र सहसा सत्यापित केले जाते.

ते विनंती किंवा कनेक्शन स्तरावर कार्य करतात की नाही याची पर्वा न करता, सर्व सेवा जाळी कार्ये आहेत यावर जोर देणे महत्वाचे आहे कार्यरत वर्ण Linkerd पेलोडचे शब्दार्थ बदलण्यास सक्षम नाही - उदाहरणार्थ, JSON तुकड्यात फील्ड जोडणे किंवा प्रोटोबफमध्ये बदल करणे. जेव्हा आपण ईएसबी आणि मिडलवेअरबद्दल बोलू तेव्हा आम्ही या महत्त्वपूर्ण वैशिष्ट्याबद्दल नंतर बोलू.

हा सेवा मेष ऑफर केलेल्या वैशिष्ट्यांचा संच आहे. प्रश्न उद्भवतो: अनुप्रयोगात त्यांची थेट अंमलबजावणी का करू नये? आणि प्रॉक्सीचा अजिबात त्रास का?

सेवा जाळी का चांगली कल्पना आहे

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

चला या प्रस्तावाचे विश्लेषण करूया.

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

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

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

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

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

आणि तुम्हाला फक्त प्रॉक्सींचा समूह जोडण्याची आवश्यकता आहे! मी वचन देतो की आम्ही लवकरच या प्रॉक्सी जोडण्याशी संबंधित ऑपरेशनल खर्च पाहू. पण आधी थांबून या स्वातंत्र्याच्या कल्पनेकडे वेगवेगळ्या दृष्टिकोनातून पाहू. लोक.

सेवा जाळी कोणाला मदत करते?

तंत्रज्ञान हे परिसंस्थेचा एक महत्त्वाचा भाग बनण्यासाठी जेवढे गैरसोयीचे असेल, ते लोकांनी स्वीकारलेच पाहिजे. मग सेवा जाळीत कोणाला रस आहे? त्याच्या वापराचा फायदा कोणाला होतो?

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

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

सेवा मालकांना देखील फायदा होतो, जरी अधिक अप्रत्यक्ष मार्गाने. सेवा मालकाचे उद्दिष्ट व्यवसाय प्रक्रियेच्या तर्काची अंमलबजावणी करण्यासाठी शक्य तितके उत्पादक असणे आहे आणि त्याला ऑपरेशनल समस्यांबद्दल जितकी कमी चिंता करावी लागेल तितके चांगले. धोरणे किंवा TLS अंमलबजावणी, म्हणा, पुन्हा प्रयत्न करण्याऐवजी, ते पूर्णपणे व्यावसायिक उद्दिष्टांवर लक्ष केंद्रित करू शकतात आणि आशा आहे की प्लॅटफॉर्म बाकीची काळजी घेईल. हा त्यांच्यासाठी मोठा फायदा आहे.

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

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

थोडक्यात, सर्व्हिस मेश हा तांत्रिक नसून एक उपाय आहे सामाजिक-तांत्रिक अडचणी. (धन्यवाद सिंडी श्रीधरन ही संज्ञा सादर केल्याबद्दल.)

सेवा जाळी माझ्या सर्व समस्यांचे निराकरण करेल?

होय. म्हणजे, नाही!

जर तुम्ही वर वर्णन केलेल्या वैशिष्ट्यांचे तीन वर्ग पाहिले - विश्वासार्हता, सुरक्षितता आणि निरीक्षणक्षमता - हे स्पष्ट होते की सेवा जाळी यापैकी कोणत्याही समस्येचे पूर्ण समाधान नाही. Linkerd विनंत्या पुन्हा जारी करू शकते (जर त्यांना माहित असेल की ते अशक्त आहेत), सेवा कायमस्वरूपी अयशस्वी झाल्यास वापरकर्त्याला काय परत करावे याबद्दल निर्णय घेण्यास असमर्थ आहे - ते निर्णय अनुप्रयोगाद्वारे घेतले जाणे आवश्यक आहे. Linkerd यशस्वी विनंत्यांची आकडेवारी ठेवू शकते, परंतु ते सेवेकडे लक्ष देऊ शकत नाही आणि त्याचे अंतर्गत मेट्रिक प्रदान करू शकत नाही - अनुप्रयोगामध्ये अशी साधने असणे आवश्यक आहे. आणि जरी Linkerd mTLS आयोजित करण्यास सक्षम आहे, पूर्ण सुरक्षा उपायांसाठी बरेच काही आवश्यक आहे.

सेवा जाळीद्वारे ऑफर केलेल्या या क्षेत्रातील वैशिष्ट्यांचा उपसंच संबंधित आहे प्लॅटफॉर्म वैशिष्ट्ये. याचा अर्थ असा आहे की फंक्शन्स:

1. व्यवसाय तर्कशास्त्र स्वतंत्र. Foo आणि Bar मधील कॉल हिस्टोग्राम ज्या पद्धतीने तयार केले जातात ते पूर्णपणे स्वतंत्र आहे का फू बारला कॉल करतो.
2. योग्यरित्या अंमलात आणणे कठीण आहे. Linkerd मध्ये, पुन्हा प्रयत्न बजेट सारख्या सर्व प्रकारच्या फॅन्सी गोष्टींसह पॅरामीटराइज्ड केले जातात (बजेटसाठी पुन्हा प्रयत्न करा), कारण अशा गोष्टींची अंमलबजावणी करण्यासाठी एक अत्याधुनिक, डोके वरचा दृष्टीकोन निश्चितपणे तथाकथित "विनंत्यांच्या हिमस्खलना" च्या उदयास कारणीभूत ठरेल. (वादळ पुन्हा प्रयत्न करा) आणि वितरण प्रणालीचे वैशिष्ट्य असलेल्या इतर समस्या.
3. एकसमान लागू केल्यावर सर्वात प्रभावी. TLS यंत्रणा सर्वत्र लागू केली तरच अर्थ प्राप्त होतो.

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

सेवा जाळी क्षमतांची उदाहरणे

थोडक्यात, सेवा जाळी विश्वासार्हता, निरीक्षणक्षमता किंवा सुरक्षिततेसाठी पूर्ण उपाय नाही. या क्षेत्रांच्या व्याप्तीसाठी सेवा मालक, Ops/SRE संघ आणि इतर कंपनी घटकांचा सहभाग आवश्यक आहे. सेवा जाळी या प्रत्येक क्षेत्रासाठी फक्त प्लॅटफॉर्म-स्तरीय “स्लाइस” प्रदान करते.

सेवा जाळी सध्या लोकप्रिय का झाली आहे?

आत्तापर्यंत तुम्ही कदाचित विचार करत असाल: ठीक आहे, जर सेवा जाळी इतकी चांगली असेल, तर आम्ही दहा वर्षांपूर्वी स्टॅकमध्ये लाखो प्रॉक्सी तैनात करणे का सुरू केले नाही?

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

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

Netflix मध्ये Hysterix होते, Google ला Stubby होते, Twitter ला Finagle लायब्ररी होती. फिनागल, उदाहरणार्थ, ट्विटरवरील प्रत्येक नवीन सेवेसाठी अनिवार्य होते. याने कनेक्शनची क्लायंट आणि सर्व्हर बाजू दोन्ही हाताळली, वारंवार विनंती करण्यास अनुमती, समर्थित विनंती राउटिंग, लोड बॅलन्सिंग आणि मापन. सेवा काय करत आहे याची पर्वा न करता संपूर्ण Twitter स्टॅकवर विश्वासार्हता आणि निरीक्षणक्षमतेचा एक सुसंगत स्तर प्रदान केला. अर्थात, हे फक्त JVM भाषांसाठी काम करत होते आणि प्रोग्रामिंग मॉडेलवर आधारित होते जे संपूर्ण ऍप्लिकेशनसाठी वापरायचे होते. तथापि, त्याची कार्यक्षमता जवळजवळ सेवा जाळी सारखीच होती. (खरं तर, लिंकर्डची पहिली आवृत्ती फक्त प्रॉक्सी स्वरूपात फिनागल गुंडाळलेली होती.)

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

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

वर्तमानाकडे जलद पुढे जा. आज अशी स्टार्टअप्स आहेत जिथे मायक्रोसर्व्हिसेस आणि डेव्हलपरचे गुणोत्तर ५:१ (किंवा अगदी 10:1), आणि आणखी काय, ते त्यांच्याशी यशस्वीपणे सामना करतात! जर 5-व्यक्ती स्टार्टअप सहजपणे 50 मायक्रो सर्व्हिसेस ऑपरेट करू शकतात, तर काहीतरी स्पष्टपणे त्यांच्या अंमलबजावणीची किंमत कमी केली आहे.

मोंझो मध्ये 1500 मायक्रोसर्व्हिसेस; प्रत्येक ओळ एक विहित नेटवर्क नियम आहे जो रहदारीस परवानगी देतो

ऑपरेटिंग मायक्रोसर्व्हिसेसच्या किंमतीतील नाट्यमय घट एका प्रक्रियेचा परिणाम आहे: कंटेनरची वाढती लोकप्रियता и वाद्यवृंद. सेवा जाळीच्या उदयास काय योगदान दिले या प्रश्नाचे हे तंतोतंत सखोल उत्तर आहे. त्याच तंत्रज्ञानाने सर्व्हिस मेश आणि मायक्रोसर्व्हिसेस दोन्ही आकर्षक बनवले: कुबर्नेट्स आणि डॉकर.

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

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

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

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

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

सेवा जाळीबद्दल इतकी चर्चा का आहे?

प्रतिबंध: या विभागात मी सर्व प्रकारच्या गृहीतके, अनुमान, बनावट आणि आतील माहिती वापरतो.

"सर्व्हिस मेश" साठी शोधा आणि तुम्हाला एक टन पुनर्नवीनीकरण कमी-कॅलरी सामग्री, विचित्र प्रकल्प आणि इको चेंबरसाठी योग्य विकृतीचा कॅलिडोस्कोप मिळेल. कोणतेही फॅन्सी नवीन तंत्रज्ञान हे करते, परंतु सेवा जाळीच्या बाबतीत समस्या विशेषतः तीव्र आहे. का?

बरं, त्यात माझी चूक आहे. यासारख्या असंख्य ब्लॉग पोस्ट आणि लेखांद्वारे मला मिळालेल्या प्रत्येक संधीला मी Linkerd आणि सेवा जाळीचा प्रचार करण्यासाठी कठोर परिश्रम करत आहे. पण मी तितका शक्तिशाली नाही. या प्रश्नाचे खरोखर उत्तर देण्यासाठी, आपण एकूण परिस्थितीबद्दल थोडे बोलणे आवश्यक आहे. आणि एका प्रकल्पाचा उल्लेख केल्याशिवाय याबद्दल बोलणे अशक्य आहे: इस्टिओ Google, IBM आणि Lyft द्वारे संयुक्तपणे विकसित केलेली एक मुक्त स्रोत सेवा जाळी आहे.

(तिन्ही कंपन्यांच्या भूमिका खूप भिन्न आहेत: लिफ्टचा सहभाग केवळ नावापुरता दिसतो; ते दूताचे लेखक आहेत, परंतु Istio च्या विकासामध्ये ते वापरत नाहीत किंवा सहभागी होत नाहीत. IBM Istio च्या विकासामध्ये सहभागी आहे आणि वापरते. Google Istio च्या विकासामध्ये सक्रियपणे सहभागी आहे. विकास , परंतु मी सांगू शकेन तितके ते प्रत्यक्षात वापरत नाही.)

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

(अभ्यासात, इस्टिओला केवळ जटिलता आणि UXच नाही तर कार्यक्षमतेतही समस्या आहेत असे दिसते. उदाहरणार्थ, दरम्यान. लिंकर्ड कामगिरी रेटिंगतृतीय-पक्षाच्या अभ्यासात, संशोधकांना अशी परिस्थिती आढळून आली ज्यामध्ये इस्टिओची शेपटी विलंबता Linkerd च्या तुलनेत 100 पट जास्त होती, तसेच संसाधन-अभावी परिस्थिती आढळून आली जिथे Linkerd यशस्वीरित्या कार्य करत असताना इस्टिओने पूर्णपणे काम करणे थांबवले.)

हे का घडले याविषयीचे माझे सिद्धांत बाजूला ठेवून, मला विश्वास आहे की सेवा जाळीभोवती प्रचंड उत्साह Google च्या सहभागाने स्पष्ट केला आहे. म्हणजे, खालील तीन घटकांचे संयोजन:

1. Istio ची Google च्या अनाहूत जाहिरात;
2. प्रकल्पाबद्दल संबंधित नापसंत, गंभीर वृत्ती;
3. कुबर्नेट्सच्या लोकप्रियतेत अलीकडील उल्कापात वाढ, ज्याच्या आठवणी अजूनही ताज्या आहेत.

हे घटक एकत्रितपणे एक मूर्ख, ऑक्सिजन-मुक्त वातावरण तयार करतात ज्यामध्ये तर्कशुद्ध निर्णय घेण्याची क्षमता कमकुवत होते आणि फक्त विचित्र विविधता शिल्लक राहते. ट्यूलिप उन्माद.

Linkerd च्या दृष्टीकोनातून, हे आहे... मी मिश्र आशीर्वाद म्हणून वर्णन करेन. म्हणजे, हे खूप छान आहे की सर्व्हिस मेशने मुख्य प्रवाहात अशा प्रकारे प्रवेश केला आहे की तो 2016 मध्ये झाला नाही जेव्हा Linkerd पहिल्यांदा सुरू झाला आणि लोकांना प्रकल्पाकडे लक्ष देणे खरोखर कठीण होते. आता अशी कोणतीही समस्या नाही! पण वाईट बातमी अशी आहे की आज सर्व्हिस मेश लँडस्केप इतका गोंधळात टाकणारा आहे की प्रत्यक्षात कोणते प्रोजेक्ट सर्व्हिस मेश श्रेणीतील आहेत हे समजणे जवळजवळ अशक्य आहे (विशिष्ट वापराच्या केससाठी कोणता सर्वात योग्य आहे हे समजू द्या). हे निश्चितपणे प्रत्येकासाठी डीलब्रेकर आहे (आणि निश्चितपणे काही प्रकरणे आहेत जिथे इस्टिओ किंवा दुसरा प्रकल्प Linkerd पेक्षा अधिक योग्य आहे, कारण नंतरचे अद्याप सार्वत्रिक समाधान नाही).

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

दरम्यान, आपल्या सर्वांना थोडा धीर धरावा लागेल.

एक सेवा जाळी मला उपयोगी पडेल, एक नम्र सॉफ्टवेअर अभियंता?

खालील प्रश्नावली तुम्हाला या प्रश्नाचे उत्तर देण्यात मदत करेल:

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

कुबर्नेट्स वापरणाऱ्या कंपनीच्या प्लॅटफॉर्मला तुम्ही सपोर्ट करत आहात का? होय, या प्रकरणात तुम्हाला सर्व्हिस मेशची आवश्यकता आहे (अर्थातच, तुम्ही फक्त मोनोलिथ किंवा बॅच प्रोसेसिंग चालवण्यासाठी K8s वापरत नाही - पण मग तुम्हाला K8 ची गरज का आहे हे मी विचारू इच्छितो). तुमच्याकडे वेगवेगळ्या लोकांनी लिहिलेल्या बर्‍याच मायक्रो सर्व्हिसेस मिळण्याची शक्यता आहे. ते सर्व एकमेकांशी संवाद साधतात आणि रनटाइम अवलंबित्वाच्या गुंतागुंतीत बांधले जातात आणि तुम्हाला या सर्वांचा सामना करण्याचा मार्ग शोधण्याची आवश्यकता आहे. Kubernetes वापरणे तुम्हाला "स्वतःसाठी" सेवा जाळी निवडण्याची परवानगी देते. हे करण्यासाठी, त्यांच्या क्षमता आणि वैशिष्ट्यांसह स्वत: ला परिचित करा आणि उपलब्ध प्रकल्पांपैकी कोणतेही आपल्यासाठी योग्य आहेत की नाही या प्रश्नाचे उत्तर द्या (मी आपले संशोधन Linkerd सह सुरू करण्याची शिफारस करतो).

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

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

निष्कर्ष

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

तुम्ही Linkerd वापरून पहावे असे मला वाटते - ते Kubernetes क्लस्टरवर (किंवा अगदी लॅपटॉपवर Minikube) स्थापित करणे. सुमारे 60 सेकंद लागतात, आणि मी कशाबद्दल बोलत आहे ते तुम्ही स्वतः पाहू शकता.

FAQ

— जर मी सेवा जाळीकडे दुर्लक्ष केले तर ते अदृश्य होईल का?
- मी तुम्हाला निराश केले पाहिजे: सेवा जाळी आमच्याबरोबर बर्याच काळापासून आहे.

- पण मला सेवा जाळी वापरायची नाही!
- बरं, हे आवश्यक नाही! तुम्ही किमान त्याच्या मूलभूत गोष्टींशी परिचित व्हावे की नाही हे समजून घेण्यासाठी फक्त माझी वरील प्रश्नावली वाचा.

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

— सेवा जाळी API गेटवेपेक्षा कशी वेगळी आहे?
- या विषयावर एक दशलक्ष लेख आहेत. फक्त गुगल करा.

— दूत ही सेवा जाळी आहे?
- नाही, दूत सेवा जाळी नाही, तो एक प्रॉक्सी सर्व्हर आहे. हे सेवा जाळी आयोजित करण्यासाठी वापरले जाऊ शकते (आणि बरेच काही - हे एक सामान्य उद्देश प्रॉक्सी आहे). पण स्वतःच ती सेवा जाळी नाही.

— नेटवर्क सर्व्हिस मेश ही सेवा जाळी आहे?
- नाही. नाव असूनही, ही सेवा जाळी नाही (आपल्याला विपणन चमत्कार कसे आवडतात?).

— सेवा जाळी माझ्या संदेश रांगेवर आधारित प्रतिक्रियाशील असिंक्रोनस प्रणालीला मदत करेल का?
- नाही, सेवा जाळी तुम्हाला मदत करणार नाही.

— मी कोणती सेवा जाळी वापरावी?
- लिंकर्ड, ब्रेनर नाही.

- लेख उदास आहे! / लेखकाचे स्वागत आहे!
— कृपया तुमच्या सर्व मित्रांसह त्याची लिंक शेअर करा जेणेकरून ते ते पाहू शकतील!

पोचपावती

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

मला स्वतःला "लिंकर्ड डेव्हलपर" म्हणवायला आवडते, परंतु वास्तविकता अशी आहे की मी प्रकल्पावरील README.md फाइलचा अधिक देखरेख करणारा आहे. आज Linkerd वर काम केले जात आहे खूप, खूप, खूप भरपूर लोक, आणि हा प्रकल्प योगदानकर्त्यांच्या आणि वापरकर्त्यांच्या अद्भुत समुदायाच्या सहभागाशिवाय घडला नसता.

आणि शेवटी, लिंकर्डच्या निर्मात्याचे विशेष आभार, ऑलिव्हर गोल्ड (प्राइमस इंटर पॅरेस), ज्यांनी, बर्याच वर्षांपूर्वी माझ्यासह, सर्व्हिस मेशसह या सर्व गोंधळात डोके वर काढले होते.

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

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

• «सर्व्हिस मेश म्हणजे काय आणि मला [मायक्रोसर्व्हिसेससह क्लाउड ऍप्लिकेशनसाठी] याची आवश्यकता का आहे?";
• «Traefik 2.0: TCP समर्थन आणि नवीन वेब इंटरफेससह सर्व्हिस मेश अपडेट";
• «Maesh - Traefik च्या लेखकांकडून Kubernetes साठी एक नवीन साधी सेवा जाळी";
• «Istio सह microservices वर परत. भाग 1";
• «कंड्युट - कुबर्नेट्ससाठी हलकी सेवा जाळी».

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