APISIX के साथ फंड मैनेजमेंट जायंट का परिवर्तन

अवलोकन

इन्वेस्को ग्रेट वॉल के बारे में

इन्वेस्को ग्रेट वॉल फंड मैनेजमेंट कंपनी लिमिटेड ("IGW") एक चीनी-अमेरिकी फंड मैनेजमेंट कंपनी है, जिसमें मल्टी-एसेट निवेश क्षमताएं और प्रमुख इक्विटी विशेषज्ञता है। कंपनी के मुख्य व्यवसायों में क्वांटिटेटिव निवेश, एक्टिव इनकम और फिक्स्ड इनकम शामिल हैं। IGW का प्रबंधित एसेट 850 बिलियन USD से अधिक है, जो 60 मिलियन से अधिक निवेशकों को सेवाएं प्रदान करता है।

IGW एसेट मैनेजमेंट पर प्राथमिक ध्यान देता है, जो इक्विटी, फिक्स्ड इनकम और क्वांटिटेटिव स्ट्रैटेजी जैसे कई एसेट क्लासेस में विविध निवेश रणनीतियां प्रदान करता है।

चुनौतियाँ

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

परिणाम

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

पृष्ठभूमि

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

वर्चुअल मशीन चरण के दौरान, विभिन्न व्यावसायिक प्रणालियों द्वारा उपयोग किए जाने वाले गेटवे में एकरूपता की कमी थी। प्रत्येक व्यवसाय स्वतंत्र रूप से संचालित होता था, जिसके कारण गेटवे से जुड़ी कई सेवाएं और उच्च रखरखाव लागत हो गई।

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

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

IGW ने APISIX क्यों चुना

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

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

इसलिए, इन चार मुख्य बिंदुओं पर विचार करते हुए, IGW की तकनीकी टीम ने APISIX और Kong के बीच एक व्यापक तुलना की, जो बाजार में लोकप्रिय और व्यापक रूप से मान्यता प्राप्त दो API गेटवे हैं:

• तकनीकी फ्रेमवर्क: APISIX और Kong दोनों OpenResty पर आधारित हैं। कॉन्फिगरेशन सेंटर के संबंध में, APISIX etcd को अपनाता है, जबकि Kong PostgreSQL को चुनता है। etcd और APISIX की क्लाउड-नेटिव प्रकृति के कारण, APISIX एक क्लाउड-नेटिव डिस्ट्रिब्यूटेड गेटवे के रूप में उभरता है। हालांकि, Kong के कॉन्फिगरेशन सेंटर का चयन सिंगल-पॉइंट-ऑफ-फेल्योर के मुद्दे पैदा कर सकता है, जिसके लिए उच्च उपलब्धता के लिए अतिरिक्त इंफ्रास्ट्रक्चर समर्थन की आवश्यकता होती है।

• कम्युनिटी गतिविधि: APISIX और Kong दोनों की सक्रिय कम्युनिटी है, जिसमें उनके रिपॉजिटरी में प्रतिदिन औसतन 20 बार कमिट होते हैं।

• प्लगइन्स: APISIX में 80+ प्लगइन हैं और प्रत्येक प्लगइन के लिए केवल एक दस्तावेज़ है; Kong में 30+ प्लगइन हैं और प्रत्येक प्लगइन के लिए 4-5 दस्तावेज़ हैं; प्रत्येक APISIX प्लगइन के लिए 100+ कोड और Kong के लिए 300+ कोड है।

• स्केलेबिलिटी: APISIX कई प्रोग्रामिंग भाषाओं का समर्थन करता है और WebAssembly का भी समर्थन करता है। Kong केवल Lua का उपयोग करके प्लगइन लिखने का समर्थन करता है।

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

• ऑब्जर्वेबिलिटी: APISIX और Kong दोनों OpenTelemetry का समर्थन करते हैं, लेकिन APISIX Elasticsearch, Prometheus, और SkyWalking से भी जुड़ सकता है। जब IGW तकनीकी चयन कर रहा था, तब Kong SkyWalking का समर्थन नहीं करता था।

उपरोक्त चिंताओं और तुलना बिंदुओं के आधार पर, IGW की तकनीकी टीम ने अंततः APISIX को API गेटवे के रूप में चुना।

IGW के लिए उपयोगकर्ता परिदृश्य और समाधान

IGW की सिस्टम आर्किटेक्चर का परिचय

IGW की व्यावसायिक प्रणाली को मोटे तौर पर तीन भागों में विभाजित किया गया था: लेन-देन क्षेत्र, उत्पादन क्षेत्र और प्रबंधन क्षेत्र, जिनमें से प्रत्येक अलग-अलग API गेटवे का उपयोग करता था। मूल रूप से, IGW ने NGINX को वेब सर्वर और रिवर्स प्रॉक्सी के रूप में उपयोग किया। एक ही नेटवर्क वर्गीकरण में व्यवसाय सभी एक ही NGINX का उपयोग करते थे। परिणामस्वरूप, प्रत्येक सेवा परिवर्तन या रूटिंग अपडेट के लिए NGINX पर मैन्युअल अपडेट और रीलोड करने की आवश्यकता होती थी।

उपरोक्त आरेख IGW की सिस्टम आर्किटेक्चर को दर्शाता है। गेटवे सुरक्षा क्लस्टर परत Zuul, Spring Cloud Gateway, Kong, और NGINX जैसे कई फ्रेमवर्क का उपयोग करती है। आर्किटेक्चर प्रबंधन एकीकृत नहीं था और प्रबंधन अपेक्षाकृत जटिल था।

समाधान

इन चुनौतियों को हल करने के लिए, IGW ने गेटवे क्लस्टर को APISIX में बदलने पर जोर दिया। चूंकि APISIX Kubernetes क्लस्टर पर तैनात है, यह YAML के माध्यम से डिक्लेरेटिव तरीके से APIs के एकीकृत प्रबंधन की अनुमति देता है। इसके अलावा, APISIX Ingress Controller Kubernetes संसाधनों में परिवर्तनों को स्वचालित रूप से देखता है, जिससे ApisixRoute, SSL और अन्य APISIX कॉन्फिगरेशन की वास्तविक समय में सिंक्रनाइज़ेशन सक्षम होता है।

नीचे APISIX का उपयोग करने के बाद IGW की रूट सिंक्रनाइज़ेशन अनुक्रम आरेख है।

उपयोगकर्ता परिदृश्य

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

कुशल इंटेलिजेंट रूटिंग

इंटेलिजेंट रूटिंग मुख्य रूप से लेयर 4 और लेयर 7 में लोड बैलेंसिंग में प्रदर्शित होती है। जैसा कि आरेख में दिखाया गया है, APISIX Ingress Controller के माध्यम से सिंक्रनाइज़ की गई रूटेड जानकारी विशिष्ट लेबल के साथ होती है, जो गलती से हटाने के ऑपरेशन को प्रभावी ढंग से रोकती है।

पर्यावरण में परीक्षण के बाद, यहां तक कि यदि डेटा हटा दिया जाता है, तो Kubernetes APISIX के साथ तेजी से और स्वचालित रूप से सिंक्रनाइज़ करने में सक्षम है, जिससे डेटा हानि का मुद्दा हल हो जाता है।

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

बढ़ाया प्रमाणीकरण

एकीकृत गेटवे को पेश करने से पहले, प्रत्येक व्यावसायिक इकाई को अपने डेटा इंटरफेस की सुरक्षा सुनिश्चित करने के लिए प्रमाणीकरण से संबंधित घटकों को अलग से विकसित करना पड़ता था। व्यावसायिक पक्ष पर, प्रत्येक सिस्टम को अतिरिक्त प्रमाणीकरण कार्यक्षमता विकसित करने का बोझ उठाना पड़ता था, जिससे विकास लागत अधिक होती थी और लागू सुविधाओं की गुणवत्ता भिन्न होती थी। परिणामस्वरूप, सुरक्षा सत्यापन के लिए, IGW ने एकीकृत प्रमाणीकरण और HTTPS रीडायरेक्ट प्लगइन पेश किए।

एकीकृत गेटवे को पेश करने से पहले, सेवाओं के HTTPS प्रमाणपत्र हाई एवेलिएबिलिटी (HA) एंडपॉइंट पर डिक्रिप्ट किए जाते थे, जिससे जटिलता, संचालन ओवरहेड और सुरक्षा जोखिम बढ़ गए।

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

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

मॉनिटरिंग से परे

पहले, IGW की मूल व्यावसायिक प्रणाली में ऑब्जर्वेबिलिटी के लिए कमजोर समर्थन ने सिस्टम समस्या निवारण, प्रदर्शन अनुकूलन, विश्वसनीयता और प्रोएक्टिव मॉनिटरिंग को प्रतिकूल रूप से प्रभावित किया।

इसलिए, IGW की तकनीकी टीम का उद्देश्य APISIX द्वारा प्रदान किए गए कई प्लगइन, जैसे लॉग मॉनिटरिंग और ट्रेसिंग, को तेजी से एकीकृत करना था, ताकि ऑब्जर्वेबिलिटी क्षमताओं को बढ़ाया जा सके।

इसके अलावा, टीम Apache SkyWalking का उपयोग करके वितरित ट्रेसिंग, Prometheus का उपयोग करके मॉनिटरिंग उद्देश्यों के लिए, और ELK का उपयोग करके कुशल लॉग संग्रह के लिए सक्रिय रूप से शोध कर रही थी। आश्चर्यजनक रूप से, APISIX इन सभी प्लगइन का समर्थन करता है और इस प्रकार IGW की तकनीकी टीम की अपेक्षाओं और आवश्यकताओं को पूरी तरह से पूरा करने वाला एक आदर्श समाधान साबित हुआ है, जिससे यह पसंदीदा विकल्प बन गया है।

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

ट्रैफिक नियंत्रण में महारत

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

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

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

APISIX का उपयोग करने के बाद की उपलब्धियां

एकीकृत API गेटवे का निर्माण

APISIX को लागू करके, IGW की तकनीकी टीम ने API गेटवे फ्रेमवर्क का मानकीकरण प्राप्त किया है, जो लोड बैलेंसिंग, डायनामिक अपस्ट्रीम, कैनरी रिलीज़, सर्किट ब्रेकिंग, प्रमाणीकरण, और ऑब्जर्वेबिलिटी जैसे समृद्ध ट्रैफिक प्रबंधन कार्य प्रदान करता है।

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

रूटिंग और सेवाओं की तैनाती की स्थिरता में सुधार

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

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

हॉट-रीलोडिंग प्रदर्शन और अपटाइम को बढ़ाता है

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

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

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

सारांश

IGW की तकनीकी टीम ने भविष्य में सहज संचालन के लिए APISIX की कार्यक्षमता, विश्वसनीयता और प्रदर्शन को और बढ़ाने की अपेक्षाएं भी रखी हैं।

इन्वेस्को ग्रेट वॉल में APISIX के सफल कार्यान्वयन ने महत्वपूर्ण लाभ और सकारात्मक परिणाम प्रदान किए हैं। APISIX के साथ, IGW टीम ने एकीकृत API गेटवे फ्रेमवर्क प्राप्त किया है, जिससे संचालन सुव