जैसे-जैसे हम एक मोनोलिथिक एप्लिकेशन से माइक्रोसर्विस आर्किटेक्चर की ओर बढ़ते हैं, हमें नई चुनौतियों का सामना करना पड़ता है।

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

मैं लंबे समय से एक ऐसे उपकरण की तलाश में था जो ऐसी समस्याओं से निपटने में मदद करेगा (मैंने इसके बारे में हैबे पर लिखा था: 1, 2), लेकिन अंत में मैंने अपना स्वयं का ओपन सोर्स समाधान बनाया। इस लेख में मैं सर्विस मेश दृष्टिकोण के लाभों के बारे में बात करता हूं और इसके कार्यान्वयन के लिए एक नया टूल साझा करता हूं।

वितरित सिस्टम में त्रुटियों को खोजने की समस्या का वितरित ट्रेसिंग एक सामान्य समाधान है। लेकिन क्या होगा अगर नेटवर्क इंटरैक्शन के बारे में जानकारी एकत्र करने का यह तरीका अभी तक सिस्टम में लागू नहीं किया गया है, या इससे भी बदतर, सिस्टम के कुछ हिस्सों में यह पहले से ही ठीक से काम करता है, लेकिन कुछ हद तक ऐसा नहीं होता है, क्योंकि इसे पुरानी सेवाओं में नहीं जोड़ा गया है ? किसी समस्या का सटीक मूल कारण निर्धारित करने के लिए, सिस्टम में क्या हो रहा है, इसकी पूरी तस्वीर होना आवश्यक है। यह समझना विशेष रूप से महत्वपूर्ण है कि प्रमुख व्यवसाय-महत्वपूर्ण मार्गों में कौन सी माइक्रोसर्विसेज शामिल हैं।

यहां सर्विस मेश दृष्टिकोण हमारी सहायता के लिए आ सकता है, जो स्वयं संचालित सेवाओं की तुलना में निचले स्तर पर नेटवर्क जानकारी एकत्र करने के लिए सभी मशीनरी से निपटेगा। यह दृष्टिकोण हमें सभी ट्रैफ़िक को रोकने और तुरंत उसका विश्लेषण करने की अनुमति देता है। इसके अलावा, एप्लिकेशन को इसके बारे में कुछ भी जानने की ज़रूरत नहीं है।

सेवा जाल दृष्टिकोण

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

Решения

इस दृष्टिकोण के कई कार्यान्वयन पहले से ही मौजूद हैं: Istio и लिंकरडी2. वे बॉक्स से बाहर बहुत सारी सुविधाएँ प्रदान करते हैं। लेकिन साथ ही, संसाधनों पर एक बड़ा ओवरहेड भी आता है। इसके अलावा, जितना बड़ा क्लस्टर जिसमें ऐसी प्रणाली संचालित होती है, नए बुनियादी ढांचे को बनाए रखने के लिए उतने ही अधिक संसाधनों की आवश्यकता होगी। एविटो में, हम कुबेरनेट्स क्लस्टर संचालित करते हैं जिसमें हजारों सेवा उदाहरण शामिल हैं (और उनकी संख्या तेजी से बढ़ रही है)। अपने वर्तमान कार्यान्वयन में, इस्तियो प्रति सेवा उदाहरण के लिए ~300एमबी रैम की खपत करता है। बड़ी संख्या में संभावनाओं के कारण, पारदर्शी संतुलन सेवाओं के समग्र प्रतिक्रिया समय (10ms तक) को भी प्रभावित करता है।

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

परिणामस्वरूप, हम अपने निर्णय पर आये:  नेत्रमेश.

नेत्रमेश

नेत्रमेश सिस्टम में सेवाओं की संख्या की परवाह किए बिना, असीमित पैमाने पर स्केल करने की क्षमता वाला एक हल्का सर्विस मेश समाधान है।

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

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

निष्पादन

हमने अधिकतम उत्पादकता प्राप्त करने पर अपना ध्यान केंद्रित किया है। सेवा के प्रत्येक उदाहरण के बगल में तैनात किए गए समाधान के लिए, रैम और सीपीयू समय की एक छोटी खपत की आवश्यकता होती है। और, निःसंदेह, प्रतिक्रिया विलंब भी छोटा होना चाहिए।

आइए देखें कि हमें क्या परिणाम मिले।

रैम

नेत्रमेश बिना ट्रैफिक के ~10एमबी और प्रति उदाहरण 50 आरपीएस तक के लोड के साथ अधिकतम 10000एमबी की खपत करता है।

इस्तियो दूत प्रॉक्सी हजारों उदाहरणों के साथ हमारे क्लस्टर में हमेशा ~300एमबी की खपत करता है। यह इसे पूरे क्लस्टर में स्केल करने की अनुमति नहीं देता है।

