ممارسة بوابة API في Tencent باستخدام Apache APISIX

Fei Han

May 24, 2021

Case Study

ما هو بوابة API؟

الهندسة التقليدية

قبل التكامل مع بوابة API، لدينا طرق قليلة لإعادة استخدام بعض الوظائف العامة، مثل:

  • الأمان: المصادقة، التفويض، منع إعادة التشغيل، منع التلاعب، منع هجمات DDoS، إلخ.
  • الموثوقية: تخفيض الخدمة، الانصهار، الحد من حركة المرور، وما إلى ذلك.

في الهندسة التقليدية، الطريقة الأكثر شيوعًا للتعامل مع هذه الحالة هي وضعها في إطار خدمة وتنفيذها من خلال AOP، على غرار الرسم البياني للهندسة التالية:

الهندسة التقليدية

يحتوي الرسم البياني للهندسة التقليدية على الوحدات التالية.

  • الخلفية: خدمات الخلفية
  • AOP: طبقة AOP التي يحملها الإطار؛
  • SD: مركز الخدمة، يستخدم لاكتشاف الخدمات الداخلية. في التقنيات السحابية الأصلية، نستخدم غالبًا Service لاستبدال هذا المكون؛
  • LB: موزع الحمل، نستخدمه على حدود الشبكة كنقطة دخول لحركة المرور الخارجية.

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

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

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

لماذا لا نضع هذه الوظائف نفسها في خدمة مستقلة، يمكن ترقيتها أو صيانتها بشكل منفصل؟

نمط البوابة

نمط البوابة

بالمقارنة مع الهندسة التقليدية، يمكننا رؤية مكون إضافي بين خدمات الخلفية و LB: البوابة.

تحتوي البوابة عادةً على العديد من الميزات القياسية والقابلة لإعادة الاستخدام، مثل المصادقة، إدارة حركة المرور، إلخ. فيما يلي الفوائد التي يمكننا الحصول عليها:

  • البوابة هي مكون تابع في الأنظمة، ويمكننا الحصول على تجربة صيانة أفضل.
  • البوابة مستقلة عن اللغة.

ومع ذلك، فإن نمط البوابة له أيضًا عيوبه:

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

كيفية تحقيق التوازن بين فوائد وعيوب نموذج البوابة هو تحدي لفريق التقنية. دعونا نرى كيف يعمل فريق Tencent OTeam مع Apache APISIX.

مقدمة

OTeam

OTeam في Tencent هي مجموعة من الفرق، وكل فريق يحافظ على منتج تقني واحد أو عدة منتجات. هدفهم هو بناء منصة وسطية مستقرة ولكن قوية للأنظمة الداخلية. أحد فرق OTeam يدعم توزيع Apache APISIX المخصص داخليًا في Tencent.

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

بعض فرق Oteams لديها عشرات المنتجات تحتها، بينما البعض الآخر لديه منتج واحد فقط. على سبيل المثال، Oteam حيث يوجد Apache APISIX لديه منتج واحد فقط، Apache APISIX. الغرض الأصلي من هذا Oteam هو الحفاظ على ميزات التخصيص لـ Apache APISIX داخل Tencent.

Apache APISIX

Apache APISIX هو مشروع من المستوى الأول من مؤسسة Apache Software Foundation، وهنا بعض النقاط الرئيسية:

  • Apache APISIX هو بوابة API سحابية الأصلية وديناميكية تعتمد على OpenResty، مع أداء توجيه أعلى من Kong.
  • يوفر Apache APISIX ميزات غنية لإدارة حركة المرور مثل موازنة الحمل، المصدر الديناميكي، الإصدار التدريجي، الانصهار، المصادقة، المراقبة، والمزيد.
  • Apache APISIX جيد في التعامل مع حركة المرور التقليدية من الشمال إلى الجنوب، وكذلك حركة المرور بين الخدمات من الشرق إلى الغرب. يمكن أيضًا استخدامه كوحدة تحكم ingress لـ k8s.
  • يستخدم Apache APISIX بشكل افتراضي ETCD كمركز تكوين، والذي يمكنه تحديث التكوين في ثوانٍ.
  • تخرج Apache APISIX من مؤسسة Apache Software Foundation واستغرق بضعة أشهر فقط.

استراتيجية عمل OTeam في Tencent

استراتيجية عمل OTeam

يوضح الرسم البياني أعلاه كيف يعمل OTeam مع مجتمع Apache APISIX:

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

هذه العملية تشبه مشاريع المصدر المفتوح الأخرى. فيما يلي بعض النقاط الرئيسية:

  • بعد حل المشكلة، يحدد مهندسو Tencent ما إذا كانت المشكلة مشكلة شائعة للمجتمع أيضًا. إذا كان الأمر كذلك، فإنهم يقدمون PR إلى المجتمع.
  • سيقوم OTeam في Tencent بمراجعة الميزات الجديدة لـ Apache APISIX بانتظام لتحديد ما إذا كانت مستقرة وما إذا كانت أيضًا نقطة ألم لـ Tencent. إذا كانت الإجابة بنعم، يتم اختيار الأكواد ذات الصلة.

