Apache APISIX सबसे अच्छा API Gateway क्यों है?

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

CNCF के API गेटवे लैंडस्केप में, लगभग 20 प्रकार के API गेटवे (क्लाउड वेंडर की सेवाओं को छोड़कर) शामिल हैं, जिनमें Apache APISIX, Kong, Tyk आदि शामिल हैं। इनमें से कई खुद को सबसे लोकप्रिय ओपन-सोर्स API गेटवे प्रोजेक्ट, अगली पीढ़ी के API गेटवे के रूप में दावा करते हैं, लेकिन क्या वे हैं?

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

API Gateway landscape.png

सॉफ्टवेयर इंजीनियर इसे अच्छी तरह जानते हैं

सॉफ्टवेयर इंजीनियर API और API गेटवे के उपयोगकर्ता और डेवलपर हैं, इसलिए इंजीनियर्स के बीच लोकप्रियता ट्रेंड का सीधा संकेतक है। नीचे चार API गेटवे: Apache APISIX, Kong, Tyk, और Gloo के GitHub योगदानकर्ताओं की कुल संख्या की तुलना करने वाला एक ग्राफ है।

GitHub Contributors.png

हम ग्राफ से देख सकते हैं कि Kong और Tyk दोनों 2015 के आसपास शुरू हुए, जबकि Apache APISIX और Gloo बाद में 2019 में शुरू हुए। और भी महत्वपूर्ण बात यह है कि हम यह भी देख सकते हैं कि सबसे युवा Apache APISIX की वक्र सबसे तेज है और इसने 320 से अधिक योगदानकर्ताओं को जमा किया है, जो दूसरे स्थान पर Kong से 57 लोगों से आगे है, और सबसे अधिक योगदानकर्ताओं वाला API गेटवे प्रोजेक्ट बन गया है।

Monthly Active Contributors.png

योगदानकर्ताओं की कुल संख्या के अलावा, मासिक सक्रिय योगदानकर्ताओं की संख्या अधिक महत्वपूर्ण है। Tyk के मासिक सक्रिय योगदानकर्ता केवल 5 के आसपास हैं और शायद ही कभी 10 से ऊपर जाते हैं, जबकि Kong और Gloo 10 और 20 के बीच उतार-चढ़ाव करते रहे हैं। इस बीच, Apache APISIX के मासिक सक्रिय योगदानकर्ता स्थिर रूप से 20 से ऊपर हैं, और चरम पर लगभग 40 हैं, जो इसे सबसे सक्रिय API गेटवे प्रोजेक्ट बनाता है।

चार ओपन-सोर्स API गेटवे प्रोजेक्ट्स के पीछे, चार संबंधित वाणिज्यिक कंपनियां हैं। इसलिए, APISIX को अलग बनाने वाला एक और संकेतक मासिक सक्रिय योगदानकर्ताओं की संख्या बनाम कर्मचारियों की संख्या का अनुपात है।

API गेटवे	APISIX	Kong	Tyk	Gloo
मासिक सक्रिय	38	20	8	24
कर्मचारी (Linkedln से)	40+	500+	200+	100+

2022 तक, Kong और Tyk का अनुपात 4% है, और Gloo का अनुपात 24% है। इसके विपरीत, APISIX लगभग 100% तक पहुंच गया है। इसके पीछे का कारण यह है कि जब से कंपनी API7.ai ने APISIX प्रोजेक्ट शुरू किया है, तब से यह ओपन-सोर्स समुदाय में लगातार प्रयास कर रही है और डेवलपर्स के बीच अपनी प्रतिष्ठा बना चुकी है।

ओपन सोर्स लाइसेंस: ओपन सोर्स API गेटवे चुनने का सबसे महत्वपूर्ण कारक

जब से MongoDB ने 2018 में अपना ओपन सोर्स लाइसेंस SSPL (सर्वर साइड पब्लिक लाइसेंस) में बदला है, तब से उद्यमों को MongoDB को मैनेज्ड सेवा के रूप में उपयोग करने पर अपना कोड ओपन सोर्स करना पड़ता है। परिणामस्वरूप, उद्यमों को प्रोजेक्ट चुनते समय प्रोजेक्ट के ओपन सोर्स लाइसेंस को गंभीरता से विचार करना होगा।

