API Gateway में Plugin Orchestration को कैसे लागू करें

वीडियो देखें

पहले मैं अपना परिचय दूं। मैं मिंग वेन हूं, API7.ai के सह-संस्थापक। मैं ओपन सोर्स प्रोजेक्ट Apache APISIX के VP और PMC सदस्य हूं। मैं Apache skywalking के कमिटर भी हूं। इसके अलावा, मैं qihoo 360 ओपन सोर्स कमेटी के संस्थापक, Tencent Cloud TVP, और TARS Foundation के TOC सदस्य हूं। मेरे पास 40 से अधिक सुरक्षा पेटेंट हैं।

आज के विषय में, मैं 4 भागों का परिचय दूंगा। पहला, Apache APISIX का संक्षिप्त परिचय। Apache APISIX क्या है और यह हमें क्या करने में मदद कर सकता है? दूसरा भाग API गेटवे में कस्टम डेवलपमेंट है, और तीसरा भाग Apache APISIX में प्लगइन है। हम इसे स्वचालित रूप से कैसे जनरेट कर सकते हैं? अंतिम भाग API गेटवे के भविष्य पर कुछ विचार हैं।

सबसे पहले, मैं Apache APISIX का संक्षिप्त परिचय दूंगा। एक वाक्य में, यह एक क्लाउड-नेटिव API गेटवे है। यहां GitHub पर Apache APISIX का रेपो एड्रेस है।

Apache APISIX एक बहुत ही युवा प्रोजेक्ट है। इसे पिछले साल जून में ओपन सोर्स किया गया और अक्टूबर में Apache इन्क्यूबेटर को दान किया गया। इस साल जुलाई में, यह Apache इन्क्यूबेटर से ग्रेजुएट हुआ और एक टॉप-लेवल प्रोजेक्ट बन गया। यह एक तेजी से बढ़ने वाला समुदाय है, इसे केवल नौ महीने लगे।

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

तो आइए देखें कि Apache APISIX आपके लिए क्या कर सकता है? यह लेयर 4 और लेयर 7 ट्रैफिक को हैंडल कर सकता है, जिसमें HTTP, HTTPS, TCP, UDP, MQTT आदि शामिल हैं।

क्योंकि Apache APISIX NGINX पर आधारित है, आप स्वाभाविक रूप से Apache APISIX का उपयोग NGINX के बजाय नॉर्थ-साउथ ट्रैफिक को हैंडल करने के लिए कर सकते हैं। साथ ही, Apache APISIX माइक्रोसर्विसेज के बीच के ट्रैफिक को भी अच्छी तरह से हैंडल कर सकता है, इसलिए आप इसे envoy के बजाय उपयोग कर सकते हैं। हमारे कुछ उपयोगकर्ता Apache APISIX को Kubernetes के इन्ग्रेस कंट्रोलर के रूप में भी उपयोग करते हैं। साथ ही, Apache APISIX के mqtt प्लगइन की मदद से, हम Apache APISIX को एक IoT गेटवे के रूप में उपयोग कर सकते हैं, या IDP प्लगइन का उपयोग करके APISIX को एक जीरो-ट्रस्ट गेटवे में बदल सकते हैं। इसलिए APISIX गेटवे पर अधिक ध्यान देता है। प्लगइन्स के माध्यम से, उपयोगकर्ता APISIX को अपनी बिजनेस आवश्यकताओं के अनुसार विभिन्न गेटवे में बदल सकते हैं।

यह Apache APISIX का तकनीकी आर्किटेक्चर है। इससे हम देख सकते हैं कि APISIX के दो भाग हैं, बाईं ओर डेटा प्लेन है, और दाईं ओर कंट्रोल प्लेन है।

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

फिर कंट्रोल प्लेन को देखते हैं। कंट्रोल प्लेन में, एडमिन एडमिन API के माध्यम से कॉन्फ़िगरेशन को etcd क्लस्टर में लिखता है, और APISIX डेटा प्लेन etcd को वॉच करेगा, ताकि कॉन्फ़िगरेशन मिलीसेकंड्स में सभी डेटा प्लेन तक पहुंच सके। डेटा प्लेन के नोड्स डेटा को प्रोसेस करने के बाद, कुछ मेट्रिक्स और लॉग डेटा को skywalking, Prometheus आदि कंपोनेंट्स को रिपोर्ट करते हैं।

