قم بتوزيع مكونات أحد التطبيقات في عملية أو حاوية منفصلة لتوفير العزل والتغليف. يمكن لهذا النمط أيضًا أن يمكّن التطبيقات من أن تتكون من مكونات وتقنيات غير متجانسة.
يسمى هذا النمط Sidecar وذلك لأنه يشبه السيارة الجانبية المرفقة بدراجة نارية. في النمط، يتم إرفاق sidecar بالتطبيق الأصل ويوفر ميزات داعمة للتطبيق. تشارك sidecar أيضاً نفس دورة حياة التطبيق الأصل، التي يتم إنشاؤها وإيقافها جنباً إلى جنب مع الأصل. يشار إلى نمط sidecar أحياناً باسم نمط sidekick وهو نمط تحليل.
السياق والمشكلة
غالباً ما تتطلب التطبيقات والخدمات وظائف ذات صلة، مثل المراقبة والتسجيل والتكوين وخدمات الشبكات. يمكن تطبيق هذه المهام الطرفية كمكونات أو خدمات منفصلة.
إذا تم دمجها بإحكام في التطبيق، فيمكن تشغيلها في نفس عملية التطبيق، مما يجعل الاستخدام الفعال للموارد المشتركة. ومع ذلك، هذا يعني أيضا أنها ليست معزولة بشكل جيد، ويمكن أن يؤثر الانقطاع في أحد هذه المكونات على المكونات الأخرى أو التطبيق بأكمله. أيضًا، عادةً ما يحتاجون إلى التنفيذ باستخدام نفس لغة التطبيق الأصلي. نتيجة لذلك، يكون للمكون والتطبيق ارتباط وثيق ببعضهما البعض.
إذا تم تقسيم التطبيق إلى خدمات، فيمكن بناء كل خدمة باستخدام لغات وتقنيات مختلفة. بينما يوفر هذا مزيدًا من المرونة، إلا أنه يعني أن كل مكون له تبعياته الخاصة ويتطلب مكتبات خاصة بلغة معينة للوصول إلى النظام الأساسي وأي موارد مشتركة مع التطبيق الأصلي. بالإضافة إلى ذلك، فإن توزيع هذه الميزات كخدمات منفصلة يمكن أن يضيف زمن انتقال للتطبيق. يمكن أن تضيف إدارة الكود والتبعيات لهذه الواجهات الخاصة باللغة أيضًا تعقيدًا كبيرًا، خاصة للاستضافة والنشر والإدارة.
حل
حدد موقع مجموعة متماسكة من المهام مع التطبيق الأساسي، ولكن ضعها داخل العملية أو الحاوية الخاصة بها، مما يوفر واجهة متجانسة لخدمات النظام الأساسي عبر اللغات.
خدمة sidecar ليست بالضرورة جزءا من التطبيق، ولكنها متصلة بها. يذهب حيث يذهب التطبيق الأصلي. تدعم Sidecars العمليات أو الخدمات التي يتم توزيعها مع التطبيق الأساسي. على الدراجة النارية، يتم توصيل السيارة الجانبية بدراجة نارية واحدة، ويمكن لكل دراجة نارية أن يكون لها عربة جانبية خاصة بها. بنفس الطريقة، تشارك خدمة sidecar مصير التطبيق الأصلي الخاص بها. لكل مثيل من التطبيق، يتم توزيع مثيل sidecar واستضافته بجانبه.
تشتمل مزايا استخدام نمط sidecar علي ما يلي:
يعد sidecar مستقلاً عن تطبيقه الأساسي من حيث بيئة وقت التشغيل ولغة البرمجة، لذلك لا تحتاج إلى تطوير عنصر جانبي واحد لكل لغة.
يمكن لـ sidecar الوصول إلى نفس الموارد مثل التطبيق الأساسي. على سبيل المثال، يمكن لـ sidecar مراقبة موارد النظام المستخدمة عن طريق كلاً من sidecar والتطبيق الأساسي.
نظرًا لقربه من التطبيق الأساسي، لا يوجد زمن انتقال كبير عند الاتصال بينهما.
حتى بالنسبة للتطبيقات التي لا توفر آلية توسعة، يمكنك أن تستخدم sidecar لتوسيع الوظائف عن طريق إرفاقها كعملية خاصة بها في نفس المضيف أو الحاوية الفرعية مثل التطبيق الأساسي.
غالباً ما يتم استخدام نمط sidecar مع الحاويات ويشار إليه بحاوية sidecar أو حاوية sidekick.
المسائل والاعتبارات
- ضع في اعتبارك تنسيق التوزيع والتعبئة الذي سوف تستخدمه لتوزيع الخدمات أو العمليات أو الحاويات. تتلاءم الحاويات بشكل خاص مع نمط sidecar.
- عند تصميم خدمة sidecar، قم بالتحديد بعناية آلية الاتصال بين العمليات. حاول استخدام تقنيات حيادية اللغة أو إطار العمل ما لم تجعل متطلبات الأداء ذلك غير عملي.
- قبل وضع الوظائف في sidecar، ضع في اعتبارك ما إذا كانت سوف تعمل بشكل أفضل كخدمة منفصلة أو خفي أكثر تقليدية.
- ضع في اعتبارك أيضًا ما إذا كان يمكن تنفيذ الوظيفة كمكتبة أو باستخدام آلية تمديد تقليدية. ربما يكون للمكتبات الخاصة بلغة معينة مستوى أعمق من التكامل وأقل حمل للشبكة.
موعد استخدام النمط
استخدم هذا النمط عندما:
- يستخدم التطبيق الأساسي الخاص بك مجموعة غير متجانسة من اللغات والأطر. يمكن استهلاك مكون موجود في خدمة sidecar من خلال التطبيقات المكتوبة بلغات مختلفة باستخدام أطر عمل متنوعة.
- يعد المكون مملوكاً من قبل فريق بعيد أو مؤسسة مختلفة.
- يجب أن يكون المكون أو الميزة في موقع مشترك على نفس المضيف مثل التطبيق.
- أنت بحاجة إلى خدمة تشارك دورة الحياة الإجمالية لتطبيقك الرئيسي، ولكن يمكن تحديثها بشكل مستقل.
- أنت بحاجة إلى تحكم دقيق في حدود الموارد لمورد أو مكون معين. على سبيل المثال، ربما ترغب في تقييد مقدار الذاكرة التي يستخدمها مكون معين. يمكنك توزيع المكون كعنصر جانبي وإدارة استخدام الذاكرة بشكل مستقل عن التطبيق الرئيسي.
قد لا يكون هذا النمط مناسبًا:
- عندما يحتاج الاتصال بين العمليات إلى التحسين. يتضمن الاتصال بين التطبيق الأصل وخدمات sidecar بعض النفقات العامة، ولا سيما زمن الانتقال في المكالمات. قد لا تكون هذه مقايضة مقبولة لواجهات الدردشة.
- فيما يتعلق للتطبيقات الصغيرة حيث لا تستحق تكلفة المورد لتوزيع خدمة sidecar لكل مثيل ميزة العزل.
- عندما تحتاج الخدمة إلى التوسع بشكل مختلف عن التطبيقات الرئيسية أو بشكل مستقل عنها. إذا كان الأمر كذلك، فربما يكون من الأفضل توزيع الميزة كخدمة منفصلة.
تصميم حمل العمل
يجب على المهندس المعماري تقييم كيفية استخدام نمط Sidecar في تصميم حمل العمل الخاص بهم لمعالجة الأهداف والمبادئ التي تغطيها ركائز Azure Well-Architected Framework. على سبيل المثال:
| الركيزة | كيف يدعم هذا النمط أهداف الركيزة |
|---|---|
| تساعد قرارات تصميم الأمان على ضمان سرية بيانات وأنظمة حمل العمل وتكاملها وتوافرها. | من خلال تغليف هذه المهمة ونشرها خارج العملية، يمكنك تقليل مساحة سطح العمليات الحساسة إلى التعليمات البرمجية المطلوبة لإنجاز المهمة فقط. يمكنك أيضا استخدام sidecars لإضافة عناصر تحكم أمان شاملة إلى مكون تطبيق غير مصمم أصلا بهذه الوظيفة. - تجزئة SE:04 - تشفير SE:07 |
| يساعد التميز التشغيلي على تقديم جودة حمل العمل من خلال العمليات الموحدة وتماسك الفريق. | يوفر هذا النمط نهجا لتنفيذ المرونة في تكامل الأدوات التي قد تعزز إمكانية مراقبة التطبيق دون مطالبة التطبيق باتخاذ تبعيات التنفيذ المباشر. فهي تمكن وظائف sidecar من التطور بشكل مستقل والحفاظ عليها بشكل مستقل عن دورة حياة التطبيق. - OE:04 الأدوات والعمليات - نظام المراقبة OE:07 |
| تساعد كفاءة الأداء حمل العمل الخاص بك على تلبية الطلبات بكفاءة من خلال التحسينات في التحجيم والبيانات والرمز. | يمكنك نقل المهام الشاملة إلى عملية واحدة يمكنها التوسع عبر مثيلات متعددة من العملية الرئيسية، ما يقلل من الحاجة إلى نشر وظائف مكررة لكل مثيل من التطبيق. - PE:07 Code والبنية الأساسية |
كما هو الحال مع أي قرار تصميم، ضع في اعتبارك أي مفاضلات ضد أهداف الركائز الأخرى التي يمكن إدخالها مع هذا النمط.
مثال
يعد نمط sidecar قابل للتطبيق على العديد من السيناريوهات. بعض الأمثلة الشائعة:
- البنية الأساسية الخاصة بـ API. يقوم فريق تطوير البنية التحتية بإنشاء خدمة يتم توزيعها جنبًا إلى جنب مع كل تطبيق، بدلاً من مكتبة العميل الخاصة بلغة معينة للوصول إلى البنية الأساسية. يتم تحميل الخدمة كـ sidecar وتوفر طبقة مشتركة لخدمات البنية الأساسية بما في ذلك التسجيل وبيانات البيئة ومخزن التكوين والاكتشاف والفحوصات الصحية وخدمات المراقبة. يراقب sidecar أيضاً بيئة مضيف التطبيق الأصل وعملية (أو الحاوية) ويقوم بتسجيل المعلومات إلى خدمة مركزية.
- قم بإدارة NGINX/HAProxy. قم بتوزيع NGINX مع خدمة sidecar التي تراقب حالة البيئة، ثم تحديث ملف تكوين NGINX وإعادة تدوير العملية عند الحاجة إلى تغيير في الحالة.
- مفوض sidecar. قم بنشر خدمة المفوض كـ sidecar. يستدعي التطبيق من خلال السفير، الذي يتعامل مع طلبات التسجيل والتوجيه وفصل الدائرة والميزات الأخرى المتعلقة بالاتصال.
- قم بإلغاء تحميل الوكيل. قم بوضع وكيل NGINX أمام مثيل خدمة node.js، لمعالجة تقديم محتوى ملف ثابت للخدمة.