नेत्रमेश के साथ हमें मेमोरी खपत में ~10 गुना की कमी मिली।

सी पी यू

लोड के तहत सीपीयू का उपयोग अपेक्षाकृत बराबर है। यह साइडकार के लिए समय की प्रति यूनिट अनुरोधों की संख्या पर निर्भर करता है। प्रति सेकंड 3000 अनुरोधों का मान चरम पर:

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

हम सेवाओं के बीच संचार के लिए HTTP/1 का उपयोग करते हैं। दूत के माध्यम से प्रॉक्सी करते समय इस्तियो के लिए प्रतिक्रिया समय में 5-10ms तक की वृद्धि हुई, जो उन सेवाओं के लिए काफी है जो एक मिलीसेकंड में प्रतिक्रिया देने के लिए तैयार हैं। नेत्रमेश के साथ यह समय घटकर 0.5-2ms हो गया है।

scalability

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

सेवा खोज

नेत्रमेश सेवा खोज के लिए कोई अतिरिक्त तंत्र नहीं जोड़ता है। सभी ट्रैफ़िक को नेत्र साइडकार के माध्यम से पारदर्शी रूप से दर्शाया जाता है।

नेत्रमेश HTTP/1 एप्लिकेशन प्रोटोकॉल का समर्थन करता है। इसे परिभाषित करने के लिए, पोर्ट की एक कॉन्फ़िगर करने योग्य सूची का उपयोग किया जाता है। आमतौर पर, सिस्टम में कई पोर्ट होते हैं जिनके माध्यम से HTTP संचार होता है। उदाहरण के लिए, हम सेवाओं और बाहरी अनुरोधों के बीच बातचीत के लिए 80, 8890, 8080 का उपयोग करते हैं। इस मामले में, उन्हें एक पर्यावरण चर का उपयोग करके सेट किया जा सकता है NETRA_HTTP_PORTS.

यदि आप सेवाओं के बीच इंट्रा-क्लस्टर संचार के लिए कुबेरनेट्स को एक ऑर्केस्ट्रेटर और इसकी सेवा इकाई तंत्र के रूप में उपयोग करते हैं, तो तंत्र बिल्कुल वैसा ही रहता है। सबसे पहले, माइक्रोसर्विस क्यूब-डीएनएस का उपयोग करके एक सेवा आईपी पता प्राप्त करता है और इसके लिए एक नया कनेक्शन खोलता है। यह कनेक्शन सबसे पहले स्थानीय नेत्र-साइडकार के साथ स्थापित किया जाता है और सभी टीसीपी पैकेट प्रारंभ में नेत्र पर पहुंचते हैं। इसके बाद, नेत्र-साइडकार मूल गंतव्य के साथ संबंध स्थापित करता है। नोड पर पॉड आईपी पर NAT बिल्कुल बिना नेट्रा के समान ही रहता है।

वितरित अनुरेखण और संदर्भ अग्रेषण

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

लेकिन एक समस्या है। जब तक सेवाएँ एक विशेष uber हेडर उत्पन्न नहीं करतीं और भेजती हैं, हम सिस्टम में कनेक्टेड ट्रेसिंग स्पैन नहीं देखेंगे। और यही वह चीज़ है जिसकी हमें समस्याओं का शीघ्रता से पता लगाने की आवश्यकता है। यहां फिर से नेत्रमेश के पास एक समाधान है। प्रॉक्सी HTTP हेडर पढ़ते हैं और, यदि उनमें उबर ट्रेस आईडी नहीं है, तो एक जेनरेट करते हैं। नेत्रमेश एक साइडकार में इनकमिंग और आउटगोइंग अनुरोधों के बारे में जानकारी संग्रहीत करता है और आवश्यक आउटगोइंग अनुरोध हेडर के साथ उन्हें समृद्ध करके उनका मिलान करता है। सेवाओं में आपको बस एक हेडर भेजना है X-Request-Id, जिसे पर्यावरण चर का उपयोग करके कॉन्फ़िगर किया जा सकता है NETRA_HTTP_REQUEST_ID_HEADER_NAME. नेत्रमेश में संदर्भ के आकार को नियंत्रित करने के लिए, आप निम्नलिखित पर्यावरण चर सेट कर सकते हैं: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (वह समय जिसके लिए संदर्भ संग्रहीत किया जाएगा) और NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (संदर्भ सफ़ाई की आवृत्ति)।

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

अनुरोध स्रोत का निर्धारण

