كيف تسهل APISIX النشر المحلي لمنصة Beeto للتواصل الاجتماعي في الشرق الأوسط

نظرة عامة

التحديات

• يؤدي هيكل الخدمة الأحادي إلى تكاليف عالية في الصيانة والتشغيل
• تعقيد في نشر البنية التحتية واستدعاء الخدمات، وتعدد تقنيات التكديس

النتائج

• توحيد حركة المرور الشمالية-الجنوبية والشرقية-الغربية، مما يوفر الموارد وتكاليف العمالة وتمكين الإدارة الديناميكية والموحدة
• تبسيط بنية النشر، مما يقلل التفاعل بين البوابة والمستخدمين
• ساعدت الإضافات المتعددة لـ APISIX شركة Beeto على إدارة التحقق من الأذونات، وتوزيع المسارات، ووظائف فحص الصحة للخدمات بكفاءة
• تمكن APISIX شركة Beeto من إطلاق الخدمات ونقلها بشكل ديناميكي، مما يجعلها صديقة للمطورين

مقدمة عن Beeto

بالنسبة لسوق الشرق الأوسط، تعتبر Beeto منصة وسائط اجتماعية عربية، مع تصميم منتج محلي وهيكل تقني. وقد احتلت المرتبة الرابعة في قائمة أفضل التطبيقات في متجر تطبيقات iOS السعودي، متجاوزة عملاق الوسائط الاجتماعية فيسبوك.

تطور الإنترنت في الشرق الأوسط ناضج، مع انتشار مرتفع جدًا للمستخدمين النشطين في الشبكات الاجتماعية. خاصة في المملكة العربية السعودية، حيث استخدم 90% من الناس الإنترنت في عام 2019. واحتلت المملكة العربية السعودية المرتبة التاسعة في عام 2020 من حيث معدل انتشار المستخدمين النشطين.

أدى نضوج سوق الإنترنت إلى انتشار البرامج الاجتماعية الدولية مثل WhatsApp وYouTube وInstagram. ومع ذلك، لا يوجد برنامج اجتماعي محلي مشابه لتويتر. لذلك، واستهدافًا لـ "نضوج الإنترنت ولكن مع قلة التخصيص المحلي" في الشرق الأوسط، أطلقت Beeto تطوير منتج محلي هناك.

أهمية التخصيص المحلي لـ Beeto

بالمقارنة مع تطبيقات تدفق الأخبار مثل تويتر وفيسبوك، خططت Beeto لإطار عمل كامل نسبيًا لنشر هيكل أعمالها في الشرق الأوسط. على سبيل المثال، كانت ملتزمة بتلبية تفاعل العلاقات للخصائص الاجتماعية، واستهلاك المحتوى (النص، البث المباشر، الإعلانات المحلية، إلخ)، بالإضافة إلى الأعمال المختلفة مثل المكافآت، السحب، التصويت، واليانصيب للفئات المالية والخدمية، وحتى متطلبات مراقبة المنصة ومراجعة أمن المحتوى.

كما ذكر سابقًا، فإن نضوج الإنترنت في سوق الشرق الأوسط يتطلب منتجات عالية الجودة. لذلك، كانت النسخة الأولى من هيكل أعمال Beeto منتجًا كاملاً يدمج جميع الميزات التي يجب أن تكون موجودة في البرامج الاجتماعية الرئيسية. في الوقت نفسه، هدف Beeto هو أن تصبح أكبر منصة اجتماعية عربية وأفضل مجتمع عربي في الشرق الأوسط بميزات "التخصيص المحلي". ولتحقيق هذا الهدف، قامت Beeto بتحليل متطلبات التخصيص المحلي كما يلي.

نقاط الألم في تصميم هيكل Beeto

