APISIX ने Tencent BlueKing में API Gateway अपग्रेड को प्रेरित किया

यह केस स्टडी टेनसेंट IEG (इंटरएक्टिव एंटरटेनमेंट ग्रुप) के ब्लूकिंग PaaS प्लेटफॉर्म के तकनीकी निदेशक लेई झू द्वारा साझा की गई है।

ब्लूकिंग के बारे में

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

अवलोकन

चुनौतियाँ

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

लक्ष्य

• प्लेटफॉर्म क्षमताओं को स्वतंत्र माइक्रोसर्विसेज में बदलें, और माइक्रोसर्विसेज परिवर्तन करके PaaS आर्किटेक्चर बनाएं
• लो-कोड तकनीक का उपयोग करके SaaS को कुशलता से विकसित करें ताकि PaaS प्लेटफॉर्म की माइक्रोसर्विसेज क्षमताओं का उपयोग किया जा सके
• विभिन्न SaaS के माध्यम से विभिन्न सेवा परिदृश्यों के लिए लचीले ढंग से प्रतिक्रिया दें

परिणाम

• K8s द्वारा प्रदान किए गए CRD कस्टम संसाधन का उपयोग करके गेटवे के एकीकृत संचालन और विस्तार को प्राप्त किया
• APISIX के साथ समृद्ध सुविधाएं प्रदान की: संसाधन प्रबंधन, संस्करण रिलीज़, स्वचालित दस्तावेज़, अनुमति प्रबंधन, अवलोकनीयता, निगरानी, और सुरक्षा सुरक्षा
• सेवा खोज परिदृश्यों का समर्थन करने के लिए लागत कम की गई, एकीकृत डेवलपर इंटरफेस और नियमों के साथ

गेम्स की विविधता और जटिलता के लिए ब्लूकिंग API गेटवे की आवश्यकता

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

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

ब्लूकिंग के आर्किटेक्चर को सारांशित करने के लिए, हम एक API आरेख प्राप्त कर सकते हैं।

• एक ओर, ब्लूकिंग एक जटिल प्लेटफॉर्म है जिसमें एकीकृत गेटवे के लिए जटिल आवश्यकताएं हैं। प्लेटफॉर्म्स के API को कॉल करने के लिए प्रॉक्सी के रूप में काम करने के अलावा, ब्लूकिंग को और अधिक गेटवे क्षमताओं की आवश्यकता है, उदाहरण के लिए, सेवा खोज, प्राधिकरण और प्रमाणीकरण, डायनामिक रूटिंग, कैनरी रिलीज़, और दर सीमित करना, आदि।

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

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

आंतरिक व्यावसायिक आवश्यकताओं के विकास के साथ, ब्लूकिंग के API गेटवे को तेजी से विविध परिदृश्यों का समर्थन करने की आवश्यकता है।

ब्लूकिंग API गेटवे 1.0

ब्लूकिंग API गेटवे 1.0 का उद्देश्य प्लेटफॉर्म्स (विभिन्न SaaS और प्रक्रिया इंजन सहित) के कॉलर को सीधे API गेटवे को कॉल करने की अनुमति देना था ताकि गेटवे के माध्यम से प्रोटोकॉल रूपांतरण और प्राधिकरण सत्यापन पूरा किया जा सके।

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

कई वर्षों के बाद, बढ़ते अनुरोधों और जटिल परिदृश्यों के साथ, ब्लूकिंग API गेटवे 1.0 की कमियाँ धीरे-धीरे सामने आने लगीं। उदाहरण के लिए:

• फ्रेमवर्क का खराब प्रदर्शन: कार्यान्वयन के लिए Django फ्रेमवर्क चुना गया था। उच्च समवर्ती परिदृश्यों में इसका प्रदर्शन औसत है और बड़े पैमाने पर अनुरोधों को संसाधित करते समय यह खिंच जाता है।

• रूटिंग कार्यान्वयन का औसत प्रदर्शन: API रूटिंग में उपयोग किए गए एल्गोरिदम का प्रदर्शन कम है, जो रूटों के मिलान और फॉरवर्डिंग की गति को प्रभावित करता है।

• डेटाबेस पर दबाव: सभी रूटिंग नीतियाँ MySQL में संग्रहीत हैं। जब बहुत सारे नियम होते हैं, तो बहुत सारे पुनर्प्राप्ति अनुरोधों को ले जाने की आवश्यकता होती है, जिससे भारी क्वेरी दबाव होता है।

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

ब्लूकिंग API गेटवे 2.0

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

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