यह निर्धारित करने के लिए कि अनुरोध कहां से आया है, आप स्रोत के साथ स्वचालित रूप से हेडर जोड़ने की कार्यक्षमता का उपयोग कर सकते हैं। एक पर्यावरण चर का उपयोग करना NETRA_HTTP_X_SOURCE_HEADER_NAME आप एक हेडर नाम निर्दिष्ट कर सकते हैं जो स्वचालित रूप से इंस्टॉल हो जाएगा। का उपयोग करके NETRA_HTTP_X_SOURCE_VALUE आप वह मान सेट कर सकते हैं जिस पर सभी आउटगोइंग अनुरोधों के लिए एक्स-सोर्स हेडर सेट किया जाएगा।

यह इस उपयोगी हेडर के वितरण को पूरे नेटवर्क में समान रूप से वितरित करने की अनुमति देता है। फिर आप इसे सेवाओं में उपयोग कर सकते हैं और इसे लॉग और मेट्रिक्स में जोड़ सकते हैं।

ट्रैफ़िक रूटिंग और नेत्रमेश आंतरिक

नेत्रमेश में दो मुख्य घटक होते हैं। पहला, नेट्रा-इनिट, ट्रैफ़िक को रोकने के लिए नेटवर्क नियम निर्धारित करता है। वह प्रयोग करता है iptables नियमों को पुनर्निर्देशित करता है साइडकार पर संपूर्ण या आंशिक ट्रैफ़िक को रोकना, जो नेत्रमेश का दूसरा मुख्य घटक है। आप कॉन्फ़िगर कर सकते हैं कि इनकमिंग और आउटगोइंग टीसीपी सत्रों के लिए किन पोर्ट को इंटरसेप्ट करने की आवश्यकता है: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.

टूल में एक दिलचस्प विशेषता भी है - संभाव्य रूटिंग। यदि आप नेट्रैमेश का उपयोग विशेष रूप से ट्रेसिंग स्पैन एकत्र करने के लिए करते हैं, तो उत्पादन वातावरण में आप संसाधनों को बचा सकते हैं और चर का उपयोग करके संभाव्य रूटिंग को सक्षम कर सकते हैं NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (0 से 1 तक). डिफ़ॉल्ट मान 1 है (सारा ट्रैफ़िक अवरुद्ध है)।

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

निर्भरता ग्राफ बनाना

जैगर में बड़ी मात्रा में ट्रेसिंग जानकारी प्राप्त करने के बाद, मैं सिस्टम में इंटरैक्शन का एक पूरा ग्राफ प्राप्त करना चाहता हूं। लेकिन यदि आपका सिस्टम काफी भरा हुआ है और प्रति दिन अरबों ट्रेसिंग स्पैन जमा होते हैं, तो उन्हें एकत्र करना इतना आसान काम नहीं है। ऐसा करने का एक आधिकारिक तरीका है: चिंगारी-निर्भरताएँ. हालाँकि, पूरा ग्राफ़ बनाने में घंटों लगेंगे और आपको पिछले 24 घंटों के लिए जैगर से संपूर्ण डेटासेट डाउनलोड करने के लिए मजबूर होना पड़ेगा।

यदि आप ट्रेसिंग स्पैन को स्टोर करने के लिए इलास्टिक्स खोज का उपयोग कर रहे हैं, तो आप इसका उपयोग कर सकते हैं एक सरल गोलांग उपयोगिता, जो इलास्टिक्स खोज की सुविधाओं और क्षमताओं का उपयोग करके मिनटों में एक ही ग्राफ़ बनाएगा।

नेत्रमेश का उपयोग कैसे करें

नेत्र को किसी भी ऑर्केस्ट्रेटर को चलाने वाली किसी भी सेवा में आसानी से जोड़ा जा सकता है। आप एक उदाहरण देख सकते हैं यहां.

फिलहाल, नेत्रा के पास सेवाओं में स्वचालित रूप से साइडकार लागू करने की क्षमता नहीं है, लेकिन कार्यान्वयन की योजनाएं हैं।

नेत्रमेश का भविष्य

मुख्य उद्देश्य नेत्रमेश न्यूनतम संसाधन लागत और उच्च प्रदर्शन प्राप्त करना, अंतर-सेवा संचार के अवलोकन और नियंत्रण के लिए बुनियादी क्षमताएं प्रदान करना है।

भविष्य में, नेटरमेश HTTP के अलावा अन्य एप्लिकेशन लेयर प्रोटोकॉल का भी समर्थन करेगा। L7 रूटिंग निकट भविष्य में उपलब्ध होगी.

यदि आपको भी ऐसी ही समस्याओं का सामना करना पड़ता है तो नेत्रमेश का उपयोग करें और प्रश्नों और सुझावों के साथ हमें लिखें।

स्रोत: www.habr.com