Apache APISIX ने Service Mesh के साथ पूर्ण ट्रैफिक प्रबंधन को एकीकृत किया

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

सर्विस मेश की वर्तमान स्थिति और समस्याएं

सर्विस मेश का उदय वर्तमान व्यावसायिक आर्किटेक्चर के विकास से गहराई से जुड़ा हुआ है। क्लाउड नेटिव के बढ़ते प्रवृत्ति के साथ, अधिकांश उद्योग माइक्रोसर्विसेज में परिवर्तन करने लगे हैं, जहां हमने पाया कि ऐप छोटे और छोटे होते जा रहे हैं, और प्रत्येक ऐप के अंदर कुछ सामान्य तत्व होते हैं। इसलिए, हमने सोचना शुरू किया, "क्या कोई ऐसी तकनीक है जो सामान्य परिदृश्य को हल कर सकती है?" इस प्रकार, साइडकार का उदय हुआ।

साइडकार के साथ, सेवा पंजीकरण और खोज, ट्रैफिक प्रबंधन, ऑब्जर्वेबिलिटी, और सुरक्षा जैसे कुछ कार्यों को इसमें डाला जा सकता है ताकि व्यावसायिक सेवाएं व्यावसायिक तर्क विकसित करने पर ध्यान केंद्रित कर सकें।

हालांकि, साइडकार के उदय ने लोगों को धीरे-धीरे इसकी कुछ समस्याओं को महसूस कराया है, जैसे:

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

इसलिए, व्यावसायिक स्थिति और समस्याओं के बीच, हमने सोचना शुरू किया कि क्या एक आदर्श सर्विस मेश समाधान हो सकता है जो इन समस्याओं को हल कर सके।

आदर्श सर्विस मेश कैसा दिखता है?

व्यावसायिक परिदृश्यों में, हमारी सर्विस मेश के लिए आवश्यकताएं, जैसा कि ऊपर दिखाया गया है, यानी संसाधन, प्रदर्शन, ट्रैफिक प्रबंधन, और स्केलिंग की दिशा में कई आयामों में आवश्यकताएं हैं। बेशक, इनके अलावा, अन्य आयामों में भी कुछ और विस्तृत आवश्यकताएं होंगी। उदाहरण के लिए:

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

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

APISIX-आधारित सर्विस मेश समाधान

Apache APISIX एक डायनामिक, रियल-टाइम, हाई-परफॉर्मेंस क्लाउड-नेटिव API गेटवे है जो लोड बैलेंसिंग, डायनामिक अपस्ट्रीम, कैनरी रिलीज, सर्किट ब्रेकिंग, प्रमाणीकरण, ऑब्जर्वेबिलिटी, और अधिक जैसी समृद्ध ट्रैफिक प्रबंधन सुविधाएं प्रदान करता है।

दुनिया भर के सैकड़ों उद्योग Apache APISIX को व्यावसायिक महत्वपूर्ण ट्रैफिक को संभालने के लिए लागू करते हैं, जिसमें वित्त, इंटरनेट, विनिर्माण, खुदरा, कैरियर्स आदि शामिल हैं, जैसे NASA, European Factory Platform, China Airlines, China Mobile, Tencent, Huawei, Weibo, Netease, Ke Holdings Inc., 360, Taikang, Nayuki Holdings Limited, आदि। इसलिए, APISIX-आधारित सर्विस मेश समाधान न केवल उपयोग स्तर पर बल्कि विभिन्न उद्योग क्षेत्रों के सामने आने पर भी मजबूत मांग में होगा।

वर्तमान सर्विस मेश समाधान की आर्किटेक्चर Istio को कंट्रोल प्लेन और APISIX को डेटा प्लेन के रूप में आधारित है।

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

डेटा प्लेन वह जगह है जहां Apache APISIX अपना लाभ उठा सकता है। एक क्लाउड-नेटिव API गेटवे के रूप में, इस सर्विस मेश समाधान में Istio के डेटा प्लेन के रूप में APISIX ने क्या कदम उठाए हैं?

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

