Distributed Systems Design Patterns - Sidecar Pattern

يعد الـ Sidecar Pattern من أشهر الأنماط الشائعة في عالم النظم الموزعة وخصوصًا في عالم الـ Containerised Applications، وهو يعتبر ضمن مجموعة الـ Single-Node Pattern
Distributed Systems Design Patterns - Sidecar Pattern

في هذه الصفحة

يعد الـ Sidecar Pattern من أشهر الأنماط الشائعة في عالم النظم الموزعة وخصوصًا في عالم الـ Containerised Applications، وهو يعتبر ضمن مجموعة الـ Single-Node Pattern ويتكون من حاويتان أو 2 Containers.

الـ Container الأول هو التطبيق الرئيسي أو الـ Main Application وهو المسئول عن الوظيفة الأساسية للتطبيق، ولا يمكن للتطبيق أن يؤدي وظيفته من غير وجوده. بينما الـ Sidecar Container هو Container إضافي ومساعد للتطبيق الرئيسي.

ما الغرض من وجود الـ Sidecar ؟

الهدف الأساسي لوجود الـ Sidecar هو التحسين والتطوير من التطبيق الرئيسي، وذلك بشكل متكرر بدون إدراك ووعي الـ Application Container بذلك. فعلى سبيل المثال: يُمكن للـ Sidecar أن يكون دوره بكل بساطة هو إضافة وظيفة أخرى ومساعدة للتطبيق الرئيسي. ويمكن أيضًا أن يتم استعماله لدعم الـ Modularity وخصوصًا مبدأ إعادة الاستعمال أو ما يعرف بالـ Reusability of Components ، فيمكن استعماله في العديد من التطبيقات الآخرى ليؤدي نفس الوظيفة المساعدة لها.

نظرة عامة عن الـ Sidecar

يمكننا أن نرى بشكل عملي دور الـ Sidecar خصوصًا في الـ Kubernetes Pods، فدعنا ننظر إليه كـ Container Group كالـ Pod API Object in Kubernetes والتي تقوم بعمل جدولة للـ Sidecar حتى يقوم ويبدأ عمله بجانب الـ Main Application على نفس النظام، وحيث أننا استطعنا أن نجعلهم على نفس النظام (الـ Machine) فمن الممكن استغلال هذه الفرصة لدعم مشاركة العديد من الـ Resources كالـ File System والـ Hostnames and Networks والعديد من الـ Resources الآخرى، بالإضافة لإنه يمكننا جعلهم يتم جدولتهم للقيام معًا كوحدة واحدة.

أمثلة واقعية لاستخدام الـ Sidecar

دعونا نرى بعض الأمثلة الواقعية لاستعمالات الـ Sidecar حتى نرى مدى أهميته في عالم النظم الموزعة.

لنفترض أننا نتعامل مع نظام قديم جدًا أو ما يعرف بالـ Legacy System ، ولكن هذا النظام القديم وظيفته لا تسمح إلا بالـ Communication من خلال بروتوكول الـ HTTP. فهل هنالك طريقة تمكننا من إضافة وظيفة أخرى للنظام ككل تجعله يستطيع التواصل وتلقي الـ Requests over HTTPS ؟ هل من الممكن اضافة الـ SSL كوظيفة إضافية للنظام ؟

الإجابة هي نعم بكل تأكيد، فيمكننا الاعتماد على الـ Sidecar Pattern في هذا المثال لعمل Container اضافي يقوم مع التطبيق الرئيسية ووظيفته هي تلقي الـ Requests والتعامل مع الـ HTTPS ومن ثم يقوم بتفويض المهمة الرئيسية لتلبي هذا الـ Request للتطبيق الرئيسي.

فكما نرى هنا استطعنا الاستفادة من الـ Sidecar في كونه طبقة من الـ Proxy للنظام القديم يمكنه من خلالها استقبال أي Requests تتعامل بالـ HTTPS.

دعونا نرى مثال آخر، ولنفترض أننا نريد تحقيق الـ Dynamic Configuration للتطبيق الرئيسي، فمن الممكن استعمال الـ Sidecar بمثابة Dynamic Configuration Manager يكون دوره الرئيسية هو عملية التزامن والـ Syncing بين الـ Configuration Service والتطبيق الرئيسي كل فترة من الزمن، فمن الممكن للمستخدم أن يقوم بتعديل الـ Configuration الخاصة بالتطبيق، ويكون دور الـ Sidecar هو أنه يقوم بتعديل الـ Local Configuration عن طريق الـ Syncing للبيانات الجديدة التي قام بتعديلها المستخدم، ويقوم بعمل Trigger للتطبيق الرئيسي حتى يقرأ البيانات الجديدة.

تحقيق مبدأ الـ Modularity وإعادة الاستعمال

كما نرى فالـ Sidecar لا تكمن مهمته الوحيدة في إضافة خصائص جديدة للنظام فقط، فهو يدعم مبدأ الـ Modularity وإعادة الاستعمال كـ Component يمكن أن يتم وضعها في العديد من التطبيقات الآخرى.

ماذا لو أردنا أن نضيف جزء بسيط من الـ Monitoring بجانب التطبيق الرئيسي حتى يتثنى لنا معرفة معلومات واحصائيات عن الـ Resources التي يقوم التطبيق باستهلاكها ؟ يمكننا بالفعل عمل Sidecar يكون دوره الرئيسي هو أنه يقوم بتجميع Metrics مختلفة عن الـ Resources ويدعم الـ Alarms وصفحة UI لعرض تلك النتائج والاحصائيات، وبالتالي يمكننا اعادة استعمال هذا الـ Sidecar في جميع التطبيقات التي نعمله عليها حتى يكون لدينا Monitoring Solution يمكننا الاعتماد عليه في كل تطبيق.

كما يمكننا الاعتماد على هذا النمط أيضًا في عمل Secret Management System يكون دوره الأساسي هو حفظ المعلومات السرية الخاصة بالتطبيق كالـ Credentials والـ Secrets APIs ويتم استعماله في كل التطبيقات كذلك.

وهنالك العديد والعديد من الأفكار يمكنك أن تتخيلها قد تتم بفضل هذا النمط واستعماله بشكل جيد، كالـ Deployment Testing Patterns مثل الـ Canary والـ Blue-Green Deployments أو أن يتم استخدامه ليقوم بتجميع وحفظ الـ Logs بشكل معين من أكثر من تطبيق مختلف حتى يكون لديك Log كامل بشكل موحد.

في الختام

يُعد هذا النمط من ضمن أهم الأنماط والأكثرها شيوعًا في عالم الـ Containerised Applications وخصوصًا Kubernetes أو أية Orchestrator Services آخرى، وذلك لمدى قوته وتأثيره واستعماله في تصميم النظم الموزعة.

اشترك الآن بنشرة اقرأ-تِك الإخبارية

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