صباح الخير للجميع!
يسعدنا اليوم أن نقدم لك ترجمة لمقال يتحدث باختصار عن اتجاه تكنولوجي جديد يسمى "شبكة الخدمة". الحل الأكثر إثارة للاهتمام في هذا المجال (في رأينا) هو
Istio ، لكن المقالة المقترحة مثيرة للاهتمام ، أولاً وقبل كل شيء ، من خلال المقارنة الصريحة للتقنيات الحالية من هذا النوع ونظرة عامة عالية المستوى على النموذج بأكمله. قام المؤلف ، توبياس كونزي ، أيضًا بكتابة مقال ثاني أكثر عملية على شبكة الخدمة - طلب للتعبير عما إذا كان الأمر يستحق نشر ترجمته
هذا المنشور هو الأول من اثنين يتحدث عن فوائد شبكات الخدمة. توضح هذه المقالة ماهية شبكة الخدمة وكيف تعمل وما هي الفائدة منها.
الجزء الثاني يستكشف لماذا وأين ومتى تستخدم هذه الشبكات ، وماذا ينتظرنا.
عند تحليل تطبيق ما إلى خدمات microservices ، يتضح بسرعة أن الاتصال بخدمة عبر الشبكة عملية أكثر تعقيدًا وأقل موثوقية مما كان يعتقد في البداية. ما كان من المفترض أن "مجرد عمل" حسب التصميم يجب أن يتم التعبير عنه بوضوح لكل عميل ولكل خدمة. يجب على العملاء اكتشاف محطات الخدمة ، والتأكد من أنها متسقة عبر إصدارات واجهة برمجة التطبيقات ، وتغليف الرسائل وإلغاء حزمها. يحتاج العملاء أيضًا إلى تتبع تنفيذ المكالمات وإدارة مثل هذه العمليات والتقاط الأخطاء وتكرار المكالمات الفاشلة والحفاظ على مهلة إذا لزم الأمر. قد يحتاج العملاء أيضًا إلى التحقق من صحة الخدمات ومكالمات السجل ومعاملات الأدوات. أخيرًا ، يحدث أن يتطابق التطبيق بالكامل مع قواعد
IAM أو متطلبات التشفير أو التحكم في الوصول.
بالطبع ، معظم هذه المشاكل ليست جديدة ، ولدينا لفترة طويلة تقنيات تحت تصرفنا تساعد في تنظيم آليات المراسلة ، على سبيل المثال SOAP و Apache Thrift و gRPC. ولكن ما تم ملاحظته مؤخرًا: التوزيع السريع للحاويات والنمو الهائل المصاحب لمكالمات الخدمة ، ودرجة التحجيم الأفقي وقصر مدة محطات الخدمة المرتبطة بها. عندما يصل التعقيد والهشاشة إلى مستوى جديد ، فهناك رغبة في تغليف اتصالات الشبكة ونقلها إلى مستوى بنية أساسية جديد. يُعرف النهج الأكثر شعبية لتوفير هذا المستوى ، المطبق اليوم ، "شبكة الخدمة".
ما هو بالضبط "شبكة الخدمة"؟
شبكة الخدمة ليست "شبكة خدمة". هذه شبكة من وسطاء واجهة برمجة التطبيقات (الوكلاء) والتي يمكن للخدمات (الصغيرة) الاتصال بها لاستخراج الشبكة بالكامل. كما قال وليام مورجان ، هذه "طبقة بنية أساسية مخصصة توفر اتصالًا آمنًا وسريعًا وموثوقًا بين الخدمات" تساعد شبكات الخدمة على مواجهة التحديات العديدة التي يواجهها المطورون عندما يتعين عليهم تبادل المعلومات مع الأجهزة الطرفية البعيدة. ومع ذلك ، تجدر الإشارة إلى أن مشاكل التشغيل الرئيسية بمساعدة شبكات الخدمة لم يتم حلها.
كيف تعمل شبكات الخدمة؟
بنية شبكة خدمة نموذجية. يتم نشر الوكلاء في طائرة البيانات كأصحاب (جانبي) ، وتقع طائرة التحكم بشكل منفصل.في شبكة خدمة نموذجية ، يتم تعديل الخدمات المنشورة بحيث يكون كل منها مصحوبًا بـ
"رفيق" الوكيل الخاص به. لا تتصل الخدمات مباشرة بالخدمات الأخرى عبر الشبكة ، ولكنها تتحول بدلاً من ذلك إلى رفقاء الوكيل المحليين ، الذين يقومون بدورهم بتغليف تعقيد تبادل المعلومات بين الخدمات. تنفذ مجموعة الوكلاء المترابطة هذه ما يسمى طائرة البيانات.
على العكس من ذلك ، تسمى مجموعة واجهات برمجة التطبيقات والأدوات المستخدمة للتحكم في سلوك البروكسي عبر شبكة الخدمة بالكامل "مستوى التحكم". في مستوى التحكم ، يقوم المستخدمون بتعيين السياسات وتكوين مستوى البيانات ككل.
لتنفيذ شبكة خدمة ، يلزم وجود طائرة بيانات وطائرة تحكم.
أهم اللاعبين: المبعوث ، لينكرد ، إستيو والقنصل
Envoy هو خادم وكيل مفتوح المصدر تم تطويره بواسطة Lyft. واليوم تشكل طائرة بيانات في العديد من شبكات الخدمات ، بما في ذلك Istio. حلت شركة Envoy محل الوكلاء الآخرين بسرعة بفضل واجهة برمجة التطبيقات للتهيئة المريحة ، والتي تتيح للطائرات التحكم ضبط سلوكها في الوقت الفعلي.
Linkerd هو مشروع مفتوح المصدر تدعمه Buoyant ، وفي نفس الوقت ، أول شبكة خدمة. كانت مكتوبة في الأصل في Scala ، مثل
Finagle ، من Twitter ، التي جاءت منها ، ثم اندمجت مع مشروع Conduit خفيف الوزن وأعيد تشغيله كـ
Linkerd 2.0 .
ربما تعد
Istio شبكة الخدمات الأكثر شهرة في عصرنا. تم إطلاقه بشكل مشترك بواسطة Google و IBM و Lyft؛ من المتوقع أن تدخل في النهاية مشروع مؤسسة
Cloud-Native Computing Foundation (CNCF). بالمعنى الدقيق للكلمة ، Istio هي طائرة تحكم ، ومن أجل تشكيل شبكة خدمة ، يجب دمجها مع طائرة البيانات. عادةً ما يستخدم Istio مع Envoy ويعمل بشكل أفضل على Kubernetes.
القنصل هو ظاهرة جديدة نسبيا في النظام البيئي للطائرات السيطرة. يعمل بشكل أفضل مع طبولوجيا تغطي العديد من مراكز البيانات ومتخصصة في اكتشاف الخدمة. يعمل القنصل مع العديد من طائرات البيانات ، ويمكن استخدامه دون إشراك طائرات التحكم الأخرى ، على سبيل المثال ، بدون Istio. دعمه هو HashiCorp.
المزايا الرئيسية والاختلافات في الأولويات
على الرغم من أن مساحة شبكات الخدمة تستمر في التطور ، إلا أن معظم المشاريع ، على ما يبدو ، توصلت بالفعل إلى فكرة المجموعة الرئيسية من الميزات التي يجب دعمها في مثل هذه الشبكة:
- اكتشاف الخدمة : اكتشاف الخدمات والحفاظ على سجلها
- التوجيه : موازنة التحميل الذكية وتوجيه الشبكة ، واختبار أفضل للأداء ، وأنماط النشر التلقائي ، على سبيل المثال ، التكوينات ذات اللون الأزرق والأخضر والكناري
- الاستقرار : إعادة المحاولة ، المهلات ، وقواطع الدوائر الكهربائية
- الأمان : تشفير يستند إلى TLS ، بما في ذلك إدارة المفاتيح
- القياس عن بعد : جمع المقاييس وتتبع معرفات
بالإضافة إلى هذه القدرات (وأحيانًا بناءً عليها) ، هناك أيضًا مستوى أكثر ثراءً من الوظائف التي تبدأ عندها اختلافات خطيرة بين شبكات الخدمات المختلفة حول ما قد يكون ذا قيمة للمهندسين المعماريين والمطورين ومسؤولي أنظمة الخدمة الصغيرة. على سبيل المثال ، يدعم Envoy WebSockets ، لكن Linkerd 2.0 (ليس بعد). بينما يدعم كل من Istio و القنصل طائرات بيانات مختلفة ، يعمل Linkerd فقط من تلقاء نفسه. لدى القنصل طائرة بيانات مدمجة خاصة به ، والتي يمكن استبدالها بأخرى أكثر قوة عندما تصبح مسألة الأداء أولوية. تم تصميم Istio كطائرة تحكم مركزية منفصلة ، في حين يتم توزيع القنصل و Linkerd بالكامل. أخيرًا ، من بين جميع شبكات الخدمة التي تمت مناقشتها أعلاه ، تدعم Istio فقط حقن الأخطاء. هذه مجرد بعض الاختلافات الرئيسية التي يجب مراعاتها إذا كنت تفكر في إدخال مثل هذه الشبكة.
نقد شبكة الخدمة
على الرغم من الشعبية الواضحة والميزات الجذابة الواعدة ، فإن شبكات الخدمة لا تستخدم على نطاق واسع كما هو متوقع. مما لا شك فيه ، هذا يرجع جزئيا إلى حداثة وحقيقة أن هذه الصناعة برمتها لا تزال تأخذ شكلها. ولكن ، عند الحديث عن شبكات الخدمات ، لا يمكنك الاستغناء عن بعض الانتقادات.
تتعلق الشكوك المرتبطة بشبكات الخدمة في المقام الأول بالتعقيد الإضافي الذي تجلبه ، وإنتاجيتها المنخفضة نسبيًا وبعض الفجوات التي تظهر عند العمل مع طبولوجيا من مجموعات متعددة.
شبكات الخدمة عبارة عن منصات غامضة ، في المرحلة الأولية للتنفيذ تتطلب استثمارات جادة في تجميع النظام نفسه ومعداته الآلية. قد يبدو أن إضافة رفيق إلى الحاوية أمر سهل للغاية ، ومع ذلك ، فإن معالجة الفشل وإعادة المحاولة المختصة تتطلب جهودًا هندسية جادة. قد يكون من الصعب تبرير مثل هذه الاستثمارات عند العمل مع التطبيقات الحالية ذات دورة حياة قصيرة ، أو مع تطبيقات سريعة التطور.
بالإضافة إلى ذلك ، يمكن لشبكات الخدمة أن تقلل بشكل خطير من أداء التطبيق مقارنة باستخدام مكالمات الشبكة المباشرة. يصعب في بعض الأحيان تشخيص المشاكل التي تنشأ في هذه الحالة ، بل إنها أكثر صعوبة في التخلص منها. نظرًا لأن معظم شبكات الخدمة تهدف إلى العمل مع تطبيقات الخدمة المصغرة القائمة بذاتها ، وليس في المناظر الطبيعية الكاملة للتطبيقات ذات الصلة ، فإن هذه الشبكات عادةً ما تنفذ دعمًا ضعيفًا للحلول للعديد من المجموعات والمناطق المختلفة.
باختصار ، ليست شبكات الخدمة حلاً سحريًا للمهندسين المعماريين والمشغلين الذين يسعون إلى التكيف بمرونة لتشغيل أسطول متزايد من الخدمات الرقمية. مثل هذه الشبكة هي حل تكتيكي ؛ فهي تمثل تحسينًا تقنيًا "أساسيًا" مصممًا لحل المشكلات ذات الصلة ، خاصة للمطورين. على مستوى الأعمال التجارية ، لن يقوموا بعكس الموقف.
التكنولوجيا ذات الصلة
تتقاطع شبكات الخدمة مع المكونات المعمارية الأخرى ، ولكن بالطبع لا يمكن اختزالها. تتضمن هذه العناصر واجهات برمجة التطبيقات (APIs) أو عبّارات التطبيق أو موازنات التحميل أو وحدات تحكم حركة المرور الواردة والصادرة (الدخول والخروج) أو بوابات تسليم التطبيق. الغرض الرئيسي من بوابة واجهة برمجة التطبيقات (API) هو توفير الخدمات مع الوصول إلى العالم الخارجي ، بينما تعمل كواجهة برمجة تطبيقات (API) واحدة لتوفير وظائف موازنة التحميل والأمن ووظائف الإدارة الأساسية. تقوم وحدات التحكم في حركة المرور الواردة والصادرة بنقل المعلومات بين العناوين غير القابلة للتوجيه في أوركسترا الحاوية والعناوين الموجهة خارجها. أخيرًا ، تشبه وحدات التحكم في تسليم التطبيقات بوابات واجهة برمجة التطبيقات ، لكن تخصصها يكمن في تسريع تسليم تطبيقات الويب ، وليس فقط واجهة برمجة التطبيقات.