इसलिए, इस प्रक्रिया में, हमने पहले APISIX में एक कॉन्फ़िगरेशन सेंटर जोड़ा जिसे xDS कहा जाता है ताकि etcd की आवश्यकता को समाप्त किया जा सके, और फिर Amesh को पेश किया, जैसा कि ऊपर दिखाया गया है, एक Go प्रोग्राम जो एक डायनामिक लिंक लाइब्रेरी में संकलित होता है जो APISIX शुरू होने पर लोड होता है। यह xDS प्रोटोकॉल का उपयोग करके Istio के साथ इंटरैक्ट करता है। फिर, यह प्राप्त कॉन्फ़िगरेशन को APISIX के xDS कॉन्फ़िगरेशन सेंटर में लिखता है, जो विशिष्ट रूटिंग नियम उत्पन्न करता है और अंततः APISIX का उपयोग करके संबंधित अनुरोधों को रूट करता है।

उपरोक्त आर्किटेक्चर के कॉन्फ़िगरेशन के बाद, निम्नलिखित परिणाम प्राप्त किए जा सकते हैं:

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

समाधान की विशिष्ट प्रदर्शन

महत्वपूर्ण प्रदर्शन सुधार

डेटा हमेशा एक तकनीकी उत्पाद को प्रस्तुत करने का सबसे सीधा और प्रभावी तरीका होता है। हम सर्विस मेश समाधान में APISIX और Envoy को डेटा प्लेन के रूप में उपयोग करते हैं, 5,000 रूट्स की मात्रा का उपयोग करके विभिन्न परिदृश्यों में स्ट्रेस टेस्टिंग करते हैं, और अंत में निम्नलिखित डेटा तुलना प्रस्तुत करते हैं।

टेस्ट परिदृश्य "5,000 रूट्स में से 3000वें रूट को मिलाना" है। टेस्ट परिदृश्यों की संख्या अधिक होने के कारण, केवल मध्य भाग के रूट्स को मिलाने वाले परिदृश्यों का वर्णन किया गया है, और सिर और पूंछ के रूट्स को मिलाने वाले परिदृश्य भी हैं। (बहुत अधिक डेटा होने के कारण, निम्नलिखित डेटा 3000 रूट्स की मात्रा के साथ टेस्ट का परिणाम है)।

ऊपर दिए गए डेटा से आप देख सकते हैं कि APISIX समान दबाव और समान मशीन कॉन्फ़िगरेशन के लिए QPS स्तर पर 5x प्रदर्शन सुधार दिखाता है। साथ ही, अनुरोध विलंबता स्तर पर, APISIX Envoy की तुलना में एक क्रमांक कम है, APISIX की विलंबता माइक्रोसेकंड रेंज में है और Envoy की मिलीसेकंड रेंज में है। बेशक, आप यह भी देख सकते हैं कि इस माप में, APISIX का CPU उपयोग केवल 50% है जब Envoy का CPU पहले से ही पूरी क्षमता पर चल रहा है।

संसाधन उपयोग में कमी

सर्विस मेश समाधान में साइडकार को इंजेक्ट करते समय, आमतौर पर अतिरिक्त संसाधनों की खपत होती है। API-आधारित समाधान संसाधन खपत को 60% तक कम कर सकता है। यह कैसे संभव है?

पहले, कॉन्फ़िगरेशन आवश्यकता के अनुसार वितरित होता है। Istio साइडकार के संसाधन प्रबंधन के लिए कुछ आवश्यकता-आधारित नीतियों के साथ आता है, जैसे नेमस्पेस द्वारा अलगाव, लेकिन इस प्रक्रिया में उपयोगकर्ता ऑपरेशन पर अतिरिक्त मानसिक बोझ और प्रबंधन कठिनाइयां आती हैं।

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

APISIX के साथ, आप इन सभी परेशानियों से बच सकते हैं। APISIX कॉन्फ़िगरेशन सीधा और स्पष्ट है, मेमोरी में संग्रहीत डेटा को कम करता है, और इसके उच्च प्रदर्शन के साथ, CPU संसाधन खपत को कम करता है। पूरे समाधान की संसाधन खपत लगभग 60% कम हो जाती है।

कम सीखने की लागत और उच्च कस्टमाइज़ेशन क्षमता

पहले, Apache Software Foundation के एक सक्रिय ओपन सोर्स प्रोजेक्ट के रूप में, APISIX समुदाय में समृद्ध दस्तावेज़ीकरण और सीखने के संसाधन प्रदान करता है, जो APISIX के साथ शुरुआत करने वालों के लिए सीखने की लागत को कम करता है।

