مرحبا يا هبر! أقدم لكم ترجمة المقال "طائرة بيانات شبكة الخدمة مقابل طائرة التحكم" لمات كلاين .



هذه المرة أردت وترجمت وصف كل من مكونات شبكة الخدمة وطائرة البيانات وطائرة التحكم. بدا لي هذا الوصف أكثر المفهوم وإثارة للاهتمام ، والأهم من ذلك أنه يؤدي إلى فهم "هل هذا ضروري؟"

نظرًا لأن فكرة "شبكة الخدمة" أصبحت أكثر شيوعًا على مدار العامين الماضيين (المقالة الأصلية 10 أكتوبر 2017) ، وزاد عدد المشاركين في الفضاء ، فقد رأيت زيادة متكافئة في الارتباك بين المجتمع التقني بأكمله فيما يتعلق بكيفية المقارنة وعلى النقيض من الحلول المختلفة.

يتم وصف الموقف بشكل أفضل في السلسلة التالية من التغريدات التي كتبت في يوليو:

الارتباك مع شبكة الخدمة (شبكة الخدمة) رقم 1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. لا أحد منهم يساوي Istio. Istio هو شيء مختلف تماما. 1 /

الأول هو مجرد طائرات البيانات. هم أنفسهم لا يفعلون شيئًا. انهم بحاجة الى ضبطها لشيء أكثر من ذلك. 2 /

Istio هو مثال على طائرة التحكم التي تربط الأجزاء ببعضها. هذه طبقة مختلفة. / النهاية

ذكرت التغريدات السابقة العديد من المشاريع المختلفة (Linkerd ، NGINX ، HAProxy ، Envoy و Istio) ، ولكن الأهم من ذلك ، قدمت المفاهيم العامة لطائرة البيانات وشبكة الخدمة وطائرة التحكم. في هذا المنشور ، سأرجع خطوة إلى الوراء وأقول ما أقصده بمصطلحي "طائرة البيانات" و "طائرة التحكم" على مستوى عالٍ للغاية ، وبعد ذلك سوف أخبر كيف ترتبط المصطلحات بالمشاريع المذكورة في التغريدات.

ما هي شبكة الخدمة (حقا)؟

الشكل 1: نظرة عامة على شبكة الخدمة

يوضح الشكل 1 مفهوم شبكة الخدمة على المستوى الأساسي. هناك أربع مجموعات خدمة (م). يرتبط كل مثيل خدمة بخادم وكيل محلي. يتم نقل كل حركة مرور الشبكة (HTTP ، REST ، gRPC ، Redis ، وما إلى ذلك) من مثيل تطبيق واحد من خلال خادم وكيل محلي إلى مجموعات الخدمة الخارجية المقابلة. وبالتالي ، لا يعرف مثيل التطبيق عن الشبكة ككل ويعرف فقط وكيله المحلي. في الواقع ، كانت شبكة النظام الموزع بعيدة عن الخدمة.

طائرة البيانات

في شبكة خدمة ، يؤدي خادم وكيل موجود محليًا للتطبيق المهام التالية:

• اكتشاف الخدمة ما هي الخدمات / الخدمات / التطبيقات المتاحة للتطبيق الخاص بك؟
• فحص الصحة هل مثيلات الخدمة التي يتم إرجاعها بواسطة اكتشاف الخدمة جاهزة وجاهزة لقبول حركة مرور الشبكة؟ يمكن أن يشمل ذلك كلاً من الفحوصات الصحية النشطة (على سبيل المثال ، فحص / فحص فحص الصحة) والسلبية (على سبيل المثال ، استخدام 3 أخطاء متتالية 5xx كإشارة إلى الحالة الصحية غير الصحية للخدمة).
• توجيه (التوجيه). بعد تلقي طلب "/ foo" من خدمة REST ، إلى أي مجموعة خدمة يجب إرسال الطلب؟
• تحميل موازنة بعد تحديد مجموعة خدمة أثناء التوجيه ، إلى أي مثيل للخدمة يجب إرسال الطلب؟ ما مهلة؟ ما الإعدادات لكسر الدائرة؟ إذا فشل الطلب ، فهل يتكرر ذلك؟
• المصادقة والترخيص بالنسبة للطلبات الواردة ، هل يمكن تعريف / تفويض خدمة الاتصال بطريقة تشفير باستخدام mTLS أو آلية أخرى؟ إذا تم تحديده / التصريح به ، فهل يُسمح بالاتصال بالعملية المطلوبة (نقطة النهاية) في الخدمة أو هل يجب رد استجابة غير مصادقة؟
• قابلية الملاحظة (قابلية الملاحظة). لكل طلب ، يجب إنشاء إحصائيات مفصلة وسجلات / سجلات وبيانات التتبع الموزعة حتى يتمكن المشغلون من فهم مشاكل تدفق المرور الموزعة وتصحيح الأخطاء عند ظهورها.

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

طائرة التحكم

شبكة التجريد التي يوفرها الوكيل المحلي في مستوى البيانات سحرية (؟). ومع ذلك ، كيف يعرف الوكيل فعليًا المسار "/ foo" إلى الخدمة B؟ كيف يمكن استخدام بيانات اكتشاف الخدمة التي يتم ملؤها مع طلبات الوكيل؟ كيف يتم تكوين موازنة التحميل ، والوقت ، وكسر الدارات ، وما إلى ذلك؟ كيفية نشر التطبيق باستخدام طريقة الأزرق / الأخضر (الأزرق / الأخضر) أو طريقة النقل التدريجي لحركة المرور؟ من الذي يقوم بإعداد إعدادات المصادقة والترخيص على مستوى النظام؟

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

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


