सेवा जाल: प्रत्येक सफ्टवेयर इन्जिनियरलाई सबैभन्दा हाइप गरिएको टेक्नोलोजीको बारेमा जान्न आवश्यक छ

नोट। अनुवाद।: सेवा जाल एक घटना हो जसको रुसी भाषामा अझै स्थिर अनुवाद छैन (२ वर्ष भन्दा बढी पहिले हामीले "सेवाहरूको लागि जाल" विकल्प प्रस्ताव गरेका थियौं, र केही समय पछि केही सहकर्मीहरूले "सेवा चलनी" संयोजनलाई सक्रिय रूपमा प्रवर्द्धन गर्न थाले)। यस प्रविधिको बारेमा निरन्तर कुराकानीले मार्केटिङ र प्राविधिक कम्पोनेन्टहरू धेरै नजिकबाट गाँसिएको अवस्थाको नेतृत्व गरेको छ। मूल शब्दको लेखकहरू मध्ये एकबाट यो अद्भुत सामग्री ईन्जिनियरहरू र अरूलाई स्पष्टता प्रदान गर्ने उद्देश्य हो।

हास्य बाट सेबास्टियन कासेरेस

परिचय

यदि तपाइँ ब्याकएन्ड प्रणाली स्पेसमा कतै काम गर्ने सफ्टवेयर इन्जिनियर हुनुहुन्छ भने, "सेवा जाल" शब्द सम्भवतः विगतका दुई वर्षहरूमा तपाइँको दिमागमा दृढतापूर्वक गाँसिएको छ। एउटा अनौठो संयोगको कारणले गर्दा, यो वाक्यांशले उद्योगलाई झन् बढी लिइरहेको छ, र यससँग सम्बन्धित हाइप र प्रमोशनल अफरहरू डाउनहिलमा उडिरहेको स्नोबल जस्तै बढिरहेका छन् र सुस्त हुने कुनै संकेत देखाउँदैनन्।

क्लाउड नेटिभ इकोसिस्टमको धमिलो, पक्षपाती पानीमा सेवा जालको जन्म भएको थियो। दुर्भाग्यवश, यसको मतलब यो हो कि यसको वरिपरि धेरै विवाद "कम-क्यालोरी वार्ता" देखि प्राविधिक शब्द प्रयोग गर्न को लागी - स्पष्ट बकवास हो। तर यदि तपाईंले सबै आवाज काट्नु भयो भने, तपाईंले सेवा जालसँग धेरै वास्तविक, परिभाषित र महत्त्वपूर्ण प्रकार्य छ भनी पाउनुहुनेछ।

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

म को हु?

नमस्ते सबै! मेरो नाम विलियम मोर्गन। म सृष्टिकर्ता मध्ये एक हुँ लिङ्कर्ड - धेरै पहिलो सेवा जाल परियोजना र शब्द को उपस्थिति को लागी दोष छ कि परियोजना सेवा जाल जस्तै (माफ गर्नुहोस् साथीहरू!) (नोट अनुवाद।: वैसे, यो शब्दको उपस्थितिको बिहानमा, 2,5 वर्ष भन्दा पहिले, हामीले पहिले नै उही लेखकको प्रारम्भिक सामग्री अनुवाद गरिसकेका छौं "सेवा जाल के हो र मलाई किन चाहिन्छ [माइक्रोसर्भिसेसको साथ क्लाउड अनुप्रयोगको लागि]?"।) म पनि टाउको बुयुएन्ट एक स्टार्टअप हो जसले Linkerd र जस्तै राम्रो सेवा जाल चीजहरू सिर्जना गर्दछ गोता.

तपाईले अनुमान लगाउन सक्नुहुन्छ कि मसँग यस मुद्दामा धेरै पक्षपाती र व्यक्तिपरक राय छ। यद्यपि, म पूर्वाग्रहलाई न्यूनतममा राख्ने प्रयास गर्नेछु (एउटा खण्ड बाहेक: "सेवा जालको बारेमा किन यति धेरै चर्चा छ?", - जसमा म अझै पनि मेरो पूर्वधारण विचारहरू साझा गर्नेछु)। म यस गाइडलाई सकेसम्म उद्देश्यपूर्ण बनाउन सक्दो प्रयास गर्नेछु। विशिष्ट उदाहरणहरूको लागि, म मुख्य रूपमा Linkerd को अनुभवमा भर पर्नेछु, जबकि अन्य सेवा जाल प्रकारहरूको कार्यान्वयनमा मलाई थाहा भएको भिन्नताहरू (यदि कुनै हो भने) औंल्याउछु।

ठीक छ, गुडीहरूमा जानको लागि समय।

सेवा जाल के हो?

सबै प्रचार को बावजूद, सेवा जाल को संरचना एकदम सरल छ। यो केवल प्रयोगकर्तास्पेस प्रोक्सीहरूको गुच्छा हो जुन सेवाहरूको "छेउमा" अवस्थित छ (हामी "अर्को" पछि के हो भन्ने बारे थोरै कुरा गर्नेछौं), साथै नियन्त्रण प्रक्रियाहरूको सेट। प्रोक्सीहरू सामूहिक रूपमा बोलाइन्छ डाटा प्लेन, र नियन्त्रण प्रक्रियाहरू भनिन्छ नियन्त्रण विमान। डाटा प्लेनले सेवाहरू बीचको कलहरू रोक्छ र तिनीहरूसँग "सबै प्रकारका विभिन्न चीजहरू" गर्छ; नियन्त्रण विमान, तदनुसार, प्रोक्सीको व्यवहार समन्वय गर्दछ र तपाइँको लागि पहुँच प्रदान गर्दछ, अर्थात्। अपरेटर, API लाई, नेटवर्कलाई हेरफेर गर्न र सम्पूर्ण रूपमा मापन गर्न अनुमति दिँदै।

यो कस्तो प्रकारको प्रोक्सी हो? यो लेयर 7-सचेत TCP प्रोक्सी हो (अर्थात् OSI मोडेलको "खातामा" लेयर 7) जस्तै HAProxy र NGINX। तपाईं आफ्नो मनपर्ने प्रोक्सी छनोट गर्न सक्नुहुन्छ; Linkerd रस्ट प्रोक्सी प्रयोग गर्दछ, साधारण नाम linkerd-proxy। हामीले यसलाई सेवा जालको लागि विशेष रूपमा राख्यौं। अन्य मेशहरूले अन्य प्रोक्सीहरूलाई प्राथमिकता दिन्छन् (दूत एक साझा विकल्प हो)। यद्यपि, प्रोक्सी छनौट गर्नु भनेको कार्यान्वयनको कुरा मात्र हो।

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

