نمط رأس مجمع

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

السياق والمشكلة

قد يتضمن التطبيق المستند إلى السحابة خدمات متعددة، مع وجود مستهلك واحد أو أكثر لكل خدمة. سيؤثر التحميل المفرط أو الفشل في الخدمة على جميع مستهلكي الخدمة.

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

تؤثر نفس مشكلة استنفاد الموارد على الخدمات مع العديد من المستهلكين. قد يستنفد عدد كبير من الطلبات التي تنشأ من عميل واحد الموارد المتوفرة في الخدمة. لم يعد المستهلكون الآخرون قادرين على استهلاك الخدمة، مما تسبب في حدوث تأثير فشل متتالي.

حل

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

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

وتشمل فوائد هذا النمط ما يلي:

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

يوضح الرسم التخطيطي التالي الرؤوس المجمعة المنظمة حول تجمعات الاتصال التي تستدعي الخدمات الفردية. إذا فشلت الخدمة A أو سببت مشكلة أخرى، يتم عزل تجمع الاتصال، لذلك تتأثر أحمال العمل التي تستخدم تجمع مؤشرات الترابط المعينة للخدمة A فقط. لا تتأثر أحمال العمل التي تستخدم الخدمة B وC ويمكنها متابعة العمل دون انقطاع.

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

المسائل والاعتبارات

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

موعد استخدام النمط

استخدم هذا النمط من أجل:

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

قد لا يكون هذا النمط مناسبًا عندما:

• قد لا يكون استخدام الموارد الأقل كفاءة مقبولًا في المشروع.
• التعقيد الإضافي ليس ضروريًا

تصميم حمل العمل

يجب على المهندس المعماري تقييم كيفية استخدام نمط Bulkhead في تصميم حمل العمل الخاص بهم لمعالجة الأهداف والمبادئ التي تغطيها ركائز Azure Well-Architected Framework. على سبيل المثال:

كما هو الحال مع أي قرار تصميم، ضع في اعتبارك أي مفاضلات ضد أهداف الركائز الأخرى التي يمكن إدخالها مع هذا النمط.

مثال

ينشئ ملف تكوين Kubernetes التالي حاوية معزولة لتشغيل خدمة واحدة، مع موارد وحدود وحدة المعالجة المركزية والذاكرة الخاصة بها.

apiVersion: v1
kind: Pod
metadata:
  name: drone-management
spec:
  containers:
  - name: drone-management-container
    image: drone-service
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "1"

الخطوات التالية

• تصميم تطبيقات Azure الموثوقة

الموارد ذات الصلة

• نمط قاطع الدائرة
• نمط إعادة المحاولة
• نمط التقييد