يمكن لفريق يشغّل خمس خدمات مصغّرة عادة أن يتدبر أمر إعادة المحاولات، ومهل الانتظار، والمصادقة المتبادلة داخل كود كل خدمة بنفسه. أما فريق يشغّل مئتي خدمة مصغّرة فلا يمكنه ذلك. عند هذا الحجم، تنتهي كل خدمة بحاجتها إلى نفس مجموعة سلوكيات الشبكة — إعادة المحاولة بتأخير تصاعدي عند فشل استدعاء لخدمة تابعة، وتشفير حركة البيانات بين الخدمات، وفرض من يُسمح له باستدعاء من، وإصدار مقاييس متسقة عن كل طلب — وتنفيذ كل ذلك داخل منطق أعمال كل خدمة يعني إما بناء مكتبة مشتركة يجب على كل فريق تبنيها والحفاظ عليها محدثة، أو قبول أن تنفذ خدمات مختلفة هذه المخاوف بشكل غير متسق. شبكة الخدمة هي الإجابة البنيوية على هذه المشكلة: فهي تنقل سلوك الشبكات خارج كود التطبيق كلياً إلى طبقة مخصصة تقف جنباً إلى جنب مع كل نسخة خدمة.
تحقق الشبكة ذلك بإرفاق وكيل خفيف الوزن بكل نسخة خدمة، يعترض كل حركة بيانات الشبكة الداخلة والخارجة من تلك النسخة، ويطبّق السياسة — إعادة المحاولات، والمهل، والتشفير، وقواعد التوجيه، والتحكم بالوصول — عند طبقة الوكيل بدلاً من داخل التطبيق. من منظور التطبيق، هو يجري استدعاء شبكة عادياً؛ والوكيل الجالس بجانبه يتولى كل شيء آخر. هذا النمط، المعروف عادة بنمط "السايدكار" (sidecar)، هو ما تُبنى عليه معظم شبكات الخدمة.
في شبكة قائمة على السايدكار، تعمل كل نسخة تطبيق جنباً إلى جنب مع وكيل — مبني غالباً على Envoy، رغم وجود وكلاء آخرين — يعترض بشفافية كل حركة البيانات الداخلة والخارجة لتلك النسخة. تشكّل هذه الوكلاء مجتمعة ما يُسمى طبقة البيانات: الجزء من الشبكة الذي يلمس فعلاً كل طلب أثناء تدفقه بين الخدمات. ولأن الوكيل يقف عند طبقة الشبكة، يمكنه تطبيق إعادة المحاولات والمهل بشكل متسق بغض النظر عن اللغة أو الإطار الذي كُتب به التطبيق نفسه، مما يحل مشكلة حقيقية ومتكررة للمؤسسات متعددة اللغات.
كما يجعل موقع السايدكار اعتماد TLS المتبادل بين الخدمات شبه مجاني. فبدلاً من أن ينفذ كل فريق تطبيق إدارة الشهادات والاتصالات المشفرة بنفسه، تُصدر طبقة التحكم في الشبكة وتُجدد شهادات قصيرة الأجل لكل وكيل تلقائياً، وتتعامل الوكلاء مع المصافحة المشفرة بشفافية. يستمر كود التطبيق في إجراء استدعاءات تبدو عادية وغير مشفرة إلى عنوان محلي، بينما تكون حركة البيانات الفعلية بين المضيفين مشفرة بالكامل ومصادَق عليها بشكل متبادل.
تقف طبقة التحكم فوق طبقة البيانات، وهي عقل الشبكة، مسؤولة عن تهيئة كل وكيل سايدكار بقواعد التوجيه الحالية، وسياسات الأمن، وتهيئة تقسيم حركة البيانات. هذا الفصل مهم تشغيلياً: تغيير سياسة إعادة محاولة، أو تحويل عشرة بالمئة من حركة البيانات إلى نسخة جديدة من خدمة، أو تقييد الخدمات المسموح لها باستدعاء واجهة خلفية حساسة، يصبح تغيير تهيئة يُدفع عبر طبقة التحكم إلى الوكلاء المعنيين، بدلاً من تغيير كود يتطلب إعادة بناء ونشر الخدمات المتأثرة.
هذه الآلية نفسها هي ما يجعل شبكة الخدمة موطناً طبيعياً لأنماط التسليم التدريجي. تقسيم حركة البيانات بين نسخة قديمة وجديدة من خدمة حسب نسبة مئوية، أو توجيه قيمة رأس محددة إلى نشر تجريبي، أو التراجع التلقائي عن حركة البيانات إلى نسخة جديدة إذا ارتفع معدل أخطائها، كلها مشاكل إدارة حركة بيانات تكون طبقة التحكم في الشبكة في موقع جيد لحلها.
لأن كل طلب يمر بالفعل عبر وكيل سايدكار، تكون الشبكة في موقع فريد لإصدار قياس عن بُعد متسق — عدد الطلبات، وزمن الاستجابة، ومعدلات الأخطاء، ورؤوس التتبع الموزع — لكل خدمة في النظام، دون حاجة أي خدمة فردية لتنفيذ ذلك بنفسها. هذا ينتج رؤية موحدة وشاملة لصحة حركة البيانات كانت ستتطلب من كل فريق دمج نفس مكتبات المقاييس والتتبع بشكل صحيح، وهو افتراض ينهار بمجرد أن يكون لدى المؤسسة أكثر من بضعة فرق بمستويات متفاوتة من انضباط القياس.
هذه الفائدة في المراقبة هي غالباً ما يقنع فعلياً منظمة هندسية متشككة بتبني الشبكة، حتى أكثر من قدرات الأمن أو إدارة حركة البيانات: بالنسبة لكثير من المؤسسات، أول مرة يرون فيها رسماً بيانياً لتبعية الخدمات كاملاً وموحداً حقاً هو اليوم الذي يشغّلون فيه قياس الشبكة عن بُعد.
لا شيء من هذا مجاني. شبكة الخدمة نفسها قطعة كبيرة من البنية التحتية الموزعة، لها دورات ترقية خاصة بها، وأنماط فشل خاصة بها، ومنحنى تعلم خاص بها لفريق المنصة المسؤول عن تشغيلها. كل طلب يمر الآن عبر قفزة وكيل إضافية على كل من جانب الإرسال والاستقبال، مضيفاً زمن استجابة صغيراً عادة بالقيمة المطلقة لكن ليس صفراً، ويحتاج قياسه لا افتراض عدم أهميته.
العبء التشغيلي لتشغيل طبقة التحكم في الشبكة حقيقي ومستمر أيضاً: تجديد الشهادات، وترقيات نسخ الوكيل عبر مئات السايدكارز المحتملة، وتشخيص أعطال الشبكة نفسها (قاعدة توجيه سيئة التهيئة يمكن أن تبدو مطابقة لخلل تطبيق من الخارج)، كلها تصبح فئات جديدة من عمل الاستدعاء الطارئ لأي فريق يملك الشبكة.
تستحق شبكة الخدمة تعقيدها عندما يكون لدى المؤسسة عدد كافٍ من الخدمات، بعدد كافٍ من اللغات، بمتطلبات أمن وموثوقية صارمة كافية، بحيث يكون البديل — بناء وصيانة مكتبات مشتركة عبر كل فريق، بكل لغة، لكل واحد من مخاوف الشبكات هذه — قد أصبح مسعى أكبر وأكثر إيلاماً من تشغيل الشبكة نفسها. المؤسسات ذات الخدمات القليلة، أو التي لديها اتفاقيات منصة قوية مفروضة بالفعل عبر إطار مشترك أو مكتبة داخلية جيدة الصيانة، غالباً ما تجد أن الشبكة تحل مشكلة لا تملكها فعلاً، بتكلفة تشغيلية مستمرة حقيقية.
يمثّل التطبيقان الأكثر اعتماداً على نطاق واسع لشبكة الخدمة، Istio وLinkerd، فلسفتين مختلفتين حقاً وليس مجرد علامتين تجاريتين لنفس الفكرة. يقدّم Istio، المبني على وكيل Envoy، سطحاً واسعاً جداً من ميزات إدارة حركة البيانات والأمن والسياسة القابلة للتهيئة، مما يجعله قادراً على التعامل مع أي متطلب توجيه أو أمن تقريباً قد تحتاجه مؤسسة، بتكلفة سطح تهيئة كبير مقابل ومنحنى تعلم تشغيلي أكثر انحداراً. يضيّق Linkerd نطاقه عمداً، مستخدماً وكيلاً خفيفاً مبنياً لغرض محدد بدلاً من Envoy، معطياً الأولوية للبساطة، وعبء موارد أقل، وسطح تهيئة أصغر على حساب مجموعة ميزات Istio الأوسع.
مع انتشار خدمات المؤسسات عبر عدة عناقيد Kubernetes، وأحياناً عبر عدة مزودي سحابة أو مناطق، يتوسع عمل الشبكة من إدارة حركة البيانات داخل عنقود واحد إلى إدارة حركة البيانات التي تحتاج إلى عبور حدود العناقيد والشبكات بأمان وموثوقية. هذا يُدخل مجموعته الخاصة من القرارات: هل ينبغي أن تتمكن الخدمات في عناقيد مختلفة من اكتشاف واستدعاء بعضها مباشرة عبر الشبكة، وكيف تُنشأ الشهادات والثقة عبر حدود العناقيد التي قد لا تتشارك سلطة شهادات واحدة افتراضياً، وكيف يتصرف التبديل عند تعطل الاتصال بعنقود أو منطقة بأكملها. الشبكات المصممة مع أخذ التشغيل متعدد العناقيد بالحسبان تدعم عادة جذر ثقة مشترك يمكن لكل طبقة تحكم عنقود توسيعه.
إدخال شبكة عبر أسطول خدمات قائم بالفعل نادراً ما يتم دفعة واحدة، والفرق التي تحاول نشراً شاملاً فورياً عبر كل مساحة أسماء في آن واحد تجد صعوبة أكبر بكثير في عزل السبب عندما يحدث خطأ ما. النمط الأكثر شيوعاً وأماناً هو تفعيل حقن سايدكار الشبكة لمساحة أسماء واحدة منخفضة المخاطر أو خدمة واحدة أولاً، ومراقبة سلوكها تحت حركة بيانات حقيقية لفترة، والتوسع تدريجياً بمجرد أن يكتسب الفريق المشغّل للشبكة ثقة في كيفية تصرفها تحت أنماط حركة البيانات وفشل المؤسسة الفعلية.
يستفيد نشر TLS المتبادل تحديداً من نهج مرحلي: تدعم معظم الشبكات وضعاً متساهلاً حيث تُقبل حركة البيانات المشفرة وغير المشفرة معاً خلال فترة انتقالية، مما يتيح للفريق التأكد من أن كل خدمة قد التقطت سايدكارها وشهادتها بنجاح قبل التحول إلى وضع صارم يرفض الاتصالات غير المشفرة كلياً.
شغّلت شركة تقنية مالية نحو ستين خدمة مصغّرة تدعم منصة مدفوعاتها، مكتوبة عبر ثلاث لغات مختلفة من فرق بمستويات متفاوتة من خبرة الشبكات. أصبحت مشكلتان متكررتان خطيرتين بما يكفي لتبرير إصلاح على مستوى المنصة: كانت حركة البيانات الداخلية بين الخدمات غير مشفرة، وكان سلوك إعادة المحاولة بين الخدمات غير متسق بشكل صارخ، مع إعادة محاولة بعض الفرق بقوة كافية للتسبب في حمل زائد متتالٍ أثناء انقطاعات الخدمات التابعة.
قدّم فريق المنصة شبكة خدمة، مفعّلاً TLS المتبادل على مستوى الشبكة كخطوة أولى، مما شفّر ووثّق كل حركة بيانات داخلية بين الخدمات دون تغيير سطر واحد من كود التطبيق. ثم عرّفوا سياسة معيارية لإعادة المحاولة والمهلة على مستوى الشبكة، مستبدلين عشرات تطبيقات إعادة المحاولة المتناقضة المصنوعة يدوياً المبعثرة عبر الخدمات بتهيئة واحدة مُدارة مركزياً وسهلة التعديل. في غضون بضعة أشهر، أُغلق استنتاج التدقيق الأمني حول حركة البيانات الداخلية، وانخفضت الأعطال المتتالية الناجمة عن عواصف إعادة المحاولة غير المتسقة بشكل ملموس.
تحل شبكة الخدمة مشكلة حقيقية تظهر تحديداً عند النطاق الواسع: نفس مجموعة مخاوف الشبكات القليلة — التشفير، وإعادة المحاولات، والتحكم بالوصول، والمراقبة — تحتاج إلى معالجة متسقة عبر كل خدمة في النظام، ومعالجتها داخل كود تطبيق كل خدمة يصبح غير مستدام بمجرد أن يكون لدى المؤسسة عدد كافٍ من الخدمات والفرق واللغات. بنقل هذا المنطق إلى طبقة سايدكار وطبقة تحكم مخصصة، تمنح الشبكة كل خدمة نفس ضمانات الأمن والموثوقية دون مطالبة كل فريق بتنفيذ نفس المنطق بشكل صحيح بنفسه. التكلفة تعقيد تشغيلي إضافي حقيقي، مما يعني أن الشبكة تستحق التبني فقط بمجرد أن تعاني المؤسسة فعلاً من الألم الذي تحله.