त्यसोभए, हामीले डाटा प्लेनलाई क्रमबद्ध गरेका छौं। कन्ट्रोल प्लेन सरल छ: यो कम्पोनेन्टहरूको सेट हो जसले डेटा प्लेनले सेवा खोज, TLS प्रमाणपत्र जारी गर्ने, मेट्रिक एग्रीगेसन, इत्यादि सहित समन्वित रूपमा सञ्चालन गर्न आवश्यक पर्ने सबै मेकानिकहरू प्रदान गर्दछ। डाटा प्लेनले नियन्त्रण प्लेनलाई जानकारी दिन्छ। यसको व्यवहार; बदलामा, कन्ट्रोल प्लेनले एपीआई प्रदान गर्दछ जसले तपाईंलाई डेटा प्लेनको व्यवहारलाई समग्र रूपमा परिवर्तन गर्न र निगरानी गर्न अनुमति दिन्छ।

तल Linkerd मा नियन्त्रण विमान र डाटा प्लेन को रेखाचित्र छ। तपाईले देख्न सक्नुहुने रूपमा, कन्ट्रोल प्लेनले धेरै फरक कम्पोनेन्टहरू समावेश गर्दछ, प्रोमेथियस उदाहरण सहित जसले प्रोक्सी सर्भरहरूबाट मेट्रिक्स सङ्कलन गर्दछ, साथै अन्य कम्पोनेन्टहरू जस्तै। destination (सेवा खोज), identity (प्रमाणपत्र प्राधिकरण, CA) र public-api (वेब र CLI को लागि अन्तिम बिन्दुहरू)। यसको विपरित, डाटा प्लेन अनुप्रयोग उदाहरणको छेउमा एक साधारण लिङ्कर्ड-प्रोक्सी हो। यो केवल एक तर्क रेखाचित्र हो; वास्तविक-विश्व परिनियोजनमा, तपाईंसँग प्रत्येक नियन्त्रण प्लेन कम्पोनेन्टको तीन प्रतिकृतिहरू र डाटा प्लेनमा सयौं वा हजारौं प्रोक्सीहरू हुन सक्छन्।

(यस रेखाचित्रमा निलो आयतहरूले Kubernetes पोडहरूको सीमाहरूलाई सङ्केत गर्छ। तपाईंले देख्न सक्नुहुन्छ कि लिङ्कर्ड-प्रोक्सी भएका कन्टेनरहरू एप्लिकेसन कन्टेनरहरू जस्तै पोडमा छन्। यो योजनालाई भनिन्छ। साइडकार कन्टेनर.)

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

अर्को महत्त्वपूर्ण परिणाम सेवा जाल आवश्यक छ विशाल प्रोक्सीहरूको संख्या। वास्तवमा, Linkerd ले प्रत्येक सेवाको प्रत्येक उदाहरणमा linkerd-proxy जोड्छ (अन्य कार्यान्वयनहरूले प्रत्येक नोड/होस्ट/भर्चुअल मेसिनमा प्रोक्सी थप्छ। त्यो जे भए पनि धेरै हो)। प्रोक्सीहरूको यस्तो सक्रिय प्रयोगले आफैंमा धेरै अतिरिक्त जटिलताहरू बोक्छ:

1. डाटा प्लेनमा प्रोक्सीहरू हुनुपर्छ छिटो, किनकि प्रत्येक कलको लागि प्रोक्सीमा दुईवटा कलहरू छन्: एउटा ग्राहक पक्षमा, एउटा सर्भर साइडमा।
2. प्रोक्सी पनि हुनुपर्छ सानो и हल्का। प्रत्येकले मेमोरी र CPU स्रोतहरू उपभोग गर्नेछ, र यो खपत एप्लिकेसनसँग रैखिक रूपमा बढ्नेछ।
3. तपाईलाई ठूलो संख्यामा प्रोक्सीहरू डिप्लोइ र अपडेट गर्नको लागि एउटा संयन्त्र चाहिन्छ। यसलाई म्यानुअल रूपमा गर्नु विकल्प होइन।

सामान्यतया, सेवा जाल यस्तो देखिन्छ (कम से कम एक चराको आँखाको दृश्यबाट): तपाईले प्रयोगकर्तास्पेस प्रोक्सीहरूको गुच्छा तैनात गर्नुहुन्छ जसले आन्तरिक, अन्तर-सेवा ट्राफिकसँग "केही गर्छ" र तिनीहरूलाई निगरानी र व्यवस्थापन गर्न नियन्त्रण विमान प्रयोग गर्दछ।

अब यो प्रश्न सोध्ने समय हो "किन?"

सेवा जाल के को लागी हो?

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

यस प्रश्नको जवाफ दुई भागहरू छन्। पहिलो, यी प्रोक्सीहरू तैनातीसँग सम्बन्धित लेनदेन लागतहरू इकोसिस्टममा भइरहेको केही परिवर्तनहरूको कारणले उल्लेखनीय रूपमा कम गर्न सकिन्छ (यसको बारेमा पछि थप)।

दोस्रो, यो जस्तै उपकरण वास्तवमा प्रणाली मा अतिरिक्त तर्क परिचय को लागी एक राम्रो तरिका हो। सेवा जालले धेरै नयाँ कार्यक्षमता थप्न सक्ने मात्र होइन, तर यो इकोसिस्टममा हस्तक्षेप नगरी पनि गर्न सकिन्छ। वास्तवमा, सम्पूर्ण सेवा जाल मोडेल यस आधारमा आधारित छ: बहु-सेवा प्रणालीमा, जे भए पनि गर्नुहोस् व्यक्तिगत सेवा, यातायात तिनीहरुको बिचमा कार्यक्षमता थप्नको लागि आदर्श बिन्दु हो।

उदाहरणका लागि, Linkerd मा (धेरै मेशहरूमा जस्तै) कार्यक्षमता मुख्य रूपमा HTTP/2 र gRPC* सहित HTTP कलहरूमा केन्द्रित हुन्छ। कार्यक्षमता धेरै धनी छ - यसलाई तीन वर्गमा विभाजन गर्न सकिन्छ:

