مبعوث. 1 المقدمة

تحيات! هذا مقال قصير يجيب على الأسئلة: "ما هو المبعوث؟"، "لماذا هو مطلوب؟" و"من أين تبدأ؟".

ما هذا

Envoy عبارة عن موازن L4-L7 مكتوب بلغة C++، ويركز على الأداء العالي والتوافر. من ناحية، يعد هذا بطريقة ما نظيرًا لـ nginx و haproxy، ويمكن مقارنتهما في الأداء. من ناحية أخرى، فهو أكثر توجها نحو بنية الخدمات الصغيرة ولديه وظائف ليست أسوأ من الموازنات في Java و Go، مثل Zuul أو Traefik.

جدول المقارنة لـ haproxy/nginx/envoy، لا يدعي أنه الحقيقة المطلقة، ولكنه يعطي صورة عامة.

NGINX
haproxy
مبعوث
ترافيك

النجوم على جيثب
11.2 ك/مرآة
1.1 ك/مرآة
12.4k
27.6k

كتبت في
C
C
C + +
go

API
لا
المقبس فقط/ادفع
طائرة بيانات/سحب
سحب

الفحص الصحي النشط
لا
نعم
نعم
نعم

تتبع مفتوح
البرنامج المساعد الخارجي
لا
نعم
نعم

JWT
البرنامج المساعد الخارجي
لا
نعم
لا

تمديد
لوا / سي
لوا / سي
لوا/C++
لا

لماذا

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

• الارتداد ثابت.

الحقيقة هي أنه في الوقت الحالي مبعوث لا يوجد دعم للتخزين المؤقت. رجال جوجل يحاولون هذا لإصلاح. سيتم تنفيذ الفكرة مرة واحدة مبعوث جميع التفاصيل الدقيقة (رؤوس حديقة الحيوان) الخاصة بامتثال RFC، ولتطبيقات محددة، تشكل واجهة. لكن في الوقت الحالي، لم يصل حتى إلى مرحلة ألفا، فالهندسة المعمارية قيد المناقشة، PR مفتوح (بينما كنت أكتب مقالة عن العلاقات العامة، تجمدت العلاقات العامة، لكن هذه النقطة لا تزال ذات صلة).

في الوقت الحالي، استخدم nginx للإحصائيات.

• التكوين الثابت.

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

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

عادةً ما يتم تنفيذ سيناريوهات نشر Canary وb/g وغير ذلك الكثير فقط في تكوين ديناميكي. أنا لا أقول أن هذا لا يمكن أن يتم بشكل ثابت، كلنا نفعل ذلك. ولكن لهذا تحتاج إلى ارتداء عكازين في أي من الموازنات مبعوث بما فيها.

المهام التي لا غنى للمبعوث عنها:

• موازنة حركة المرور في الأنظمة المعقدة والديناميكية. يتضمن ذلك شبكة الخدمة، ولكنها ليست بالضرورة الشبكة الوحيدة.
• الحاجة إلى وظيفة التتبع الموزعة أو الترخيص المعقد أو الوظائف الأخرى المتوفرة في مبعوث خارج الصندوق أو تم تنفيذه بسهولة، ولكن في nginx/haproxy يجب أن تكون محاطًا بـ lua والمكونات الإضافية المشكوك فيها.

كلاهما، إذا لزم الأمر، يوفران أداءً عاليًا.

كيف يعمل هذا؟

يتم توزيع Envoy في ثنائيات فقط كصورة عامل إرساء. تحتوي الصورة بالفعل على مثال للتكوين الثابت. لكننا مهتمون به فقط لفهم الهيكل.

Envoy.yaml التكوين الثابت

static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address:
        protocol: TCP
        address: 0.0.0.0
        port_value: 10000
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match:
                  prefix: "/"
                route:
                  host_rewrite: www.google.com
                  cluster: service_google
          http_filters:
          - name: envoy.router
  clusters:
  - name: service_google
    connect_timeout: 0.25s
    type: LOGICAL_DNS
    # Comment out the following line to test on v6 networks
    dns_lookup_family: V4_ONLY
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: service_google
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: www.google.com
                port_value: 443
    transport_socket:
      name: envoy.transport_sockets.tls
      typed_config:
        "@type": type.googleapis.com/envoy.api.v2.auth.UpstreamTlsContext
        sni: www.google.com

التكوين الديناميكي

