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

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

DotCloud को इतिहास

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

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

होस्ट गरिएका अनुप्रयोगहरूको लागि ट्राफिक मार्ग

डटक्लाउडमा भएका अनुप्रयोगहरूले HTTP र TCP अन्त्यबिन्दुहरू उजागर गर्न सक्छन्।

HTTP अन्त्य बिन्दुहरू गतिशील रूपमा लोड ब्यालेन्सर क्लस्टर कन्फिगरेसनमा थपियो हिपचे। यो आजको स्रोतसाधनसँग मिल्दोजुल्दो छ आक्रामक Kubernetes मा र लोड ब्यालेन्सर जस्तै ट्रैफिक.

डोमेन नामले डटक्लाउड लोड ब्यालेन्सरहरूमा पोइन्ट गरेको भएमा ग्राहकहरूले उपयुक्त डोमेनहरू मार्फत HTTP अन्त्य बिन्दुहरूमा जडान गर्छन्। खासै केई हैन।

TCP अन्तिम बिन्दुहरू पोर्ट नम्बरसँग सम्बन्धित, जुन त्यसपछि वातावरण चर मार्फत स्ट्याकमा रहेका सबै कन्टेनरहरूमा पठाइन्छ।

ग्राहकहरूले उपयुक्त होस्टनाम (गेटवे-X.dotcloud.com जस्तै) र पोर्ट नम्बर प्रयोग गरेर TCP अन्त्य बिन्दुहरूमा जडान गर्न सक्छन्।

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

यदि तपाइँ Kubernetes सँग परिचित हुनुहुन्छ भने, यसले तपाइँलाई सेवाहरूको सम्झना दिलाउनेछ नोडपोर्ट.

डटक्लाउड प्लेटफर्ममा कुनै समान सेवाहरू थिएनन् क्लस्टरआईपी: सरलताको लागि, सेवाहरू प्लेटफर्म भित्र र बाहिर दुबैबाट समान रूपमा पहुँच गरिएको थियो।

सबै कुरा एकदम सरल रूपमा व्यवस्थित गरिएको थियो: HTTP र TCP रूटिङ नेटवर्कहरूको प्रारम्भिक कार्यान्वयनहरू सम्भवतः पाइथनका केही सय लाइनहरू मात्र थिए। साधारण (म भोली भन्दछु) एल्गोरिदमहरू जुन प्लेटफर्म बढ्दै जाँदा र थप आवश्यकताहरू देखा पर्दा परिष्कृत गरियो।

अवस्थित कोडको विस्तृत रिफ्याक्टरिंग आवश्यक थिएन। खासमा, १२ कारक एपहरू वातावरण चर मार्फत प्राप्त ठेगाना प्रत्यक्ष प्रयोग गर्न सक्नुहुन्छ।

यो कसरी आधुनिक सेवा जाल भन्दा फरक छ?

सीमित दृश्यता। हामीसँग TCP राउटिंग जालको लागि कुनै पनि मेट्रिक्स थिएन। जब यो HTTP राउटिङको कुरा आउँछ, पछिका संस्करणहरूले त्रुटि कोडहरू र प्रतिक्रिया समयहरू सहित विस्तृत HTTP मेट्रिक्स प्रस्तुत गरे, तर आधुनिक सेवा मेसहरू अझ अगाडि जान्छन्, उदाहरणका लागि प्रोमेथियस जस्ता मेट्रिक्स सङ्कलन प्रणालीहरूसँग एकीकरण प्रदान गर्दै।

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

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

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

आधुनिक सेवा मेसहरूले स्मार्ट लोड ब्यालेन्सिङ एल्गोरिदमहरू पनि लागू गर्दछ। ब्याकएन्डको स्वास्थ्य अनुगमन गरेर, तिनीहरूले छिटो ब्याकइन्डहरूमा थप ट्राफिक पठाउन सक्छन्, परिणामस्वरूप समग्र प्रदर्शनमा सुधार हुन्छ।

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

प्लेटफर्म सेवाहरूको लागि ट्राफिक रूटिङ

ठीक छ, हामीले एप्लिकेसनहरू बीचको ट्राफिकमा छलफल गरेका छौं, तर डटक्लाउड प्लेटफर्मको बारेमा के हो?

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

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

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

