लोकप्रिय हाउसिंग प्लेटफॉर्म Beike, Apache APISIX को क्यों चुनता है

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

Kong या Apache APISIX

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

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

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

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

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

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

हालांकि, सबसे महत्वपूर्ण समस्या यह है कि Apache APISIX का प्रदर्शन इसके सीमित ओपन-सोर्स समय के कारण कमजोर हो सकता है। एक ही परीक्षण वातावरण में Kong के साथ तनाव परीक्षण के परिणामों की तुलना करने पर, Apache APISIX ने अंततः Kong को हरा दिया। हालांकि, Kong के लिए यह उचित नहीं है क्योंकि Kong बहुत भारी और जटिल है। दूसरी ओर, मेरे उपयोग के मामले में कोई अंतर नहीं है क्योंकि Apache APISIX में सभी आवश्यक कार्यक्षमताएं प्रदान की गई हैं। Apache APISIX के प्रदर्शन परीक्षण रिपोर्ट के अनुसार, एक सिंगल-कोर CPU 24k QPS तक पहुंच सकता है, जबकि विलंबता केवल 0.7 मिलीसेकंड है।

संक्षेप में, मैंने Apache APISIX को निम्नलिखित कारणों से चुना:

• यह परियोजना की सभी आवश्यकताओं को पूरा कर सकता है, Apache APISIX की सीखने की लागत कम है
• Kong का कोड बेस बड़ा है, जो कोड को बनाए रखने में चुनौतीपूर्ण बनाता है
• Apache APISIX के लेखक OpenResty समुदाय में अधिक सक्रिय हैं, जो बेहतर कोड गुणवत्ता प्रदान कर सकते हैं
• सबसे महत्वपूर्ण बात यह है कि लेखकों से सीधे संवाद करके किसी भी प्रश्न को जल्दी से हल किया जा सकता है

आधिकारिक वेबसाइट द्वारा प्रदान किए गए APISIX के कारण निम्नलिखित चित्र में दिखाए गए हैं:

Apache APISIX क्या क्षमताएं प्रदान कर सकता है

• हॉट अपडेट और हॉट प्लगइन्स
• डायनामिक लोड बैलेंसिंग
• सक्रिय और निष्क्रिय स्वास्थ्य जांच
• सर्किट ब्रेकिंग
• प्रमाणीकरण
• दर सीमित करना
• gRPC प्रोटोकॉल रूपांतरण
• डायनामिक TCP/UDP, gRPC, WebSocket, MQTT ब्रोकर
• डैशबोर्ड
• प्रतिबंधित और अनुमति सूची
• सर्वरलेस

Apache APISIX लगभग दस संस्करणों में जारी किया गया है, जो इन सूचीबद्ध कार्यक्षमताओं से कहीं अधिक समर्थन करता है। व्यावसायिक स्थिति के अनुसार आर्किटेक्चर डायग्राम निम्नानुसार खींचा गया है:

हमने APISIX को कैसे एकीकृत किया

कुछ दिनों के कोड पढ़ने के बाद, मुझे Apache APISIX की बुनियादी समझ हो गई, लेकिन एक सवाल उठा: मैंने कभी कोई ओपन-सोर्स प्रोजेक्ट विकसित नहीं किया है। मैं इसे कैसे पूरा कर सकता हूं? मैंने स्थानीय रूप से तीन अलग-अलग शाखाएं बनाईं, एक Apache APISIX शाखा ऊपरी ओपन-सोर्स रिपॉजिटरी की ओर इशारा करती है, एक अन्य शाखा dev नियमित व्यावसायिक पुनरावृत्ति के लिए उपयोग की जाती है, और अंतिम मुख्य शाखा ऑनलाइन अपग्रेड के लिए उपयोग की जाती है।