ما هي المشكلة التي نبحث عن حل لها؟ لا يمكنك فقط إعادة تحميل تكوين موازن التحميل تحت التحميل، ستظهر مشاكل "صغيرة":

• التحقق من صحة التكوين.

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

• اتصالات طويلة الأمد.

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

• فحوصات صحية نشطة.

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

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

ترتيب مبعوث (من الملف أعلاه) يحتوي على الكيانات التالية:

• مستمع - المستمع معلق على IP/منفذ محدد
• استضافة افتراضية - المضيف الظاهري حسب اسم المجال
• الطريق - قاعدة التوازن
• كتلة — مجموعة من المنبع مع موازنة المعلمات
• نقطة النهاية - عنوان المثيل الأولي

يمكن ملء كل من هذه الكيانات بالإضافة إلى بعض الكيانات الأخرى ديناميكيًا؛ ولهذا الغرض، يحدد التكوين عنوان الخدمة التي سيتم تلقي التكوين منها. يمكن أن تكون الخدمة REST أو gRPC، ويفضل gRPC.

تتم تسمية الخدمات على التوالي: LDS، VHDS، RDS، CDS وEDS. يمكنك الجمع بين التكوين الثابت والديناميكي، مع تقييد أنه لا يمكن تحديد مورد ديناميكي في مورد ثابت.

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

التكوين يأخذ الشكل التالي:

Envoy.yaml التكوين الديناميكي

dynamic_resources:
  ads_config:
    api_type: GRPC
    grpc_services:
      envoy_grpc:
        cluster_name: xds_clr
  cds_config:
    ads: {}
static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address:
        protocol: TCP
        address: 0.0.0.0
        port_value: 10000
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager
          stat_prefix: ingress_http
          rds:
            route_config_name: local_route
            config_source:
              ads: {}
          http_filters:
          - name: envoy.router
  clusters:
  - name: xds_clr
    connect_timeout: 0.25s
    type: LOGICAL_DNS
    dns_lookup_family: V4_ONLY
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: xds_clr
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: xds
                port_value: 6565

عند الركض مبعوث باستخدام هذا التكوين، سيتم الاتصال بسطح التحكم ومحاولة طلب تكوين RDS وCDS وEDS. يتم وصف كيفية حدوث عملية التفاعل هنا.

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

• دفق gRPC واحد لجميع أنواع الموارد، ويتم إرسال الحالة الكاملة للمورد.
• تيارات منفصلة، ​​حالة كاملة.
• تيار واحد، حالة تزايدية.
• تيارات منفصلة، ​​​​حالة تزايدية.

يتيح لك نظام xDS التزايدي تقليل حركة المرور بين مستوى التحكم و مبعوث، وهذا مناسب للتكوينات الكبيرة. لكنه يعقد التفاعل؛ يحتوي الطلب على قائمة بالموارد اللازمة لإلغاء الاشتراك والاشتراك.

يستخدم مثالنا ADS - دفق واحد لـ RDS وCDS وEDS والوضع غير التزايدي. لتمكين الوضع المتزايد، تحتاج إلى تحديد api_type: DELTA_GRPC

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

تسخين

في مبعوث عند بدء التشغيل أو عند تلقي تكوين جديد من مستوى التحكم، يتم إطلاق عملية تسخين الموارد. وهي مقسمة إلى إحماء المستمع والإحماء العنقودي. يتم إطلاق الأول عندما تكون هناك تغييرات في RDS/LDS، والثاني عند CDS/EDS. هذا يعني أنه إذا تغيرت المنبع فقط، فلن يتم إعادة إنشاء المستمع.

أثناء عملية الإحماء، من المتوقع وجود موارد تابعة من مستوى التحكم أثناء المهلة. في حالة انتهاء المهلة، لن تكون التهيئة ناجحة ولن يبدأ المستمع الجديد في الاستماع على المنفذ.
ترتيب التهيئة: EDS، CDS، الفحص الصحي النشط، RDS، LDS. مع تمكين عمليات التحقق من الصحة النشطة، لن تنتقل حركة المرور إلى المنبع إلا بعد إجراء فحص صحي واحد ناجح.

إذا تمت إعادة إنشاء المستمع، فسينتقل المستمع القديم إلى حالة DRAIN وسيتم حذفه بعد إغلاق جميع الاتصالات أو انتهاء المهلة --drain-time-s، الافتراضي 10 دقائق.

أن تستمر.

المصدر: www.habr.com