सतह पर, Apache APISIX, Kong, और Gloo सभी वाणिज्यिक-अनुकूल Apache लाइसेंस संस्करण 2.0 का उपयोग करते हैं, और Tyk Mozilla पब्लिक लाइसेंस संस्करण 2.0 का उपयोग करता है। हालांकि, गहराई से देखें तो Kong, Gloo, और Tky सभी वाणिज्यिक ओपन सोर्स वेंडर्स द्वारा समर्थित हैं। वे किसी भी समय MongoDB की तरह अपना लाइसेंस बदल सकते हैं, जिससे पब्लिक क्लाउड या अन्य कंपनियों को इसे स्वतंत्र रूप से उपयोग करने से रोका जा सकता है, और आपको नए संस्करणों तक पहुंचने के लिए भुगतान करने के लिए मजबूर किया जा सकता है।

लाइसेंस परिवर्तन की संभावना कोई नहीं जानता। यह जोखिम, हालांकि, डैमोकल्स की तलवार की तरह है, जो उपयोगकर्ताओं के ऊपर लटकी हुई है।

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

Apache APISIX, Kong और Gloo का प्रदर्शन

समुदाय में अक्सर पूछा जाने वाला प्रश्न: किसका प्रदर्शन बेहतर है, Envoy-आधारित Gloo या NGINX-आधारित APISIX? हालांकि प्रदर्शन सबसे महत्वपूर्ण मीट्रिक नहीं है, लेकिन यह निर्विवाद रूप से सबसे सीधा मीट्रिक है। नीचे दी गई तालिका Apache APISIX और Gloo के बेंचमार्क स्कोर दिखाती है। Apache APISIX का QPS Gloo से 4.6 गुना अधिक है, और Apache APISIX की लेटेंसी Gloo की लेटेंसी का केवल 7% है।

API गेटवे	Apache APISIX	Gloo Edge
QPS	59122	12903
लेटेंसी	50.000% 470.00us 75.000% 648.00us 90.000% 0.89ms 99.000% 1.60ms	50.000% 6.80ms 75.000% 9.25ms 90.000% 11.32ms 99.000% 17.06ms

NGINX या Envoy का चयन प्रदर्शन अंतर का मुख्य कारक नहीं है, बल्कि APISIX ने अपने सोर्स कोड में किए गए अंतर्निहित अनुकूलन हैं। यहां तक कि KONG से तुलना करने पर, जो NGINX-आधारित है, APISIX का प्रदर्शन बहुत बेहतर है। नीचे दिया गया ग्राफ GigaOm की रिपोर्ट से लिया गया है, जिसमें Kong के एंटरप्राइज संस्करण और AP7 एंटरप्राइज संस्करण (पूर्ण डेटा के लिए आप हमसे संपर्क कर सकते हैं) का परीक्षण किया गया है।

Kong की लेटेंसी API7 (Apache APISIX के लेखकों द्वारा बनाया गया एंटरप्राइज संस्करण) की लेटेंसी से दसियों या यहां तक कि सौ गुना अधिक है।

APISIX का प्रदर्शन इतना बेहतर क्यों है? कोड के सामने कोई रहस्य नहीं है।

बातें सस्ती हैं, मुझे कोड दिखाओ

अब, हम Apache APISIX, Kong, और Gloo का तकनीकी दृष्टिकोण से विश्लेषण करेंगे। Apache APISIX का लाभ ज्यादातर सोर्स कोड के अनुकूलन और नवाचार पर निर्भर करता है। इन तकनीकों के लाभ सरल PoC (प्रूफ ऑफ कॉन्सेप्ट) में जरूरी नहीं दिखाई देते, बल्कि अधिक जटिल प्रोडक्शन वातावरण में दिखाई देते हैं।

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

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

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

यह क्लाउड-नेटिव आर्किटेक्चर के साथ अधिक संरेखित है
यह API गेटवे के लिए आवश्यक डेटा प्रकार का बेहतर प्रतिनिधित्व करता है
इसकी उपलब्धता अधिक होगी
परिवर्तनों को सब-मिलीसेकंड स्तर पर सूचित किया जा सकता है

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

उच्च-प्रदर्शन रूट मिलान एल्गोरिदम