1. सम्बन्धित सुविधाहरू विश्वसनीयता। दोहोर्याइएको अनुरोधहरू, टाइमआउटहरू, क्यानरी दृष्टिकोण (ट्राफिक विभाजन/पुनर्निर्देशन), आदि।
2. सम्बन्धित सुविधाहरू निगरानी। प्रत्येक सेवा वा व्यक्तिगत निर्देशनहरूको लागि सफलता दर, ढिलाइ र अनुरोध भोल्युमहरूको एकत्रीकरण; सेवाहरूको टोपोलोजिकल नक्सा निर्माण, आदि।
3. सम्बन्धित सुविधाहरू सुरक्षा। म्युचुअल TLS, पहुँच नियन्त्रण, आदि।

* Linkerd को दृष्टिकोणबाट, gRPC व्यावहारिक रूपमा HTTP/2 बाट फरक छैन: यसले केवल पेलोडमा प्रोटोबफ प्रयोग गर्दछ। विकासकर्ताको दृष्टिकोणबाट, दुई चीजहरू, अवश्य पनि, फरक छन्।

यी धेरै संयन्त्रहरू अनुरोध स्तरमा काम गर्छन् (त्यसैले "L7 प्रोक्सी")। उदाहरणका लागि, यदि Foo सेवाले बार सेवामा HTTP कल गर्छ भने, Foo छेउमा linkerd-proxy ले बुद्धिमानी लोड ब्यालेन्सिङ गर्न सक्छ र अवलोकन गरिएको विलम्बताको आधारमा Foo देखि बार इन्स्ट्यान्सहरूमा कल कलहरू गर्न सक्छ; यदि आवश्यक भएमा यो अनुरोध दोहोर्याउन सक्छ (र यदि यो असक्षम छ भने); यसले प्रतिक्रिया कोड र टाइमआउट, आदि रेकर्ड गर्न सक्छ। त्यसै गरी, बार साइडमा लिङ्कर्ड-प्रोक्सीले अनुरोध अस्वीकार गर्न सक्छ यदि यो अनुमति छैन वा अनुरोध सीमा नाघ्यो भने; यसको पक्षमा ढिलाइ रेकर्ड गर्न सक्छ, आदि।

प्रोक्सीहरूले जडान स्तरमा पनि "केही गर्न" सक्छन्। उदाहरण को लागी, Foo छेउमा linkerd-proxy ले TLS जडान सुरु गर्न सक्छ, र पट्टी छेउमा linkerd-proxy ले यसलाई समाप्त गर्न सक्छ, र दुबै पक्षले एकअर्काको TLS प्रमाणपत्रहरू प्रमाणित गर्न सक्छन्*। यसले सेवाहरू बीचको इन्क्रिप्शन मात्र प्रदान गर्दैन, तर सेवाहरू पहिचान गर्ने क्रिप्टोग्राफिक रूपमा सुरक्षित तरिका पनि प्रदान गर्दछ: Foo र बारले तिनीहरू हुन् भनेर "प्रमाण" गर्न सक्छन्।

* "मित्रको म्युचुअल" भनेको ग्राहकको प्रमाणपत्र पनि प्रमाणित भएको हो (आपसी TLS)। "क्लासिक" TLS मा, उदाहरणका लागि ब्राउजर र सर्भरको बीचमा, केवल एक पक्ष (सर्भर) को प्रमाणपत्र सामान्यतया प्रमाणित हुन्छ।

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

यो सेवा जाल प्रदान गर्ने सुविधाहरूको सेट हो। प्रश्न उठ्छ: किन तिनीहरूलाई सीधा अनुप्रयोगमा लागू नगर्ने? र प्रोक्सीसँग किन चिन्ता लिने?

किन सेवा जाल एक राम्रो विचार हो

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

यस प्रस्तावको विश्लेषण गरौं।

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

(ठीक छ, अघिल्लो अनुच्छेदमा अझै पनि मेरो विश्वास समावेश छ कि यो दृष्टिकोण सर्भर सफ्टवेयर सिर्जना गर्ने आधुनिक तरिका हो। अरूले मोनोलिथहरू, "प्रतिक्रियात्मक माइक्रोसर्विसेस" र अन्य चीजहरू विकास गर्न रुचाउँछन् जुन माथि दिइएको परिभाषा अन्तर्गत पर्दैन। यी व्यक्तिहरूले सम्भवतः आफ्नो राय मेरो भन्दा फरक छ। बदलामा, मलाई लाग्छ कि तिनीहरू "गलत" छन् - यद्यपि कुनै पनि अवस्थामा सेवा जाल तिनीहरूका लागि धेरै उपयोगी छैन)।

«सम्पूर्ण स्ट्याकको लागि वर्दी" सेवा जाल द्वारा प्रदान गरिएको कार्यक्षमता मिशन-महत्वपूर्ण मात्र होइन। तिनीहरू कुन भाषामा लेखिएका छन्, कुन ढाँचा प्रयोग गर्छन्, कसले लेखेका छन्, तिनीहरू कसरी प्रयोगमा आएका छन्, र तिनीहरूको विकास र प्रयोगको अन्य कुनै पनि सूक्ष्मताहरूको ख्याल नगरी तिनीहरू एप्लिकेसनका सबै सेवाहरूमा लागू हुन्छन्।

«आवेदन कोड बाट स्वतन्त्र" अन्तमा, सेवा जालले सम्पूर्ण स्ट्याकमा निरन्तर कार्यक्षमता मात्र प्रदान गर्दैन, यसले अनुप्रयोगलाई सम्पादन गर्न आवश्यक पर्दैन। कन्फिगरेसन, अपडेट गर्ने, सञ्चालन, मर्मतसम्भार, इत्यादिका लागि कार्यहरू सहित सेवा जाल कार्यक्षमताको आधारभूत आधार पूर्ण रूपमा प्लेटफर्म स्तरमा रहन्छ र अनुप्रयोगबाट स्वतन्त्र छ। अनुप्रयोग सेवा जाल प्रभावित बिना परिवर्तन गर्न सक्नुहुन्छ। बारीमा, सेवा जाल अनुप्रयोगबाट कुनै पनि सहभागिता बिना परिवर्तन गर्न सक्छ।

छोटकरीमा, सेवा जालले महत्त्वपूर्ण कार्यक्षमता मात्र प्रदान गर्दैन, तर विश्वव्यापी, एकसमान, र अनुप्रयोग-स्वतन्त्र रूपमा पनि गर्छ। र यसैले, यद्यपि सेवा जाल कार्यक्षमता सेवा कोडमा लागू गर्न सकिन्छ (उदाहरणका लागि, प्रत्येक सेवामा समावेश गरिएको पुस्तकालयको रूपमा), यो दृष्टिकोणले एकरूपता र स्वतन्त्रता प्रदान गर्दैन जुन सेवा जालको मामलामा धेरै मूल्यवान छ।