يشمل التخصيص المحلي الاحتياجات الاجتماعية المحلية الحالية على مستوى الأعمال، وعمليات التخصيص المحلي على المستوى التقني، مثل نشر الخدمات وتخزين البيانات. أولئك الذين يعرفون Weibo أو تويتر يعرفون أن الأمر يتطلب عشرات أو مئات الأنظمة المعمارية للتعاون وراء مثل هذا المنتج الضخم لتدفق المعلومات. تظهر نقاط الألم في هيكل Beeto كما يلي.

هيكل الخدمة الأحادي يسبب تكاليف عالية

يمكن تقسيم خدمات Beeto إلى ثمانية أجزاء، كما يلي.

يتطلب تنفيذ هذه الأعمال نشرًا محليًا في الشرق الأوسط. إذا تم تقسيم كل عمل حسب الخدمة، فإن كل خدمة هي هيكل أحادي منفصل.

يوضح الرسم البياني للهيكل الأحادي أعلاه بنية نشر شائعة. لنأخذ خدمة تدفق الأخبار في Beeto كمثال. إذا أردنا تلبية طلب المستخدم لتصفح تدفق الأخبار، يجب علينا دعم الوصول إلى الشبكة العامة، أي الوصول إلى حركة المرور الشمالية-الجنوبية؛ في الوقت نفسه، توفر خدمة تدفق الأخبار أيضًا بعض المكالمات الداخلية في شكل أعمال الموضوع، أي مكالمات حركة المرور الشرقية-الغربية.

لذلك، تدعم الخدمة العامة أنماط المكالمات الخارجية والداخلية. بعد موازنة الحمل من الطبقة السابعة، يتم توزيع حركة مرور المستخدمين على خوادم مختلفة، ثم يتم استدعاء موارد التخزين المختلفة. حركة المرور الشرقية-الغربية مشابهة أيضًا. تعالج مجموعة الطبقة السابعة حركة المرور الشمالية-الجنوبية والشرقية-الغربية، وموازنة الحمل، المصادقة، ومراقبة العقد.

عندما يتم دمج خدمات الأعمال المتعددة، يمكن أن تكون البنية العامة كما يلي:

كما ترون، توجد الخدمات في طبقات التكيف، والأعمال، والخدمات الأساسية. لكل من هذه الخدمات بنية نشر تفصيلية للهيكل الأحادي المذكور أعلاه، لذلك هناك عدة مجموعات من الطبقة السابعة في الوسط، مما يجعلها بنية نظام معقدة للغاية.

ومع ذلك، نظرًا لأن منتج Beeto في مرحلة البدء ويتم إطلاق المنتج في الشرق الأوسط، ولكن فريق البحث والتطوير موجود في الصين، فإن الأمر يتطلب تكاليف كبيرة للخوادم والصيانة. علاوة على ذلك، مع زيادة الأعمال لاحقًا، سيزداد عدد الخدمات الأحادية حتمًا، مما يجعل من الصعب التحكم في كل من التكاليف وعمليات الصيانة.

صعوبة في إطلاق خدمات متعددة

بالإضافة إلى تعقيد نشر البنية التحتية، المكالمات بين الخدمات داخل المجموعة معقدة للغاية أيضًا.

يتم توزيع حركة المرور الشمالية-الجنوبية على مجموعات الخدمات المختلفة، وتتشابك حركة المرور الشرقية-الغربية أيضًا بين الخدمات المختلفة، مع تشابك علاقات الاستدعاء بين هذه الخدمات.

بالإضافة إلى ذلك، تحتاج هذه العلاقات الاستدعائية إلى أن يتم صيانتها من قبل الخدمات، مما يؤدي إلى عدم وضوح تتبع الاستدعاءات وسوء الإدارة.

بالإضافة إلى علاقات الاستدعاء المعقدة، هناك أيضًا اختلافات في تكديس التقنيات بين كل خدمة. على سبيل المثال، في بروتوكول الاستدعاء، توفر بعض الخدمات HTTP، بينما توفر أخرى RPC؛ من حيث تطوير لغات البرمجة، هناك مزيج من Java، Go، ولغات برمجة أخرى.

