API गेटवे क्या है, और यह क्यों आवश्यक है?

एपीआई का परिचय

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

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

एपीआई के उदय ने "टावर ऑफ बेबल" की समस्या को सफलतापूर्वक हल कर दिया है। डेवलपर्स को केवल अन्य सिस्टम द्वारा एक्सपोज़ किए गए एपीआई पर ध्यान केंद्रित करने की आवश्यकता है और अंतर्निहित कार्यान्वयन विवरण को समझने की आवश्यकता नहीं है।

मोबाइल ऐप्स, ऑनलाइन गेम्स, लाइव वीडियो स्ट्रीमिंग, रिमोट कॉन्फ्रेंस, और IoT डिवाइस के लिए क्लाइंट डिवाइस और सर्वर के बीच कनेक्शन और डेटा ट्रांसमिशन एपीआई के बिना असंभव है। एपीआई उनके संचार में एक महत्वपूर्ण भूमिका निभाते हैं।

एपीआई गेटवे क्यों उपयोग करें?

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

जब शुरुआत में बहुत सारे एपीआई नहीं होते हैं, तो एपीआई गेटवे आमतौर पर वेब सर्वर और अपस्ट्रीम सेवाओं द्वारा जुड़ा एक आभासी घटक होता है। सरल कार्यक्षमताएं जैसे रूटिंग, फॉरवर्डिंग, रिवर्स प्रॉक्सी, और लोड बैलेंसिंग Apache, NGINX, और कुछ अन्य घटकों द्वारा की जाती हैं; अन्य कार्यक्षमताएं जैसे प्रमाणीकरण और दर सीमित करना अपस्ट्रीम सेवाओं पर निर्भर करती हैं।

आपको एपीआई गेटवे की आवश्यकता क्यों है?

हालांकि, जैसे-जैसे एपीआई की संख्या बढ़ती है, "आलसी" डेवलपर्स को एक गंभीर समस्या का सामना करना पड़ता है। अपस्ट्रीम सेवाओं के विभिन्न हिस्सों में, समान प्रमाणीकरण, दर सीमित करना, लॉगिंग, और कुछ अन्य कार्यों को बार-बार कोड किया जाता है। यह न केवल संसाधनों की बर्बादी है; यह कोड प्रबंधन का एक बुरा सपना भी है। जब कोड का एक हिस्सा संशोधित या अपग्रेड किया जा रहा होता है, तो अन्य स्थानों पर कोड को भी अपडेट करने की आवश्यकता होती है। हम इस समस्या को कैसे हल करें? बुद्धिमान डेवलपर्स ने जल्दी ही एक समाधान ढूंढ लिया: सामान्य कार्यों को अमूर्त (निकाल) करें और उन्हें एक ही घटक में रखें। हम अपस्ट्रीम सेवाओं से व्यावसायिक तर्क से असंबंधित कोड को निकालते हैं, और Apache और NGINX जैसे घटकों को बढ़ाते हैं। यह पहली पीढ़ी के एपीआई गेटवे का विकास है।

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

एपीआई गेटवे की भूमिका

एपीआई गेटवे को अधिक लचीला और कुशल बनाने के लिए, एपीआई गेटवे डेवलपर्स ने अंतर्निहित संरचना पर बहुत सारे नवाचार किए हैं, जैसे:

