Service Mesh

Service Mesh — إدارة التواصل بين الخدمات Service Mesh

طبقة بنية تحتية تنقل منطق الشبكة (توجيه، أمان، مراقبة) خارج كود كل خدمة عبر Proxy يعمل بجانبها (Sidecar)، دون تعديل الكود.

بدل تكرار منطق Retry وmTLS والمراقبة داخل كود كل خدمة بلغتها الخاصة، يضع Service Mesh Proxy خفيفاً (Sidecar) بجانب كل نسخة خدمة يعترض كل حركة الشبكة الداخلة والخارجة منها. مجموع هذه الـ Proxies يُشكّل Data Plane، وتديره مركزياً Control Plane تترجم قواعد التوجيه والأمان لإعدادات فعلية لكل Proxy.

Istio (يستخدم Envoy كـ Proxy وistiod كـ Control Plane) هو التطبيق الأشهر، وLinkerd بديل أخف يستخدم Proxy مخصصاً بلغة Rust ومنحنى تعلّم أبسط.

الصياغة

Service ←→ Sidecar Proxy ←→ Network ←→ Sidecar Proxy ←→ Service
                ↑                              ↑
              Control Plane (يهيّئ الاثنين)

📄 مثال

# Pod مع Sidecar — لا تعديل على كود التطبيق
apiVersion: v1
kind: Pod
spec:
  containers:
    - name: order-service
      image: order-service:1.4
    - name: istio-proxy
      image: envoyproxy/envoy

أهم النقاط

العنصر	الوظيفة
Data Plane	مجموع الـ Sidecar Proxies التي تمر عبرها كل حركة الشبكة فعلياً
Control Plane	المكون المركزي الذي يترجم القواعد لإعدادات ويوزّعها على كل Proxy
mTLS تلقائي	تشفير ومصادقة بين الخدمات دون أي كود إضافي في التطبيق

💡 نصائح عملية

لا تحتاج Service Mesh مع عدد صغير من الخدمات — الفائدة تظهر مع نمو العدد وتنوع اللغات
قيّم Linkerd إن كانت الأولوية البساطة وخفة الموارد، وIstio إن احتجت ميزات توجيه متقدمة واسعة

⚠️ أخطاء شائعة

تركيب Service Mesh لنظام صغير من خدمتين أو ثلاث — تعقيد تشغيلي إضافي بلا فائدة تُذكر
تجاهل زمن الاستجابة الإضافي الذي يضيفه مرور كل طلب عبر Proxy إضافي

🎓 تريد فهم الصورة الكاملة خطوة بخطوة؟ ابدأ من مسار MICROSERVICES الكامل بالعربي.