سيؤدي نظام بنية الخدمات المتعددة هذا بشكل واضح إلى كشف مشكلة تكاليف النشر والصيانة العالية عند تنفيذه محليًا. علاوة على ذلك، تحتاج Beeto إلى إدخال تكاليف الخوادم على كل مجموعة من خدمات الطبقة السابعة، بينما يؤدي اختلاف حركة المرور لكل خدمة إلى عدم توازن حركة المرور، مما يؤدي إلى انخفاض معدل استخدام موارد مثل الخوادم وإهدار الموارد.

نظرًا لأن Beeto ركزت أكثر على ترقيات الأعمال والتكرارات، تم تصميم البنية لتسهيل الصيانة والإدارة الموحدة، فكيف يمكن تحقيق هذا الهدف؟

بوابة APISIX تعزز بنية Beeto

لحل مشاكل الإدارة غير المريحة للخدمات والتكاليف العالية وللاستفادة من الأداء الديناميكي لـ APISIX مع etcd، والذي يتوافق بشكل أكبر مع متطلبات منتج Beeto، تم إدخال APISIX كبوابة API في نشر البنية، وتم بناء مجموعة بوابات، كما هو موضح في الشكل أدناه.

توفر مجموعة بوابات APISIX أدوات تمديد مثل مركز التسجيل، التحكم في الخدمات، مراقبة الخدمات، تحويل البروتوكولات، والإضافات لجميع الخدمات. يمكن تسجيل مجموعات الخدمات جميعها مع البوابة، ويمكن إضافة خدمات جديدة وإزالتها مباشرة من خلال البوابة.

بعد إدخال البوابة، أصبح تتبع الاستدعاءات للمجموعة بأكملها أكثر وضوحًا. يتم توجيه حركة المرور الشمالية-الجنوبية وتحويلها بواسطة البوابة، وتتم معالجة حركة المرور الشرقية-الغربية بواسطة البوابة للخدمات على الشبكة الداخلية. على المستوى الوظيفي، تقوم APISIX بالحفاظ على المصادقة التي يتم استدعاؤها بواسطة هذه الحركة بحيث يمكن للطبقة البوابة فهم الاختلافات في الأداء وحركة المرور بين الخدمات.

بالطبع، نظرًا لأن البوابة تحمل كل حركة المرور في هذه البنية، فإن عدد الخدمات سيزداد لاحقًا مع توسع الخدمة، مما يزيد من تكاليف صيانة البوابة، وسيحتاج إلى النظر في حلول جديدة. ومع ذلك، في السياق الحالي، يظل الحل هو الخيار الأفضل.

الممارسات بعد تطبيق APISIX

Apache APISIX، كبوابة API، يمكنها التعامل مع مجموعة متنوعة من السياسات على مستوى البوابة، مثل المصادقة، تحويل الخدمات، وفحوصات الصحة. لذلك، قامت Beeto بالعديد من المحاولات على مستوى الممارسات التجارية بعد إدخال APISIX.

الأمان: إضافة المصادقة

حركة المرور الشمالية-الجنوبية: الكوكيز

كما ذكرنا سابقًا، تمر حركة مرور المستخدمين للشبكة العامة عبر البوابة. يتم التحقق من مصادقة مستخدمي الشبكة العامة بناءً على طلب المستخدم باستخدام الكوكيز. عندما يطلب المستخدم إحضار الكوكيز إلى البوابة، يتم التحقق منها بواسطة إضافة المصادقة.

كما هو موضح في الرسم البياني أعلاه، ستقوم الإضافة أولاً بإجراء التحقق المحلي ثم التحقق من مصادقة الخدمة البعيدة وفقًا للسياسة. بمجرد التحقق من الكوكيز، سيتم تحويل الطلب إلى الخدمة المحددة.

مزايا القيام بذلك هي:

1. يتم ضمان أمان كوكيز المستخدمين. فقط طبقة البوابة يمكنها استقبال ومعالجة الكوكيز أثناء التنفيذ لأن الكوكيز هي بيانات حساسة. هذا يمنع المشاكل الأمنية الناجمة عن عدم اتساق قواعد معالجة الأعمال ويتجنب بشكل فعال تسرب الكوكيز بسبب العوامل البشرية وعدم الانتظام.

2. تقليل تعقيد التحقق من الكوكيز للخدمات. تحتاج الكوكيز إلى التحقق محليًا أو عن بعد وتتطلب ترقية الخدمات في نفس الوقت عند ترقية الكوكيز. تقوم APISIX بإدارة وفحص موحد، مما يوفر تكلفة التحقق من خدمات الأعمال ويشير إلى النتائج، والتي يمكن استخدامها لمعالجة قواعد الأعمال، مما يضمن أن كل معالجة أعمال تركز أكثر على الأعمال نفسها.

حركة المرور الشرقية-الغربية: الرمز المميز

في الرسم البياني أدناه، تقوم الخدمة A باستدعاء الخدمة B. بشكل عام، كل ما هو مطلوب هو API للاتصال ببعضها البعض. ومع ذلك، في العملية الداخلية، من الضروري فهم "من استدعى API، كيف تم استدعاؤه، هل من الضروري التحقق من الصلاحية، وهل من الضروري التحكم في الباحث"، وما إلى ذلك، والتي تحتاج إلى معالجتها داخليًا.

مع بوابة APISIX، تصبح العملية أبسط بكثير. يحتاج الاستدعاء المتبادل لجميع الخدمات الداخلية فقط إلى التسجيل على خدمة المصادقة Auth، ويتم إصدار مفتاح App لكل خدمة للإشارة إلى معرف الهوية للخدمة. في الوقت نفسه، سيمر الاستدعاء المتبادل للخدمات الداخلية أيضًا عبر البوابة. بعد حمل الرمز المميز عبر البوابة، ستقوم البوابة بالمصادقة على الرمز المميز من خلال إضافات الرمز المميز. بعد اجتياز المصادقة، سيتم تمرير معرف المصادقة إلى الخدمة المستدعاة. خلال العملية بأكملها، سيقوم نظام الخدمة بإجراء تسجيل المصادقة وإكمال استدعاء متبادل.

بفضل قاعدة الرمز المميز لمفتاح App، يمكن تتبع مصدر الاستدعاء بسهولة، مما يمكن استخدامه للتحقق من الأخطاء والتحكم في الصلاحيات، ويوفر أيضًا تحكمًا فعالًا في الاستدعاءات غير القانونية. لذلك، فإن ميزة المصادقة الموحدة هي أنها تضمن أمان ووحدة المجموعة، سواء لحركة المرور الشمالية-الجنوبية أو الشرقية-الغربية، مما يساعد بشكل كبير في تتبع المشاكل والتحكم في الاستدعاءات.

قابلية التوسع: توسيع وترحيل الخدمات عديمة الحالة

تتكون بنية النشر العامة لمجموعة Beeto من الأعلى إلى الأسفل من: مجموعات بوابات APISIX - مجموعات خدمات الأعمال للخدمات عديمة الحالة - مجموعات مراكز البيانات للخدمات ذات الحالة. عند النشر محليًا في الشرق الأوسط، يتم نشرها جميعًا على مجموعات السحابة الرئيسية. وفقًا لنطاق تغطية السحابة في الشرق الأوسط والشركات المصنعة للسحابة في مناطق مختلفة، من الضروري النظر في توسيع وترحيل خدمات السحابة عند نشر الخدمات.

في عملية الترحيل، ركزت Beeto على ترحيل الخدمات عديمة الحالة. ليس من المناسب التعديل الديناميكي بسبب تكلفة الترحيل المحدودة لمركز البيانات؛ يتم حمل معظم الطلبات بواسطة الخدمة عديمة الحالة، لذلك من المهم جدًا ضمان أن الخدمة عديمة الحالة لديها قابلية توسع جيدة.