इस आर्किटेक्चर डायग्राम से हम देख सकते हैं कि APISIX केवल etcd पर निर्भर करता है, और इसमें mysql और postgresql जैसे RDS नहीं हैं। इसलिए, APISIX को हाई अवेलेबिलिटी के लिए बेहतर डिज़ाइन किया गया है। साथ ही, इसका आर्किटेक्चर सरल होगा, जो डिप्लॉयमेंट और ऑप्स के लिए सुविधाजनक है।

यह चित्र Apache APISIX का लैंडस्केप है। इसे बाईं ओर से देखते हुए, APISIX कई 4-लेयर और 7-लेयर प्रोटोकॉल को सपोर्ट करता है। यह न केवल ब्राउज़र और मोबाइल ऐप्स से ट्रैफिक को सपोर्ट करता है, बल्कि विभिन्न IoT डिवाइस से APISIX को ट्रैफिक रिपोर्ट करने को भी सपोर्ट करता है।

Apache APISIX कई एक्सटर्नल सर्विस डिस्कवरी सेंटर्स को भी सपोर्ट करता है, जिसमें etcd consoul शामिल है।

एक बहुत ही महत्वपूर्ण इंफ्रास्ट्रक्चर सॉफ्टवेयर के रूप में, API गेटवे को आमतौर पर ट्रैफिक के प्रवेश द्वार पर रखा जाता है। इसलिए, इसे न केवल क्लाइंट से सभी रिक्वेस्ट को प्रोसेस करने की आवश्यकता होती है, बल्कि कुछ बैकएंड सर्विसेज से भी कनेक्ट करने की आवश्यकता होती है, जैसे कि skywalking, datadog, kafka आदि।

इस चित्र के निचले भाग में, APISIX न केवल बेयर मेटल पर चलने को सपोर्ट करता है, बल्कि विभिन्न पब्लिक क्लाउड के सर्वर पर भी चलने को सपोर्ट करता है। हम ARM प्लेटफॉर्म पर चलने को भी सपोर्ट करते हैं।

ठीक है, भाग 1 APISIX का संक्षिप्त परिचय था, और फिर भाग 2 में, मैं API गेटवे में कस्टम प्लगइन्स के डेवलपमेंट का परिचय दूंगा।

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

उदाहरण के लिए, यदि आपकी कंपनी में कुछ पुराने सिस्टम हैं, या कुछ विशेष प्रोटोकॉल हैं, जैसे कि वित्त और सुरक्षा उद्योग में कुछ प्रोटोकॉल, तो आपको गेटवे स्तर पर कुछ ट्रांसकोड करने की आवश्यकता होती है।

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

आइए पहले Kong को देखें। यह एक प्रसिद्ध API गेटवे प्रोजेक्ट है। यह 5 साल पुराना है। Kong की टेक्नोलॉजी स्टैक मूल रूप से APISIX के समान है, और दोनों NGINX और Lua पर आधारित हैं। लेकिन Kong का तकनीकी आर्किटेक्चर APISIX के समान नहीं है। Kong postgres और Cassandra जैसे RDS पर आधारित है। APISIX etcd का उपयोग करता है, और APISIX का समाधान Kubernetes और क्लाउड नेटिव के करीब है।

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

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

आइए दूसरे को देखें, जो पूर्व-पश्चिम ट्रैफिक को प्रोसेस करने के लिए एक बहुत ही प्रसिद्ध ओपन सोर्स डेटा प्लेन प्रोजेक्ट है, Envoy, जो C++ में लिखा गया है। इसलिए, Envoy का प्लगइन स्वाभाविक रूप से C++ में भी लागू होता है। इसलिए इसे शुरू करना आसान नहीं है।

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

Kong और Envoy के समाधान समान हैं: वे चाहते हैं कि अधिक डेवलपर्स प्लगइन्स डेवलप करने की क्षमता रखें, चाहे वे go, Lua या WASM का उपयोग करें। इसलिए APISIX पर वापस आते हुए, हम एक सिल्वर बुलेट ढूंढना चाहते हैं।

