كيف تستخدم Zoom نظام APISIX Ingress في خط أنابيب التوصيل المستمر لديها؟

الخلفية

في السنوات الأخيرة، ظهرت العديد من برامج المؤتمرات عبر الإنترنت الشهيرة مع تطور الاجتماعات عبر الإنترنت والعمل عن بُعد. ومن أبرزها Zoom، الذي أصبح أداة اجتماعات شائعة للعمل من المنزل، والتعليم عبر الإنترنت، والسيناريوهات الاجتماعية. حيث يضم 350 مليون مشارك يومي في الاجتماعات ونحو 470,000 عميل أعمال مدفوع يستخدمون المنصة. علاوة على ذلك، تُظهر البيانات الحديثة أن عدد الدقائق المستخدمة لتسهيل الاجتماعات قد وصل إلى أكثر من 3.3 تريليون دقيقة سنويًا.

ومع ذلك، مثل غيرها من شركات SaaS والإنترنت، واجهت Zoom تحديات تقنية مع توسع أعمالها بسرعة.

• عدد كبير من الخدمات الصغيرة (Microservices): بسبب النمو السريع لأعمال Zoom وفرقها، هناك حاجة لتسليم أكثر من 100 خدمة خلفية. ومع ذلك، يصعب إدارة عدد كبير من الخدمات الصغيرة بكفاءة.

• بيئات نشر متنوعة: غالبًا ما تواجه شركات SaaS سيناريوهات حيث يجب على العملاء النشر على سحابات مخصصة، وسحابات خاصة، وسحابات متعددة. نظرًا لأن خدمات أعمال Zoom منتشرة في جميع أنحاء العالم، فهناك تحديات تقنية مع عدد كبير من بيئات السحابة الهجينة.

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

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

فيما يلي الأسباب التفصيلية التي جعلت Zoom لا تستمر في اختيار هذه الأدوات مفتوحة المصدر السابقة.

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

بعد عدة جولات من المقارنة والتحقق، اختارت Zoom في النهاية APISIX Ingress Controller لدعم خط أنابيب التسليم المستمر الجديد.

Apache APISIX Ingress Controller

ما هو Apache APISIX Ingress Controller؟

Apache APISIX Ingress Controller هو متحكم دخول سحابي يستخدم Apache APISIX كطائرة بيانات لحمل حركة المرور ويوسع وظائف Kubernetes باستخدام CRD (تعريف الموارد المخصصة). وهو مسؤول عن التفاعل مع خادم Kubernetes API، وتطبيق التحكم في الوصول القائم على الأدوار (RBAC)، ومراقبة التغييرات، وتنفيذ تحويل الكائنات داخل متحكم الدخول، ومقارنة التغييرات، ثم مزامنتها مع Apache APISIX. علاوة على ذلك، يمكنه دعم الموارد المخصصة، بما في ذلك APISIX Route، وAPISIX Upstream، وغيرها من مداخل Kubernetes الأصلية، للتحكم في حركة المرور الخارجية للوصول إلى الخدمات الموزعة في Kubernetes.

فيما يلي مخطط توقيت APISIX Ingress Controller.

لماذا اختارت Zoom APISIX Ingress Controller؟

وفقًا للخلفية المذكورة أعلاه، يطرح السؤال التالي: ما نوع خط أنابيب التسليم المستمر الذي تريد Zoom بناؤه، وكيف تعتمد APISIX Ingress لإنشاء خط أنابيب التسليم المستمر الأساسي؟

كانت Zoom تستخدم سابقًا NGINX كبوابة API. ومع ذلك، مع التطور السريع للأعمال وزيادة الخدمات الصغيرة، أصبحت قيود حل NGINX الحالي أكثر وضوحًا.

يجب على الفرق المختلفة صيانة NGINX بشكل منفصل، وآلاف الأسطر من ملفات تكوين NGINX تجعل الصيانة صعبة. بالإضافة إلى ذلك، لا يمكن لـ NGINX التوسع بسرعة عند نشر العديد من الأسطر على خادم السحابة. حول طريقة إعادة تحميل NGINX، يمكنك التحقق من هذه المدونة. بدأت أعمال Zoom في التطور نحو متحكم الدخول (Ingress Controller).

قام فريق بوابة API بالبحث في بعض الحلول مفتوحة المصدر. بعد محاكاة الهجرة وتحليل تكوين الأعمال الفعلي في NGINX وعدد كبير من اختبارات الأداء ومقارنة النظام البيئي للإضافات، اختارت Zoom في النهاية مشروع APISIX Ingress Controller التابع لمؤسسة Apache Software Foundation، لاستكشاف بوابة سحابية أكثر تقدمًا.

مع الأخذ في الاعتبار سيناريوهات أعمالها، ركزت Zoom بشكل أكبر على الجزأين التاليين، والذي يمكن لـ APISIX Ingress تلبيتهما.

