भाग 1: OpenResty का उपयोग करके एक Microservices API गेटवे कैसे बनाएं

इस लेख में, आइए OpenResty के अध्यायों पर चलते हैं। मैं तीन अध्यायों का उपयोग करके आपको यह बताऊंगा कि माइक्रोसर्विस API गेटवे को कैसे लागू किया जाए। इस प्रक्रिया में, हम न केवल पहले सीखे गए OpenResty ज्ञान को शामिल करेंगे, बल्कि मैं आपको यह भी दिखाऊंगा कि कैसे एक नए उत्पाद और ओपन-सोर्स प्रोजेक्ट को शुरू से बनाया जाए, जिसमें उद्योग, उत्पाद और प्रौद्योगिकी चयन जैसे कई आयाम शामिल हों।

माइक्रोसर्विस API गेटवे क्या करता है?

आइए पहले माइक्रोसर्विस API गेटवे की भूमिका को देखें। नीचे दी गई तस्वीर इसका संक्षिप्त विवरण है:

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

• रिवर्स प्रॉक्सी और लोड बैलेंसिंग, जो NGINX की स्थिति और कार्यों के साथ मेल खाते हैं;
• डायनामिक कार्य जैसे डायनामिक अपस्ट्रीम, डायनामिक SSL प्रमाणपत्र, और रनटाइम में डायनामिक करंट और रेट लिमिटिंग, जो NGINX के ओपन-सोर्स संस्करण में नहीं हैं;
• अपस्ट्रीम की सक्रिय और निष्क्रिय स्वास्थ्य जांच, साथ ही सेवा सर्किट ब्रेकर;
• API गेटवे पर आधारित विस्तार करके पूर्ण-जीवनचक्र API प्रबंधन प्लेटफॉर्म बनाना।

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

1. क्लाउड-नेटिव अनुकूल, आर्किटेक्चर हल्का होना चाहिए और कंटेनराइज करने में आसान होना चाहिए।
2. Prometheus, Zipkin, SkyWalking जैसे सांख्यिकी और मॉनिटरिंग घटकों के साथ जुड़ना।
3. gRPC प्रॉक्सी का समर्थन, और HTTP और gRPC के बीच प्रोटोकॉल रूपांतरण, उपयोगकर्ता के HTTP अनुरोध को आंतरिक सेवा gRPC अनुरोध में बदलना।
4. OpenID Relying Party की भूमिका निभाना, Auth0 और Okta जैसे पहचान प्रमाणीकरण प्रदाताओं की सेवाओं के साथ जुड़ना, और ट्रैफिक सुरक्षा को सर्वोच्च प्राथमिकता देना।
5. रनटाइम में उपयोगकर्ता फ़ंक्शन को डायनामिक रूप से निष्पादित करके Serverless को साकार करना, जिससे गेटवे के एज नोड्स अधिक लचीले हो जाते हैं।
6. उपयोगकर्ताओं को लॉक न करना और हाइब्रिड क्लाउड डिप्लॉयमेंट आर्किटेक्चर का समर्थन करना।
7. गेटवे नोड स्टेटलेस होना चाहिए और इसे मनमाने ढंग से विस्तारित और संकुचित किया जा सकता है।

जब एक माइक्रोसर्विस API गेटवे में उपरोक्त कार्य होते हैं, तो उपयोगकर्ता की सेवा केवल व्यापार पर ध्यान केंद्रित कर सकती है। व्यापार कार्यान्वयन से संबंधित नहीं होने वाले कार्य स्वतंत्र गेटवे स्तर पर हल किए जा सकते हैं। उदाहरण के लिए, सेवा खोज, सर्किट ब्रेकर, प्रमाणीकरण, रेट लिमिटिंग, सांख्यिकी, प्रदर्शन विश्लेषण, आदि।

इस दृष्टिकोण से, API गेटवे NGINX के सभी कार्यों को प्रतिस्थापित कर सकता है और उत्तर-दक्षिण ट्रैफिक को संभाल सकता है; यह Istio कंट्रोल प्लेन और Envoy डेटा प्लेन की भूमिका को भी पूरा कर सकता है और पूर्व-पश्चिम ट्रैफिक को संभाल सकता है।

पहिया को फिर से क्यों बनाना है?

क्योंकि माइक्रोसर्विस API गेटवे की स्थिति इतनी महत्वपूर्ण है, यह हमेशा से एक युद्धक्षेत्र रहा है, और पारंपरिक IT दिग्गज इस क्षेत्र में लंबे समय से हैं। Gartner द्वारा 2018 में जारी API Lifecycle Report के अनुसार, Google, CA, IBM, Red Hat, और Salesforce सभी अग्रणी निर्माता हैं, और डेवलपर्स के लिए अधिक परिचित Apache APISIX विजनरीज़ में शामिल है।

तो, सवाल यह है कि हमें एक नया पहिया क्यों बनाना है?

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

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

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

यही कारण है कि ओपन-सोर्स API गेटवे समाधान लोकप्रिय हो गए हैं। हालांकि, मौजूदा ओपन-सोर्स उत्पाद सर्वशक्तिमान नहीं हैं, और उनमें भी कई कमियां हैं:

