تقليل التنسيق لتحقيق قابلية التوسع
تتكون معظم تطبيقات السحابة من خدمات تطبيقات متعددة - واجهات الويب الأمامية وقواعد البيانات والعمليات التجارية وإعداد التقارير والتحليل وما إلى ذلك. لتحقيق قابلية التوسع والموثوقية، يجب تشغيل كل من هذه الخدمات على مثيلات متعددة.
الأنظمة غير المنسقة، حيث يمكن التعامل مع العمل بشكل مستقل دون الحاجة إلى تمرير الرسائل بين الأجهزة، تكون أبسط عموما في التحجيم. التنسيق عادة ليس حالة ثنائية، ولكن طيف. يحدث التنسيق في طبقات مختلفة، مثل البيانات أو الحساب.
ماذا يحدث عندما تحاول حالتان إجراء عمليات متزامنة تؤثر على حالة مشتركة ما؟ في بعض الحالات، يجب أن يكون هناك تنسيق عبر العقد، على سبيل المثال للحفاظ على ضمانات ACID. في هذا الرسم التخطيطي، ينتظر Node2 Node1 لتحرير قفل قاعدة البيانات:
يحد التنسيق من فوائد المقياس الأفقي ويخلق اختناقات. في هذا المثال، عندما تقوم بتوسيع نطاق التطبيق وإضافة المزيد من الحالات، سترى زيادة في تنازع القفل. في أسوأ الحالات، ستقضي مثيلات الواجهة الأمامية معظم وقتها في انتظار الأقفال.
دلالات "مرة واحدة بالضبط" هي مصدر آخر متكرر للتنسيق. على سبيل المثال، يجب معالجة الطلب مرة واحدة بالضبط. عاملان يستمعان لأوامر جديدة. Worker1 يستلم طلبًا للمعالجة. يجب أن يتأكد التطبيق من أن Worker2 لا يكرر العمل، ولكن أيضًا في حالة تعطل Worker1، لا يتم إسقاط الطلب.
يمكنك استخدام نمط مثل مجدول وكيل المشرف للتنسيق بين العمال، ولكن في هذه الحالة قد يكون الأسلوب الأفضل هو تقسيم العمل. يتم تعيين نطاق معين من الطلبات لكل عامل (على سبيل المثال، حسب منطقة الفوترة). إذا تعطل عامل، فإن المثيل الجديد ينتقل من حيث توقف المثيل السابق، ولكن لا يتم التنافس على مثيلات متعددة.
التوصيات
استخدم المكونات المنفصلة التي تتصل بشكل غير متزامن. يجب أن تستخدم المكونات الأحداث بشكل مثالي للتواصل مع بعضها البعض.
اختر الاتساق النهائي. عند توزيع البيانات، يتطلب الأمر تنسيقًا لفرض ضمانات تناسق قوية. على سبيل المثال، افترض أن عملية ما تقوم بتحديث قاعدتي بيانات. بدلاً من وضعها في نطاق معاملة واحدة، من الأفضل أن يتمكن النظام من استيعاب الاتساق النهائي، ربما باستخدام نمط معاملة التعويض للتراجع المنطقي بعد الفشل.
استخدم أحداث المجال لمزامنة الحالة. حدث النطاق هو حدث يسجل وقت حدوث شيء له أهمية داخل النطاق. يمكن للخدمات المهتمة الاستماع إلى الحدث، بدلاً من استخدام معاملة عالمية للتنسيق عبر خدمات متعددة. إذا تم استخدام هذا الأسلوب، يجب أن يتسامح النظام مع الاتساق النهائي (انظر العنصر السابق).
ضع في اعتبارك أنماطًا مثل CQRS وتحديد مصادر الأحداث. يمكن أن يساعد هذان النموذجان في تقليل الخلاف بين أحمال عمل القراءة والكتابة.
يفصل نمط CQRS عمليات القراءة عن عمليات الكتابة. في بعض التطبيقات، يتم فصل البيانات المقروءة فعليًا عن بيانات الكتابة.
في نمط Event Sourcing، يتم تسجيل تغييرات الحالة كسلسلة من الأحداث في مخزن بيانات الإلحاق فقط. يُعد إلحاق حدث بالتيار عملية ذرية تتطلب الحد الأدنى من التأمين.
هذان النموذجان يكملان بعضهما بعضًا. إذا كان مخزن الكتابة فقط في CQRS يستخدم مصادر الأحداث، فيمكن لمتجر القراءة فقط الاستماع لنفس الأحداث لإنشاء لقطة قابلة للقراءة للحالة الحالية، ومُحسّنة للاستعلامات. قبل اعتماد CQRS أو تحديد مصادر الأحداث، كن على دراية بالتحديات التي تواجه هذا النهج.
تقسيم البيانات والحالة. تجنب وضع كل بياناتك في مخطط بيانات واحد يتم مشاركته عبر العديد من خدمات التطبيقات. تفرض بنية الخدمات المصغرة هذا المبدأ بجعل كل خدمة مسؤولة عن مخزن البيانات الخاص بها. ضمن قاعدة بيانات واحدة، يمكن أن يؤدي تقسيم البيانات إلى أجزاء إلى تحسين التزامن، لأن كتابة الخدمة في جزء واحد لا تؤثر على خدمة الكتابة إلى جزء مختلف. على الرغم من أن التقسيم يضيف درجة معينة من التنسيق، يمكنك استخدام التقسيم لزيادة التوازي لتحسين قابلية التوسع. قسم الحالة المتجانسة إلى أجزاء أصغر بحيث يمكن إدارة البيانات بشكل مستقل.
تصميم عمليات متكررة. عندما يكون ذلك ممكنًا، يجب أن تكون عمليات التصميم عاطلة عن العمل. بهذه الطريقة، يمكن التعامل معها باستخدام دلالات مرة واحدة على الأقل. على سبيل المثال، يمكنك وضع عناصر العمل في قائمة انتظار. إذا تحطم عامل في منتصف العملية، فسيقوم عامل آخر بالتقاط عنصر العمل. إذا كان العامل بحاجة إلى تحديث البيانات بالإضافة إلى إرسال رسائل أخرى كجزء من منطقه، يجب استخدام نمط معالجة الرسائل غير المتكررة.
استخدم التزامن المتفائل عندما يكون ذلك ممكنًا. يستخدم التحكم في التزامن المتشائم أقفال قاعدة البيانات لمنع التعارضات. يمكن أن يتسبب هذا في ضعف الأداء وتقليل التوفر. مع التحكم في التزامن المتفائل، تقوم كل معاملة بتعديل نسخة أو لقطة من البيانات. عند تنفيذ المعاملة، يتحقق محرك قاعدة البيانات من صحة المعاملة ويرفض أي معاملات قد تؤثر على اتساق قاعدة البيانات.
تدعم قاعدة بيانات Azure SQL وSQL Server التزامن المتفائل من خلال عزل اللقطة. تدعم بعض خدمات تخزين Azure التزامن المتفائل من خلال استخدام Etags، بما في ذلك Azure Cosmos DB وAzure Storage.
ضع في اعتبارك MapReduce أو خوارزميات أخرى موزعة متوازية. اعتمادًا على البيانات ونوع العمل الذي يتعين القيام به، قد تتمكن من تقسيم العمل إلى مهام مستقلة يمكن أن تؤديها عدة عقد تعمل بالتوازي. راجع أسلوب هندسة الحوسبة الكبيرة.
استخدم انتخاب القائد للتنسيق. في الحالات التي تحتاج فيها إلى تنسيق العمليات، تأكد من أن المنسق لا يصبح نقطة فشل واحدة في التطبيق. باستخدام نمط انتخاب القائد، يكون أحد الأمثلة هو القائد في أي وقت ويعمل كمنسق. إذا فشل القائد، يتم انتخاب مثيل جديد ليكون القائد.