आप Apache APISIX को NGINX या Kong के बजाय क्यों चुनेंगे?

API गेटवे क्लाउड-नेटिव युग में एक महत्वपूर्ण इंफ्रास्ट्रक्चर घटक है। एक API गेटवे का मूल्यांकन करने के लिए दो सामान्य मानदंड हैं: यह कितना डायनामिक है, और इसकी ऑब्जर्वेबिलिटी कितनी परिपक्व है। कई कंपनियां पहले Nginx या Kong को अपने API गेटवे के रूप में उपयोग करती थीं, लेकिन बाद में Apache APISIX पर स्विच कर गईं। क्लाउड-नेटिव युग के लिए जन्मा Apache APISIX वास्तव में विभिन्न आयामों में व्यवसायों के लिए कई समस्याओं को हल करता है। अब आप सोच रहे होंगे, क्यों?

NGINX और Kong की सीमाएं

मोनोलिथिक सेवाओं के युग में, NGINX अधिकांश परिदृश्यों को संभाल सकता है। जबकि क्लाउड-नेटिव युग में, NGINX की वास्तुकला के कारण दो कमियां हैं:

NGINX क्लस्टर प्रबंधन का समर्थन नहीं करता है। लगभग हर कंपनी का अपना NGINX कॉन्फ़िगरेशन प्रबंधन सिस्टम होता है। हालांकि सिस्टम समान हैं, लेकिन कोई एकीकृत समाधान नहीं है।
NGINX कॉन्फ़िगरेशन के हॉट रीलोडिंग का समर्थन नहीं करता है। यदि उपयोगकर्ता NGINX का कॉन्फ़िगरेशन संशोधित करता है, तो NGINX को रीलोड करना आवश्यक होगा। साथ ही, Kubernetes में सेवाएं अक्सर बदलती रहती हैं। इसलिए यदि NGINX का उपयोग ट्रैफ़िक को संभालने के लिए किया जाता है, तो आपको अक्सर सेवा को रीस्टार्ट करना होगा, जो उद्यमों के लिए अस्वीकार्य है।

Kong, NGINX की कमियों को हल करता है लेकिन नई सीमाएं लाता है:

Kong को PostgreSQL या Cassandra डेटाबेस पर निर्भर रहना पड़ता है, जो Kong के पूरे आर्किटेक्चर को बहुत भारी बना देता है और उद्यम को उच्च उपलब्धता की सीमा प्रदान करेगा। यदि डेटाबेस विफल हो जाता है, तो पूरा API गेटवे विफल हो जाता है।
Kong का रूटिंग ट्रैवर्सल सर्च का उपयोग करता है। जब गेटवे में एक हजार से अधिक रूट होते हैं, तो इसका प्रदर्शन नाटकीय रूप से गिर जाता है।

APISIX उपरोक्त सभी सीमाओं को हल करता है और क्लाउड-नेटिव युग में सर्वश्रेष्ठ API गेटवे बन जाता है।

Apache APISIX के लाभ

अच्छी तरह से डिज़ाइन किया गया आर्किटेक्चर

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

जैसा कि ऊपर दिए गए चित्र में दिखाया गया है, बाएं और दाएं APISIX के डेटा प्लेन और कंट्रोल प्लेन हैं:

डेटा प्लेन: NGINX के नेटवर्क लाइब्रेरी पर आधारित (NGINX के रूट मिलान, स्थिर कॉन्फ़िगरेशन, और C मॉड्यूल का उपयोग किए बिना), यह Lua और NGINX का उपयोग करके अनुरोध ट्रैफ़िक को डायनामिक रूप से नियंत्रित करता है;
कंट्रोल प्लेन: प्रशासक अंतर्निहित RESTful API के माध्यम से etcd को संचालित कर सकते हैं। etcd के Watch मैकेनिज्म की मदद से, APISIX कॉन्फ़िगरेशन को मिलीसेकंड के भीतर प्रत्येक नोड पर सिंक्रनाइज़ कर सकता है।

