नमस्कार, हेब्र! मैं आपके लिए मैट क्लेन द्वारा "सेवा जाल डेटा विमान बनाम नियंत्रण विमान" लेख का अनुवाद प्रस्तुत करता हूं।



इस बार मैंने सेवा जाल, डेटा प्लेन और कंट्रोल प्लेन के दोनों घटकों के विवरण का अनुवाद और अनुवाद किया। यह विवरण मुझे सबसे अधिक समझ में आता है और दिलचस्प है, और सबसे महत्वपूर्ण बात यह है कि "क्या यह आवश्यक है?"

जैसा कि "सेवा जाल" का विचार पिछले दो वर्षों में अधिक से अधिक लोकप्रिय हो गया है (मूल लेख 10 अक्टूबर, 2017) और अंतरिक्ष में प्रतिभागियों की संख्या में वृद्धि हुई है, मैंने पूरे तकनीकी समुदाय के बीच भ्रम की स्थिति में तुलनात्मक रूप से तुलना करने के तरीके को देखा है। और इसके विपरीत विभिन्न समाधान।

जुलाई में लिखे गए ट्वीट्स की निम्नलिखित श्रृंखला में स्थिति का सबसे अच्छा वर्णन किया गया है:

सर्विस मेश (सर्विस मेश) नंबर 1: लिंकरड ~ = नगनेक्स ~ = हैप्रोक्सी ~ = एनवॉय के साथ भ्रम। उनमें से कोई भी इस्तियो के बराबर नहीं है। इस्तियो कुछ पूरी तरह से अलग है। 1 /

पहले सिर्फ डेटा प्लेन हैं। वे खुद कुछ नहीं करते। उन्हें कुछ और करने की जरूरत है। 2 /

इस्तियो एक नियंत्रण विमान का एक उदाहरण है जो भागों को एक साथ जोड़ता है। यह एक अलग परत है। / अंत

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

सेवा जाल (वास्तव में) क्या है?

चित्र 1: सेवा जाल अवलोकन

चित्र 1 सबसे मूल स्तर पर एक सेवा जाल की अवधारणा को दर्शाता है। चार सेवा समूह (AD) हैं। प्रत्येक सेवा आवृत्ति स्थानीय प्रॉक्सी सर्वर से संबद्ध है। एक एकल अनुप्रयोग उदाहरण से सभी नेटवर्क ट्रैफ़िक (HTTP, REST, gRPC, Redis, आदि) स्थानीय प्रॉक्सी सर्वर के माध्यम से संबंधित बाहरी सेवा समूहों में प्रेषित किया जाता है। इस प्रकार, एप्लिकेशन इंस्टेंस पूरे नेटवर्क के बारे में नहीं जानता है और केवल इसके स्थानीय प्रॉक्सी के बारे में जानता है। वास्तव में, वितरित प्रणाली का नेटवर्क सेवा से दूरस्थ था।

डाटा प्लेन

सेवा जाल में, अनुप्रयोग के लिए स्थानीय रूप से स्थित एक प्रॉक्सी सर्वर निम्नलिखित कार्य करता है:

• सेवा खोज आपके आवेदन के लिए कौन सी सेवाएं / सेवाएं / एप्लिकेशन उपलब्ध हैं?
• स्वास्थ्य की जाँच क्या सेवा के उदाहरण सेवा खोज द्वारा लौटाए गए हैं और नेटवर्क ट्रैफ़िक स्वीकार करने के लिए तैयार हैं? इसमें दोनों सक्रिय (जैसे, / स्वास्थ्य जांच प्रतिक्रिया) और निष्क्रिय (जैसे, सेवा की अस्वास्थ्यकर स्थिति के संकेत के रूप में 3 लगातार 5xx त्रुटियों का उपयोग करके) स्वास्थ्य जांच शामिल हो सकते हैं।
• रूटिंग (रूटिंग)। REST सेवा से "/ foo" के लिए अनुरोध प्राप्त करने के बाद, किस सेवा समूह को अनुरोध भेजा जाना चाहिए?
• लोड संतुलन रूटिंग के दौरान सर्विस क्लस्टर का चयन करने के बाद, किस सेवा के लिए अनुरोध भेजा जाना चाहिए? क्या समय समाप्त हुआ? सर्किट तोड़ने के लिए क्या सेटिंग्स? यदि अनुरोध विफल हो जाता है, तो क्या इसे दोहराया जाना चाहिए?
• प्रमाणीकरण और प्राधिकरण आने वाले अनुरोधों के लिए, कॉलिंग सेवा को mTLS या किसी अन्य तंत्र का उपयोग करके क्रिप्टोग्राफिक रूप से पहचाना / अधिकृत किया जा सकता है? यदि इसकी पहचान / अधिकृत किया गया है, तो क्या यह सेवा में अनुरोधित ऑपरेशन (समापन बिंदु) को कॉल करने की अनुमति दी गई है या एक अनौपचारिक प्रतिक्रिया वापस आ गई है?
• Observability (observability)। प्रत्येक अनुरोध के लिए, विस्तृत आँकड़े, लॉग / लॉग, और वितरित ट्रेस डेटा उत्पन्न किया जाना चाहिए ताकि ऑपरेटर वितरित ट्रैफ़िक प्रवाह और डिबगिंग समस्याओं को समझ सकें क्योंकि वे उत्पन्न होते हैं।

