स्प्रिंग क्लाउड गेटवे को छोड़ दें! फिनटेक ऐप हुआनबेई, Apache APISIX का उपयोग कैसे करता है

जावा के प्रति प्यार और नफरत

वित्तीय प्रणालियाँ जावा को क्यों पसंद करती हैं

जावा अपनी भाषा के लाभ और विशाल पारिस्थितिकी तंत्र के कारण हमेशा लोकप्रिय रहा है और कई डेवलपर्स द्वारा पसंद किया जाता है।

पिछले 15 से 20 वर्षों में, कई वित्तीय प्रणालियों ने जावा को अपने प्राथमिक टेक स्टैक के रूप में चुना है। कुछ जांच के बाद, हमने जावा के निम्नलिखित लाभों का निष्कर्ष निकाला है:

उपरोक्त कारणों के कारण, जावा वित्तीय सॉफ्टवेयर प्रणाली का पसंदीदा बन गया है।

क्लाउड-नेटिव युग में जावा की वर्तमान स्थिति

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

सबसे पहले, जावा का प्रदर्शन कमजोर है; आप यह समझेंगे कि मैं यह क्यों कह रहा हूँ जब आप जावा की तुलना C-संबंधित टेक स्टैक से करेंगे।

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

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

अंतिम लेकिन कम नहीं, पॉइंटर समस्या पर भी चर्चा करने योग्य है। पॉइंटर उन डेवलपर्स के लिए एक अच्छा संसाधन है जो C/C++ से परिचित हैं। हालांकि, जावा एक वर्चुअल मशीन पर चलता है, जिसका अर्थ है कि मेमोरी प्रबंधन डेवलपर्स के बजाय GC (गार्बेज कलेक्शन) द्वारा संभाला जाता है। उस स्थिति में, जावा का प्रदर्शन कुछ परिस्थितियों में पर्याप्त नहीं हो सकता है जब उच्च समवर्तीता, ट्रैफिक और प्रदर्शन की सख्त मांग होती है।

हुआनबेई ने APISIX को क्यों चुना

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

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

स्प्रिंग क्लाउड गेटवे और APISIX के बीच आर्किटेक्चर अंतर

APISIX को अपनाने से पहले हुआनबेई ने तीन अलग-अलग API गेटवे सिस्टम का उपयोग किया था। हुआनबेई ने स्प्रिंग क्लाउड गेटवे को अपने ऑपरेशन और एग्जिट सिस्टम के गेटवे के रूप में और OpenResty को अपने व्यावसायिक सिस्टम के गेटवे के रूप में उपयोग किया।

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

व्यवसाय के विकास के साथ, गेटवे को मूल आर्किटेक्चर में कुछ स्थिरता समस्याएं होने लगीं, जैसे मेमोरी ओवरफ्लो, उच्च CPU उपयोग, आदि। इसलिए, हुआनबेई ने गेटवे प्रदर्शन को सुधारने और कई गेटवे को एकीकृत रूप से प्रबंधित करने के लिए Apache APISIX को आर्किटेक्चर में एकमात्र गेटवे के रूप में उपयोग किया।

नए गेटवे फ्रेमवर्क में, गेटवे सीधे सेवा खोज के माध्यम से अनुरोध ट्रैफिक को व्यावसायिक सिस्टम में स्थानांतरित करेगा। हालांकि, यदि बैकएंड एप्लिकेशन सेवा खोज का समर्थन नहीं करता है या Consul में एक स्वस्थ Pod नहीं है, तो सिस्टम ट्रैफिक को पिछले इंट्रानेट K8s Ingress पर पुनर्निर्देशित करेगा।

APISIX का व्यावहारिक अनुप्रयोग

हुआनबेई को वास्तविक व्यावसायिक परिदृश्यों में APISIX कॉन्फ़िगरेशन को संशोधित करना पड़ता है क्योंकि यह अपने कई आंतरिक गेटवे फ्रेमवर्क के कारण Apache APISIX को सीधे उपयोग नहीं कर सकता है।

APISIX बिल्ड और तैनाती

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

कस्टम कोड के लपेटने में lua_package_path का उपयोग कोड निर्देशिका को निर्दिष्ट करने के लिए नहीं किया गया; इसके बजाय, यह सीधे डिफ़ॉल्ट इमेज apisix को स्रोत कोड निर्देशिका के तहत कवर करता है यदि उसी नाम की फ़ाइल मौजूद हो। Dockerfile नीचे दिखाया गया है:

FROM registry.xxx.net:5001/apisix-shuhe:v1.5
ENV APP_NAME={{APP_NAME}}
COPY {{PRODUCT_FILE}} /tmp/deploy2/artifact.tar.gz