• कार्यक्षमता प्लगइन्स। जैसे-जैसे एपीआई गेटवे पर अधिक से अधिक कार्यक्षमताएं एम्बेड की जाती हैं, हम प्रत्येक कार्यक्षमता को अलग करने के लिए कैसे सुनिश्चित करें? एक लेगो-जैसा प्लगइन तंत्र एक आदर्श समाधान होगा। मुख्यधारा के एपीआई गेटवे सभी प्लगइन्स का उपयोग करते हैं। Apache APISIX में, इसे "प्लगइन्स" कहा जाता है। Envoy में, इसे "फिल्टर्स" कहा जाता है। प्लगइन्स गेटवे डेवलपर्स को कार्यान्वयन विवरण से मुक्त करते हैं, और नई कार्यक्षमताओं को लागू करने के लिए कम विकास संसाधनों की आवश्यकता होती है।
• डेटा प्लेन और कंट्रोल प्लेन का अलगाव। पहली पीढ़ी के एपीआई गेटवे में, डेटा प्लेन और कंट्रोल प्लेन एक ही कंप्यूटर प्रक्रिया में लागू किए जाते थे। यह उपयोगकर्ताओं के लिए डिप्लॉय और उपयोग करने में आसान होता है, लेकिन यह महत्वपूर्ण सुरक्षा जोखिम पैदा करता है। डेटा प्लेन सीधे बाहरी दुनिया को सेवाएं प्रदान करता है। यदि हैकर्स बाहर से डेटा प्लेन में घुसपैठ करते हैं, तो वे कंट्रोल अनुमतियां और कंट्रोल प्लेन के डेटा (जैसे SSL प्रमाणपत्र) प्राप्त कर सकते हैं, जिससे अधिक विनाशकारी नुकसान हो सकता है। इसलिए, अधिकांश ओपन-सोर्स एपीआई गेटवे अब DP और CP को अलग-अलग डिप्लॉय करते हैं और कॉन्फ़िगरेशन के प्रबंधन और सिंक्रनाइज़ेशन के लिए रिलेशनल डेटाबेस या etcd का उपयोग करते हैं।

Apache APISIX को उदाहरण के रूप में लेते हुए, निम्नलिखित आर्किटेक्चर डायग्राम उपरोक्त नवाचारों को दर्शाता है:

क्लाउड-नेटिव से चुनौतियां

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

मोनोलिथिक से माइक्रोसर्विसेज

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

हालांकि, माइक्रोसर्विसेज के विकास के साथ कुछ दुष्प्रभाव भी आते हैं, जैसे:

• एपीआई और माइक्रोसर्विसेज की संख्या दर्जनों से हजारों या यहां तक कि दसियों हजारों तक बढ़ गई है।
• हम कैसे जल्दी से पता लगा सकते हैं कि किस एपीआई ने त्रुटि पैदा की है?
• हम एपीआई की सुरक्षा कैसे सुनिश्चित कर सकते हैं?
• हम सेवा सर्किट ब्रेक और सेवा डाउनग्रेड कैसे प्राप्त कर सकते हैं?

एपीआई गेटवे सुरक्षा, ऑब्जर्वेबिलिटी, और कैनरी रिलीज़ की समस्याओं को स्वयं हल नहीं कर सकता है। इसे Prometheus, Zipkin, Skywalking, Datadog, Okta, आदि जैसे कई अन्य ओपन-सोर्स प्रोजेक्ट्स और SaaS सेवाओं के साथ सहयोग करने की आवश्यकता है, ताकि उद्यमों के लिए बेहतर समाधान प्रदान किया जा सके।

डायनामिक और क्लस्टर प्रबंधन

पहली चुनौती इकोसिस्टम से आती है, जबकि दूसरी तकनीक से आती है।

डायनामिक

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

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

कंटेनर्स की इलास्टिक स्केलिंग से जुड़ी तकनीकी चुनौतियां भी हैं:

• अपस्ट्रीम सेवाओं के आईपी पते और पोर्ट्स का लगातार बदलना।
• आईपी व्हाइटलिस्ट और डेनीलिस्ट का लगातार अपडेट होना।
• सेवा स्वास्थ्य की असामान्यता का पता लगाना और संभालना।
• एपीआई का नियमित रिलीज़ होना।
• सेवा पंजीकरण और खोज की समयबद्धता।
• SSL प्रमाणपत्रों का गर्म नवीनीकरण और स्वचालित रोटेशन।

इन तकनीकी चुनौतियों का समाधान करने का केंद्र डायनामिक्स है।

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

क्लस्टर प्रबंधन

दूसरा तकनीकी दर्द बिंदु क्लस्टर प्रबंधन है।

WPS, चीन की एक SaaS ऑफिस सॉफ्टवेयर कंपनी, जो Microsoft office 365 जैसे सॉफ्टवेयर प्रदान करती है। उनके पास Apache APISIX चलाने वाले सैकड़ों भौतिक मशीनें हैं, लगभग 10,000 कोर CPUs क्लाइंट्स से एपीआई अनुरोधों को प्रोसेस करते हैं, और प्रतिदिन दसियों अरब एपीआई को प्रोसेस करते हैं।

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

