ओपन-सोर्स API गेटवे Apache APISIX का तकनीकी अन्वेषण
पृष्ठभूमि
Apache APISIX एक गतिशील, रियल-टाइम, उच्च प्रदर्शन वाला ओपन-सोर्स API गेटवे है जो लोड बैलेंसिंग, डायनामिक रूटिंग, कैनरी रिलीज, सर्किट ब्रेकिंग, पहचान प्रमाणीकरण और ऑब्जर्वेबिलिटी जैसे समृद्ध ट्रैफिक प्रबंधन कार्य प्रदान करता है।
एक API गेटवे के रूप में, Apache APISIX उद्यमों को गेटवे, Kubernetes Ingress और सर्विस मेश जैसे परिदृश्यों में API और माइक्रोसर्विस ट्रैफिक को तेजी से और सुरक्षित रूप से प्रोसेस करने में मदद कर सकता है। इसके अलावा, यह क्लाइंट से सर्वर तक के उत्तर-दक्षिण ट्रैफिक और विभिन्न उद्यम माइक्रोसर्विसेज के बीच पूर्व-पश्चिम ट्रैफिक को संभाल सकता है।
6 जून 2019 को ओपन-सोर्स किए जाने के बाद, APISIX को अक्टूबर 2019 में Apache Software Foundation को दान कर दिया गया और कुछ ही महीनों में Apache Software Foundation का एक टॉप-लेवल प्रोजेक्ट बन गया।
APISIX इतने कम समय में इतनी तेजी से क्यों उभरा? APISIX ने किस तरह के जादुई तकनीकी अन्वेषण किए? क्यों अधिक से अधिक डेवलपर्स और उद्यम APISIX का उपयोग करना चाहते हैं? आइए जानें।
Apache APISIX की मुख्य विशेषताएं
डेटाबेस पर निर्भरता से मुक्त
APISIX प्रोजेक्ट के आने से पहले कई वाणिज्यिक API गेटवे या ओपन-सोर्स API गेटवे प्रोजेक्ट्स थे। इन प्रतिस्पर्धियों की संभावित समस्या यह है कि इनमें से अधिकांश उत्पाद अपने API डेटा, कॉन्फ़िगरेशन जानकारी, सर्टिफिकेट कॉन्फ़िगरेशन और रूट जानकारी को एक रिलेशनल डेटाबेस में स्टोर करते हैं।
रिलेशनल डेटाबेस में स्टोर करने के स्पष्ट लाभ यह हैं कि यह उपयोगकर्ताओं को SQL स्टेटमेंट्स के साथ लचीली क्वेरी करने और बैकअप और अनुवर्ती रखरखाव करने में सुविधाजनक बनाता है।
हालांकि, हर सिक्के के दो पहलू होते हैं। एक बेसिक मिडलवेयर के रूप में, API गेटवे सभी क्लाइंट ट्रैफिक को संभालेगा, जिससे उपलब्धता के लिए उच्च आवश्यकताएं बढ़ जाती हैं। यदि आपका API गेटवे एक रिलेशनल डेटाबेस पर निर्भर करता है, तो एक बार डेटाबेस में त्रुटि होने पर, जैसे कि क्रैश और डेटा हानि, गेटवे प्रभावित होगा। इस स्थिति में, सिस्टम की समग्र उपलब्धता की सीमा और मजबूत हो जाती है।
इसलिए, APISIX के डिजाइनरों ने ऐसी समस्याओं से बचने के लिए अंतर्निहित आर्किटेक्चर के पहलू से हर संभव प्रयास किया।
APISIX का आर्किटेक्चर मुख्य रूप से दो भागों में विभाजित है। पहला भाग, जिसे डेटा प्लेन कहा जाता है, क्लाइंट्स के अनुरोधों और ट्रैफिक को संभालने वाला घटक है। यह प्रमाणीकरण, सर्टिफिकेट ऑफलोडिंग, लॉग विश्लेषण और ऑब्जर्वेबिलिटी का समर्थन करता है। डेटा प्लेन कोई डेटा स्टोर नहीं करता है, यह एक स्टेटलेस संरचना है।
दूसरा भाग कंट्रोल प्लेन कहलाता है। APISIX कंट्रोल प्लेन पर MySQL जैसे पारंपरिक कॉन्फ़िगरेशन स्टोरेज का उपयोग नहीं करता है, बल्कि etcd का उपयोग करता है।
ऐसा करने के लाभ:
- उत्पादों के क्लाउड-नेटिव आर्किटेक्चर के साथ अधिक एकीकृत
- API गेटवे द्वारा संग्रहीत डेटा प्रकारों के लिए अधिक उपयुक्त
- उच्च उपलब्धता की विशेषताओं को बेहतर ढंग से प्रतिबिंबित करना
- परिवर्तनों की मिलीसेकंड सूचनाएं
etcd का उपयोग करके, डेटा प्लेन को केवल etcd के परिवर्तनों की निगरानी करने की आवश्यकता होती है। यदि आप डेटाबेस को पोल करते हैं, तो नवीनतम कॉन्फ़िगरेशन प्राप्त करने में 5-10 सेकंड लग सकते हैं। हालांकि, यदि आप etcd कॉन्फ़िगरेशन परिवर्तनों पर नजर रखते हैं, तो आप मिलीसेकंड के भीतर प्रतिक्रिया प्राप्त कर सकते हैं, जिससे रियल-टाइम प्रभाव प्राप्त होता है।
इसलिए, एक रिलेशनल डेटाबेस के बजाय etcd का उपयोग करने से APISIX अंतर्निहित क्लाउड वातावरण के साथ अधिक संगत हो जाता है और इसकी उच्च उपलब्धता के लाभ को मजबूत करता है।
एकाधिक प्रोग्रामिंग भाषाओं के लिए प्लगइन्स
API गेटवे डेटाबेस और अन्य मिडलवेयर से कुछ अलग होते हैं। बाद वाले की तुलना में, गेटवे अधिक बार कस्टमाइज्ड डेवलपमेंट और सिस्टम इंटीग्रेशन में उपयोग किए जाते हैं।
हालांकि APISIX ने कई आधिकारिक प्लगइन्स जारी किए हैं, फिर भी विभिन्न उपयोगकर्ताओं के लिए सभी उपयोग परिदृश्यों को कवर करना मुश्किल है। इसलिए, वास्तविक उपयोग में, व्यवसाय के लिए कुछ कस्टमाइज्ड प्लगइन्स को विकसित करने की आवश्यकता होती है, कम या ज्यादा। APISIX गेटवे के माध्यम से अधिक प्रोटोकॉल या सिस्टम को एकीकृत करता है और अंततः गेटवे स्तर पर एकीकृत प्रबंधन प्राप्त करता है।
शुरुआत में, APISIX केवल Lua भाषा में प्लगइन्स के विकास का समर्थन करता था। लाभ यह है कि विकसित प्लगइन्स मूल प्रोग्रामिंग भाषा के अंतर्निहित अनुकूलन के माध्यम से उच्च प्रदर्शन प्राप्त कर सकते हैं। हालांकि, एक स्पष्ट नुकसान यह है कि Lua, एक नई भाषा सीखने के लिए समय और सीखने की लागत की आवश्यकता होती है।
मूल रूप से, APISIX दो तरीकों से समस्याओं को हल करता है।
पहला तरीका है Runner Plugin के माध्यम से अधिक मुख्यधारा प्रोग्रामिंग भाषाओं का समर्थन करना, जैसे Java, Python, Go, आदि। यदि आप एक बैकएंड इंजीनियर हैं, तो आपको इनमें से कम से कम एक भाषा जाननी चाहिए; तब आप RPC प्रोटोकॉल का उपयोग करके और अपनी परिचित भाषा का उपयोग करके एक APISIX प्लगइन विकसित कर सकते हैं।
एक ओर, यह विकास लागत को कम करने और विकास दक्षता को बढ़ाने के लिए फायदेमंद है। हालांकि, दूसरी ओर, प्रदर्शन स्तर पर कुछ विलंब होता है। तो सवाल उठता है। क्या कोई समाधान होगा जो Lua के मूल प्रदर्शन को प्राप्त कर सके और साथ ही उच्च-स्तरीय भाषा को ध्यान में रख सके?
यहां दूसरा तरीका आता है, जो ऊपर की तस्वीर के बाईं ओर दिखाया गया है। WebAssembly का उपयोग पहले फ्रंट एंड या ब्राउज़र पर एक तकनीक के रूप में किया गया था और धीरे-धीरे सर्वर साइड पर अपने लाभ प्रदान करता है।
WebAssembly को APISIX में एम्बेड करके, उपयोगकर्ता इसका उपयोग WebAssembly बाइटकोड को APISIX में चलाने के लिए कर सकते हैं। अंतिम प्रभाव यह है कि एक APISIX प्लगइन को उच्च प्रदर्शन और उच्च-स्तरीय प्रोग्रामिंग भाषाओं में लिखा जा सकता है।
इसलिए वर्तमान APISIX संस्करण में, उपयोगकर्ता Lua, Go, Python, Wasm, और अन्य तरीकों का उपयोग करके APISIX पर आधारित कोड को कस्टमाइज कर सकते हैं। यह डिजाइन डेवलपर्स के लिए थ्रेसहोल्ड को कम करता है और APISIX के कार्यों के लिए अधिक संभावनाएं प्रदान करता है।
प्लगइन का हॉट रीलोडिंग
APISIX में NGINX की तुलना में दो महत्वपूर्ण प्रगति हैं: APISIX क्लस्टर प्रबंधन और डायनामिक रीलोडिंग का समर्थन करता है।
यदि आपने NGINX का उपयोग किया है, तो आप जानते होंगे कि NGINX के सभी कॉन्फ़िगरेशन nginx.conf फ़ाइल में लिखे जाते हैं। क्लस्टर नियंत्रण करने के लिए, आपको हर सर्वर पर nginx.conf फ़ाइल को संशोधित करने की आवश्यकता होती है। इस पूरी प्रक्रिया में कोई केंद्रीकृत प्रबंधन कंट्रोल प्लेन नहीं होता है। प्रत्येक NGINX डेटा प्लेन और कंट्रोल प्लेन का संयोजन होता है। यदि उपयोगकर्ताओं के पास दर्जनों या सैकड़ों NGINX सर्वर हैं, तो प्रबंधन लागत बहुत अधिक होगी।
ऊपर वर्णित परिदृश्य में, nginx.conf फ़ाइल को संशोधित करने के बाद हर NGINX सर्वर को काम करने के लिए रीस्टार्ट करने की आवश्यकता होती है। उदाहरण के लिए, सर्टिफिकेट अपडेट या अपस्ट्रीम परिवर्तन के लिए, आपको पहले कॉन्फ़िगरेशन फ़ाइल को संशोधित करना होगा और सर्वर को रीस्टार्ट करना होगा ताकि यह प्रभावी हो सके। यदि आपका अनुरोध विशेष रूप से बड़ा नहीं है तो यह विधि मुश्किल से स्वीकार्य है। हालांकि, जैसे-जैसे API और माइक्रोसर्विसेज अधिक से अधिक दिखाई देते हैं, यदि प्रत्येक संशोधन के लिए सर्वर को रीस्टार्ट करने की आवश्यकता होती है, तो क्लाइंट पर प्रभाव बहुत बड़ा होगा।
- हॉट अपडेट्स और हॉट प्लगइन्स: बिना रीस्टार्ट के अपने कॉन्फ़िगरेशन और प्लगइन्स को लगातार अपडेट करता है!
- प्रॉक्सी रिव्राइट: अपस्ट्रीम को भेजने से पहले अनुरोध के होस्ट, URI, स्कीमा, मेथड और हेडर को रिव्राइट करने का समर्थन करता है।
- रिस्पॉन्स रिव्राइट: क्लाइंट को कस्टमाइज्ड रिस्पॉन्स स्टेटस कोड, बॉडी और हेडर सेट करता है।
- डायनामिक लोड बैलेंसिंग: वेट के साथ राउंड-रॉबिन लोड बैलेंसिंग।
- हैश-आधारित लोड बैलेंसिंग: कंसिस्टेंट हैशिंग सत्रों के साथ लोड बैलेंसिंग।
- हेल्थ चेक्स: अपस्ट्रीम नोड पर हेल्थ चेक्स को सक्षम करता है और लोड बैलेंसिंग के दौरान अस्वस्थ नोड्स को स्वचालित रूप से फ़िल्टर करता है ताकि सिस्टम की स्थिरता सुनिश्चित हो सके।
- सर्किट-ब्रेकर: अस्वस्थ अपस्ट्रीम सेवाओं की बुद्धिमान ट्रैकिंग।
- प्रॉक्सी मिरर: क्लाइंट अनुरोधों को मिरर करने की क्षमता प्रदान करता है।
- ट्रैफिक स्प्लिट: उपयोगकर्ताओं को विभिन्न अपस्ट्रीम्स के बीच ट्रैफिक के प्रतिशत को धीरे-धीरे निर्देशित करने की अनुमति देता है।
ऊपर की तस्वीर में उन घटकों को सूचीबद्ध किया गया है जहां APISIX वर्तमान में हॉट रीलोडिंग को लागू करता है। हम देख सकते हैं कि कोड अपस्ट्रीम से सर्टिफिकेट और यहां तक कि प्लगइन तक रियल-टाइम में प्रभावी होता है। कुछ समुदाय के सदस्य समझ सकते हैं कि अपस्ट्रीम और सर्टिफिकेट्स डायनामिक क्यों हैं क्योंकि डेटा अक्सर बदलता है। हालांकि, वे पूछेंगे कि प्लगइन के संशोधन को डायनामिक क्यों होना चाहिए क्योंकि उनका मानना है कि प्लगइन को संशोधित करना कम बार होता है, जो अत्यधिक सक्रिय होने के लिए अनावश्यक लगता है।
APISIX के अंतर्निहित डिजाइनरों के रूप में, हम चाहते हैं कि यह अंततः डायनामिक हो, जो उद्यम के लिए अधिक संभावनाओं को बढ़ाने में एक महत्वपूर्ण लाभ प्रदान करता है। उदाहरण के लिए, उपयोगकर्ता डीबग प्लगइन को संशोधित करते समय कोड को ट्रबलशूट कर सकते हैं, बिना किसी प्लगइन कोड को बदले। ऐसी परिस्थितियों में, उपयोगकर्ता किसी भी समय समस्या को पुन: उत्पन्न कर सकता है और इसे रीस्टार्ट किए बिना रिकॉर्ड कर सकता है। डीबगिंग फ़ंक्शन के साथ प्लगइन हॉट रीलोडिंग मैकेनिज्म के साथ बहुत लचीला होगा, जो डेवलपर्स को ट्रबलशूटिंग में समय और प्रयास बचाने में मदद करेगा।
प्लगइन का डायनामिक ऑर्केस्ट्रेशन
हॉट रीलोडिंग के अलावा, APISIX प्लगइन्स के बीच रियल-टाइम डायनामिक ऑर्केस्ट्रेशन का समर्थन करता है। डायनामिक ऑर्केस्ट्रेशन प्लगइन्स के संचालन के लिए अनंत संभावनाएं भी लाता है।
प्लगइन ऑर्केस्ट्रेशन क्या है? जब हम विभिन्न आवश्यकताओं को प्रस्तुत करते हैं, तो हम एक अनुरोध को एक प्लगइन में बदलना चाहते हैं, जैसे LEGO खेलना। हम एक एकीकृत मानक के माध्यम से अनंत विविध संभावित आकार बना सकते हैं, जैसे आकार फिट और इंटरसेक्शन, जो LEGO का एक आनंद है। APISIX प्लगइन्स के लिए, प्रत्येक प्लगइन एक स्वतंत्र केस आवश्यकता को पूरा करता है। हम यह पूछना बंद नहीं कर सकते कि क्या यह संभव है कि उपयोगकर्ता अपनी आवश्यकताओं को प्लगइन्स के साथ कस्टमाइज कर सकें जैसे वे LEGO खेल रहे हों।
उदाहरण के लिए, यदि APISIX में 100 प्लगइन्स हैं, तो उपयोगकर्ता केवल इन 100 प्लगइन्स के कार्यों को देख सकते हैं न कि उनकी अंतर्निहित लचीलापन को। इसलिए, मिडलवेयर विकसित करते समय, हमें यह विचार करने की आवश्यकता है कि उत्पाद क्या हो सकता है और लोगों द्वारा उनका उपयोग करते समय अधिक संभावनाएं कैसे प्रदान की जाएं।
APISIX में वर्तमान में लगभग 100 प्लगइन्स हैं, लेकिन इसकी 100 से अधिक संभावनाएं हैं। इसलिए, प्लगइन व्यवस्था में इसकी क्षमता विकसित करने के बाद, संयोजन 100 * 99 * 98 * 97 * 96 * ..., अनंत के करीब हो जाता है।
उदाहरण के लिए, जब आप किसी उपयोगकर्ता की दर को सीमित करते हैं, तो आमतौर पर एक त्रुटि कोड होगा। आप बाद की गतिविधि रिकॉर्डिंग के लिए एक लॉगिंग प्लगइन या एक त्रुटि रिपोर्टिंग प्लगइन को जोड़ने का प्रयास कर सकते हैं। नीचे की तस्वीर APISIX के प्लगइन ऑर्केस्ट्रेशन के मॉडल को दिखाती है।
इस सुविधा का एक छिपा हुआ लाभ है: प्रत्येक प्लगइन के कोड को कवर करने वाला एक पूर्ण टेस्ट सूट। जब उपयोगकर्ता प्लगइन को व्यवस्थित करता है, तो उसे कोई कोड लिखने की आवश्यकता नहीं होती है। यह डिजाइन उत्पाद प्रबंधकों, सुरक्षा इंजीनियरों और संचालन और रखरखाव इंजीनियरों के लिए बहुत अनुकूल होगा, जिन्हें लंबे समय तक प्रशिक्षण और सीखने में समय बिताने की आवश्यकता नहीं होती है। इसके बजाय, वे कुछ सेटिंग्स को समायोजित करने के लिए प्लगइन्स को ड्रॉप करके एक नया APISIX प्लगइन बना सकते हैं। इसके अलावा, नए प्लगइन कोड की गुणवत्ता ओपन-सोर्स APISIX के आधिकारिक कोड के समान उच्च होगी।
सभी दिशाओं के ट्रैफिक के लिए गेटवे
सर्वर-साइड इंजीनियर जो कुछ गेटवे-संबंधित विकास करते हैं, वे दो बुनियादी अवधारणाओं से परिचित हो सकते हैं: उत्तर-दक्षिण ट्रैफिक, जो क्लाइंट्स, ब्राउज़रों या IoT (इंटरनेट ऑफ थिंग्स) डिवाइस से सर्वर तक के ट्रैफिक को संदर्भित करता है, और पूर्व-पश्चिम ट्रैफिक, जो उद्यमों के भीतर सिस्टम और माइक्रोसर्विसेज के बीच आपसी कॉल को संदर्भित करता है।
उत्तर-दक्षिण और पूर्व-पश्चिम ट्रैफिक से निपटने में घटक अलग-अलग होते हैं। उदाहरण के लिए, उत्तर-दक्षिण ट्रैफिक एक लोड बैलेंसर से गुजर सकता है, API गेटवे पर जा सकता है, और फिर एक सेवा गेटवे में प्रवेश कर सकता है। यही कारण है कि NGINX, APISIX और Spring Cloud Gateway जैसे घटक हैं। जब आप एक सर्विस मेश के साथ पूर्व-पश्चिम ट्रैफिक से निपटते हैं, तो आप Envoy जैसे घटकों का उपयोग कर सकते हैं, जो बहुत लगते हैं, लेकिन यदि आप उनके कार्यों पर ध्यान केंद्रित करते हैं तो आप उनकी समानताएं पा सकते हैं। अधिकांश रूटिंग शेड्यूलिंग, डायनामिक अपस्ट्रीम और सुरक्षित पहचान प्रमाणीकरण के लिए प्लगइन्स हैं। इस स्थिति में, क्या हम उत्तर-दक्षिण और पूर्व-पश्चिम ट्रैफिक से निपटने वाले घटकों को एकीकृत कर सकते हैं? आदर्श तरीका यह है कि जब एक क्लाइंट का अनुरोध सर्वर में प्रवेश करता है, तो यह सभी APISIX द्वारा लिया जाता है। चाहे उत्तर-दक्षिण हो या पूर्व-पश्चिम, सभी ट्रैफिक और डेटा कंट्रोल प्लेन के माध्यम से नियंत्रित होते हैं। यह APISIX की वर्तमान तकनीक के साथ पूरी तरह से प्राप्त करने योग्य है।
हमारे कुछ उपयोगकर्ता पहले ही पुष्टि कर चुके हैं कि यह मोड उपयोगकर्ता के संचालन और रखरखाव लागत को काफी कम कर सकता है। इसके साथ ही, यह जटिलता को कम कर सकता है, जिससे पूरे सिस्टम की प्रतिक्रिया गति में सुधार होता है। इसके अलावा, ऐसी सकारात्मक प्रतिक्रिया APISIX के बाद के पुनरावृत्तियों के लिए एक स्पष्ट दिशा प्रदान करती है, जिससे APISIX को पूर्ण-ट्रैफिक गेटवे स्तर पर अधिक कार्य और भूमिकाओं को आजमाने की अनुमति मिलती है।
मल्टी-सर्विस डिस्कवरी घटकों का समर्थन
गेटवे एक मूलभूत लेकिन महत्वपूर्ण घटक है। यह सभी क्लाइंट अनुरोधों को संसाधित करता है और विभिन्न सिस्टम और ओपन-सोर्स प्रोजेक्ट्स के साथ एकीकृत होता है, जो अधिक महत्वपूर्ण है।
एक और आवश्यक घटक - सर्विस डिस्कवरी और पंजीकरण अन्य तत्वों के साथ एकीकरण में उपयोग किया जाएगा। उपयोगकर्ता विभिन्न सेवाओं को अलग-अलग भागों में रखेंगे, जैसे Eureka और Nacos। इसलिए, बड़े पैमाने और लंबे समय तक चलने वाले IT सिस्टम में कई सर्विस डिस्कवरी घटकों का सह-अस्तित्व बहुत आम है।
इस स्थिति में, सभी ट्रैफिक इनग्रेस और एग्रेस गेटवे बन जाते हैं। लगभग सभी गेटवे केवल एक सर्विस डिस्कवरी का समर्थन करते हैं। आपको A रूट पर एक अलग Nacos सर्विस डिस्कवरी घटक और B रूट पर एक अन्य Consul घटक निर्दिष्ट करने की आवश्यकता होती है। इसलिए, आपको विभिन्न सर्विस डिस्कवरी घटकों से मेल खाने के लिए कई गेटवे तैनात करने की आवश्यकता होती है।
वर्तमान में, APISIX न केवल डेटा प्लेन पर सर्विस डिस्कवरी का समर्थन करता है, बल्कि कंट्रोल प्लेन पर सर्विस पंजीकरण और सर्विस डिस्कवरी घटकों का समर्थन करने के लिए धीरे-धीरे समर्थन करता है। यह कुछ बड़े पैमाने और दीर्घकालिक उद्यम सेवाओं के लिए एक अत्यधिक कुशल समाधान है। आप केवल एक API गेटवे तैनात करके विभिन्न सर्विस डिस्कवरी और पंजीकरण घट