RUN mkdir /tmp/deploy/ && tar -xf /tmp/deploy2/artifact.tar.gz -C /tmp/deploy/ && \
cp -R /tmp/deploy/apisix/ /usr/local/apisix/ && \
cp /tmp/deploy/bin/apisix /usr/bin/apisix && \
cp /tmp/deploy/conf/apisix-$APP_NAME.yaml /usr/local/apisix/conf/apisix.yaml && \
cp /tmp/deploy/conf/config-$APP_NAME.yaml /usr/local/apisix/conf/config.yaml && \
set -x && \
bin='#! /usr/local/openresty/luajit/bin/luajit\npackage.path = "/usr/local/apisix/?.lua;" .. package.path' && \
sed -i "1s@.*@$bin@" /usr/bin/apisix && \
rm -rf /tmp/*

APISIX लॉग स्थानीय रूप से संग्रहीत किया जाता है (Syslog या अन्य प्लगइन्स द्वारा एकत्र किया जा सकता है); हम NGINX के कॉन्फ़िग टेम्पलेट को संशोधित कर सकते हैं और उपयोग किए जाने वाले प्रोफ़ाइल की जांच कर सकते हैं ताकि यह तय किया जा सके कि हम लॉग को स्थानीय रूप से संग्रहीत करना चाहते हैं या Syslog के माध्यम से FLUENTD में संग्रहीत करना चाहते हैं। हमें इमेज बनाते समय FLUENTD_HOST वेरिएबल को भी बदलना होगा जैसा कि नीचे दिखाया गया है:

{% **if** gw_profile and **string**.find( gw_profile,'local') then %}
access_log logs/access.**log** main;error_log logs/
**error**.**log** warn;
{%else%}
access_log syslog:server=${FLUENTD_HOST}:5141 json_format;
error_log syslog:server=${FLUENTD_HOST}:5142 warn;
{%end%}

NGINX कॉन्फ़िग टेम्पलेट में, हुआनबेई ने न केवल लॉग संग्रहण को संशोधित किया है, बल्कि ENV पर्यावरण चर और lua_shared_dicts कॉन्फ़िग को लूप में जोड़ा है और कुछ NGINX अनुकूलन पैरामीटर को ठीक किया है।

हुआनबेई विभिन्न व्यावसायिक आवश्यकताओं के आधार पर ट्रैफिक को अलग करता है और समान कार्यक्षमता वाले कई गेटवे बनाता है। इसलिए, हुआनबेई आंतरिक रूप से "एकल स्रोत कोड लेकिन कई गेटवे एप्लिकेशन" योजना का उपयोग करता है। पहले, हुआनबेई प्रोफ़ाइल फ़ंक्शन का उपयोग करके प्रत्येक गेटवे के config-xxx.yaml फ़ाइल को कॉन्फ़िगर करता है, और फिर यह DevOps प्लेटफॉर्म के माध्यम से इमेज बनाते समय अपने एप्लिकेशन के नाम के आधार पर विभिन्न गेटवे की Docker इमेज बना सकता है।

एंटरप्राइज़-स्तरीय कस्टम प्लगइन्स

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

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

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

गेटवे कैनरी रिलीज़

पहले हुआनबेई ने OpenShift को अपने K8s कंटेनर के रूप में उपयोग किया था (वर्तमान में यह ACK क्लस्टर में अपग्रेड हो गया है), और Ingress Haproxy के साथ बनाया गया है।

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

वास्तविक कार्यान्वयन प्रवाह नीचे दिखाया गया है, यह पुराने गेटवे के Namespace के तहत एक नया गेटवे तैनात करने के लिए समूह c और d को जोड़ेगा, और यह नए और पुराने गेटवे के ट्रैफिक अनुपात को नियंत्रित कर सकता है।

जावा से संबंधित गेटवे कारक

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

अब, हम आसानी से एक प्रॉक्सी (API गेटवे) का उपयोग करके बहु-संस्करण और बहु-भाषा समस्याओं को हल कर सकते हैं। तो जावा टेक स्टैक का उपयोग करने वाली कंपनियों के लिए APISIX को अपने API गेटवे के रूप में चुनने के क्या लाभ हैं? हम हुआनबेई के व्यावहारिक अनुभव के आधार पर दो पहलुओं से निष्कर्ष निकालते हैं।

कंपनी के लिए

1. महान कार्यक्षमता और प्रदर्शन

APISIX का QPS 80k तक पहुंच सकता है यदि हुआनबेई 4-कोर वर्चुअल मशीन का उपयोग करता है और किसी भी प्लगइन के बिना APISIX को स्ट्रेस टेस्ट करता है। इसके अलावा, APISIX ने स्प्रिंग क्लाउड गेटवे के प्रदर्शन समस्या को पूरी तरह से हल कर दिया है जब उपभोक्ता ट्रैफिक प्राप्त होता है, और उत्पादन वातावरण में इसका प्रदर्शन पिछले गेटवे की तुलना में 30% बेहतर हो गया है।

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

2. व्यावसायिक लागत कम करें

APISIX का उपयोग करने से पहले, कंपनियों को प्रदर्शन समस्याओं को हल करने के लिए सर्वर की संख्या बढ़ानी पड़ती थी, जिससे हार्डवेयर लागत में काफी वृद्धि होती थी।

हुआनबेई ने लागत की गणना की है, और यह पाया है कि APISIX का उपयोग करने के बाद सर्वर की लागत लगभग 60% कम हो गई है। इसके अलावा, टेक स्टैक को एकीकृत करने के बाद, व्यवसाय APISIX मूल आर्किटेक्चर के आधार पर विभिन्न सुविधाओं को तेजी से विस्तारित कर सकता है, विकास व्यय को कम कर सकता है, और उत्पाद रिलीज़ समय को तेज कर सकता है।

डेवलपर्स के लिए

1. व्यावसायिक आवश्यकताओं को पूरा करें

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

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

2. रखरखाव लागत कम करें

पहले उपयोग किए जाने वाले OpenResty की तुलना में, APISIX का सीखने की लागत कम है और इसे बनाए रखना आसान है। इसके अलावा, APISIX के समृद्ध प्लगइन्स कुछ मानक सुविधाओं की तैनाती और विकास को सरल करते हैं, जिससे उत्पाद रिलीज़ समय कम हो जाता है।

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

निष्कर्ष: वित्तीय उद्योग विकास के रुझान

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

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

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

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