सेवा नेटवर्क (सेवा जाल) में पिछले सभी बिंदुओं के लिए, डेटा विमान जिम्मेदार है। वास्तव में, सेवा (साइडकार) के लिए प्रॉक्सी लोकल एक डाटा प्लेन है। दूसरे शब्दों में, डाटा प्लेन प्रत्येक नेटवर्क पैकेट को सशर्त प्रसारण, अग्रेषण और निगरानी के लिए जिम्मेदार है जिसे सेवा से भेजा या भेजा जाता है।

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

नेटवर्क एब्सट्रैक्ट जो डेटा प्लेन में स्थानीय प्रॉक्सी प्रदान करता है वह जादुई (?) है। हालांकि, प्रॉक्सी वास्तव में सेवा बी के लिए "/ foo" मार्ग के बारे में कैसे जानता है? सेवा खोज डेटा जो प्रॉक्सी अनुरोधों के साथ आबादी वाला है, का उपयोग कैसे किया जा सकता है? लोड बैलेंसिंग, टाइमआउट, सर्किट ब्रेकिंग आदि कैसे कॉन्फ़िगर की गई सेटिंग्स हैं? नीली / हरी (नीली / हरी) विधि या यातायात के क्रमिक हस्तांतरण की विधि का उपयोग करके आवेदन कैसे तैनात करें? सिस्टम-वाइड प्रमाणीकरण और प्राधिकरण सेटिंग कौन सेट करता है?

उपरोक्त सभी आइटम सेवा जाल के नियंत्रण विमान द्वारा प्रबंधित किए जाते हैं। नियंत्रण विमान स्टेटलेस आइसोलेटेड प्रॉक्सी सर्वर के एक सेट को स्वीकार करता है और उन्हें एक वितरित प्रणाली में बदल देता है ।

मुझे लगता है कि कई टेक्नोलॉजिस्ट डेटा प्लेन और कंट्रोल प्लेन की अलग-अलग अवधारणाओं को खोजने का कारण मानते हैं, क्योंकि ज्यादातर लोगों के लिए डेटा प्लेन परिचित है, जबकि कंट्रोल प्लेन विदेशी / समझ से बाहर है। हम लंबे समय से भौतिक नेटवर्क राउटर और स्विच के साथ काम कर रहे हैं। हम समझते हैं कि पैकेज / अनुरोधों को बिंदु ए से बिंदु बी तक जाना चाहिए, और इसके लिए हम हार्डवेयर और सॉफ्टवेयर का उपयोग कर सकते हैं। नई पीढ़ी के सॉफ्टवेयर प्रॉक्सिस केवल उन उपकरणों के ट्रेंडी संस्करण हैं जिनका हमने लंबे समय से उपयोग किया है।


चित्र 2: मानव नियंत्रण विमान

हालांकि, हमने लंबे समय तक नियंत्रण विमान का उपयोग किया है, हालांकि अधिकांश नेटवर्क ऑपरेटर सिस्टम के इस हिस्से को किसी भी तकनीकी घटक के साथ नहीं जोड़ सकते हैं। इसका कारण सरल है:
आज उपयोग किए जाने वाले अधिकांश नियंत्रण विमान हैं ... हम ।

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


चित्र 3: उन्नत सेवा जाल नियंत्रण विमान

चित्र 3 सेवा जाल के "विस्तारित" नियंत्रण विमान को दर्शाता है। इसमें निम्नलिखित भाग होते हैं:

• मानव : अभी भी एक व्यक्ति (उम्मीद से कम गुस्से में) है जो पूरे सिस्टम के बारे में उच्च-स्तरीय निर्णय लेता है।
• कंट्रोल प्लेन UI : एक व्यक्ति सिस्टम को नियंत्रित करने के लिए कुछ प्रकार के यूजर इंटरफेस के साथ इंटरैक्ट करता है। यह एक वेब पोर्टल, एक कमांड लाइन एप्लिकेशन (सीएलआई) या कुछ अन्य इंटरफ़ेस हो सकता है। उपयोगकर्ता इंटरफ़ेस का उपयोग करते हुए, ऑपरेटर के पास ऐसे वैश्विक सिस्टम कॉन्फ़िगरेशन मापदंडों तक पहुंच है:
  
  • तैनाती प्रबंधन, नीले / हरे और / या क्रमिक यातायात हस्तांतरण के साथ
  • प्रमाणीकरण और प्राधिकरण सेटिंग
  • रूटिंग टेबल विनिर्देशों, उदाहरण के लिए, जब एप्लिकेशन ए "/ फू" के बारे में जानकारी का अनुरोध करता है, तो क्या होता है
  • बैलेंसर सेटिंग लोड करें, जैसे टाइमआउट, रिट्रीस, सर्किट ब्रेकिंग पैरामीटर आदि।
• वर्कलोड शेड्यूलर : एक निश्चित प्रकार की योजना / ऑर्केस्ट्रेशन प्रणाली, जैसे कुबेरनेट्स या घुमंतू के माध्यम से बुनियादी ढांचे में सेवाएं शुरू की जाती हैं। अनुसूचक अपने स्थानीय प्रॉक्सी सर्वर के साथ सेवा को लोड करने के लिए जिम्मेदार है।
• सेवा खोज जब शेड्यूलर सर्विस इंस्टेंस को शुरू और बंद करता है, तो यह स्वास्थ्य राज्य को सेवा की खोज प्रणाली की रिपोर्ट करता है।
• सिडकर प्रॉक्सी कॉन्फ़िगरेशन API : स्थानीय प्रॉक्सी गतिशील रूप से ऑपरेटर के हस्तक्षेप के बिना "अंततः सुसंगत" मॉडल के अनुसार सिस्टम के विभिन्न घटकों से राज्य को निकालता है। संपूर्ण प्रणाली, जिसमें वर्तमान में चल रही सभी सेवाएँ और स्थानीय प्रॉक्सी सर्वर शामिल हैं, अंततः एक पारिस्थितिकी तंत्र में परिवर्तित हो जाती हैं। एनवॉय डेटा प्लेन एपीआई इस बात का एक उदाहरण है कि यह व्यवहार में कैसे काम करता है।

अनिवार्य रूप से, नियंत्रण विमान का लक्ष्य एक ऐसी नीति स्थापित करना है जिसे अंततः डेटा विमान द्वारा अपनाया जाएगा। अधिक उन्नत नियंत्रण विमान ऑपरेटर से कुछ प्रणालियों के अधिक हिस्सों को हटा देंगे और उन्हें कम मैनुअल नियंत्रण की आवश्यकता होगी, बशर्ते कि वे सही तरीके से काम करें!!

डाटा प्लेन और कंट्रोल प्लेन। डाटा प्लेन बनाम कंट्रोल प्लेन समरी

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

वर्तमान परियोजना परिदृश्य

ऊपर दिए गए स्पष्टीकरण का अनुमान लगाते हुए, आइए “सेवा जाल” परियोजना की वर्तमान स्थिति को देखें।

• डेटा प्लेन : लिंकरड, एनजीआईएनएक्स, हाप्रोसी, एनवॉय, ट्रैफिक
• नियंत्रण विमान : इस्तियो, नेल्सन, स्मार्टस्टैक

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

2016 की शुरुआत में, लिंकरड सेवा जाल के लिए डेटा प्लेन के लिए पहले प्रॉक्सी सर्वरों में से एक था और इसने सेवा जाल डिजाइन मॉडल के प्रति जागरूकता बढ़ाने और ध्यान बढ़ाने का शानदार काम किया। इसके लगभग 6 महीने बाद, एनवॉय लिंकरड में शामिल हो गए (हालाँकि वह 2015 के अंत से ही Lyft के साथ हैं)। लिंकरड और एनवॉय दो परियोजनाएं हैं जो सेवा नेटवर्क पर चर्चा करते समय सबसे अधिक बार उल्लेखित हैं।

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

नेल्सन और स्मार्टस्टैक नियंत्रण विमान और डेटा विमान के अलगाव को और स्पष्ट करने में मदद करते हैं। नेल्सन एनवॉय को अपने प्रॉक्सी के रूप में उपयोग करता है और HashiCorp स्टैक के आधार पर सेवा जाल का एक विश्वसनीय नियंत्रण विमान बनाता है, अर्थात। खानाबदोश आदि। स्मार्टस्टैक शायद सेवा नेटवर्क की एक नई लहर है। स्मार्टस्टैक एक HAProxy या NGINX के चारों ओर एक नियंत्रण विमान बनाता है, जो सेवा जाल और डेटा प्लेन से नियंत्रण विमान को हटाने की क्षमता प्रदर्शित करता है।

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

मुख्य बिंदु (मुख्य टेकअवे)

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