तो यह सिल्वर बुलेट कैसा दिखता है? हम सोचते हैं कि गेटवे स्तर पर, कस्टम डेवलपमेंट की समस्या को हल करने के लिए पहले निम्नलिखित दो समस्याओं को हल करना होगा।

पहली यह है कि जिन प्लगइन्स को डेवलप करने की आवश्यकता होती है, वे वास्तव में सरल होते हैं। मौजूदा 40 से अधिक ओपन सोर्स प्लगइन्स का पुन: उपयोग कैसे करें?

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

यदि हम इन दो समस्याओं को हल कर सकते हैं, तो हमारे पास अधिक लोगों को, न केवल डेवलपर्स को, AP गेटवे को डेवलप करने की क्षमता देने का अवसर होगा।

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

हम प्रत्येक प्लगइन को केवल एक फीचर करने के लिए बना सकते हैं, जैसे कि एक माइक्रोसर्विस, जो लिनक्स में प्रक्रिया के डिज़ाइन के समान है। इसलिए, हमने माइक्रो-प्लगइन नामक एक अवधारणा प्रस्तावित की है।

हमारे प्रत्येक प्लगइन केवल एक स्वतंत्र फीचर करते हैं। फिर, हमें लिनक्स पाइप के समान एक डिज़ाइन की आवश्यकता होती है ताकि इन माइक्रो प्लगइन्स को जोड़ सकें।

उदाहरण के लिए, मैं पहले एक uri ब्लॉक प्लगइन को कॉल करता हूं। कॉल पूरा होने के बाद, मैं यह निर्धारित करूंगा कि क्या uri वास्तव में ब्लॉक है। यदि यह ब्लॉक है, तो Kafka प्लगइन को कॉल करना जारी रखें।

इस पाइप विधि का उपयोग करके, इन प्लगइन्स को जोड़ा जा सकता है। Apache APISIX में अब 40 से अधिक प्लगइन्स हैं। 40 से अधिक प्लगइन्स के क्रमचय में असीमित संभावनाएं हैं, जो उपयोगकर्ता की आवश्यकताओं को पूरा करने के लिए पर्याप्त हैं।

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

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

साथ ही, यह API गेटवे डेवलपमेंट की बार को कम करेगा, जिससे अधिक से अधिक लोग AP गेटवे में योगदान कर सकेंगे। यदि हम एक नारे का उपयोग करें, तो वह है "क्रिएटिविटी से क्रिएशन तक", हम न केवल अपने विचारों को डेवलपर्स के लिए डॉक्यूमेंट में लिख सकते हैं, बल्कि सीधे एक नया प्लगइन भी बना सकते हैं।

यह एक अच्छा विचार लगता है, तो क्या इसे लागू किया जा सकता है? वास्तव में, हम तकनीकी सोच से बाहर निकलकर देख सकते हैं कि अन्य उद्योगों में इसे कैसे हल किया जाता है।

उदाहरण के लिए, मेडिकल उद्योग के प्रोसेस इंजन में, वे GUI तरीके से बनाए जाते हैं, क्योंकि उनके उपयोगकर्ता डॉक्टर होते हैं। फिर, बच्चों के लिए लेगो भी ऐसा ही है। आप सीमित संख्या में बिल्डिंग ब्लॉक्स का उपयोग करके असीमित संभावित आकृतियों का निर्माण कर सकते हैं।

GUI और लेगो विचारों को एक साथ रखें, तो हम देख सकते हैं कि यह वास्तव में स्क्रैच है, जो बच्चों को प्रोग्रामिंग सिखाता है, इसलिए बार बहुत कम होगी।

पिछली दो समस्याओं को हल करने के आधार पर, APISIX ने एक नई अवधारणा प्रस्तावित की है: प्लगइन ऑर्केस्ट्रेशन। यहां प्लगइन ऑर्केस्ट्रेशन का एक डेमो है, हम पहले इस छोटे वीडियो को देख सकते हैं।

इस वीडियो में, हम पहले एक uri ब्लॉक प्लगइन बनाते हैं, और फिर हम एक कंडीशनल जजमेंट बनाते हैं। यदि uri ब्लॉक सही है, तो हम इसे फॉल्ट इंजेक्शन प्लगइन में जोड़ेंगे; यदि uri ब्लॉक का परिणाम गलत है, तो हम इसे kafka प्लगइन को पास करेंगे ताकि लॉग रिकॉर्ड किया जा सके।