यी सेवाहरू सरल र कच्चा तरिकामा पर्दाफास गरिएका थिए: YAML फाइलले तिनीहरूको नाम र ठेगानाहरू सूचीबद्ध गरेको थियो; र प्रत्येक ग्राहकले यो YAML फाइलको एक प्रतिलिपि प्रयोगको लागि लिनु पर्थ्यो।

एकातिर, यो अत्यन्त भरपर्दो छ किनभने यसलाई बाहिरी कुञ्जी/मूल्य स्टोरको समर्थन आवश्यक पर्दैन जस्तै Zookeeper (सम्झनुहोस्, etcd वा Consul त्यस समयमा अवस्थित थिएन)। अर्कोतर्फ, सेवाहरू सार्न गाह्रो भयो। प्रत्येक पटक एक चाल बनाइयो, सबै ग्राहकहरूले अपडेट गरिएको YAML फाइल प्राप्त गर्नेछन् (र सम्भावित रूपमा रिबुट)। धेरै सहज छैन!

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

(यो पनि TLS जडानहरूमा ट्राफिकलाई समेट्ने र प्राप्त गर्ने पक्षमा अर्को प्रोक्सी सर्भर राख्ने योजना थियो, साथै प्राप्त सेवाको सहभागिता बिना TLS प्रमाणपत्रहरू प्रमाणीकरण गर्ने, जुन जडानहरू स्वीकार गर्न कन्फिगर गरिएको छ। localhost। यस बारे पछि थप)।

यो धेरै समान छ SmartStack Airbnb बाट, तर महत्त्वपूर्ण भिन्नता यो हो कि SmartStack लागू गरिएको छ र उत्पादनमा तैनात गरिएको छ, जबकि डटक्लाउड डकर बनेपछि डटक्लाउडको आन्तरिक राउटिङ प्रणाली सुरक्षित गरिएको थियो।

म व्यक्तिगत रूपमा SmartStack लाई Istio, Linkerd र Consul Connect जस्ता प्रणालीहरूको पूर्ववर्ती मध्ये एक मान्छु किनभने तिनीहरू सबै एउटै ढाँचा पछ्याउँछन्:

• प्रत्येक नोडमा प्रोक्सी चलाउनुहोस्।
• ग्राहकहरू प्रोक्सीमा जडान हुन्छन्।
• ब्याकएन्ड परिवर्तन हुँदा नियन्त्रण विमानले प्रोक्सी कन्फिगरेसन अपडेट गर्दछ।
• ... लाभ!

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

यदि हामीले आज समान ग्रिड लागू गर्न आवश्यक छ भने, हामी समान सिद्धान्तहरू प्रयोग गर्न सक्छौं। उदाहरणका लागि, अन्तरिक्षमा ठेगानाहरूमा सेवा नामहरू म्याप गरेर आन्तरिक 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 वा कन्सुलमा निर्भर हुन्छ। Istio ले Kubernetes स्रोतहरूको सेट हेर्न Kubernetes API प्रयोग गर्दछ।

यस बीचमा र त्यसपछि: मैले व्यक्तिगत रूपमा यो उपयोगी पाएँ Kubernetes API विवरणजसले पढ्छ:

Kubernetes API सर्भर एक "गूंगा सर्भर" हो जसले API स्रोतहरूको लागि भण्डारण, संस्करण, प्रमाणीकरण, अद्यावधिक, र अर्थशास्त्र प्रदान गर्दछ।

Istio Kubernetes संग काम गर्न डिजाइन गरिएको छ; र यदि तपाइँ यसलाई Kubernetes बाहिर प्रयोग गर्न चाहनुहुन्छ भने, तपाइँले Kubernetes API सर्भर (र etcd सहायक सेवा) को एक उदाहरण चलाउन आवश्यक छ।

सेवा ठेगानाहरू

Istio ClusterIP ठेगानाहरूमा निर्भर गर्दछ जुन Kubernetes आवंटित गर्दछ, त्यसैले Istio सेवाहरूले आन्तरिक ठेगाना प्राप्त गर्दछ (दायरामा होइन। 127.0.0.0/8).