र तपाईले गर्नु पर्ने भनेको प्रोक्सीहरूको गुच्छा थप्नु हो! म वाचा गर्छु कि हामी यी प्रोक्सीहरू थप्न सम्बन्धित परिचालन लागतहरू छिट्टै हेर्नेछौं। तर पहिले रोकौं र स्वतन्त्रताको यो विचारलाई विभिन्न दृष्टिकोणबाट हेरौं। मान्छे को.

सेवा जाल कसले मद्दत गर्छ?

जतिसुकै असुविधाजनक होस्, प्रविधिलाई इकोसिस्टमको महत्त्वपूर्ण भाग बन्नको लागि, यसलाई मानिसहरूले स्वीकार गर्नुपर्छ। त्यसोभए सेवा जालमा कसको रुचि छ? यसको प्रयोगबाट कसलाई फाइदा हुन्छ?

यदि तपाइँ आधुनिक सर्भर सफ्टवेयर विकास गर्दै हुनुहुन्छ भने, तपाइँ आफ्नो टोलीलाई एक समूहको रूपमा सोच्न सक्नुहुन्छ सेवा मालिकहरूजसले सँगै व्यापार तर्कको विकास र कार्यान्वयन गर्दछ, र प्लेटफर्म मालिकहरू, यी सेवाहरू सञ्चालन गर्ने आन्तरिक प्लेटफर्मको विकास गर्दै। साना संगठनहरूमा, यी समान व्यक्तिहरू हुन सक्छन्, तर कम्पनी बढ्दै जाँदा, यी भूमिकाहरू अझ स्पष्ट हुन जान्छ र उप-भूमिकाहरूमा पनि विभाजित हुन्छ ... सूक्ष्म सेवाहरूको संगठनात्मक प्रभाव, आदि) n। तर अहिलेको लागि यी विवरणहरूलाई दिइएको रूपमा लिनुहोस्)।

यस दृष्टिकोणबाट, सेवा जालका स्पष्ट लाभार्थीहरू प्लेटफर्म मालिकहरू हुन्। आखिरमा, प्लेटफर्म टोलीको लक्ष्य भनेको आन्तरिक प्लेटफर्म सिर्जना गर्नु हो जसमा सेवा मालिकहरूले व्यापार तर्क लागू गर्न सक्छन् र त्यसो गर्ने तरीकाले तिनीहरू यसको सञ्चालनको अस्पष्ट विवरणहरूबाट सकेसम्म स्वतन्त्र छन् भन्ने सुनिश्चित गर्दछ। सेवा जालले यो लक्ष्य हासिल गर्नको लागि महत्वपूर्ण क्षमताहरू मात्र प्रदान गर्दैन, यसले सेवा मालिकहरूमा निर्भरता नथोप्ने तरिकाले गर्छ।

सेवा मालिकहरूले पनि लाभ उठाउँछन्, यद्यपि अधिक अप्रत्यक्ष रूपमा। सेवा मालिकको लक्ष्य व्यापार प्रक्रियाको तर्क लागू गर्न सकेसम्म उत्पादक हुनु हो, र उसले कम परिचालन मुद्दाहरूको बारेमा चिन्ता गर्नु पर्छ, राम्रो। नीतिहरू वा TLS कार्यान्वयन गर्न, भन्नुहोस्, पुन: प्रयास गर्नुहोस्, तिनीहरूले व्यापार उद्देश्यहरूमा मात्र ध्यान केन्द्रित गर्न सक्छन् र प्लेटफर्मले बाँकीको ख्याल राख्छ भन्ने आशा गर्न सक्छन्। यो उनीहरूको लागि ठूलो फाइदा हो।

प्लेटफर्महरू र सेवाहरूको मालिकहरू बीचको यस्तो विभाजनको संगठनात्मक मूल्यलाई बढी अनुमान गर्न सकिँदैन। मलाई लाग्छ उनले योगदान गर्छिन् मुख्य सेवा जालको मूल्यमा योगदान।

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

छोटकरीमा, सेवा जाल अधिक समाधान हो, प्राविधिक होइन, तर सामाजिक-प्राविधिक समस्याहरू। (धन्यवाद सिन्डी श्रीधरन यो शब्द परिचयको लागि।)

के सेवा जालले मेरो सबै समस्याहरू समाधान गर्छ?

हो। मेरो मतलब, होइन!

यदि तपाइँ माथि उल्लिखित सुविधाहरूको तीन वर्गहरू हेर्नुभयो भने - विश्वसनीयता, सुरक्षा, र अवलोकन - यो स्पष्ट हुन्छ कि सेवा जाल यी कुनै पनि समस्याहरूको पूर्ण समाधान होइन। जबकि Linkerd ले अनुरोधहरू पुन: जारी गर्न सक्छ (यदि यो थाहा छ कि तिनीहरू असक्षम छन्), यो सेवा स्थायी रूपमा असफल भएको छ भने प्रयोगकर्तालाई के फिर्ता गर्ने भन्ने बारे निर्णय गर्न असमर्थ छ - ती निर्णयहरू एप्लिकेसनद्वारा हुनुपर्छ। Linkerd ले सफल अनुरोधहरूको तथ्याङ्क राख्न सक्छ, तर यो सेवा हेर्न र यसको आन्तरिक मेट्रिक्स प्रदान गर्न सक्षम छैन - अनुप्रयोगसँग त्यस्ता उपकरणहरू हुनुपर्दछ। र यद्यपि Linkerd mTLS संगठित गर्न सक्षम छ, पूर्ण सुरक्षा समाधानहरू धेरै आवश्यक छ।

सेवा जाल द्वारा प्रस्तावित यी क्षेत्रहरूमा सुविधाहरूको एक उपसमूह सम्बन्धित छ प्लेटफर्म सुविधाहरू। यसबाट मेरो मतलब कार्यहरू जुन:

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

यी कार्यहरू प्रोक्सी स्तरमा लागू गरिएको हुनाले (र अनुप्रयोग स्तरमा होइन), सेवा जालले तिनीहरूलाई प्रदान गर्दछ। प्लेटफर्म, अनुप्रयोगहरू होइन। तसर्थ, सेवाहरू कुन भाषामा लेखिएका छन्, तिनीहरूले कुन ढाँचा प्रयोग गर्छन्, कसले र किन लेखेका छन् भन्ने कुराले फरक पार्दैन। प्रोक्सीहरू यी सबै विवरणहरू बाहिर काम गर्छन्, र कन्फिगरेसन, अद्यावधिक, सञ्चालन, मर्मतसम्भार, इत्यादिका लागि कार्यहरू सहित, यो कार्यक्षमताको आधारभूत आधार मात्र प्लेटफर्म स्तरमा निहित हुन्छ।