الشكل 2: طائرة التحكم البشرية

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

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


الشكل 3: طائرة مراقبة شبكة خدمة متقدمة

يوضح الشكل 3 مستوى التحكم "الممتد" لشبكة الخدمة. يتكون من الأجزاء التالية:

• الإنسان : لا يزال هناك شخص (نأمل أن يكون أقل غضبًا) يتخذ قرارات عالية المستوى بشأن النظام بأكمله.
• وحدة التحكم UI : يتفاعل الشخص مع نوع من واجهة المستخدم للتحكم في النظام. يمكن أن يكون بوابة ويب أو تطبيق سطر أوامر (CLI) أو واجهة أخرى. باستخدام واجهة المستخدم ، يمكن للمشغل الوصول إلى معلمات تكوين النظام العالمية مثل:
  
  • إدارة النشر ، الأزرق / الأخضر و / أو مع نقل حركة المرور تدريجيا
  • إعدادات المصادقة والترخيص
  • مواصفات جدول التوجيه ، على سبيل المثال ، عندما يطلب التطبيق A معلومات حول "/ foo" ، ماذا يحدث
  • قم بتحميل إعدادات موازن ، مثل المهلات ، وإعادة المحاولة ، ومعلمات قطع الدائرة ، إلخ
• جدولة عبء العمل : يتم إطلاق الخدمات في البنية التحتية من خلال نوع معين من نظام التخطيط / التنسيق ، مثل Kubernetes أو Nomad. المجدول مسؤول عن تحميل الخدمة مع خادم البروكسي المحلي.
• اكتشاف الخدمة عندما يبدأ المجدول ويوقف مثيلات الخدمة ، فإنه يبلغ عن الحالة الصحية لنظام اكتشاف الخدمة.
• واجهات برمجة التطبيقات لتهيئة وكيل Sidecar : تستخرج الوكلاء المحليون الحالة بشكل ديناميكي من مختلف مكونات النظام وفقًا للنموذج "المتسق في نهاية المطاف" دون تدخل المشغل. يتحول النظام بأكمله ، الذي يتألف من جميع مثيلات الخدمات الجاري تشغيلها حاليًا ، إلى نظام بيئي واحد. واجهة برمجة تطبيقات بيانات Envoy هي مثال على كيفية عمل ذلك في الممارسة العملية.

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

طائرة البيانات وطائرة التحكم. طائرة البيانات مقابل ملخص طائرة التحكم

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

المشهد الحالي للمشروع

بعد الاطلاع على الشرح أعلاه ، دعنا ننظر إلى الوضع الحالي لمشروع "شبكة الخدمة".

• طائرات البيانات : Linkerd ، NGINX ، HAProxy ، Envoy ، Traefik
• طائرات التحكم : Istio ، نيلسون ، SmartStack

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

في بداية عام 2016 ، كان Linkerd واحدًا من أول خوادم البروكسي لمستوى البيانات لشبكة الخدمة وقام بعمل رائع في زيادة الوعي وزيادة الاهتمام بنموذج تصميم شبكة الخدمة. بعد حوالي 6 أشهر من ذلك ، انضم Envoy إلى Linkerd (على الرغم من أنه كان يعمل مع Lyft منذ نهاية عام 2015). Linkerd و Envoy هما من المشاريع التي يتم ذكرها غالبًا عند مناقشة شبكات الخدمات.

تم الإعلان عن Istio في مايو 2017. تتشابه أهداف مشروع Istio مع مستوى التحكم الممتد الموضح في الشكل 3 . مبعوث Istio هو الخادم الوكيل الافتراضي. وبالتالي ، Istio هي طائرة التحكم ، والمبعوث هو طائرة البيانات. في وقت قصير ، تسبب Istio في الكثير من الاضطرابات ، وبدأت طائرات البيانات الأخرى تتكامل كبديل لـ Envoy (أثبت كل من Linkerd و NGINX التكامل مع Istio). حقيقة أنه يمكنك استخدام مستويات بيانات مختلفة في نفس مستوى التحكم تعني أن مستوى التحكم ومستوى البيانات لا يرتبطان بالضرورة ارتباطًا وثيقًا. يمكن أن تشكل واجهة برمجة التطبيقات (API) مثل واجهة برمجة تطبيقات بيانات Universal Envoy جسراً بين جزأين من النظام.

يساعد كل من Nelson و SmartStack في توضيح فصل طائرة التحكم ومستوى البيانات. يستخدم نيلسون Envoy كوكيله ويقوم ببناء طائرة تحكم موثوقة لشبكة الخدمة تعتمد على مكدس HashiCorp ، أي البدوي الخ ربما يكون SmartStack أول موجة جديدة من شبكات الخدمة. يُشكل SmartStack مستوى تحكم حول HAProxy أو NGINX ، مما يدل على القدرة على فصل طائرة تحكم عن شبكة خدمة ومستوى بيانات.

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

النقاط الرئيسية (الوجبات الرئيسية)

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