Istio बिना Kubernetes क्लस्टरमा एक विशेष सेवाको लागि ClusterIP ठेगानामा ट्राफिक kube-proxy द्वारा रोकिन्छ र प्रोक्सीको ब्याकइन्डमा पठाइन्छ। यदि तपाइँ प्राविधिक विवरणहरूमा रुचि राख्नुहुन्छ भने, kube-proxy ले ClusterIP ठेगानामा जाने गन्तव्य आईपी ठेगानाहरू पुन: लेख्नको लागि 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) मार्फत एन्ड-टु-इन्ड इन्क्रिप्सन र प्रमाणीकरण पनि प्रदान गर्दछ। कम्पोनेन्ट भनिन्छ Citadel.

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

र, अवश्य पनि, हामीले दृश्यता उल्लेख गर्यौं: दूतले वितरित ट्रेसिङ प्रदान गर्दा मेट्रिक्सको ठूलो मात्रा सङ्कलन गर्दछ। माइक्रोसर्भिसेस आर्किटेक्चरमा, यदि एकल एपीआई अनुरोध माइक्रोसर्भिसेस A, B, C, र D मार्फत पास हुनु पर्छ, तब लगइन गर्दा, वितरित ट्रेसिङले अनुरोधमा एक अद्वितीय पहिचानकर्ता थप्नेछ र यी सबै माइक्रोसर्भिसेसहरूमा सब-रिक्वेस्टहरू मार्फत यो पहिचानकर्ता भण्डारण गर्नेछ। सबै सम्बन्धित कलहरू क्याप्चर गर्न। ढिलाइ, आदि।

विकास गर्नुहोस् वा किन्नुहोस्

Istio जटिल हुनुको लागि प्रतिष्ठा छ। यसको विपरित, मैले यस पोष्टको सुरुमा वर्णन गरेको रूटिङ जाल निर्माण गर्नु अवस्थित उपकरणहरू प्रयोग गरेर अपेक्षाकृत सरल छ। त्यसोभए, के यसको सट्टामा आफ्नै सेवा जाल सिर्जना गर्न अर्थ छ?

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

तर यदि हामीसँग उन्नत आवश्यकताहरू छन् भने, सेवा जाल "खरीद" धेरै राम्रो विकल्प जस्तो देखिन्छ। (यो सधैं "किन्नुहोस्" होइन किनभने Istio खुला स्रोत हो, तर हामीले अझै पनि यसलाई बुझ्न, डिप्लोय गर्न र व्यवस्थापन गर्न इन्जिनियरिङ समय लगानी गर्न आवश्यक छ।)

के मैले Istio, Linkerd वा Consul Connect रोज्नुपर्छ?

अहिलेसम्म हामीले Istio को बारेमा मात्र कुरा गरेका छौं, तर यो मात्र सेवा जाल होइन। लोकप्रिय विकल्प - लिङ्कर्ड, र त्यहाँ थप छ कन्सुल जडान.

के छनौट गर्ने?

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

एक आशाजनक दृष्टिकोण जस्तै उपकरण प्रयोग गर्न हो सुपरग्लु। यसले सेवा जालहरूद्वारा पर्दाफास गरिएका एपीआईहरूलाई सरल बनाउन र एकीकृत गर्नको लागि एब्स्ट्रेक्शन लेयर लागू गर्दछ। विभिन्न सेवा मेसहरूको विशिष्ट (र, मेरो विचारमा, अपेक्षाकृत जटिल) API हरू सिक्नुको सट्टा, हामीले SuperGloo को सरल निर्माणहरू प्रयोग गर्न सक्छौं - र सजिलैसँग एकबाट अर्कोमा स्विच गर्न सक्छौं, मानौं हामीसँग HTTP इन्टरफेसहरू र ब्याकएन्डहरू सक्षम वर्णन गर्ने मध्यवर्ती कन्फिगरेसन ढाँचा छ। Nginx, HAProxy, Traefik, Apache को लागि वास्तविक कन्फिगरेसन उत्पन्न गर्ने...

मैले Istio र SuperGloo सँग अलिकति ड्याबल गरेको छु, र अर्को लेखमा म SuperGloo प्रयोग गरेर अवस्थित क्लस्टरमा Istio वा Linkerd कसरी थप्ने भनेर देखाउन चाहन्छु, र पछिल्लोले कसरी काम गर्छ, त्यो हो, तपाईलाई बाट स्विच गर्न अनुमति दिन्छ। कन्फिगरेसनहरू अधिलेखन नगरी अर्को सेवा जाल।

स्रोत: www.habr.com