Technical Tutorials

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

هيمنتان عملاقتان تهيمنان على هذا المجال: Istio وLinkerd. يستفيد كلاهما من نمط وكيل الجار (sidecar proxy) لكنهما يتعاملان مع التحديات المعمارية بفلسفات مختلفة. في هذا المنشور، سنستكشف كيفية عملهما، نقارن ميزاتهما، وننظر في التطبيقات العملية.

كيف تعمل شبكات الخدمات: نمط الجار (Sidecar)

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

هذا الفصل في الاهتمامات أمر حيوي. فهو يضمن بقاء كود تطبيقك نظيفاً، وقابلاً للنقل، ومستقلاً عن التقنية. سواء كانت خدمتك مكتوبة بلغة Go أو Python أو Java، تتعامل الشبكة مع تعقيدات الشبكة بشكل موحد.

Istio: غني بالميزات ومتوافق أصلاً مع Kubernetes

تم تطوير Istio بواسطة Google وIBM وLyft، وهو على الأرجح شبكة الخدمات الأكثر شيوعاً لـ Kubernetes. وهو معروف بمجموعة ميزاته الواسعة، بما في ذلك إدارة حركة المرور المتقدمة، وأمان TLS المتبادل (mTLS)، والرصد الشامل من خلال التكامل مع Prometheus وGrafana.

ومع ذلك، فإن هذا الغنى يأتي مع تعقيد. يتكون Istio من مستويين متميزين:

مستوى البيانات (Data Plane): يتكون من وكلاء Envoy الذين يتعاملون مع حركة المرور الفعلية.
مستوى التحكم (Control Plane): يدير الوكلاء، ويدفع التكوينات وجمع فحوصات الصحة.

غالباً ما يتضمن تكوين Istio ملفات تعريف YAML التي تحدد VirtualServices وDestinationRules. فيما يلي مثال بسيط لتوجيه 10٪ من حركة المرور إلى إصدار جديد من الخدمة (Canary Deployment):

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: bookinfo
spec:
  hosts:
  - "productpage.default.svc.cluster.local"
  http:
  - route:
    - destination:
        host: productpage
        subset: v1
      weight: 90
    - destination:
        host: productpage
        subset: v2
      weight: 10

Istio مثالي للفرق التي تحتاج إلى تحكم دقيق في توجيه حركة المرور وهي على استعداد للاستثمار في الحمل التشغيلي لإدارة مستوى تحكم معقد.

Linkerd: البساطة والأداء

يتبع Linkerd، الذي أنشأته Buoyant، نهج "الأقل هو أكثر". إنه مبني على Rust بدلاً من C++ (مثل Envoy)، مما أدى إلى بصمة أصغر بكثير وأوقات بدء تشغيل أسرع. غالباً ما يُمدح Linkerd لسهولة تثبيته وتشغيله.

على الرغم من أنه يحتوي على ميزات جاهزة أقل من Istio، إلا أنه يوفر كل الأساسيات: mTLS التلقائي، والرصد، وإدارة حركة المرور الأساسية. تؤكد فلسفته التصميمية على البساطة، مما يجعله خياراً ممتازاً للمنظمات التي تريد فوائد شبكة الخدمات دون منحنى التعلم الحاد.

لتوجيه حركة المرور المتقدم، يعتمد Linkerd على تعريفات الموارد المخصصة (CRDs) الخاصة به مثل HTTPRoute أو TrafficSplit، وهي بشكل عام أكثر بديهية من التكوينات الطويلة لـ Istio.

اختيار الأداة المناسبة

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

الخاتمة

لم تعد شبكات الخدمات خياراً "جيداً إذا توفرت" للخدمات المصغرة واسعة النطاق؛ بل أصبحت مطلباً قياسياً للأنظمة المرنة والآمنة والقابلة للرصد. سواء اخترت القوة الشاملة لـ Istio أو البساطة الأنيقة لـ Linkerd، فإن تنفيذ شبكة خدمات هو خطوة كبيرة نحو إتقان تصميم الأنظمة الحديثة. مع نمو بنيتك التحتية، تذكر أن الأداة الأفضل هي تلك التي تناسب ثقافة فريقك واحتياجاتك التشغيلية بشكل أفضل.