في بنية Beeto، تنعكس قابلية توسع الخدمة بشكل رئيسي في جانبين: قابلية توسع الخدمة الأحادية وقابلية توسع المجموعة بأكملها. على سبيل المثال، إذا نفدت موارد خدمة أحادية واحتاجت إلى التوسع، يمكن لبوابات APISIX إضافة عقد بشكل ديناميكي للتوسع. وبالمثل، في حالات المجموعات المتقاطعة أو السحابة المتقاطعة، يمكن تحقيق قابلية توسع المجموعة عن طريق نشر بوابات APISIX متعددة وترحيل خدمات مختلفة إلى عقد بوابات مختلفة.

بالنسبة لخدمات الأعمال، تظل البنية العامة دون تغيير بحيث يمكن تحقيق التوسع الديناميكي والانكماش للخدمات المختلفة وترحيل الخدمات على مستوى البوابة. العملية بأكملها لديها خطة وأهداف واضحة، وبمجرد حدوث تغييرات، لن تكون البنية العامة غير مستقرة.

قابلية التمديد الوظيفي: التحويل الديناميكي للخدمات

بالإضافة إلى هذه السيناريوهات العامة المألوفة للبوابة المذكورة أعلاه، توفر Apache APISIX أيضًا مساعدة كبيرة لـ Beeto من حيث التحويل الديناميكي للخدمات.

أولئك الذين يعرفون واجهة المستخدم والخلفية للتطبيقات يعرفون أن صفحات المنتجات المختلفة يتم توفيرها بواسطة خدمات مختلفة. تتكون الصفحة من وحدات مختلفة، يتم إرسال محتواها جميعًا من API. أي بيانات ترسلها API إلى الوحدة يتم عرضها على الأطراف. هذا هو مواصفات عرض العميل المشتركة لجعل عملية عرض العميل أكثر عمومية ومعالجة الأعمال أكثر مرونة.

في تنفيذ PageA في الشكل أعلاه، على سبيل المثال، يستدعي العميل API للخدمة A، ويرسل بيانات الوحدة المقابلة، ويكمل عرض PageA. سيؤدي هذا الإجراء إلى مشاكل حيث يحتاج العميل إلى الحفاظ على كل صفحة وAPI لكل خدمة. إذا تغير المحتوى، يجب حله عن طريق النشر، وهو غير صديق من حيث القابلية للتشغيل والكفاءة.

حل المشكلة أعلاه هو تنفيذ توزيع موحد للخدمات في البنية العامة. يطلب العميل أولاً عنوان API، ويحول جميع الطلبات من هذا النوع إلى API واحد، ويعالج معلمات الطلب وقواعد URL لعنوان URL على مستوى البوابة، ثم يقدم إضافة التوزيع. أخيرًا، يتم تحويل الطلبات المحللة مباشرة إلى الخدمة المحددة على مستوى البوابة وفقًا لقواعد التكوين.

يحتاج العميل فقط إلى تحديد مواصفات العرض خلال العملية بأكملها، وليس مصدر البيانات. تقوم طبقة البوابة بتحمل مسؤولية توزيع الخدمات وتحويل حركة المرور مباشرة. يمكن تحديث ملف تكوين الإضافة في APISIX بشكل ديناميكي في الوقت الفعلي، ويمكن تعديل قواعد التحويل بشكل ديناميكي، مما يجعلها مرنة للغاية. في الواقع، بالنسبة لتطبيقات مثل بنية BFF (Backend for Frontend)، يمكن حل مثل هذه المتطلبات على مستوى البوابة.

الخلاصة

يقدم هذا المقال الممارسات التطبيقية لإدخال Apache APISIX في Beeto من منظور التفكير التصميمي والأعمال.

دعمت APISIX Beeto في التحكم في تكاليف الموارد وخطوط منتجات الأعمال المتعددة وساعدت Beeto على تحقيق النشر المحلي والإدارة الموحدة وسيناريوهات صديقة للصيانة في الشرق الأوسط.