एक अनुरोध को संसाधित करने के लिए, API गेटवे को प्रत्येक अनुरोध की होस्ट जानकारी, URI, HTTP विधियों और अन्य जानकारी के साथ लक्ष्य अभिव्यक्ति का मिलान करना होता है। इस प्रकार, एक कुशल मिलान एल्गोरिदम महत्वपूर्ण है। हैश-आधारित एल्गोरिदम का प्रदर्शन अच्छा है, लेकिन फ़ज़ी मिलान प्राप्त नहीं कर सकता। रेगुलर एक्सप्रेशन फ़ज़ी मिलान कर सकते हैं, लेकिन प्रदर्शन इतना अच्छा नहीं है। Apache APISIX का समाधान एक पेड़ का उपयोग करना है, एक कुशल खोज डेटा संरचना जो फ़ज़ी मिलान का समर्थन करती है। अधिक सटीक रूप से, Apache APISIX एक रेडिक्स ट्री (संपीड़ित प्रीफ़िक्स ट्री) का उपयोग करता है, एक डेटा संरचना जो केवल एक बच्चे वाले मध्यवर्ती नोड्स को संपीड़ित करती है। सभी ज्ञात API गेटवे उत्पादों में, Apache APISIX पहला है जिसने रूट मिलान में रेडिक्स ट्री को लागू किया है और एक प्रीफ़िक्स से कई रूट्स के मिलान के परिदृश्य का समर्थन करता है। कार्यान्वयन विवरण के लिए, lua-resty-radixtree देखें।

एक अनुरोध का मिलान करते समय, रेडिक्स ट्री के साथ एल्गोरिदम इसे प्रगतिशील रूप से मिलाएगा, जिसकी जटिलता O(K) है (K रूट में URI की लंबाई है, और यह API की संख्या से स्वतंत्र है)। यह एल्गोरिदम उन परिदृश्यों में बहुत अच्छी तरह से काम करता है जहां बड़ी संख्या में रूट्स हैं, जैसे पब्लिक क्लाउड या CDN पर। यह तेजी से बढ़ने वाले बड़ी संख्या में रूट्स से निपटने में भी कोई समस्या नहीं है।

उच्च-प्रदर्शन IP मिलान एल्गोरिदम

एक IP पते के दो नोटेशन हैं: मानक IP नोटेशन और CIDR नोटेशन, 32-बिट IPv4 को उदाहरण के रूप में लेते हुए:

मानक IP नोटेशन: 192.168.1.1
CIDR नोटेशन: 192.168.1.1/8

Apache APISIX का IP मिलान और रूट मिलान अलग-अलग एल्गोरिदम का उपयोग करते हैं। 192.168.1.1 के IP को उदाहरण के रूप में लेते हुए, चूंकि प्रत्येक IP सेगमेंट की सीमा 0 से 255 तक है, हम सोच सकते हैं कि IP पता चार 16-बिट पूर्णांक संख्याओं से बना है, और IP की लंबाई निश्चित है। इस प्रकार, हम मिलान को पूरा करने के लिए एक अधिक कुशल एल्गोरिदम का उपयोग कर सकते हैं।

मान लें कि एक IP लाइब्रेरी है जिसमें 500 IPv4 रिकॉर्ड हैं, APISIX 500 IPv4 रिकॉर्ड को हैश टेबल में कैश करेगा, और IP मिलान के लिए हैश टेबल का उपयोग करेगा। समय जटिलता O(1) है। अन्य API गेटवे लिस्ट इटरेशन के माध्यम से IP मिलान को पूरा करते हैं और गेटवे पर भेजे गए प्रत्येक अनुरोध को 500 बार तक इटरेट किया जा सकता है। इसलिए, APISIX का उच्च-सटीक IP मिलान एल्गोरिदम बड़े पैमाने पर IP व्हाइटलिस्ट और डेनिलिस्ट मिलान (जैसे WAF) के परिदृश्यों की दक्षता को बहुत बढ़ाता है।

रूट्स का परिष्करण

API गेटवे पूर्व-परिभाषित नियमों को अनुरोधों की विभिन्न जानकारी के साथ मिलाते हैं, जैसे होस्ट जानकारी, URI, URI क्वेरी पैरामीटर्स, URI पथ पैरामीटर्स, HTTP विधियां, अनुरोध हेडर आदि। ये जानकारी अधिकांश API गेटवे द्वारा समर्थित हैं। हालांकि, Apache APISIX इनके अलावा और भी डेटा का समर्थन करता है ताकि अधिक जटिल मामलों को हल किया जा सके।