कुल मिलाकर, ब्लूकिंग API गेटवे 2.0 ने प्रदर्शन समस्याओं और संस्करण 1.0 में सामने आई अधिकांश समस्याओं को हल किया। लेकिन समय के साथ, नई समस्याएं धीरे-धीरे सामने आने लगीं।

• अपर्याप्त अलगाव: वास्तविक भौतिक अलगाव प्राप्त नहीं किया जा सकता; रिलीज़ प्रक्रिया के कारण लंबे समय तक कनेक्शन टूट जाते हैं

• एकल प्रोटोकॉल समर्थन: केवल HTTP का समर्थन करता है, और वास्तविक परिदृश्यों में गैर-HTTP प्रोटोकॉल की मांग बढ़ रही है

• डायनामिक रूटिंग नियमों का समर्थन नहीं: शर्तों से मिलान किए गए डायनामिक रूटिंग नियमों का समर्थन नहीं करता; कैनरी रिलीज़ परिदृश्यों के लिए पर्याप्त अनुकूल नहीं; परिदृश्य-आधारित संयोजन और एनकैप्सुलेशन में असमर्थ

• सेवा खोज क्षमता की कमी: स्वचालित सेवा खोज क्षमता की कमी, माइक्रोसर्विसेज आर्किटेक्चर के लिए अनुकूल नहीं

ब्लूकिंग API गेटवे के तकनीकी चयन में APISIX उत्कृष्ट है

कंपनी में कई उत्पाद प्रणालियाँ हैं जिन्हें API गेटवे का उपयोग करने की आवश्यकता है। गेटवे के लिए सभी विविध आवश्यकताओं को एक ही सेट में एकीकृत करना बहुत कठिन है।

इसलिए, हमारे पास एक वितरित गेटवे डिजाइन करने का विचार है। यानी, एक बड़े गेटवे को कई माइक्रोगेटवे में विभाजित किया जाता है, जिनका उपयोग विभिन्न प्रणालियों के लिए गेटवे की आवश्यकताओं में अंतर को संतुलित करने के लिए किया जाता है।" झू ने कहा।

वितरित गेटवे आर्किटेक्चर के घटक मुख्य रूप से दो श्रेणियों में विभाजित हैं: प्रबंधन साइड और माइक्रोगेटवे उदाहरण।

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

"माइक्रोगेटवे के तकनीकी चयन में, हमने बाजार में कई लोकप्रिय ओपन-सोर्स गेटवे का संदर्भ लिया, जैसे Kong और Tyk। लोकप्रियता, तकनीकी स्टैक, प्रोटोकॉल समर्थन, और अन्य स्तरों की तुलना करने के बाद, हमने अंततः APISIX को हमारे माइक्रोगेटवे के सबसे महत्वपूर्ण बैकएंड तकनीक के रूप में चुना।" झू ने कहा।

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

इसके अलावा, इसकी उत्कृष्ट संगतता के कारण, APISIX को ब्लूकिंग की आवश्यकताओं के अनुसार अनुकूलित किया जा सकता है। उदाहरण के लिए, APISIX के आधार पर, ब्लूकिंग ने आंतरिक आवश्यकताओं के अनुसार APISIX के कंट्रोल सरफेस को अनुकूलित किया है।

APISIX पर आधारित ब्लूकिंग API गेटवे 3.0

क्लाउड-नेटिव वातावरण में, K8s सबसे महत्वपूर्ण बुनियादी घटक है जिस पर ध्यान देने की आवश्यकता है। क्योंकि पूरा माइक्रोगेटवे क्लाउड-नेटिव वातावरण के लिए डिज़ाइन किया गया है, संस्करण 3.0 में K8s पर आधारित एक नया आर्किटेक्चर डिज़ाइन है।

मुख्य भाग K8s द्वारा प्रदान किए गए CRD कस्टम संसाधन का उपयोग करके API गेटवे के संपूर्ण संचालन और विस्तार को प्राप्त करना है।

जैसा कि ऊपर के चित्र में दिखाया गया है, गेटवे में K8s CRD संसाधनों का एक सेट पेश किया गया है, जिसमें BkGatewayStage (गेटवे वातावरण), BkGatewayService (बैकएंड सेवा), आदि शामिल हैं। इन CRDs के माध्यम से, ब्लूकिंग प्रत्येक माइक्रोगेटवे उदाहरण के विशिष्ट व्यवहार को नियंत्रित कर सकता है।

