شبكة الخدمات (مقدمة)

شبكة الخدمات (مقدمة)

حين تُقسّم تطبيقاً متكاملاً إلى عشرات الخدمات المصغّرة، تجد نفسك فجأة أمام حاجة كل خدمة إلى التواصل مع الأخريات — بأمان وموثوقية وقابلية للرصد والمراقبة. على النطاق الصغير، تُعالج ذلك داخل كل خدمة: مكتبة إعادة محاولة هنا، وشهادة TLS هناك، ومسجّل أحداث في مكان آخر. غير أن هذا النهج ينهار تماماً حين تتجاوز عدد خدماتك الخمسين؛ إذ تُعيد كل فريق تنفيذ الاهتمامات المشتركة ذاتها بلغات مختلفة وأساليب متباينة وأخطاء مغايرة.

تأتي شبكة الخدمات (Service Mesh) لاستخلاص كل هذه السباكة الشبكية من شيفرة تطبيقاتك، وتضعها في طبقة البنية التحتية حيث تُدار بشكل موحّد عبر جميع الخدمات بصرف النظر عن اللغة أو الإطار المستخدم.

وكيل الجانب (Sidecar Proxy): الفكرة الجوهرية

اللبنة الأساسية لشبكة الخدمات هي وكيل الجانب (sidecar proxy). يُنشر مع كل نسخة من الخدمة وكيلٌ صغير في المضيف أو الحجرة (Pod) ذاتها. يُعترض كل حركة المرور الواردة والصادرة بشكل شفاف وتُوجَّه عبر هذا الوكيل — دون أن يدري تطبيقك بوجوده.

يتولى الوكيل المهام التالية:

• TLS المتبادل (mTLS) — يُشفَّر كل اتصال بين الخدمات تلقائياً ويتحقق الطرفان من هويتيهما بشهادات قصيرة الأجل، دون أي تعديل في الشيفرة.
• موازنة الحمل — يعرف الوكيل جميع النسخ الموجودة في المنبع ويمكنه استخدام خوارزميات مراعية للاستجابة (كأقل الطلبات تحميلاً) بدلاً من التوزيع الدوري البسيط الذي يوفره البحث في DNS.
• إعادة المحاولة والمهل الزمنية — تُعرَّف مرة واحدة في سياسة مركزية، مع التخلص من منطق إعادة المحاولة المتكرر في كل خدمة.
• قاطع الدائرة (Circuit Breaking) — يتتبع الوكيل معدلات الأخطاء ويوقف توجيه الحركة إلى منبع فاشل قبل أن ينتشر العطل.
• التتبع الموزع — يُدرج الوكيل ترويسات التتبع ويُرسلها (مثل X-B3-TraceId) تلقائياً، مانحاً إياك تتبعاً شاملاً للطلبات من البداية للنهاية دون أي قياس داخل الخدمات.
• تشكيل الحركة — إطلاق تدريجي (Canary)، وتوجيه A/B، وحقن الأعطال لاختبار الفوضى — كل ذلك يُتحكم به عبر واجهة برمجية مركزية.

مستوى التحكم مقابل مستوى البيانات

تنقسم شبكة الخدمات مفاهيمياً إلى مستويين:

• مستوى البيانات (Data Plane) — مجموعة جميع وكلاء الجانب العاملين إلى جانب خدماتك. يتعاملون مع حزم الشبكة الفعلية في الوقت الحقيقي. Envoy هو الوكيل السائد هنا، ويستخدمه كل من Istio وAWS App Mesh.
• مستوى التحكم (Control Plane) — مكوّن مركزي (مثل istiod في Istio، أو مستوى تحكم Linkerd) يوزّع قواعد التوجيه وشهادات mTLS وإعدادات القياس على جميع وكلاء الجانب. لا يقع في مسار الطلب — بل يُدير الإعدادات فحسب.

مثال واقعي: إصدار تدريجي (Canary) بدون تغيير شيفرة

تخيّل أنك تنشر الإصدار 2 من خدمة الدفع. بدون شبكة خدمات، قد تحتاج إلى إعداد قاعدة موازن حمل مُرجَّح، أو تشغيل نظام feature-flag معقد داخل الخدمة. مع الشبكة، تطبّق ملف YAML واحداً من نوع VirtualService على مستوى التحكم:

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