दूसरा, APISIX का सोर्स कोड Lua पर आधारित है, जो अपेक्षाकृत पढ़ने और समझने में आसान है, क्योंकि यह एक हल्की स्क्रिप्टिंग भाषा है, इसलिए APISIX सोर्स कोड को देखना स्पष्ट है।

अंत में, APISIX-आधारित सेकेंडरी डेवलपमेंट बहुत आसान है। जब आप अपने व्यवसाय के लिए कस्टम प्लगइन बनाना चाहते हैं, तो न केवल नेटिव Lua भाषा समर्थित है, बल्कि आप APISIX के Plugin Runner का उपयोग करके Python, Java, Go, और यहां तक कि Wasm जैसी अधिक परिचित भाषाओं में सेकेंडरी डेवलपमेंट कर सकते हैं।

APISIX की इकोलॉजिकल शक्ति भी उत्पाद की मजबूत एक्स्टेंसिबिलिटी के कारण है।

APISIX स्वयं सुरक्षा, लॉगिंग, ऑब्जर्वेबिलिटी, और अधिक के लिए विस्तृत प्लगइन्स प्रदान करता है। ये प्लगइन्स पूरी तरह से उपयोग किए जा सकते हैं जब APISIX को एक पारंपरिक गेटवे घटक के रूप में उपयोग किया जाता है। हालांकि, जब APISIX को कंट्रोल प्लेन पर Istio के साथ मिलाकर एक सर्विस मेश बनाने के लिए उपयोग किया जाता है, तो कई संसाधन Istio कंट्रोल प्लेन पर परिभाषित नहीं होते हैं। तो इस स्थिति में क्या किया जा सकता है?

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

इस तरह से CRD का उपयोग करने का सबसे तात्कालिक लाभ यह है कि यह एक्सटेंशन को अधिक नेटिव बनाता है, डिक्लेरेटिव कॉन्फ़िगरेशन का उपयोग करके इसे उपयोगकर्ताओं के लिए स्वीकार करना आसान बनाता है जबकि Istio के मूल कॉन्फ़िगरेशन को पूरी तरह से संगत बनाए रखता है। एक और लाभ यह है कि पहले से Istio समाधान का उपयोग करने वाले उपयोगकर्ताओं के लिए माइग्रेशन लागत कम होती है।

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

APISIX-आधारित सर्विस मेश समाधान के भविष्य की संभावनाएं

पीछे मुड़कर देखें, तो APISIX-आधारित सर्विस मेश समाधान पहले से ही पिछले लेख में उल्लिखित समस्याओं की ओर काम कर रहा है, और आदर्श सर्विस मेश समाधान की ओर काम कर रहा है।

APISIX-आधारित सर्विस मेश समाधान के साथ, आप देख सकते हैं कि ट्रैफिक बाहर से APISIX Ingress के माध्यम से आता है और बीच में APISIX के माध्यम से प्रोसेस होता है। इस प्रक्रिया में, APISIX Ingress उत्तर-दक्षिण ट्रैफिक को संभालता है, और Amesh + Istio पूर्व-पश्चिम ट्रैफिक को संभालता है।

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

आगामी पुनरावृत्तियों में, APISIX-आधारित सर्विस मेश समाधान को और गहरा किया जाएगा, जैसे कि:

APISIX कार्यक्षमता के साथ xRPC क्षमताओं के कार्यान्वयन का निर्माण करना।
नेटिव हेटेरोजेनस मल्टी-प्रोटोकॉल सपोर्ट करना।
Istio सहित सभी प्रकार के परिदृश्यों और कॉन्फ़िगरेशन को कवर करना, जिससे उपयोगकर्ता माइग्रेशन लागत को काफी कम किया जा सके।

निष्कर्ष में, वर्तमान तकनीकी प्रवृत्तियों में, सर्विस मेश निश्चित रूप से भविष्य में एक लोकप्रिय प्रवृत्ति होगी। हालांकि विभिन्न समाधान अभी भी पूर्ण नहीं हैं, लेकिन समग्र स्थिति एक ऊपरी सर्पिल है। बेशक, APISIX-आधारित सर्विस मेश भी उस आदर्श सर्विस मेश समाधान की ओर बढ़ रहा है जो हर किसी के मन में है।