يا هبر! أقدم انتباهكم إلى ترجمة المقال автора مات كلاين.
هذه المرة، "أردت وترجمت" وصفًا لكل من مكونات شبكة الخدمة ومستوى البيانات ومستوى التحكم. بدا لي هذا الوصف الأكثر مفهومة وإثارة للاهتمام، والأهم من ذلك أنه يؤدي إلى فهم "هل هو ضروري على الإطلاق؟"
مع تزايد شعبية فكرة "شبكة الخدمة" على مدى العامين الماضيين (المقال الأصلي 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 يُظهر مستوى التحكم "الممتد" لشبكة الخدمة. يتكون من الأجزاء التالية:
- الانسان: لا يزال هناك شخص (نأمل أن يكون أقل غضبًا) يتخذ قرارات عالية المستوى فيما يتعلق بالنظام بأكمله.
- واجهة مستخدم مستوى التحكم: يتفاعل الشخص مع نوع ما من واجهة المستخدم للتحكم في النظام. يمكن أن يكون هذا بوابة ويب أو تطبيق سطر أوامر (CLI) أو واجهة أخرى. باستخدام واجهة المستخدم، يستطيع المشغل الوصول إلى معلمات تكوين النظام العالمي مثل:
- التحكم في النشر، الأزرق/الأخضر و/أو الانتقال التدريجي لحركة المرور
- خيارات المصادقة والترخيص
- مواصفات جدول التوجيه، على سبيل المثال عندما يطلب التطبيق "أ" معلومات حول ما يحدث "/foo".
- إعدادات موازن التحميل، مثل المهلات، وإعادة المحاولة، وإعدادات قطع الدائرة، وما إلى ذلك.
- جدولة عبء العمل: يتم تشغيل الخدمات على البنية التحتية من خلال نوع ما من أنظمة الجدولة/التنسيق، مثل Kubernetes أو Nomad. يكون المجدول مسؤولاً عن تحميل الخدمة مع الوكيل المحلي الخاص بها.
- اكتشاف الخدمة. عندما يبدأ المجدول مثيلات الخدمة ويوقفها، فإنه يقوم بإبلاغ حالة السلامة إلى نظام اكتشاف الخدمة.
- واجهات برمجة تطبيقات تكوين وكيل Sidecar : يقوم الوكلاء المحليون باستخراج الحالة ديناميكيًا من مكونات النظام المختلفة باستخدام نموذج ثابت في النهاية دون تدخل المشغل. النظام بأكمله، الذي يتكون من جميع مثيلات الخدمة قيد التشغيل حاليًا وخوادم الوكيل المحلية، يتقارب في النهاية في نظام بيئي واحد. تعد واجهة برمجة التطبيقات لمستوى البيانات العالمية الخاصة بـ Envoy أحد الأمثلة على كيفية عمل ذلك عمليًا.
بشكل أساسي، الغرض من مستوى التحكم هو تحديد السياسة التي سيتم قبولها في النهاية بواسطة مستوى البيانات. ستقوم طائرات التحكم الأكثر تقدمًا بإزالة المزيد من أجزاء بعض الأنظمة من المشغل وتتطلب تشغيلًا يدويًا أقل، بشرط أن تعمل بشكل صحيح!...
مستوى البيانات ومستوى التحكم. مستوى البيانات مقابل ملخص مستوى التحكم
- مستوى بيانات شبكة الخدمة: يؤثر على كل حزمة/طلب في النظام. مسؤول عن اكتشاف التطبيق/الخدمة، والتحقق من الصحة، والتوجيه، وموازنة التحميل، والمصادقة/الترخيص وإمكانية المراقبة.
- طائرة التحكم في شبكة الخدمة: يوفر السياسة والتكوين لجميع مستويات البيانات قيد التشغيل داخل شبكة الخدمة. لا يلمس أي حزم/طلبات على النظام. يقوم مستوى التحكم بتحويل جميع مستويات البيانات إلى نظام موزع.
المشهد الحالي للمشروع
بعد أن فهمنا الشرح أعلاه، دعونا نلقي نظرة على الوضع الحالي لمشروع شبكة الخدمة.
- طائرات البيانات: لينكيرد، إنجينكس، هابروكسي، إنفوي، ترافيك
- طائرات التحكم: إستيو، نيلسون، سمارت ستاك
بدلاً من الخوض في تحليل متعمق لكل حل من الحلول المذكورة أعلاه، سأتناول بإيجاز بعض النقاط التي أعتقد أنها تسبب الكثير من الارتباك في النظام البيئي في الوقت الحالي.
كان Linkerd واحدًا من أوائل خوادم بروكسي مستوى البيانات لشبكة الخدمة في أوائل عام 2016 وقد قام بعمل رائع في زيادة الوعي والاهتمام بنموذج تصميم شبكة الخدمة. وبعد حوالي 6 أشهر، انضم Envoy إلى Linkerd (على الرغم من أنه كان يعمل مع Lyft منذ أواخر عام 2015). Linkerd وEnvoy هما المشروعان اللذان يتم ذكرهما غالبًا عند مناقشة شبكات الخدمة.
تم الإعلان عن Istio في مايو 2017. أهداف مشروع Istio تشبه إلى حد كبير مستوى التحكم الممتد الموضح في الصورة الشكل 3. مبعوث Istio هو الوكيل الافتراضي. وبالتالي، فإن Istio هو مستوى التحكم، وEnvoy هو مستوى البيانات. في وقت قصير، أثار Istio الكثير من الإثارة، وبدأت طائرات البيانات الأخرى في التكامل كبديل لـ Envoy (أظهر كل من Linkerd وNGINX التكامل مع Istio). إن حقيقة إمكانية استخدام مستويات بيانات مختلفة ضمن نفس مستوى التحكم تعني أن مستوى التحكم ومستوى البيانات ليسا بالضرورة مقترنين بإحكام. يمكن لواجهة برمجة التطبيقات (API)، مثل واجهة برمجة التطبيقات (API) لمستوى البيانات العامة الخاصة بـ Envoy، أن تشكل جسرًا بين جزأين من النظام.
يساعد Nelson وSmartStack في توضيح الفصل بين مستوى التحكم ومستوى البيانات. يستخدم Nelson Envoy كوكيل له ويقوم ببناء مستوى تحكم موثوق به لشبكة الخدمة استنادًا إلى مكدس HashiCorp، أي. البدوي ، الخ. ربما كان SmartStack هو الأول من موجة جديدة من شبكات الخدمة. يقوم SmartStack ببناء مستوى تحكم حول HAProxy أو NGINX، مما يوضح القدرة على فصل مستوى التحكم عن شبكة الخدمة عن مستوى البيانات.
تكتسب بنية الخدمات الصغيرة مع شبكة الخدمة المزيد والمزيد من الاهتمام (بحق!)، وبدأ المزيد والمزيد من المشاريع والموردين في العمل في هذا الاتجاه. على مدى السنوات القليلة المقبلة، سنرى الكثير من الابتكارات في كل من مستوى البيانات ومستوى التحكم، بالإضافة إلى المزيد من الخلط بين المكونات المختلفة. في نهاية المطاف، يجب أن تصبح بنية الخدمات الصغيرة أكثر شفافية وسحرًا (؟) بالنسبة للمشغل.
نأمل أقل وأقل غضبا.
الماخذ الرئيسية
- تتكون شبكة الخدمة من جزأين مختلفين: مستوى البيانات ومستوى التحكم. كلا المكونين مطلوبان، وبدونهما لن يعمل النظام.
- الجميع على دراية بطائرة التحكم، وفي هذه المرحلة، يمكن أن تكون أنت طائرة التحكم!
- تتنافس جميع مستويات البيانات مع بعضها البعض على الميزات والأداء وقابلية التكوين وقابلية التوسعة.
- تتنافس جميع مستويات التحكم مع بعضها البعض في الميزات وقابلية التكوين والتوسعة وسهولة الاستخدام.
- يمكن أن يحتوي مستوى تحكم واحد على التجريدات وواجهات برمجة التطبيقات الصحيحة بحيث يمكن استخدام مستويات بيانات متعددة.
المصدر: www.habr.com