Snowball Finance ने APISIX के साथ अपनी Active-Active आर्किटेक्चर को बदल दिया

स्नोबॉल फाइनेंस के इंफ्रास्ट्रक्चर टीम के सीनियर डेवलपमेंट इंजीनियर वेनजी शी ने Apache APISIX Summit ASIA 2022 में APISIX के साथ स्नोबॉल फाइनेंस के अभ्यास को साझा किया। यह लेख उस साझाकरण पर आधारित है, जो बताता है कि कैसे स्नोबॉल फाइनेंस Apache APISIX का उपयोग करके अपने आंतरिक एक्टिव-एक्टिव आर्किटेक्चर के विकास को प्राप्त करता है, जिससे अधिक लचीली सेवा प्रबंधन संभव होता है।

चुनौतियाँ

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

लक्ष्य

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

परिणाम

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

पृष्ठभूमि

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

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

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

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

एक्टिव-एक्टिव परिवर्तन की समस्याएं

जब यह स्टैंडअलोन आर्किटेक्चर लागू कर रहा था, तो उपयोगकर्ता ट्रैफिक सर्वर लोड बैलेंसिंग (SLB) के माध्यम से प्रवेश करता था, गेटवे के माध्यम से सरल सामान्य लॉजिक प्रोसेसिंग से गुजरता था और फिर बैकएंड सेवा को फॉरवर्ड किया जाता था। बैकएंड सेवा, एक एकीकृत प्रमाणीकरण मॉड्यूल के माध्यम से, SDK का उपयोग करके स्नोबॉल यूजर सेंटर के साथ उपयोगकर्ता प्रमाणीकरण शुरू करती थी और सफल प्रमाणीकरण पर आगे की प्रोसेसिंग जारी रखती थी।

व्यावहारिक व्यावसायिक परिदृश्यों में, कुछ समस्याएं धीरे-धीरे सामने आई हैं।

1. जटिल SDK प्रमाणीकरण मॉड्यूल

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

साथ ही, स्नोबॉल फाइनेंस का प्रमाणीकरण लॉजिक जटिल था। OAuth2.0/JWT प्रोटोकॉल के अलावा, कई कारकों को ध्यान में रखना पड़ता था, जैसे क्लाइंट संस्करण और स्नोबॉल फाइनेंस के तहत कई APPs। इसके अलावा, प्रमाणीकरण मॉड्यूल सेवा में एम्बेडेड था, इसलिए अपग्रेड करना अधिक कठिन हो गया।

2. OpenResty की सीमित कार्यक्षमता

स्नोबॉल फाइनेंस ने पहले OpenResty को अपने गेटवे के रूप में उपयोग किया था, लेकिन OpenResty कुछ कार्यों में कमजोर था। इसलिए, डेवलपर्स को OpenResty को अपने मौजूदा मॉनिटरिंग सिस्टम के साथ एकीकृत करने के लिए अधिक कस्टमाइजेशन करने की आवश्यकता होती थी। इसके अलावा, DevOps इंजीनियरों को द्वितीयक विकास प्रक्रिया को लागू करने के लिए कस्टम स्क्रिप्ट्स जोड़नी पड़ती थीं।

3. स्व-विकसित रजिस्ट्री सेंटर पर निर्भरता

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

API गेटवे प्रौद्योगिकी चयन

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

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

स्नोबॉल फाइनेंस चाहता है कि नया API गेटवे निम्नलिखित आवश्यकताओं को पूरा करे:

• उच्च प्रदर्शन
• मजबूत स्केलेबिलिटी
• कई प्रोटोकॉल का समर्थन
• गेटवे प्रमाणीकरण के लिए कम लागत

नीचे OpenResty, Spring Gateway, Kong और APISIX के बीच एक विस्तृत API गेटवे प्रौद्योगिकी चयन सूची दी गई है।

गेटवे	लाभ	नुकसान	O&M लागत	उपलब्धता
OpenResty	अत्यधिक कस्टमाइजेबल और स्थिर	खराब ऑब्जर्वेबिलिटी	उच्च	उच्च
Spring Gateway	Java विकास के लिए अनुकूल	प्रदर्शन स्तर आवश्यकताओं को पूरा नहीं करता है	मध्यम	मध्यम
Kong	शक्तिशाली और कार्यों में समृद्ध	PostgreSQL सिंगल-पॉइंट डेटाबेस	कम	मध्यम
APISIX	क्लाउड-नेटिव, कई प्रोग्रामिंग भाषाओं का समर्थन करता है और मजबूत स्केलेबिलिटी है	/	कम	उच्च