قابلية الرصد جاهزة فوراً

بما أن كل طلب يمر عبر الوكيل، يمكن للشبكة إصدار الإشارات الذهبية لكل اتصال بين الخدمات دون أي قياس داخل التطبيقات:

• المقاييس (Metrics) — معدل الطلبات، معدل الأخطاء، الكمون عند النسب المئوية 50/95/99، تُجمعها Prometheus.
• التتبعات (Traces) — ترويسات التتبع المُرسَلة تلقائياً تغذّي Jaeger أو Zipkin، مانحةً إياك رسماً بيانياً شاملاً لكل استدعاء بين الخدمات.
• السجلات (Logs) — سجلات الوصول لكل طلب من كل وكيل، مُمركزة في Loki أو Elasticsearch.

في شركة Lyft (التي أنشأت Envoy في الأصل)، أفاد المهندسون بأن إضافة الشبكة منحتهم رؤية لآلاف الاستدعاءات بين الخدمات لم يكونوا قادرين على رؤيتها من قبل — دون تعديل سطر واحد من شيفرة التطبيق.

التكلفة: هل تستحق شبكة الخدمات العناء؟

تُضيف شبكة الخدمات تعقيداً وعبئاً حقيقيين:

• عبء الكمون: يُضيف كل عبور عبر وكيل جانبي ما بين 0.2 إلى 1 ميلي ثانية من الكمون (قفزتان لكل استدعاء — واحدة في المصدر وأخرى في الوجهة). لسلسلة من 10 استدعاءات قد يصل ذلك إلى 20 ميلي ثانية إضافية. مقبول لمعظم أحمال العمل؛ مؤلم لأنظمة التداول ذات الكمون الفائق المنخفض.
• عبء الذاكرة: يستهلك كل وكيل Envoy جانبي نحو 50 إلى 100 ميجابايت من الذاكرة العشوائية. مع 200 حجرة، يعني ذلك 10 إلى 20 جيجابايت من الذاكرة للوكلاء وحدهم.
• تعقيد التشغيل: تنتشر مكوّنات مستوى التحكم في Istio. تتطلب تشخيص إعدادات الشبكة مهارات وأدوات جديدة (istioctl، linkerd viz).
• إدارة الشهادات: يجب على الشبكة تدوير شهادات mTLS بانتظام. خطأ في إعداد مرجع التصديق يمكن أن يُعطّل حركة المرور بين الخدمات على مستوى المجموعة كلها.

تطبيقات شبكات الخدمات الشائعة

• Istio — الشبكة الأكثر ثراءً بالميزات؛ تستخدم وكلاء Envoy الجانبية وistiod كمستوى تحكم. Kubernetes-native. متكاملة الميزات لكن معقدة.
• Linkerd — خفيفة الوزن، تُركّز على Kubernetes، مكتوبة بـ Rust. أسهل في التشغيل من Istio. ميزات أقل لكنها تغطي 80% من حالات الاستخدام.
• AWS App Mesh — شبكة مُدارة قائمة على Envoy لأحمال عمل AWS. تكامل جيد مع ECS وEKS وApp Mesh Gateway.
• Consul Connect — شبكة HashiCorp، تعمل عبر Kubernetes والأجهزة الافتراضية غير المُحتوية، مفيدة في البيئات الهجينة.

متى تستخدم شبكة الخدمات؟

تُصبح شبكة الخدمات خياراً منطقياً حين تتحقق جميع الشروط التالية:

1. لديك 10 خدمات مصغّرة أو أكثر مع أنماط اتصال معقدة بينها.
2. تعمل على Kubernetes (أو منسّق مشابه يجعل حقن الوكيل الجانبي تلقائياً).
3. تحتاج إلى أمان بدون ثقة (Zero-Trust) (mTLS في كل مكان) أو تحكم دقيق في الحركة لا تستطيع مكتبات التطبيقات توفيره بشكل موحّد.
4. يمتلك فريقك النضج التشغيلي لتشغيل وتشخيص طبقة البنية التحتية الإضافية.