चित्र में कई "ऑपरेटर्स" इस आर्किटेक्चर का मुख्य भाग हैं। ऊपर प्लगइन ऑपरेटर्स सेवा है, जिसमें कई प्लगइन ऑपरेटर्स शामिल हैं। उदाहरण के लिए, सेवा खोज के लिए जिम्मेदार ऑपरेटर सेवा खोज केंद्र में पंजीकृत बैकएंड सेवा का पता K8s क्लस्टर में लिखेगा।

मध्य में मुख्य ऑपरेटर सभी गेटवे-संबंधित CRD संसाधनों की निगरानी करता है। संसाधन रिकॉन्सिलर गेटवे कॉन्फ़िगरेशन को APISIX माइक्रोगेटवे उदाहरण द्वारा समझे जाने योग्य प्रारूप में परिवर्तित करने के लिए जिम्मेदार है, इस प्रकार माइक्रोगेटवे के पूर्ण जीवनचक्र प्रबंधन को प्राप्त करता है।

इस माइक्रोगेटवे सेट को दो तैनाती प्रकारों में विभाजित किया गया है:

• साझा गेटवे: डिफ़ॉल्ट प्रकार, जो प्लेटफॉर्म पर तैनात है, और API एक्सेस पता प्लेटफॉर्म द्वारा एकीकृत रूप से उत्पन्न और प्रबंधित किया जाता है।

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

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

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

उपरोक्त आर्किटेक्चर और मोड के आधार पर, APISIX के समर्थन से ब्लूकिंग API गेटवे 3.0 अधिक समृद्ध कार्यक्षमता प्रदान करता है। उदाहरण के लिए, संसाधन प्रबंधन, संस्करण रिलीज़, स्वचालित दस्तावेज़, SDK, अनुमति प्रबंधन, अवलोकनीयता, निगरानी और अलर्टिंग, और सुरक्षा सुरक्षा।

APISIX का उपयोग करके ब्लूकिंग गेटवे 3.0 के व्यावहारिक परिदृश्य

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

सेवा खोज

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

उपरोक्त CRD संसाधनों को K8s क्लस्टर में लिखे जाने के बाद, यह सेवा खोज-संबंधित नियंत्रकों से संबंधित कार्यों को ट्रिगर करेगा। इसके बाद, रिकॉन्सिलर संबंधित सेवा खोज कॉन्फ़िगरेशन को पकड़ सकता है और सेवा खोज से संबंधित प्रोग्राम ऑब्जेक्ट्स बना सकता है।

फिर रिकॉन्सिलर Watcher और Lister जैसे अंतर्निहित सेवा खोज इंटरफेस के माध्यम से सेवा खोज केंद्र के संबंधित पते की जानकारी पढ़ता है और प्राप्त पते को CRD संसाधन BkGatewayEndpoints के माध्यम से K8s क्लस्टर में वापस लिखता है।

दाईं ओर के मुख्य ऑपरेटर द्वारा कुछ जटिल प्रसंस्करण के बाद, ये एंडपॉइंट्स अंततः APISIX के संबंधित अपस्ट्रीम में सिंक्रनाइज़ हो जाते हैं। एक पूर्ण सेवा खोज प्रक्रिया पूरी हो जाती है।

विकास को सुविधाजनक बनाने के लिए, ब्लूकिंग ने एक सामान्य सेवा खोज फ्रेमवर्क कार्यान्वित किया है, जो एकीकृत विकास इंटरफेस और विनिर्देश प्रदान करता है और अन्य प्रकार के सेवा खोज परिदृश्यों का समर्थन करने के लिए कम लागत पर उपयोग किया जा सकता है।

एकीकृत प्रमाणीकरण

एकीकृत प्रमाणीकरण भाग अपेक्षाकृत सरल है। दैनिक अभ्यास में, तीन स्रोतों से अनुरोध होते हैं: ब्राउज़र, प्लेटफॉर्म, और व्यक्तिगत उपयोगकर्ता। APISIX के आधार पर, ब्लूकिंग ने एक प्रमाणीकरण प्लगइन, BK-Auth, को अनुकूलित किया है ताकि एकीकृत प्रमाणीकरण प्राप्त किया जा सके।

विशिष्ट कार्यान्वयन प्रक्रिया ऊपर के चित्र में दिखाई गई है। अनुरोध के बाद, प्लगइन हेडर से संबंधित क्रेडेंशियल जानकारी पढ़ेगा और फिर BK-Auth प्रमाणीकरण सेवा को कॉल करेगा ताकि क्रेडेंशियल को सत्यापित किया जा सके और संबंधित SaaS जानकारी पढ़ी जा सके। फ