अगली पीढ़ी का एपीआई गेटवे

उपरोक्त चुनौतियों और दर्द बिंदुओं ने धीरे-धीरे एक नई पीढ़ी के एपीआई गेटवे को जन्म दिया है।

अगली पीढ़ी के एपीआई गेटवे की विशेषताएं

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

• डेवलपर्स और उपयोगकर्ताओं की आवश्यकताओं और दर्द बिंदुओं को बहुत तेजी से एकत्र करने में सक्षम
• इन समस्याओं को ओपन-सोर्स प्रोजेक्ट्स में हल करने का प्रयास करना
• ओपन-सोर्स प्रोजेक्ट्स का उपयोग करना आसान हो जाता है, जिससे अधिक डेवलपर्स आकर्षित होते हैं

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

एपीआई गेटवे कम लागत पर द्वितीयक विकास का समर्थन करता है

साथ ही, डेवलपर्स को कम लागत पर कस्टम विकास करने की अनुमति देना भी अगली पीढ़ी के एपीआई गेटवे की एक मुख्य विशेषता बन गई है। एकीकरण एपीआई गेटवे के लिए एक आवश्यक कार्य है। डाउनस्ट्रीम के लिए, यह प्रोटोकॉल पार्सिंग और प्रोटोकॉल रूपांतरण है, जिसमें GraphQL, gRPC, Dubbo, आदि शामिल हैं; अपस्ट्रीम के लिए, यह Okta, Keycloak, Datadog, और Prometheus को प्रमाणीकरण और ऑब्जर्वेबिलिटी सेवाओं और कंपनी के आंतरिक प्रमाणीकरण, लॉगिंग, ऑडिटिंग, और अन्य सेवाओं के साथ एकीकृत करता है।

एपीआई गेटवे एकीकरण प्रक्रिया के सभी घटकों को कवर नहीं कर सकता है। इसलिए, डेवलपर्स के लिए अपने स्वयं के व्यावसायिक आवश्यकताओं को पूरा करने के लिए प्लगइन्स के माध्यम से कस्टम विकास करना अनिवार्य है।

विभिन्न एपीआई गेटवे कस्टम विकास के लिए विभिन्न प्रोग्रामिंग भाषाओं और विकास विधियों को प्रदान करते हैं। उदाहरण के लिए, Apache APISIX और Kong दोनों Lua का उपयोग करके नेटिव प्लगइन्स लिख सकते हैं, जबकि Envoy C++ का उपयोग करके नेटिव प्लगइन्स लिखता है। साथ ही, Apache APISIX Go, Python, Node.js, Java, और Wasm का उपयोग करके प्लगइन्स विकसित कर सकता है। लगभग सभी डेवलपर्स इन मुख्यधारा की प्रोग्रामिंग भाषाओं में से एक का उपयोग करते हैं।

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

उदाहरण: ब्लैक फ्राइडे ट्रैफ़िक के लिए एपीआई गेटवे

अगले, हम एक ठोस उदाहरण के साथ समझाएंगे कि एपीआई गेटवे क्या करता है।

ब्लैक फ्राइडे पर, ई-कॉमर्स कंपनियों के पास बहुत सारे प्रमोशन होते हैं, और इस अवधि के दौरान एपीआई अनुरोधों की मात्रा सामान्य से दसियों गुना अधिक होती है। पहले, आइए देखें कि यदि एपीआई गेटवे नहीं होता तो तकनीकी आर्किटेक्चर कैसा होगा:

जैसा कि आप ऊपर की छवि से देख सकते हैं, ऑर्डर और पेमेंट सेवाओं में प्रमाणीकरण और लॉगिंग कार्य दोहराए जाते हैं। एक ई-कॉमर्स सेवा आमतौर पर हजारों विभिन्न सेवाओं से बनी होती है। इस समय, बहुत सारे कोड और प्रक्रियाएं दोहराई जाएंगी।

निम्नलिखित चित्र एपीआई गेटवे जोड़ने के बाद का आर्किटेक्चर डायग्राम है:

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

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

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