सेवा जाल क्षमताहरूको उदाहरणहरू

संक्षेपमा, सेवा जाल विश्वसनीयता, अवलोकन, वा सुरक्षाको लागि पूर्ण समाधान होइन। यी क्षेत्रहरूको दायरा सेवा मालिकहरू, Ops/SRE टोलीहरू र अन्य कम्पनी निकायहरूको सहभागिता आवश्यक छ। सेवा जालले यी प्रत्येक क्षेत्रका लागि प्लेटफर्म-स्तर "स्लाइस" मात्र प्रदान गर्दछ।

किन सेवा जाल अहिले लोकप्रिय भएको छ?

अहिले सम्म तपाई सायद सोचिरहनु भएको छ: ठीक छ, यदि सेवा जाल यति राम्रो छ भने, हामीले दस वर्ष पहिले स्ट्याकमा लाखौं प्रोक्सीहरू तैनाथ गर्न किन सुरु गरेनौं?

यस प्रश्नको साधारण जवाफ छ: दस वर्ष पहिले सबैले मोनोलिथहरू बनाए, र कसैलाई सेवा जालको आवश्यकता पर्दैन। यो सत्य हो, तर मेरो विचारमा यो जवाफले बिन्दु गुमाउँछ। दस वर्ष पहिले पनि, ठूला-ठूला प्रणालीहरू निर्माण गर्ने आशाजनक तरिकाको रूपमा माइक्रोसर्भिसेसको अवधारणालाई ट्विटर, फेसबुक, गुगल र नेटफ्लिक्स जस्ता कम्पनीहरूमा व्यापक रूपमा छलफल र लागू गरिएको थियो। सामान्य दृष्टिकोण - कमसेकम उद्योगका भागहरूमा म सम्पर्कमा आएको - यो थियो कि माइक्रोसर्भिसेसहरू ठूला प्रणालीहरू निर्माण गर्न "सही तरिका" थिए, यो धेरै गाह्रो भए पनि।

निस्सन्देह, यद्यपि दस वर्ष पहिले त्यहाँ माइक्रोसर्भिसहरू सञ्चालन गर्ने कम्पनीहरू थिए, तिनीहरूले सेवा जाल बनाउन सक्ने सबै ठाउँमा प्रोक्सीहरू टाँस्दैनन्। यद्यपि, यदि तपाईले नजिकबाट हेर्नुभयो भने, तिनीहरूले यस्तै केहि गरे: यी मध्ये धेरै कम्पनीहरूले नेटवर्क संचारको लागि विशेष आन्तरिक पुस्तकालयको प्रयोग गर्न आवश्यक छ (कहिलेकाहीँ मोटो ग्राहक पुस्तकालय भनिन्छ, फ्याट ग्राहक पुस्तकालय).

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

यसरी, दस वर्ष पहिले त्यहाँ माइक्रो सर्भिस मात्र थिएन, तर विशेष प्रोटो-सर्भिस-मेस पुस्तकालयहरू पनि थिए जसले आज सेवा मेषले समाधान गर्ने समान समस्याहरू समाधान गर्थे। तर, त्यसबेला सेवा जाल नै थिएन । उनी देखा पर्नु अघि त्यहाँ अर्को शिफ्ट हुनुपर्‍यो।

र गहिरो जवाफ यहीँ छ, जुन विगत १० वर्षमा भएको अर्को परिवर्तनमा लुकेको छ: माइक्रोसर्भिसेसहरू प्रयोग गर्ने लागत नाटकीय रूपमा घटेको छ। माथि उल्लेख गरिएका कम्पनीहरू जसले दस वर्षअघि माइक्रो सर्भिसहरू प्रयोग गर्थे—ट्विटर, नेटफ्लिक्स, फेसबुक, गुगल—ठूलो मात्रा र विशाल स्रोतका कम्पनीहरू थिए। तिनीहरूसँग आवश्यकता मात्र थिएन, तर ठूला माइक्रोसर्भिसेस-आधारित अनुप्रयोगहरू निर्माण, तैनाती र सञ्चालन गर्ने क्षमता पनि थियो। ट्विटर ईन्जिनियरहरूले मोनोलिथिकबाट माइक्रोसर्भिसेस दृष्टिकोणमा सार्ने ऊर्जा र प्रयास अद्भुत छ। (निष्पक्ष हुन, त्यसैले यो सफल भएको तथ्य हो।) यस प्रकारका पूर्वाधारात्मक चालहरू साना कम्पनीहरूका लागि असम्भव थिए।

वर्तमानमा छिटो अगाडि बढ्नुहोस्। आज त्यहाँ स्टार्टअपहरू छन् जहाँ विकासकर्ताहरूका लागि माइक्रो सेवाहरूको अनुपात 5: 1 (वा पनि 10:1), र थप के छ, तिनीहरू सफलतापूर्वक तिनीहरूलाई सामना गर्छन्! यदि 5-व्यक्ति स्टार्टअपले सजिलैसँग 50 माइक्रोसर्भिसेसहरू सञ्चालन गर्न सक्छ, तब केहिले स्पष्ट रूपमा तिनीहरूको कार्यान्वयनको लागत घटाएको छ।

Monzo मा 1500 microservices; प्रत्येक रेखा एक निर्धारित नेटवर्क नियम हो जसले ट्राफिकलाई अनुमति दिन्छ

सञ्चालन माइक्रो सेवाहरूको लागतमा नाटकीय कमी एउटा प्रक्रियाको परिणाम हो: कन्टेनरहरूको बढ्दो लोकप्रियता и अर्केस्ट्रेटरहरू। यो ठ्याक्कै सेवा जाल को उद्भव मा योगदान के प्रश्न को गहिरो जवाफ छ। एउटै प्रविधिले सेवा मेस र माइक्रोसर्भिसेस दुवैलाई आकर्षक बनायो: Kubernetes र Docker।

किन? ठिक छ, डकरले एउटा ठूलो समस्या समाधान गर्छ - प्याकेजिङ समस्या। एउटा एप्लिकेसन र यसको (गैर-नेटवर्क) रनटाइम निर्भरताहरूलाई कन्टेनरमा प्याकेज गरेर, डकरले एप्लिकेसनलाई एक विनिमेय इकाईमा परिणत गर्दछ जुन होस्ट गर्न र जहाँ पनि चलाउन सकिन्छ। एकै समयमा, यसले सञ्चालनलाई धेरै सरल बनाउँछ बहुभाषी स्ट्याक: किनकी कन्टेनर कार्यान्वयनको एक परमाणु इकाई हो, डिप्लोयमेन्ट र परिचालन उद्देश्यका लागि, यसले भित्र के छ भन्ने फरक पर्दैन, यो JVM, नोड, गो, पाइथन, वा रुबी अनुप्रयोग हो। तपाइँ भर्खर यसलाई सुरु गर्नुहोस् र यो हो।