1. PostgreSQL और MySQL जैसे रिलेशनल डेटाबेस पर निर्भरता। इस तरह, जब कॉन्फ़िगरेशन बदलता है, तो गेटवे नोड केवल डेटाबेस को पोल कर सकता है। यह न केवल कॉन्फ़िगरेशन को धीमा कर देता है, बल्कि कोड को जटिल बनाता है, जिससे इसे समझना मुश्किल हो जाता है। साथ ही, डेटाबेस सिस्टम का एकल बिंदु और प्रदर्शन बाधा बन जाता है, जो समग्र उच्च उपलब्धता की गारंटी नहीं दे सकता है। यदि आप Kubernetes वातावरण में API गेटवे का उपयोग करते हैं, तो रिलेशनल डेटाबेस और अधिक बोझिल हो जाता है, जो तेजी से स्केलिंग के लिए प्रतिकूल है।
2. प्लगइन्स को हॉट-लोड नहीं किया जा सकता है। जब आप एक नया प्लगइन जोड़ते हैं या मौजूदा प्लगइन के कोड को संशोधित करते हैं, तो आपको सेवा को पुनः लोड करना होगा ताकि यह प्रभावी हो सके। यह NGINX कॉन्फ़िगरेशन को संशोधित करने के बाद पुनः लोड करने की आवश्यकता के समान है, जो उपयोगकर्ता अनुरोधों को प्रभावित करेगा।
3. कोड संरचना जटिल और समझने में मुश्किल है। कुछ ओपन-सोर्स प्रोजेक्ट्स ने बहु-स्तरीय ऑब्जेक्ट-ओरिएंटेड एनकैप्सुलेशन किया है, और कुछ सरल तर्क धुंधला हो गया है। लेकिन, API गेटवे के परिदृश्य के लिए, सीधा अभिव्यक्ति स्पष्ट और अधिक कुशल होगी, और यह द्वितीयक विकास के लिए भी अधिक अनुकूल है।

इसलिए, हमें एक हल्का, क्लाउड-नेटिव और विकास-अनुकूल API गेटवे की आवश्यकता है। बेशक, हम बंद दरवाजों के पीछे कार नहीं बना सकते हैं। हमें मौजूदा API गेटवे की विशेषताओं को गहराई से समझने की आवश्यकता है। इस समय, Cloud Native Software Foundation (CNCF) का पैनोरमा एक अच्छा संदर्भ है:

API गेटवे कोर घटक और अवधारणाएं

बेशक, इसे लागू करने से पहले, हमें API गेटवे के कोर घटकों को समझने की आवश्यकता है। हमारे द्वारा पहले उल्लेखित API गेटवे के कार्यों के अनुसार, इसे चलाने के लिए कम से कम निम्नलिखित घटकों की आवश्यकता होती है।

पहला है Route। यह कुछ नियमों को परिभाषित करके क्लाइंट के अनुरोध को मिलाता है, फिर मिलान परिणाम के अनुसार संबंधित प्लगइन को लोड और निष्पादित करता है, और अनुरोध को निर्दिष्ट अपस्ट्रीम पर फॉरवर्ड करता है। ये रूटिंग मिलान नियम host, uri, header, आदि से बना हो सकता है। NGINX में परिचित location रूटिंग का एक कार्यान्वयन है।

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

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

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

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

रूट

पहले Route के बारे में बात करते हैं। एक रूट में तीन भाग शामिल होंगे: मिलान शर्तें, बाउंड प्लगइन और अपस्ट्रीम, जैसा कि निम्नलिखित चित्र में दिखाया गया है:

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

सेवा

अगला Service को देखते हैं। यह एक प्रकार के API का अमूर्त है, और इसे Route के समूह का अमूर्त भी समझा जा सकता है। यह आमतौर पर अपस्ट्रीम सेवाओं के साथ 1:1 संबंध रखता है, और Route और Service के बीच संबंध आमतौर पर N:1 होता है। मैंने इसे एक चित्र के साथ भी दर्शाया है:

Service की इस परत के अमूर्त के माध्यम से, हम डुप्लिकेट Plugin और Upstream को अलग कर सकते हैं। इस तरह, जब Plugin और Upstream बदलते हैं, तो हमें केवल Service को संशोधित करने की आवश्यकता होती है, न कि कई Route पर बाउंड डेटा को संशोधित करने की।

अपस्ट्रीम

अंत में, Upstream के बारे में बात करते हैं। उपरोक्त उदाहरण को जारी रखते हुए, यदि दो Route में अपस्ट्रीम समान हैं, लेकिन बाउंड प्लगइन अलग हैं, तो हम अपस्ट्रीम को अलग से अमूर्त कर सकते हैं, जैसा कि निम्नलिखित चित्र में दिखाया गया है:

इस तरह, जब अपस्ट्रीम नोड बदलता है, तो Route को पूरी तरह से पता नहीं चलता है, और वे सभी Upstream के अंदर संसाधित होते हैं।

इन तीन मुख्य अवधारणाओं के व्युत्पत्ति प्रक्रिया से, हम यह भी देख सकते हैं कि ये अमूर्त व्यावहारिक उपयोग परिदृश्यों पर आधारित हैं न कि कल्पना पर। ये सभी API गेटवे पर लागू होते हैं, चाहे विशिष्ट तकनीकी समाधान कुछ भी हों।

सारांश

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

यहां आपके लिए सोचने के लिए एक प्रश्न है: "पारंपरिक उत्तर-दक्षिण ट्रैफिक और माइक्रोसर्विस के बीच पूर्व-पश्चिम ट्रैफिक के संबंध में, क्या आपको लगता है कि API गेटवे दोनों को संभाल सकता है?" यदि आप पहले से ही एक API गेटवे का उपयोग कर रहे हैं, तो आप तकनीकी चयन पर अपने विचार भी लिख सकते हैं। आपका स्वागत है संवाद और चर्चा करने के लिए, और आप इस लेख को अपने सहयोगियों और दोस्तों के साथ साझा करके सीखने और प्रगति करने के लिए आमंत्रित हैं।

अगला: भाग 2: OpenResty का उपयोग करके माइक्रोसर्विस API गेटवे कैसे बनाएं भाग 3: OpenResty का उपयोग करके माइक्रोसर्विस API गेटवे कैसे बनाएं