दो सप्ताह की कड़ी मेहनत के बाद, मेरे प्रोजेक्ट में कुछ मूलभूत संरचनाएं हैं। यह परिणाम की जांच करने का समय है; यही कारण है कि हमने तनाव परीक्षण चरण शुरू किया। सेवा Tencent Cloud पर 8 कोर और 32 GB मेमोरी सर्वर पर तैनात है, और ऊपरी सिरा एक नियमित क्लाउड प्रोडक्शन वातावरण है, इसलिए इसे बहुत कठिन परीक्षण नहीं किया जा सकता है। प्रदर्शन रिपोर्ट निम्नानुसार है:

प्रदर्शन रिपोर्ट सारांश: इंटरफ़ेस समय खपत 47% कम हो गई है, कोई त्रुटि नहीं उठाई गई है, और स्थिरता में सुधार हुआ है। TPS शिखर मूल्य 82% बढ़ गया है, कोई त्रुटि नहीं उठाई गई है, और स्थिरता में सुधार हुआ है।

विकास वातावरण तैयार है, और हमने क्लाउड तैनाती का अध्ययन शुरू किया। Apache APISIX कई स्थापना विधियों का समर्थन करता है: Docker, RPM पैकेज, Luarocks, और स्रोत कोड। बुरी खबर यह है कि क्लाउड वातावरण में कुछ भी स्थापित करने की अनुमति नहीं है, और स्रोत कोड केवल एक निश्चित मार्ग पथ में रखा जा सकता है। इसलिए Apache APISIX की कई सुविधाएं समर्थित नहीं होंगी क्योंकि वे OpenResty 1.15.8 पर आधारित हैं। मैं क्या कर सकता हूं? कोड रिपॉजिटरी में संकलित फाइलें उत्पन्न होती हैं, इसे कुछ निर्दिष्ट निर्देशिका के तहत संकलित करना होगा, और आप PCRE के स्थिर बाइंडिंग का उपयोग नहीं कर सकते हैं, जिसने हमें 1-2 दिन खर्च किए। अंत में, हमने ग्रे रिलीज़ को समायोजित किया; ट्रैफ़िक कई हफ्तों में 2% से कुल मात्रा तक बढ़ गया। सौभाग्य से, अंत में सब कुछ सफलतापूर्वक हो गया।

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

Apache APISIX शाखा को 0.7 में अपग्रेड करना आसान है, लेकिन हम कोड को कैसे मर्ज कर सकते हैं? इन दो संस्करणों के बीच कोड परिवर्तन बहुत बड़े हैं। मैं पहले उन्हें मर्ज करने का प्रयास करता हूं, लेकिन बहुत सारे संघर्ष हैं, और हम इतने खतरनाक गति पर हैं। संघर्षों को हल करने की मानक विधि अवास्तविक है, जो बहुत सारे छिपे हुए बग का कारण बन सकती है। क्या कोई कुशल समाधान है? मैंने ऑनलाइन खोज की और शॉर्टकट विधियां पाईं: git checkout –ours और git checkout –theirs (कृपया इसे खोजें यदि आपने इसका उपयोग नहीं किया है), और कुछ ही मिनटों में APISIX 0.5 से 0.7 तक अपग्रेड पूरा किया। बेशक, यह APISIX कोड की मजबूती का भी धन्यवाद है, जो मुझे केवल व्यावसायिक प्लगइन्स जोड़ने की अनुमति देता है बिना किसी युग्मन के।

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

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

प्रोजेक्ट को फिर से लॉन्च करने के बाद, Apache APISIX 0.7 संस्करण अभी भी मुझे समय-समय पर आश्चर्यचकित कर सकता है। Apache APISIX 0.5 संस्करण में उपयोग किया गया रूटिंग निर्भरता libr3 था, जबकि Apache APISIX 0.7 में रेडिक्स ट्री का उपयोग किया गया था, जो बेहतर प्रदर्शन करता है। CPU उपयोग और मेमोरी उपयोग प्रतिशत दोनों में कमी आई है। Apache APISIX 0.5 में, CPU उपयोग 1-10% है, और मेमोरी 0.1% है। Apache APISIX 0.7 में, CPU उपयोग 1-2% तक कम हो गया है, और मेमोरी 0.1% से कम है, जो उत्कृष्ट है।

भविष्य की योजना

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

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