डेटा अपडेट करने के लिए, Kong डेटाबेस पोलिंग विधि का उपयोग करता है; नवीनतम कॉन्फ़िगरेशन प्राप्त करने में 5-10 सेकंड लग सकते हैं, जबकि APISIX etcd कॉन्फ़िगरेशन परिवर्तनों की निगरानी करके इसे प्राप्त करता है, जो समय को मिलीसेकंड में नियंत्रित कर सकता है।

चूंकि APISIX और etcd दोनों मल्टी-इंस्टेंस डिप्लॉयमेंट का समर्थन करते हैं, इसलिए कोई सिंगल पॉइंट ऑफ फेल्योर नहीं है।

समृद्ध इकोसिस्टम

निम्नलिखित चित्र APISIX के इकोसिस्टम मैप को दर्शाता है। इस चित्र से हम देख सकते हैं कि APISIX L7 प्रोटोकॉल्स जैसे HTTP(S), HTTP2, Dubbo, IoT प्रोटोकॉल MQTT आदि का समर्थन करता है। इसके अलावा, APISIX L4 प्रोटोकॉल्स जैसे TCP/UDP का भी समर्थन करता है।

चित्र के दाएं भाग में कुछ ओपन-सोर्स या SaaS सेवाएं हैं, जैसे Apache SkyWalking, Prometheus, HashiCorp Vault आदि। चित्र के निचले भाग में अधिक सामान्य ऑपरेटिंग सिस्टम वातावरण, क्लाउड वेंडर और हार्डवेयर वातावरण हैं। एक ओपन-सोर्स सॉफ्टवेयर के रूप में, APISIX को ARM64 सर्वर पर भी चलाया जा सकता है।

APISIX न केवल कई प्रोटोकॉल और ऑपरेटिंग सिस्टम का समर्थन करता है, बल्कि मल्टी-लैंग्वेज प्रोग्रामिंग प्लगइन्स का भी समर्थन करता है। जब यह पहली बार आया था, APISIX केवल Lua भाषा का उपयोग करके प्लगइन्स लिखने का समर्थन करता था। इस मामले में, डेवलपर्स को Lua और NGINX से संबंधित तकनीकी स्टैक में महारत हासिल करने की आवश्यकता होती है। हालांकि, Lua और NGINX अपेक्षाकृत कम डेवलपर्स के लिए परिचित तकनीकें हैं। इसलिए, हमने APISIX पर मल्टी-लैंग्वेज प्लगइन डेवलपमेंट को सक्षम किया है, और Java, Golang, Node.js, और Python जैसी भाषाओं को आधिकारिक रूप से समर्थित किया है।

सक्रिय समुदाय

नीचे दिया गया चित्र योगदानकर्ता वृद्धि वक्र है, जहां क्षैतिज अक्ष समयरेखा को दर्शाता है, और ऊर्ध्वाधर अक्ष योगदानकर्ताओं की कुल संख्या को दर्शाता है। हम देख सकते हैं कि दो परियोजनाएं, Apache APISIX और Kong, अपेक्षाकृत अधिक सक्रिय हैं। Apache APISIX ने पहले दिन से ही एक उत्कृष्ट वृद्धि दर बनाए रखी है और Kong की तुलना में लगभग दोगुनी दर से तेजी से बढ़ रहा है। जुलाई 2022 तक, APISIX के योगदानकर्ताओं की संख्या Kong से अधिक हो गई है, जो APISIX की लोकप्रियता को दर्शाता है। बेशक, किसी परियोजना की सक्रियता का मूल्यांकन करने के कई अन्य तरीके हैं, जैसे मासिक सक्रिय मुद्दे, PR की कुल संख्या आदि। अच्छी खबर यह है कि APISIX इन पहलुओं में भी अद्वितीय है।

एकीकृत प्रॉक्सी इंफ्रास्ट्रक्चर

नीचे दिए गए चित्र से, मुझे विश्वास है कि आप APISIX के लक्ष्य को समझ गए होंगे: प्रॉक्सी इंफ्रास्ट्रक्चर को एकीकृत करना।