Kubernetes ले सबै कुरा अर्को स्तरमा लैजान्छ। अब जब त्यहाँ "चलाउनका लागि चीजहरू" र तिनीहरूलाई चलाउन धेरै मेसिनहरू छन्, त्यहाँ एउटा उपकरणको आवश्यकता छ जसले तिनीहरूलाई एक अर्कासँग सम्बद्ध गर्न सक्छ। व्यापक अर्थमा, तपाइँ कुबेरनेटलाई धेरै कन्टेनरहरू र धेरै मेसिनहरू दिनुहुन्छ, र यसले तिनीहरूलाई एकअर्काको विरुद्धमा नक्सा बनाउँछ (निस्सन्देह, यो एक गतिशील र सधैं परिवर्तन हुने प्रक्रिया हो: नयाँ कन्टेनरहरू प्रणालीको वरिपरि घुम्छन्, मेसिनहरू सुरु हुन्छन् र बन्द हुन्छन्। , आदि। यद्यपि, Kubernetes ले यी सबैलाई ध्यानमा राख्छ)।

एक पटक Kubernetes कन्फिगर गरिसकेपछि, एक सेवा प्रयोग गर्न र सञ्चालन गर्न लाग्ने समय लागत दस सेवाहरू प्रयोग गर्न र सञ्चालन गर्न लागत भन्दा थोरै फरक हुन्छ (वास्तवमा, यो लगभग 100 सेवाहरूको लागि समान छ)। बहुभाषिक कार्यान्वयनलाई प्रोत्साहन गर्ने प्याकेजिङ मेकानिजमको रूपमा यस कन्टेनरहरूमा थप्नुहोस्, र तपाईंसँग विभिन्न भाषाहरूमा लेखिएका माइक्रोसर्भिसेसहरूको रूपमा लागू गरिएका नयाँ अनुप्रयोगहरू छन् - ठ्याक्कै त्यस्तो प्रकारको वातावरण जुन सेवा जालको लागि उपयुक्त छ।

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

यसको संक्षेपमा: सेवा जालहरू अहिले लोकप्रिय भएको कारण, दस वर्ष पहिले होइन, कुबर्नेट्स र डकरले मात्र उल्लेखनीय रूपमा बढेको छैन। आवश्यकता यसमा, बहुभाषिक सूक्ष्म सेवाहरूको सेटको रूपमा अनुप्रयोगहरूको कार्यान्वयनलाई सरल बनाएको छ, तर यो पनि उल्लेखनीय रूपमा घटाइएको छ। लागत यसको सञ्चालनको लागि, साइडकार प्रोक्सी फ्लीटहरू तैनाती र समर्थन गर्ने संयन्त्र प्रदान गर्दै।

सेवा जालको बारेमा किन यति धेरै चर्चा छ?

रोकथाम: यस खण्डमा म सबै प्रकारका अनुमान, अनुमान, मनगढन्ते र भित्री जानकारीको प्रयोग गर्छु।

"सेवा जाल" को लागि खोजी गर्नुहोस् र तपाईले एक टन पुन: प्रयोग गरिएको कम क्यालोरी सामग्री, अनौठो परियोजनाहरू, र इको चेम्बरको योग्य विकृतिको क्यालिडोस्कोप भेट्नुहुनेछ। कुनै पनि फैंसी नयाँ प्रविधिले यो गर्छ, तर सेवा जालको अवस्थामा समस्या विशेष गरी तीव्र छ। किन?

खैर, यसमा मेरो गल्ती छ। मैले Linkerd लाई प्रवर्द्धन गर्न कडा मेहनत गरिरहेको छु र यो जस्तै अनगिन्ती ब्लग पोष्टहरू र लेखहरू मार्फत प्राप्त हुने हरेक मौका सेवा जाल। तर म त्यति शक्तिशाली छैन। यस प्रश्नको जवाफ दिनको लागि, हामीले समग्र अवस्थाको बारेमा थोरै कुरा गर्न आवश्यक छ। र एउटा परियोजना उल्लेख नगरी यसको बारेमा कुरा गर्न असम्भव छ: इस्तिओ Google, IBM र Lyft द्वारा संयुक्त रूपमा विकसित गरिएको खुला स्रोत सेवा जाल हो।

(तीन कम्पनीहरूको धेरै फरक भूमिकाहरू छन्: लिफ्टको संलग्नता नाममा मात्र देखिन्छ; तिनीहरू दूतका लेखक हुन्, तर इस्टियोको विकासमा प्रयोग वा भाग लिँदैनन्। IBM Istio को विकासमा संलग्न छ र प्रयोग गर्दछ। Google सक्रिय रूपमा Istio को विकासमा संलग्न छ। विकास, तर वास्तवमा मैले भन्न सक्ने रूपमा यसलाई प्रयोग गर्दैन।)

Istio परियोजना दुई चीजहरूको लागि उल्लेखनीय छ। पहिलो, त्यहाँ ठूलो मार्केटिङ प्रयास छ जुन गुगल, विशेष गरी, यसलाई प्रवर्द्धन गर्न लगाइरहेको छ। म अनुमान गर्छु कि सेवा जाल अवधारणा बारे सचेत अधिकांश मानिसहरूले आज पहिलो पटक Istio मार्फत यसको बारेमा सिके। दोस्रो कुरा Istio कत्तिको खराब प्राप्त भएको थियो। यस विषयमा, म स्पष्ट रूपमा एक चासो पार्टी हुँ, तर सकेसम्म उद्देश्य रहन कोशिस गर्दै, म अझै मद्दत गर्न सक्दिन मार्क धेरै नकारात्मक रवैया, धेरै विशिष्ट छैन (यद्यपि अद्वितीय छैन: systemd दिमागमा आउँछ, तुलना गरिएको थियो पहिले नै बारम्बार...) खुला स्रोत परियोजनाको लागि।

