ما هو Service Mesh؟

مقدمة عن Service Mesh

Service Mesh هي بنية تحتية قابلة للتكوين تُستخدم لإدارة الاتصالات بين الخدمات في أنظمة الخدمات المصغرة. تهدف إلى معالجة حركة المرور بين الخدمات المصغرة، والتي تُعرف أيضًا بحركة المرور الشرقية-الغربية.

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

Service Mesh تشبه TCP/IP بين الخدمات المصغرة، حيث تعالج وظائف الاتصال بين الخدمات مثل المكالمات الشبكية، الحد من المعدل، والمراقبة، وغيرها. نطبق Service Mesh بشكل رئيسي على منصة Kubernetes. أيضًا، النمط الأكثر كلاسيكية يُسمى sidecar، والذي يقوم بفصل بعض الوظائف العامة في حاوية sidecar وتركيبها مع حاوية الخدمة في نفس الـ pod. الصورة التالية توضح سبب تسميتها بـ Service Mesh.

Sidecar ليس النمط الوحيد الذي يُطبق Service Mesh؛ بالإضافة إلى ذلك، لدينا نمط DaemonSet ونمط Ambient mesh:

• الفرق بين نمط DaemonSet ونمط sidecar هو أن نمط DaemonSet يسمح لكل عقدة في مجموعة Kubernetes بتشغيل pod واحد فقط، ويعمل هذا الـ pod كـ sidecar proxy. مقارنة بنمط sidecar، يستخدم نمط DaemonSet موارد آلة أقل بكثير، لكنه يعاني من عيوب مثل العزل الضعيف، وصعوبة التنبؤ باستدعاءات الموارد، وغيرها. يمكنك العثور على المزيد من الاختلافات في هذه المقالة: Sidecars و DaemonSets: معركة أنماط الحاويات.

• Ambient mesh هو نمط جديد لمستوى البيانات تم تقديمه من قبل Istio في 7 سبتمبر 2022. لحل مشكلة اقتران البنية التحتية للنشر، يقوم Ambient mesh بفصل وكيل مستوى البيانات عن pod التطبيق بحيث يمكن نشره بشكل منفصل.

يقوم Ambient mesh بتقسيم مستوى البيانات إلى طبقة آمنة وطبقة معالجة L7: تقوم الطبقة الآمنة بمعالجة وظائف مثل توجيه TCP، مقاييس المراقبة، تسجيل الوصول، أنفاق mTLS؛ بالإضافة إلى جميع وظائف الطبقة الآمنة، تحتوي طبقة معالجة L7 على العديد من الوظائف الأخرى مثل التحكم في حركة المرور عبر توجيه HTTP، المراقبة، وتحقيق سياسات تفويض غنية لـ L7.

بالإضافة إلى ذلك، يستخدم Ambient mesh وكيلًا مشتركًا يُسمى ztunnel (نفق الثقة الصفرية)، والذي يعمل في كل عقدة داخل مجموعة Kubernetes ويقوم بتوصيل ومصادقة الأحمال العملية داخل الشبكة بشكل آمن. يمكنك قراءة هذه المقالة إذا كنت ترغب في معرفة المزيد عن نمط Ambient mesh: تقديم Ambient Mesh

لماذا نحتاج إلى Service Mesh؟

قبل أن تصبح Service Mesh شائعة، كانت إدارة الخدمات في العديد من هياكل الخدمات المصغرة تتحقق من خلال إطار عمل الخدمات المصغرة بالتعاون مع منصة التحكم. ومع ذلك، هذه الطريقة تعاني من المشكلات التالية:

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

لحل هذه المشكلات، اقترح المهندس السابق في تويتر Willian Morgan، أحد مؤسسي Linkerd، مفهوم "Service Mesh". تستخدم Service Mesh نمط sidecar لفصل البنية التحتية عن منطق الخدمة دون التأثير على التطبيق، مما يحقق ترقية موحدة للغة وإدارة العمليات.

تقوم Service Mesh بنقل وظائف مثل التحكم في حركة المرور، المراقبة، والاتصالات الآمنة إلى المكونات الأساسية؛ وبالتالي، لا يحتاج المطورون إلى القلق بشأن التنفيذ المحدد لطبقة الاتصال وإدارة الخدمات. يمكن للمطورين ترك كل العمل المتعلق بالاتصال لـ Service Mesh والتركيز على تطوير الخدمات. بناءً على هذه الميزات، يمكن لـ Service Mesh مساعدتنا في حل تلك المشكلات المذكورة سابقًا.