• أمان البيانات: تأخذ Zoom خصوصية العملاء وأمان الخدمة على محمل الجد؛ وبالتالي، يتم استخدام مصادقة mTLS والتحقق منها على نطاق واسع في غرف الاجتماعات والمكالمات الهاتفية عبر الإنترنت. ومع ذلك، يمكن للعديد من بوابات API المماثلة تقديم مثل هذه الخدمة فقط في إصدارها المؤسسي، بينما توفر APISIX Ingress إمكانية كبيرة وملاءمة لتحقيق هذا الهدف.

• استقرار الخدمة: تتطلب خدمات Zoom الخلفية نشر Multi-AZ (مناطق توفر متعددة) لتوفير توفر عالي عبر مناطق مختلفة. بشكل عام، يتم وضع الأعمال في مركز بيانات آخر. إذا حدث خطأ في مركز البيانات الأصلي، يجب تحويل حركة مرور العميل إلى مركز بيانات آخر، حيث يمكن لـ APISIX Ingress تلبية هذا المطلب بنجاح.

ميزات Apache APISIX Ingress Controller

باستخدام Apache APISIX كطائرة بيانات لحمل حركة مرور الأعمال، يرث Apache APISIX Ingress Controller المزايا التالية من Apache APISIX.

• أداء عالي واستقرار: كبوابة API ديناميكية عالية الأداء مفتوحة المصدر، يتمتع Apache APISIX بمرونة واستقرار في أدائه، ويستخدم في العديد من سيناريوهات حركة المرور الكبيرة للشركات.

• مجتمع نشط: كأحد أفضل مشاريع بوابات API مفتوحة المصدر وأكثرها نشاطًا، يمتلك Apache APISIX مجتمعًا نشطًا وحافظ على معدل نمو ممتاز منذ اليوم الأول.

• نظام بيئي غني: يدعم Apache APISIX بروتوكولات L7، بما في ذلك HTTP(S)، وHTTP2، وDubbo، وبروتوكول IoT MQTT، إلخ. بالإضافة إلى ذلك، يدعم APISIX بروتوكولات L4 مثل TCP/UDP. علاوة على ذلك، يدعم Apache APISIX 3.0 ARM64 بالكامل.

• إضافات متعددة: هناك ما يقرب من 100 إضافة تم إصدارها من APISIX الرسمية التي يمكن للمستخدمين استخدامها بسحب بسيط. توفر إعادة التحميل الساخن والتنسيق الديناميكي للإضافات راحة كبيرة للمستخدمين.

بالإضافة إلى ذلك، يتمتع APISIX Ingress Controller أيضًا بالمزايا الفريدة التالية:

• توافق جيد: يدعم APISIX Ingress Controller إصدارات متعددة من موارد الدخول ويمكن أن يكون متوافقًا مع إصدارات Kubernetes المختلفة.

• تحديث ديناميكي: لا حاجة لإعادة تحميل الخدمة عند تعديل المسارات، والشهادات، والتكوينات الأخرى، مما يضمن تشغيل سلس للأعمال.

• توسيع مرن: نظرًا لأن APISIX Ingress Controller يعتمد على هيكل يفصل بين طائرة التحكم وطائرة البيانات، يمكن توسيع مجموعة طائرة البيانات لـ Apache APISIX بشكل مستقل دون توسيع APISIX Ingress Controller.

• ودية للعمليات والصيانة: في الهيكل الحالي، يمكن للمستخدمين اختيار نشر مجموعة طائرة البيانات APISIX في مجموعة Kubernetes أو بيئة الأجهزة العارية الفعلية وفقًا للوضع الفعلي. علاوة على ذلك، بسبب الفصل الهيكلي لـ APISIX ingress، تحمل APISIX على طائرة البيانات حركة المرور بينما يكون APISIX ingress controller مكون طائرة التحكم. لذلك، لن يؤثر فشل APISIX Ingress Controller على حركة مرور الأعمال.

بعد الانتهاء من اختيار البوابة، واجه فريق بوابة API تحديًا جديدًا: كيفية ترحيل تكوين بوابة API الأصلية لمئات الخدمات إلى APISIX Ingress؟ كان فريق البنية التحتية في Zoom يقوم بتطوير خط أنابيب التسليم المستمر، مما يمكن أن يقلل بشكل كبير من تكلفة الترحيل للتحويل من nginx.conf وتكوينات Ingress الأخرى إلى APISIX Ingress.

عملية ووظائف بناء خط أنابيب التسليم المستمر

خط أنابيب التسليم المستمر لـ Zoom

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

هناك ستة أجزاء في خط أنابيب التسليم المستمر:

1. الإعداد: إعداد الموارد المحددة مسبقًا، بما في ذلك البنية التحتية، والبرمجيات الوسيطة، وموارد الخدمات السحابية، إلخ؛

2. التكوين: إعداد ملفات التكوين والمفاتيح المطلوبة للتطبيق؛

3. النشر: استخدام K8s للنشر في سيناريوهات السحابة الأصلية (بما في ذلك معلومات الحاويات، وصور الحاويات، والمعلمات، والإصدارات، والنسخ)؛