في البداية، كان OTeam يقوم بمزامنة الأكواد مع Apache APISIX كل 12 ساعة حتى نتمكن من متابعة Apache APISIX بسرعة، ولكن هذا النهج تسبب في بعض المشاكل:

  • بعد مزامنة الأكواد مع Apache APISIX، يمكننا التأكد من أن اللوائح صحيحة ولكن لا يمكننا التأكد من أن الأكواد مستقرة. حدثت بعض الأخطاء العرضية في حالات التزامن.
  • الأكواد المدمجة تسبب أحيانًا تعارضات متعددة في PRs المنبع منطقيًا، ولكن Apache APISIX و CI لـ OTeam لا يمكنهما اكتشاف هذه الحالة. فقط عندما نقوم بدمج PRs في الفرع الرئيسي يمكننا اكتشاف أن شيئًا ما حدث خطأ.

لهذه الأسباب، يتحول OTeam الآن إلى اختيار الأكواد للميزات المطلوبة بعد المراجعات الداخلية.

اتجاه OTeam

اعتبارًا من مايو 2021، قام OTeam بتطبيق Apache APISIX لأكثر من عشر فرق داخل Tencent، مع حركة طلبات الأعمال اليومية الضخمة التي تتجاوز مليار. في الوقت نفسه، قام OTeam أيضًا بتطوير أكثر من عشر ميزات لـ Apache APISIX، بما في ذلك اكتشاف الخدمة، تحويل بروتوكول RPC، والاتصال بمنصة المراقبة.

في الوقت نفسه، ساهم OTeam أيضًا ببعض الميزات القياسية لمجتمع Apache APISIX. حاليًا، اثنان من أعضاء فريق OTeam هم أيضًا أعضاء في PMC لـ Apache APISIX، وقد ساهم OTeam بأكثر من 50 PR للمجتمع. نعتقد أن OTeam سيستمر في التعاون مع مجتمع Apache APISIX في المستقبل.

ميزات OTeam الداخلية

نقاط الألم الداخلية

المسؤولية الأساسية لـ OTeam هي الحفاظ على ميزات Apache APISIX لـ Tencent. دعونا نلقي نظرة على نقاط الألم التي واجهها OTeam.

  • إطار عمل RPC ليس ودودًا للواجهة الأمامية: هناك العديد من المشاريع القديمة داخل Tencent التي تستخدم إطار عمل TARS، فهو لا يدعم بروتوكول HTTP مباشرة مثل TRPC، فهو يدعم فقط بروتوكول TCP التقليدي لإطار عمل RPC، ويستخدم المحتوى المنقول بروتوكول ثنائي محدد. نحتاج إلى الحفاظ على خدمة وسيطة لتحويل هذه الواجهات إلى شكل HTTP + JSON ودود للواجهة الأمامية.
  • تنوع مراكز الخدمة: هناك العديد من مراكز الخدمة في خدمات Tencent الداخلية، مثل CL5، L5، Polaris، إلخ. على الرغم من أننا سنستخدم مركز خدمة واحد تدريجيًا، إلا أننا سنستخدم عدة مراكز خدمة في نفس الوقت خلال هذه الفترة الممتدة. Apache APISIX الأولي لا يدعم هذا.
  • الإنذار: كبوابة، الإنذار ليس اتجاهًا يجب أن تهتم به، ولكن كمكون أساسي، يجب أن يكون الإنذار مكونًا مطلوبًا للفريق. كيفية حل مشكلة الإنذار هي أيضًا نقطة ألم.
  • الأمان: لدى Tencent كمية كبيرة من حركة المرور ومتطلبات الأمان. العديد من المنتجات الموجهة للمستهلك تستخدم OTeam، ويجب أن تواجه عددًا كبيرًا من إساءة استخدام المستخدمين وهجمات الشبكة. الحالات الأكثر شيوعًا هي DDos، إعادة التشغيل، التلاعب بالطلبات، إلخ. هل يمكننا حل هذه المشكلات في طبقة البوابة؟

حل المشكلات

هندسة OTeam

يأتي الرسم البياني أعلاه من تبسيط لحالة تطبيق داخل Tencent. يمكننا رؤية أن العديد من المشكلات التي تم طرحها قد تم حلها في OTeam:

  • تحويل البروتوكول: بناءً على Apache APISIX، يحقق OTeam تحويل بروتوكول TRPC و TARS. أولئك الذين لا يقومون بتنفيذ خدمات HTTP القديمة يمكنهم استخدام مكون التحويل في البوابة مباشرة لتحقيق متطلبات نقل HTTP و RPC دون كتابة خدمات وسيطة.
  • مراكز خدمة متعددة: لقد ساهمنا بهذه الميزة للمجتمع. الإبلاغ لمنصة المراقبة: يستخدم OTeam في Tencent مكونات إضافية للاتصال بمنصات المراقبة. يحتاج المستخدمون فقط إلى إجراء بعض التكوينات، ثم يقوم النظام تلقائيًا بالإبلاغ عن المقاييس، السجلات. بالمناسبة، يمكن للمستخدمين تكوين سياسات الإنذار على منصة المراقبة.
  • منع إعادة التشغيل ومنع التلاعب: ينفذ OTeam مكونات إضافية لمنع إعادة التشغيل ومنع التلاعب، مما يسمح للأعمال الخارجية التي تحتاج إلى هذه القدرات باستخدامها مباشرة لحماية أمان واجهات برمجة التطبيقات الخاصة بهم.

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

الخلاصة

ساعد OTeam فريق الأعمال في حل نقاط الألم الخاصة بهم وتحسين ميزات Apache APISIX داخل Tencent باستمرار، والمضي قدمًا مع تطور المجتمع.

إذا لم يكن لدى فريقك بوابة، يمكنك البحث والتعرف على المزيد حول Apache APISIX ومرحبًا بك للمشاركة في مجتمع Apache APISIX.

Tags: