APISIX कैसे Beeto सोशल मीडिया प्लेटफॉर्म को मध्य पूर्व में स्थानीयकृत तैनाती में सुविधा प्रदान करता है

अवलोकन

चुनौतियाँ

• मोनोलिथिक सेवा आर्किटेक्चर के कारण रखरखाव और संचालन में उच्च लागत
• जटिल आर्किटेक्चर तैनाती और सेवा कॉल, और कई प्रौद्योगिकी स्टैक

परिणाम

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

Beeto का परिचय

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

मध्य पूर्व में इंटरनेट विकास परिपक्व है, सोशल नेटवर्क में सक्रिय उपयोगकर्ताओं की बहुत अधिक पैठ है। विशेष रूप से सऊदी अरब में, जहां 2019 में 90% लोगों ने इंटरनेट का उपयोग किया। 2020 में सऊदी अरब में सक्रिय उपयोगकर्ताओं की पैठ दर 9वें स्थान पर थी।

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

Beeto के लिए स्थानीयकरण महत्वपूर्ण है

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

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

Beeto आर्किटेक्चर डिजाइन में दर्द बिंदु

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

मोनोलिथिक सेवा आर्किटेक्चर के कारण उच्च लागत

Beeto की सेवाओं को आठ भागों में विभाजित किया जा सकता है, जैसा कि नीचे दिखाया गया है।

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

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

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

जब कई व्यवसायों की सेवाएं संयुक्त होती हैं, तो समग्र आर्किटेक्चर हो सकता है:

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

हालांकि, चूंकि Beeto उत्पाद स्टार्टअप चरण में है और उत्पाद मध्य पूर्व में लॉन्च किया गया है, लेकिन इसका R&D टीम चीन में है, इसलिए बड़े सर्वर और रखरखाव लागत की आवश्यकता है। इसके अलावा, जैसे-जैसे व्यवसाय बढ़ता है, मोनोलिथिक सेवाओं की संख्या अनिवार्य रूप से बढ़ेगी, जिससे लागत और रखरखाव संचालन दोनों को नियंत्रित करना और अधिक कठिन हो जाएगा।

कई सेवाओं को लॉन्च करने में कठिनाई

आर्किटेक्चर तैनाती की जटिलता के अलावा, क्लस्टर के भीतर सेवाओं के बीच कॉल भी बहुत जटिल हैं।

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

इसके अलावा, इन कॉल संबंधों को सेवाओं द्वारा बनाए रखने की आवश्यकता होती है, जिससे कॉल ट्रेसिंग अस्पष्ट हो जाती है और प्रबंधन खराब हो जाता है।

कॉल संबंधों की जटिलता के अलावा, प्रत्येक सेवा के बीच तकनीकी स्टैक में भी अंतर होता है। उदाहरण के लिए, कॉल प्रोटोकॉल पर, कुछ सेवाएं HTTP प्रदान करती हैं, जबकि अन्य RPC प्रदान करती हैं; प्रोग्रामिंग भाषाओं के विकास के संदर्भ में, Java, Go, और अन्य प्रोग्रामिंग भाषाओं का मिश्रण है।

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

चूंकि Beeto व्यापार उन्नयन और पुनरावृत्ति पर अधिक ध्यान केंद्रित करता है, आर्किटेक्चर को रखरखाव और एकीकृत प्रबंधन को सुविधाजनक बनाने के लिए डिज़ाइन किया गया है, तो इस लक्ष्य को कैसे प्राप्त किया जाए?

APISIX गेटवे Beeto के आर्किटेक्चर को शक्ति प्रदान करता है

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

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

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

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

APISIX लागू करने के बाद के अभ्यास

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

सुरक्षा: प्रमाणीकरण प्लगइन

उत्तर-दक्षिण ट्रैफ़िक: कुकी

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

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

ऐसा करने के दो लाभ हैं:

1. उपयोगकर्ताओं की कुकी की सुरक्षा सुनिश्चित होती है। निष्पादन के दौरान केवल गेटवे परत ही कुकी प्राप्त और प्रसंस्करण कर सकती है क्योंकि कुकी संवेदनशील डेटा होती है। यह व्यापार प्रसंस्करण नियमों में असंगति के कारण होने वाली सुरक्षा समस्याओं को रोकता है और मानवीय कारकों और अनियमितताओं के कारण कुकी लीक को प्रभावी ढंग से रोकता है।

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

पूर्व-पश्चिम ट्रैफ़िक: टोकन

नीचे दिए गए चित्र में, सेवा A सेवा B को कॉल करती है। आम तौर पर, एक API ही कॉल करने के लिए आवश्यक होता है। हालांकि, आंतरिक प्रक्रिया में, यह समझना आवश्यक है कि "किसने API को कॉल किया, इसे कैसे कॉल किया गया, क्या अधिकार जांच करना आवश्यक है, और क्या शोधकर्ता को नियंत्रित करना आवश्यक है", और इसी तरह, जिन्हें आंतरिक रूप से संभालने की आवश्यकता होती है।

APISIX गेटवे के साथ, प्रक्रिया बहुत सरल हो जाती है। सभी आंतरिक सेवाओं की आपसी कॉल केवल Auth प्रमाणीकरण सेवा पर पंजीकृत होने की आवश्यकता होती है, और प्रत्येक सेवा को एक App key जारी किया जाता है जो सेवा की पहचान ID को इंगित करता है। साथ ही, आंतरिक सेवाओं की आपसी कॉल भी गेटवे से गुजरती है। गेटवे के माध्यम से टोकन ले जाने के बाद, गेटवे टोकन प्लगइन्स के माध्यम से टोकन का प्रमाणीकरण करता है। प्रमाणीकरण पास होने के बाद, प्रमाणीकरण पहचानकर्ता को कॉल की गई सेवा को पास किया जाता है। पूरी प्रक्रिया के दौरान, सेवा प्रणाली प्रमाणीकरण पंजीकरण करती है और एक आपसी कॉल पूरा करती है।

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

स्केलेबिलिटी: स्टेटलेस सेवा विस्तार और माइग्रेशन

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

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

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

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

कार्यात्मक विस्तार: सेवाओं का गतिशील फॉरवर्डिंग

उपरोक्त परिचित गेटवे सामान्य परिदृश्यों के अलावा, Apache APISIX सेवा गतिशील फॉरवर्डिंग के संदर्भ में Beeto को महत्वपूर्ण सहायता प्रदान करता है।

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

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

उपरोक्त समस्या का समाधान समग्र आर्किटेक्चर में सेवाओं का एकीकृत वितरण लागू करना है। क्लाइंट पहले API पता का अनुरोध कर