(अभ्यासमा, Istio जटिलता र UX मा मात्र नभई कार्यसम्पादनमा पनि समस्या भएको देखिन्छ। उदाहरणका लागि, समयमा Linkerd प्रदर्शन मूल्याङ्कनतेस्रो-पक्ष अध्ययनमा, अन्वेषकहरूले इस्टियोको पुच्छर विलम्बता Linkerd को तुलनामा 100 गुणा बढी भएको अवस्थाहरू फेला पारे, साथै स्रोत-भोकै अवस्थाहरू जहाँ Linkerd सफलतापूर्वक काम गर्न जारी राख्यो जबकि Istio ले पूर्ण रूपमा काम गर्न छोड्यो।)

यो किन भयो भन्ने बारे मेरो सिद्धान्तहरू छोडेर, म विश्वास गर्छु कि सेवा जाल वरिपरि अत्यधिक उत्साह Google को सहभागिता द्वारा व्याख्या गरिएको छ। अर्थात्, निम्न तीन कारकहरूको संयोजन:

1. Istio को Google को हस्तक्षेपकारी पदोन्नति;
2. परियोजना प्रति एक समान अस्वीकृत, आलोचनात्मक रवैया;
3. Kubernetes को लोकप्रियता मा भर्खरको उल्का वृद्धि, जसको सम्झना अझै ताजा छ।

यी कारकहरू सँगै मिलेर एक स्तब्ध, अक्सिजन-रहित वातावरण सिर्जना गर्दछ जसमा तर्कसंगत निर्णयको क्षमता कमजोर हुन्छ, र केवल अनौठो विविधता रहन्छ। ट्यूलिप उन्माद.

Linkerd को परिप्रेक्ष्यबाट, यो हो ... म मिश्रित आशिष्को रूपमा वर्णन गर्नेछु। मेरो मतलब, यो राम्रो छ कि सेवा जालले मुख्यधारामा प्रवेश गरेको छ जुन 2016 मा थिएन जब Linkerd पहिलो पटक सुरु भयो र यो परियोजनामा ​​ध्यान दिन मानिसहरूलाई प्राप्त गर्न साँच्चै गाह्रो थियो। अब यस्तो समस्या छैन! तर नराम्रो खबर यो हो कि सेवा जाल ल्यान्डस्केप आज यति भ्रामक छ कि कुन परियोजनाहरू वास्तवमा सेवा जाल कोटिमा पर्दछ भनेर बुझ्न लगभग असम्भव छ (कुनै विशेष प्रयोग केसको लागि सबैभन्दा उपयुक्त हो भनेर बुझ्नुहोस्)। यो पक्कै पनि सबैको लागि एक सौदाब्रेकर हो (र त्यहाँ निश्चित रूपमा केहि केसहरू छन् जहाँ इस्टियो वा अर्को परियोजना Linkerd भन्दा राम्रो उपयुक्त छ, किनकि पछिल्ला अझै पनि विश्वव्यापी समाधान होइन)।

Linkerd को पक्षमा, हाम्रो रणनीति भनेको कोलाहललाई बेवास्ता गर्ने, वास्तविक सामुदायिक समस्याहरू समाधान गर्नमा ध्यान केन्द्रित गर्ने, र अनिवार्य रूपमा हाइपको मृत्युको लागि पर्खने हो। अन्ततः, हाइप कम हुनेछ र हामी शान्त रूपमा काम गर्न जारी राख्न सक्छौं।

यस बीचमा, हामी सबैले थोरै धैर्य गर्नुपर्छ।

एक विनम्र सफ्टवेयर इन्जिनियर, मेरो लागि सेवा जाल उपयोगी हुनेछ?

निम्न प्रश्नावलीले तपाईंलाई यस प्रश्नको जवाफ दिन मद्दत गर्नेछ:

के तपाईं व्यापार तर्क लागू गर्नमा मात्र संलग्न हुनुहुन्छ? यस अवस्थामा, सेवा जाल तपाईलाई उपयोगी हुनेछैन। त्यो हो, निस्सन्देह, तपाइँ यसमा रुचि राख्न सक्नुहुन्छ, तर आदर्श रूपमा सेवा जालले तपाइँको वातावरणमा कुनै पनि कुरालाई प्रत्यक्ष असर गर्नु हुँदैन। तपाईलाई के गर्नको लागि भुक्तानी गरिन्छ त्यसमा काम गरिरहनुहोस्।

के तपाइँ Kubernetes प्रयोग गर्ने कम्पनीमा प्लेटफर्मलाई समर्थन गर्दै हुनुहुन्छ? हो, यस अवस्थामा तपाईलाई सेवा जाल चाहिन्छ (जबसम्म, अवश्य पनि, तपाईले केवल एक मोनोलिथ वा ब्याच प्रशोधन गर्न K8s प्रयोग गरिरहनु भएको छैन - तर म तपाईलाई किन K8s चाहिन्छ भनेर सोध्न चाहन्छु)। तपाईं सम्भवतः विभिन्न व्यक्तिहरूद्वारा लेखिएका धेरै माइक्रोसर्भिसेसहरूको साथ समाप्त हुनुहुनेछ। तिनीहरू सबै एक-अर्कासँग अन्तरक्रिया गर्छन् र रनटाइम निर्भरताहरूको ट्याङ्गलमा बाँधिएका छन्, र तपाईंले यो सबैसँग सम्झौता गर्ने तरिका खोज्नुपर्छ। Kubernetes प्रयोग गर्नाले तपाईंलाई "आफ्नो लागि" सेवा जाल छनौट गर्न अनुमति दिन्छ। यो गर्नको लागि, तिनीहरूको क्षमताहरू र सुविधाहरूको साथ आफैलाई परिचित गर्नुहोस् र कुनै पनि उपलब्ध परियोजनाहरू तपाईंको लागि उपयुक्त छन् कि छैनन् भन्ने प्रश्नको जवाफ दिनुहोस् (म लिङ्कर्डसँग तपाईंको अनुसन्धान सुरु गर्न सिफारिस गर्दछु)।

के तपाईं Kubernetes प्रयोग नगर्ने तर माइक्रो सेवाहरू प्रयोग गर्ने कम्पनीको प्लेटफर्म कम्पनी हुनुहुन्छ? यस अवस्थामा, सेवा जाल तपाईंको लागि उपयोगी हुनेछ, तर यसको प्रयोग गैर-तुच्छ हुनेछ। अवश्य पनि तपाईं सक्नुहुन्छ नकल गर्नु प्रोक्सीहरूको गुच्छा राखेर काम सेवा जाल, तर Kubernetes को एक महत्त्वपूर्ण फाइदा डिप्लोइमेन्ट मोडेल हो: म्यानुअल रूपमा यी प्रोक्सीहरू कायम राख्न धेरै समय, प्रयास र खर्च चाहिन्छ।