كيف تعمل Service Mesh؟

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

حاليًا، تستخدم معظم Service Meshes بنية مستوى البيانات + مستوى التحكم، كما هو موضح أدناه:

مستوى التحكم

يدير مستوى التحكم ويُكوّن مستوى البيانات ويقوم بتنفيذ الاستراتيجيات أثناء تشغيل الخدمة. جميع الحالات داخل مستوى التحكم مع Service Mesh واحدة ستشارك نفس موارد التكوين.

يركز مستوى التحكم أكثر على التسليم والاستراتيجيات مثل الأمان، المراقبة، والتحكم في حركة المرور. سيقوم أيضًا بجمع بيانات المراقبة لمستوى البيانات بحيث يمكن لـ DevOps استخدامها.

مستوى البيانات

يعمل مستوى البيانات عادة كـ proxy ويتكون من العديد من وكلاء sidecar. سيعمل sidecar مع نسخ الخدمة بالتوازي ويتحكم في حركة مرور تطبيق الخدمة عن طريق اعتراض تدفق بيانات الخدمة.

كما ذكرنا سابقًا، يتم تحقيق Service Mesh من خلال تطبيق نمط sidecar في Kubernetes وتغليفه كحاوية. يقترح sidecar استخدام حاوية إضافية لتوسيع وتعزيز الحاوية الرئيسية، وتُسمى هذه الحاوية الإضافية بحاوية sidecar، والتي يتم تخصيصها في نفس الـ pod مع حاوية الخدمة. من ناحية أخرى، فإن Service Mesh هي شبكة متشابكة تتكون من وكلاء sidecar هؤلاء.

تطبيقات Service Mesh

في بنية الخدمات المصغرة، عادة ما يقوم المهندسون بتشفير الخدمات العامة المكشوفة أو تقييد الوصول لحماية الخدمة، لكنهم يتجاهلون أمان الاتصالات داخل المجموعات. حتى الآن، لا تزال العديد من تطبيقات الخدمات المصغرة تفتقر إلى تشفير الاتصالات بين الخدمات، ويتم نقل حركة المرور الداخلية للمجموعة حتى في شكل بيانات خام. نتيجة لذلك، من المحتمل جدًا أن تتعرض حركة المرور الداخلية لهجمات التنصت وهجمات MITM (Man-in-the-middle attack).

لتجنب الهجمات على حركة المرور الداخلية للمجموعة، نستخدم mTLS لتشفير بيانات حركة المرور. يمكن لـ mTLS تأمين أمان الاتصالات بين الخدمات المصغرة داخل Service Mesh. يستخدم تقنية التشفير لمصادقة كل خدمة مصغرة وتشفير حركة المرور بين الخدمات بشكل متبادل.

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

بدلاً من ذلك، إذا استخدمنا Service Mesh، يمكننا توفير اتصالات mTLS دون أن تكون الخدمة الأصلية على علم بذلك. لذلك، في Service Mesh، نقوم بنقل جميع الوظائف المتعلقة بالاتصال إلى وكلاء sidecar.

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

من هذا السيناريو، يمكن للجميع فهم سبب قدرة Service Mesh على توسيع الوظائف الحالية دون التأثير على الخدمة الحالية. ولكن، بالطبع، بالإضافة إلى تحقيق وظيفة تكوين أمان حركة المرور الداخلية المشابهة لـ mTLS، يمكن لـ Service Mesh أيضًا توسيع وظائف مثل التحكم في حركة المرور، المراقبة، وبروتوكولات الترميز بسرعة عن طريق تعديل تكوين مستوى التحكم.

الخلاصة

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

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

مع التطور المتفجر للسحابة الأصلية وتحسين Service Mesh، من المحتمل أن تحل Service Mesh محل بنية الخدمات المصغرة بالكامل في المستقبل وتصبح الخيار الأول لإعادة بناء بنية الخدمات المصغرة والسحابة الأصلية لكل شركة.

إذا كنت ترغب في معرفة المزيد عن إدارة API، يمكنك الاتصال بنا في أي وقت: https://api7.ai/contact.