फिर हम प्रत्येक प्लगइन और जजमेंट कंडीशन को कॉन्फ़िगर करते हैं। अंत में, आइए curl के साथ इसे वेरीफाई करें कि क्या यह नया प्लगइन वास्तव में गेटवे के नोड पर काम कर रहा है। हां, यह काम करता है।

अगला, मैं आपको समझाऊंगा कि यह प्लगइन ऑर्केस्ट्रेशन कैसे लागू किया गया है। यह भी एक तकनीकी मुद्दा हो सकता है जिसके बारे में हर कोई चिंतित है।

प्लगइन ऑर्केस्ट्रेशन को लागू करने के लिए, हमें तीन चरणों का पालन करना होगा।

चरण 1 में, हमें इस नए प्लगइन का वर्णन करने के लिए DAG का उपयोग करने की आवश्यकता है। हम देख सकते हैं कि बाईं ओर तीर वाला ग्राफ वास्तव में एक DAG (डायरेक्टेड एसाइक्लिक ग्राफ) है, जो पिछले वीडियो में वर्णित कोड के समान है। फिर यह मनुष्यों के लिए एक अनुकूल वर्णन विधि है। कंप्यूटर के लिए, हमें इसे दाईं ओर डेटा स्ट्रक्चर की एक वर्णन भाषा में बदलना होगा। उदाहरण के लिए, नंबर 1 नोड के बाद 2 4 6 का मतलब है कि नोड 1, जो दूसरे, चौथे और छठे नोड को इंगित करता है; नंबर 3 का मान nil है, जिसका अर्थ है कि नंबर 3 नोड के पीछे कोई अन्य नोड नहीं है, और अन्य समान हैं। इस तरह, हम एक DAG को डेटा स्ट्रक्चर वर्णन में बदलते हैं।

इस डेटा स्ट्रक्चर होने के बाद, हम इस डेटा स्ट्रक्चर को JSON स्ट्रिंग में बदलते हैं, और फिर इस JSON स्ट्रिंग को सर्वर को पास करते हैं। दाईं ओर की JOSN स्ट्रिंग डेमो में देखे गए प्लगइन से परिवर्तित है।

चरण 1 के बाद, हमारे पास पहले से ही json द्वारा वर्णित एक स्ट्रिंग है, लेकिन हम इस स्ट्रिंग को APISIX द्वारा चलाए जा सकने वाले कोड में कैसे परिवर्तित करते हैं?

हम जानते हैं कि APISIX में हम Lua कोड चला रहे हैं, इसलिए हमें एक कंपाइलर की आवश्यकता है, जो json को AST (अब्स्ट्रैक्ट सिंटैक्स ट्री) में पार्स करे, और अंत में Lua कोड जनरेट करे। इस समय, हमने इस चरण को करने के लिए jsonschema का उपयोग किया है। नीचे ओपन सोर्स रिपॉजिटरी है।

Lua कोड जनरेट करने के बाद, हम APISIX कंट्रोल प्लेन का उपयोग करके Lua कोड को एडमिन API के माध्यम से etcd में लिखते हैं, और फिर APISIX डेटा प्लेन नोड watch etcd के माध्यम से Lua कोड प्राप्त करता है। APISIX में Lua कोड को डायनामिक रूप से चलाने की क्षमता है, जैसे कि APISIX का सर्वरलेस प्लगइन।

इसलिए, प्लगइन ऑर्केस्ट्रेशन द्वारा जनरेट किया गया नया प्लगइन, DAG से डेटा नोड के वास्तविक रनिंग तक, पूरी प्रक्रिया पूरी तरह से डायनामिक है, जो APISIX की एक बहुत ही महत्वपूर्ण विशेषता है।

यदि आप इसे देखते हैं, तो क्या आपके मन में एक प्रश्न है, मैं इसे कहां आजमा सकता हूं? चिंता न करें, यहां एक ओपन सोर्स प्रोजेक्ट है, और हमारे पास एक ऑनलाइन डेमो भी है।

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

एक प्रवृत्ति यह है कि पारंपरिक नॉ