आंतरिक मांगों और बाजार में लोकप्रिय गेटवे उत्पादों की तुलना करने के बाद, स्नोबॉल फाइनेंस ने अंततः Apache APISIX को अपने आर्किटेक्चर के लिए चुना।

Apache APISIX पर आधारित अभ्यास

समायोजित आर्किटेक्चर

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

स्नोबॉल फाइनेंस ने मुख्य रूप से APISIX पर आधारित निम्नलिखित समायोजन किए हैं:

• प्रमाणीकरण मॉड्यूल को प्रॉक्सी स्तर पर एकीकृत किया गया और APISIX का उपयोग करके एकीकृत प्रमाणीकरण किया गया। JWT प्रकारों के लिए, APISIX के jwt-auth प्लगइन का उपयोग करके सीधे स्थानीय प्रमाणीकरण किया जा सकता है।
• OAuth 2.0 के साथ संगतता बनाए रखी गई और APISIX का उपयोग करके स्नोबॉल फाइनेंस यूजर सेंटर को कॉल करके प्रोसेसिंग की गई।
• स्नोबॉल फाइनेंस के बैकएंड RPC सेवा रजिस्ट्री सेंटर के साथ जुड़ा गया ताकि JWT प्रमाणीकरण विफल होने पर इसके बैकएंड सेवाओं का उपयोग करके प्रमाणीकरण किया जा सके।

अनुप्रयोग परिदृश्य

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

परिदृश्य 1: गेटवे प्रमाणीकरण

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

1. APISIX को गेटवे के रूप में एकीकृत करने के बाद, स्नोबॉल फाइनेंस ने APISIX गेटवे स्तर का उपयोग करके प्रमाणीकरण को एक समान रूप से प्रबंधित किया। मूल JWT प्रमाणीकरण विधि को आधिकारिक प्लगइन jwt-auth से बदल दिया गया। jwt-auth प्लगइन को कॉन्फ़िगर और उपयोग करना अपेक्षाकृत सरल है: केवल डैशबोर्ड में रूट और अपस्ट्रीम जैसी संबंधित जानकारी को कॉन्फ़िगर करके, प्लगइन सक्षम हो जाएगा।
2. स्नोबॉल फाइनेंस ने पिछले OAuth 2.0 से संबंधित प्रमाणीकरण विधि को संभालने के लिए grpc-transcode प्लगइन का उपयोग किया।

स्नोबॉल फाइनेंस ने आंतरिक रूप से प्रमाणीकरण को लागू करने के लिए gRPC को कॉल करने के लिए निम्नलिखित तीन समाधानों पर विचार किया:

• समाधान 1: Lua का उपयोग करके सीधे gRPC को कॉल करना। चूंकि इस समाधान में लोड बैलेंसिंग और डायनामिक अपस्ट्रीम जैसे संबंधित कार्यान्वयन पर विचार करना पड़ता है, इसलिए यह प्रक्रिया अधिक परेशानी भरी होगी, इसलिए इसे छोड़ दिया गया।
• समाधान 2: Lua कोरोटीन का उपयोग करके Golang लॉजिक को कॉल करना। स्नोबॉल फाइनेंस ने इस तरीके को छोड़ दिया क्योंकि इसके पास संबंधित व्यावहारिक अनुभव की कमी थी।
• समाधान 3: Lua का उपयोग करके HTTP कॉल करना, और gRPC इंटरफेस को APISIX के grpc-transcode प्लगइन का उपयोग करके लागू करना। APISIX समुदाय के तेज प्लगइन अनुकूलन पुनरावृत्तियों के कारण, स्नोबॉल फाइनेंस ने अंततः gRPC कॉल को लागू करने के लिए इस विकल्प को चुना।

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

परिदृश्य 2: ऑब्जर्वेबिलिटी के तहत बहु-आयामी मॉनिटरिंग