के तपाईं मोनोलिथहरूसँग काम गर्ने कम्पनीमा प्लेटफर्मको लागि जिम्मेवार हुनुहुन्छ? यस अवस्थामा, तपाईंलाई सम्भवतः सेवा जालको आवश्यकता पर्दैन। यदि तपाइँ मोनोलिथहरूसँग काम गर्दै हुनुहुन्छ (वा मोनोलिथहरूको सङ्कलन पनि) जसले राम्रोसँग परिभाषित र विरलै अन्तरक्रिया ढाँचाहरू परिवर्तन गरेको छ भने, सेवा जालले तपाइँलाई प्रस्ताव गर्न थोरै हुनेछ। त्यसोभए तपाइँ यसलाई बेवास्ता गर्न सक्नुहुन्छ र आशा गर्न सक्नुहुन्छ कि यो खराब सपना जस्तै हराउनेछ ...

निष्कर्षमा

सम्भवतः, सेवा जाल अझै पनि "संसारमा सबैभन्दा हाइप गरिएको टेक्नोलोजी" भनिनु हुँदैन - यो संदिग्ध सम्मान सम्भवतः बिटकोइन वा एआईसँग सम्बन्धित छ। उनी सम्भवतः शीर्ष पाँचमा छिन्। तर यदि तपाईंले आवाजको तहहरू काट्नु भयो भने, यो स्पष्ट हुन्छ कि सेवा जालले Kubernetes मा अनुप्रयोगहरू निर्माण गर्नेहरूलाई वास्तविक फाइदाहरू ल्याउँछ।

म तपाईंलाई Linkerd कोसिस गर्न चाहन्छु - यसलाई Kubernetes क्लस्टरमा स्थापना गर्दै (वा ल्यापटपमा Minikube पनि) लगभग 60 सेकेन्ड लाग्छ, र म के कुरा गरिरहेको छु तपाईं आफैले देख्न सक्नुहुन्छ।

सोधिने प्रश्न

- यदि मैले सेवा जाललाई बेवास्ता गरे, के यो हराउनेछ?
- म तपाईंलाई निराश गर्नुपर्छ: सेवा जाल लामो समय को लागी हामी संग छ।

- तर म सेवा जाल प्रयोग गर्न चाहन्न!
- खैर, यो आवश्यक छैन! तपाईंले कम्तिमा यसको आधारभूत कुराहरूसँग परिचित हुनुपर्दछ कि भनेर बुझ्न माथिको मेरो प्रश्नावली पढ्नुहोस्।

— के यो राम्रो पुरानो ESB/मिडलवेयर नयाँ ससको साथ होइन?
- सेवा जालले परिचालन तर्कसँग सम्बन्धित छ, सिमान्टिक होइन। यो मुख्य कमजोरी थियो उद्यम सेवा बस (IT IS B)। यो पृथकता कायम राख्नाले सेवा जाललाई समान भाग्यबाट बच्न मद्दत गर्दछ।

— सेवा जाल API गेटवेहरूबाट कसरी फरक हुन्छ?
- यस विषयमा लाखौं लेखहरू छन्। यो मात्र गुगल गर्नुहोस्।

- दूत सेवा जाल हो?
- होइन, दूत सेवा जाल होइन, यो एक प्रोक्सी सर्भर हो। यो सेवा जाल व्यवस्थित गर्न प्रयोग गर्न सकिन्छ (र धेरै - यो एक सामान्य उद्देश्य प्रोक्सी हो)। तर आफैमा यो सेवा जाल होइन।

- नेटवर्क सेवा जाल एक सेवा जाल हो?
- छैन। नामको बावजुद, यो सेवा जाल होइन (तपाईलाई मार्केटिङ चमत्कार कसरी मनपर्छ?)।

— के सेवा जालले मेरो सन्देश लाइनमा आधारित प्रतिक्रियाशील एसिन्क्रोनस प्रणालीलाई मद्दत गर्नेछ?
- होइन, सेवा जालले तपाईंलाई मद्दत गर्दैन।

- मैले कुन सेवा जाल प्रयोग गर्नुपर्छ?
- लिङ्कर्ड, कुनै दिमाग छैन।

- लेख बेकार छ! / लेखक स्वागत छ!
- कृपया तपाइँका सबै साथीहरूसँग यसको लिङ्क साझा गर्नुहोस् ताकि उनीहरूले यसलाई देख्न सकून्!

स्वीकार

तपाईले शीर्षकबाट अनुमान लगाउनु भएको हुन सक्छ, यो लेख जे क्रेप्सको उत्कृष्ट ग्रन्थ "बाट प्रेरित थियो।लग: प्रत्येक सफ्टवेयर इन्जिनियरले वास्तविक-समय डाटाको एकीकृत अमूर्तताको बारेमा के थाहा पाउनु पर्छ" मैले जेलाई दस वर्षअघि भेटेको थिएँ जब मैले लिंक्ड इनमा उहाँसँग अन्तर्वार्ता लिएँ र उहाँ त्यसबेलादेखि नै मेरो लागि प्रेरणाको स्रोत हुनुहुन्छ।

जब म आफूलाई "Linkerd विकासकर्ता" भन्न मन पराउँछु, वास्तविकता यो हो कि म परियोजनामा ​​README.md फाइलको मर्मतकर्ता हुँ। Linkerd आज काम भइरहेको छ धेरै, धेरै, धेरै много मानिसहरू, र यो परियोजना योगदानकर्ता र प्रयोगकर्ताहरूको अद्भुत समुदायको सहभागिता बिना हुने थिएन।

र अन्तमा, Linkerd को सिर्जनाकर्तालाई विशेष धन्यवाद, ओलिभर गोल्ड (प्राइमस इन्टर पेरेस), जो, धेरै वर्ष पहिले म संगै, सेवा जाल संग यो सबै गडबड मा टाउको मा डुब्यो।

अनुवादकबाट PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «सेवा जाल के हो र मलाई किन चाहिन्छ [माइक्रोसर्भिसेसको साथ क्लाउड अनुप्रयोगको लागि]?»;
• «Traefik 2.0: TCP समर्थन र नयाँ वेब इन्टरफेस संग सेवा जाल अद्यावधिक»;
• «Maesh - Traefik को लेखकहरु बाट Kubernetes को लागी एक नयाँ सरल सेवा जाल»;
• «Istio संग microservices मा फर्कनुहोस्। भाग 1»;
• «कन्ड्युट - Kubernetes को लागि हल्का सेवा जाल"।

स्रोत: www.habr.com