4. الوصول: إنشاء خدمة Kubernetes وتكوين قواعد التوجيه لـ Apache APISIX Ingress تلقائيًا إذا كان النشر يتطلب وصولاً خارجيًا؛

5. المراقبة: تنفيذ تكوينات متعلقة بالمراقبة، مثل المراقبة، والإنذارات، والسجلات، وتحليل التتبع؛

6. التوسيع: الإعلان عن قواعد التوسيع الديناميكي لـ KEDA (التوسيع التلقائي القائم على الأحداث في Kubernetes) من خلال مقاييس المراقبة.

كيفية اعتماد APISIX Ingress في خط الأنابيب

إدارة المشروع

يركز مديرو المشاريع بشكل أكبر على التكرارات البحثية والتطويرية وكيفية إدارة تقدم الإصدارات التكرارية وكفاءة الموظفين على الجدول الزمني المقابل للتكرارات. تستخدم Zoom داخليًا سير عمل GitOps لبناء تكوين بوابة API في نموذج تسليم التطبيقات. في هذا النموذج، يتم دمج تعريف قواعد توجيه APISIX مع "النشر" وغيرها من الروابط، وتسليم التحكم في التغيير إلى GitHub. مع إنشاء ودمج فروع GitHub، يحقق خط الأنابيب توافقًا زمنيًا بين إصدار التطبيق وتكوين البوابة والتراجع.

# مقتطف من كود خط أنابيب CD لـ Zoom في مستودع Git
deploy:
  type: Deployment
  replicas: ~{ replicas, 2 }
  version: "latest"
  containers:
    - name: my-app
      image: "busybox"
      command: "echo 'Demo' && sleep 99d"
access:
  - protocol: https
    host: my-domain.my-org.com
    cert: my-tls-cert
    apisix:
      routes:
        http:
          - name: my-api
            authentication:
              # ......
            match:
              paths:
                - /my-api/*

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

تطوير التطبيقات

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

من الأكواد المذكورة أعلاه، يمكننا أن نرى أن المطورين يحتاجون فقط إلى تعريف Authentication و Match في خط أنابيب التسليم المستمر هذا. لا يحتاجون إلى معرفة المنطق الأساسي:

• أولاً، ترجمته إلى Kubernetes Deployment و Service.
• ثم، استدعاء واجهة برمجة التطبيقات للنظام الأساسي للتحقق من صحة المسار.
• أخيرًا، ترجمته إلى كائنات ApisixRoute.

يوفر دمج تكوين APISIX وسير عمل خط أنابيب التسليم المستمر طريقة أكثر توفيرًا للجهد للمطورين.

إدارة البيئة

غالبًا ما تحدث متطلبات إدارة ومراقبة البيئة المعقدة في سيناريوهات toB، ويجب مراعاة قضايا التسليم في بعض سيناريوهات السحابة الخاصة، والسحابة المخصصة، والسحابة الهجينة.

تم تنفيذ بعض تكوينات APISIX ingress لتلبية متطلبات حجب الاختلافات البيئية. بهذه الطريقة، يمكن لمديري النظام التحكم بشكل شامل في الاختلافات في بعض البيئات غير المتجانسة. جميع الخدمات الموزعة في البيئة فعالة، مما يتجنب العبء المعرفي وعمليات النشر الخاصة الناتجة عن الاختلافات البيئية لمطوري التطبيقات والعمليات. على سبيل المثال، يمكن لـ Zoom استخدام التكوين المخصص لتعطيل التتبع لبعض البيئات، وتحويل كائنات ApisixRoute إلى كائنات Ingress الأصلية وشرح NGINX Ingress، واستخدام صور مختلفة لسحب الأسرار.

علاوة على ذلك، يلزم عزل متعدد المستأجرين عند استخدام عدة خطوط أعمال لبيئة APISIX. يوفر APISIX Ingress محدد Annotation الذي يمكّن كائنات ApisixRoute المختلفة من أن يتم التقاطها بواسطة مثيلات مختلفة من APISIX Ingress Controller.

إدارة البنية التحتية

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

يوفر كل إضافة من خط الأنابيب عناصر تكوين لمهندسي البنية التحتية. في الإضافة ingress-apisix، هناك خاصية defaultPlugins.

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

الخلاصة

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

بالإضافة إلى ذلك، أطلق Apache APISIX Ingress رسميًا الإصدار V1.5 في أغسطس 2022، والذي يوحد اقتراح جميع إصدارات API للموارد ويرفع جميع إصدارات CRD API إلى V2. في الوقت نفسه، يدعم معظم موارد Gateway API. مكّن Apache APISIX Ingress موارد Ingress من استخدام أي إضافات APISIX عن طريق إضافة Annotation جديد "k8s.apisix.apache.org/plugin-config-name" إلى موارد Ingress. بهذه الطريقة، سيتم زيادة سهولة استخدام APISIX Ingress Controller بشكل كبير وتقليل التكلفة للمستخدمين للهجرة من متحكمات الدخول الأخرى إلى APISIX Ingress Controller.

لمزيد من المعلومات، يرجى التحقق من Apache APISIX Ingress V1.5.