स्नोबॉल फाइनेंस में वेबसाइटों के लॉन्च के बाद कई मेट्रिक्स की मॉनिटरिंग करना आवश्यक है, जो मुख्य रूप से निम्नलिखित तीन भागों पर केंद्रित है:

• NGINX कनेक्शन स्थिति और इनबाउंड/आउटबाउंड ट्रैफिक
• HTTP त्रुटि स्थिति कोड दर (सेवा या अपस्ट्रीम/डाउनस्ट्रीम समस्याओं के समस्या निवारण के लिए उपयोग किया जाता है)
• APISIX अनुरोध विलंबता (APISIX द्वारा अनुरोध को फॉरवर्ड करने पर लॉजिक निष्पादन में लगने वाला समय)

उदाहरण के लिए, कुछ मामलों में, APISIX की विलंबता उच्च प्रतीत होती है (जैसा कि नीचे दिए गए चित्र में दिखाया गया है), जो विलंबता की गणना लॉजिक से संबंधित है। वर्तमान में, लॉजिक एकल HTTP अनुरोध पर NGINX द्वारा लगने वाले समय को इस अनुरोध के अपस्ट्रीम तक रूटिंग में लगने वाले समय से घटाकर APISIX विलंबता मेट्रिक्स प्राप्त करता है।

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

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

परिदृश्य 3: ZooKeeper रजिस्ट्री का स्केलिंग

स्नोबॉल फाइनेंस में, gRPC कॉल ZooKeeper रजिस्ट्री पर आधारित होते हैं। प्रमाणीकरण को लागू करने की प्रक्रिया में, जब स्थानीय JWT सत्यापन विफल होता है, तो API गेटवे को स्नोबॉल फाइनेंस यूजर सेंटर में gRPC सेवा को एक्सेस करने की आवश्यकता होती है, जिसके लिए API गेटवे को रजिस्ट्री सेंटर से बैकएंड gRPC सेवा पता सूची प्राप्त करने की आवश्यकता होती है।

APISIX आधिकारिक प्लगइन apisix-seed ZooKeeper के साथ सेवा खोज को एकीकृत कर सकता है। स्नोबॉल फाइनेंस ने अपने स्वयं के व्यवसाय के लिए अधिक विशिष्ट कुछ कस्टमाइजेशन किए हैं।

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

उपरोक्त चित्र से यह भी देखा जा सकता है कि ZK-Rest क्लस्टर ZooKeeper डेटा को Rest के रूप में एक्सेस करता है। केवल इसका एक उदाहरण जोड़कर ही उच्च उपलब्धता सुविधाएं प्राप्त की जा सकती हैं, जिससे कुछ जटिल ऑपरेशन्स को समाप्त किया जा सकता है। लेकिन इस ऑपरेशन से एक और स्पष्ट नुकसान भी होता है। जब ZK-Rest क्लस्टर को नियमित रूप से पोल किया जाता है, तो यह सेवा सूची को अपडेट करने में विलंब का कारण बन सकता है।

सारांश और दृष्टिकोण

वर्तमान में, Apache APISIX स्नोबॉल फाइनेंस के भीतर गेटवे स्तर के रूप में अच्छी तरह से काम कर रहा है। विशेष रूप से:

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

बाद के उपयोग में, स्नोबॉल फाइनेंस निम्नलिखित करने की योजना बना रहा है:

• K8s क्लस्टर में APISIX Ingress Controller को लागू करना।
• HTTP/gRPC प्रोटोकॉल रूपांतरण के लिए grpc-transcode प्लगइन का उपयोग करके एकीकृत बैकएंड इंटरफेस प्राप्त करना।
• ट्रैफिक-स्प्लिट प्लगइन का उपयोग करके ट्रैफिक लेबलिंग करना, Nacos रजिस्ट्री सेंटर से जुड़ना, और कैनरी रिलीज़ और अन्य सेवा प्रशासन को लागू करना।

बाद की योजनाओं में, Apache APISIX का उपयोग करके मौजूदा OpenResty को प्रतिस्थापित किया जाएगा और अंततः पूर्ण-जीवनचक्र उत्तर-दक्षिण ट्रैफिक का प्रबंधन प्राप्त किया जाएगा।