क्योंकि APISIX का मूल एक उच्च-प्रदर्शन प्रॉक्सी सेवा है, यह किसी भी पर्यावरण गुण से बंधा नहीं है। इसलिए, जब यह Ingress और Service Mesh जैसे उत्पादों में विकसित होता है, तो आपको APISIX के आंतरिक संरचना को बदलने की आवश्यकता नहीं है। निम्नलिखित आपको चरण-दर-चरण बताएगा कि APISIX इन परिदृश्यों का समर्थन कैसे करता है।

लोड बैलेंस और API गेटवे

पहला पारंपरिक LB और API गेटवे परिदृश्यों के लिए है। क्योंकि APISIX NGINX + LuaJIT पर आधारित है, इसमें उच्च-प्रदर्शन और सुरक्षा सुविधाएं हैं, और SSL प्रमाणपत्र के डायनामिक लोडिंग, SSL हैंडशेक ऑप्टिमाइजेशन और अन्य कार्यों का समर्थन करता है। लोड बैलेंसिंग में, APISIX भी बेहतर प्रदर्शन करता है। NGINX से APISIX पर स्विच करने से प्रदर्शन में गिरावट नहीं आती है, बल्कि एकीकृत प्रबंधन जैसी सुविधाओं के कारण प्रबंधन दक्षता में सुधार होता है।

माइक्रोसर्विस गेटवे

APISIX आपको कई भाषाओं में एक्सटेंशन प्लगइन्स लिखने की अनुमति देता है, जो पूर्व-पश्चिम माइक्रोसर्विस API गेटवे के सामने आने वाली मुख्य समस्या को हल कर सकता है - विषम वातावरण में एकीकृत तरीके से कैसे प्रबंधित करें। APISIX Nacos, etcd और Eureka जैसी सेवा खोज, और मानक DNS विधियों का भी समर्थन करता है, जो Zuul, Spring Cloud Gateway, और Dubbo जैसे माइक्रोसर्विस API गेटवे को पूरी तरह से प्रतिस्थापित कर सकता है।

Kubernetes Ingress

वर्तमान में, K8s का आधिकारिक Kubernetes Ingress Controller प्रोजेक्ट मुख्य रूप से NGINX कॉन्फ़िगरेशन फ़ाइल पर आधारित है, इसलिए यह रूटिंग क्षमता और लोडिंग मोड में थोड़ा कमजोर है और कुछ स्पष्ट सीमाएं हैं। उदाहरण के लिए, जब किसी API को जोड़ा या संशोधित किया जाता है, तो नए NGINX कॉन्फ़िगरेशन को अपडेट करने के लिए सेवा को रीस्टार्ट करना आवश्यक होता है। सेवा को रीस्टार्ट करने का ऑनलाइन ट्रैफ़िक पर बड़ा प्रभाव पड़ता है।

APISIX Ingress Controller उपरोक्त सभी सीमाओं को पूरी तरह से हल करता है: यह पूरी तरह से हॉट रीलोडिंग का समर्थन करता है। साथ ही, यह APISIX के सभी लाभों को विरासत में लेता है और मूल Kubernetes CRD का भी समर्थन करता है, जो उपयोगकर्ताओं के लिए माइग्रेशन को सुविधाजनक बनाता है।

सर्विस मेश

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

सारांश

Apache APISIX के ओपन-सोर्स होने के पहले दिन से तीन साल हो चुके हैं। अत्यधिक सक्रिय समुदाय और केस स्टडीज़ ने साबित कर दिया है कि APISIX क्लाउड-नेटिव युग में सही API गेटवे है। इस लेख को पढ़कर, मुझे विश्वास है कि आप APISIX को और अधिक व्यापक रूप से समझ गए होंगे।

यदि आपके कोई प्रश्न हैं, तो आप GitHub issue में संदेश छोड़ सकते हैं; समुदाय योगदानकर्ता जल्दी से प्रतिक्रिया देंगे; बेशक, आप APISIX Slack चैनल और मेलिंग लिस्ट में भी शामिल हो सकते हैं; कृपया Join Us देखें।