पहले, Apache APISIX NGINX बिल्ट-इन वेरिएबल्स का समर्थन करता है, जिसका अर्थ है कि हम दर्जनों NGINX बिल्ट-इन वेरिएबल्स को मिलान पैरामीटर्स के रूप में उपयोग कर सकते हैं, जिनमें uri, server_name, server_addr, request_uri, remote_port, remote_addr, query_string, host, hostname, arg_name शामिल हैं।

NGINX बिल्ट-इन वेरिएबल्स की सूची के लिए, NGINX वेरिएबल्स देखें।

दूसरा, Apache APISIX सशर्त अभिव्यक्तियों को मिलान नियमों के रूप में समर्थन करता है, और इसकी संरचना [var, operator, val], ...]] है, जहां:

var मान NGINX बिल्ट-इन वेरिएबल्स हो सकते हैं।
operator बराबर, अधिक, कम, रेगुलर एक्सप्रेशन, शामिल आदि का समर्थन करता है।

मान लें कि अभिव्यक्ति ["arg_name", "==", "json"] है, इसका मतलब है कि क्या वर्तमान अनुरोध के URI क्वेरी पैरामीटर्स में name पैरामीटर का मान json के बराबर है। Apache APISIX इस सुविधा को अपने लाइब्रेरी lua-resty-expr के माध्यम से लागू करता है। विवरण के लिए, कृपया lua-resty-expr देखें। यह सुविधा उपयोगकर्ता को बहुत लचीलापन देती है और अत्यधिक विस्तार योग्य है।

इसके अलावा, Apache APISIX उपयोगकर्ताओं को रूट्स की ttl (टाइम टू लिव) सेट करने की अनुमति देता है।

$ curl http://127.0.0.1:9080/apisix/admin/routes/2?ttl=60 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
    "uri": "/aa/index.html",
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "39.97.63.215:80": 1
        }
    }
}'

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

अंत में, Apache APISIX कस्टमाइज्ड फ़िल्टर फ़ंक्शन का समर्थन करता है, कोई filter_func पैरामीटर में कस्टम Lua फ़ंक्शन लिख सकता है, उदाहरण के लिए:

$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
    "uri": "/index.html",
    "hosts": ["foo.com", "*.bar.com"],
    "filter_func": "function(vars)
                    return vars['host'] == 'api7.ai'
                end",
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "127.0.0.1:1980": 1
        }
    }
}'

filter_func का इनपुट पैरामीटर vars है, और vars से NGINX वेरिएबल्स प्राप्त किए जा सकते हैं, और फिर फ़िल्टरिंग लॉजिक को कस्टमाइज़ किया जा सकता है।

मल्टी-लैंग्वेज प्लगइन्स का समर्थन

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

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

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

इस स्थिति के जवाब में, APISIX दो समाधान प्रदान करता है।

पहला समाधान प्लगइन रनर के माध्यम से अधिक मुख्यधारा की प्रोग्रामिंग भाषाओं (जैसे Java, Python, Go आदि) का समर्थन करना है। प्लगइन रनर का उपयोग करके, बैकएंड इंजीनियर्स स्थानीय RPC के माध्यम से संचार कर सकते हैं और उन प्रोग्रामिंग भाषाओं का उपयोग करके APISIX प्लगइन्स विकसित कर सकते हैं जिनसे वे परिचित हैं। इसका लाभ यह है कि यह विकास लागत को कम करता है और विकास दक्षता को बढ़ाता है। नुकसान यह होगा कि प्रदर्शन में कमी आएगी। तो, क्या ऐसा कोई तरीका है कि डेवलपर्स के लिए परिचित उच्च-स्तरीय भाषाओं का उपयोग करके Lua के निकट-मूल प्रदर्शन प्राप्त किया जा सके?

मल्टी-लैंग्वेज आर्किटेक्चर.png

दूसरा समाधान Wasm का उपयोग करके प्लगइन्स विकसित करना है, जैसा कि ऊपर दिए गए चित्र के बाएं भाग में दिखाया गया है। Wasm (वेबएसेंबली) पहले ब्राउज़र में चलने वाली एक नई प्रकार की तकनीक के रूप में उपयोग किया जाता था, लेकिन अब यह सर्वर साइड पर भी अपने लाभ दिखा रहा है। हमने Wasm को APISIX में एम्बेड किया है, और उपयोगकर्ता Wasm का उपयोग करके Wasm बाइटकोड को APISIX में चलाने के लिए संकलित कर सकते हैं। Wasm का उपयोग करने के लिए हमने एक Was