مشاركة عبر

النظام الأساسي للبيانات لأحمال العمل ذات المهام الحرجة على Azure

  • مقالة

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

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

في هذه البنية، هناك مخزنان للبيانات:

  • قاعدة بيانات

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

    يوصى بشدة بالنسخ المتماثل للبيانات في تكوين نشط-نشط. يجب أن يكون التطبيق قادرا على الاتصال على الفور بمنطقة أخرى. يجب أن تكون جميع المثيلات قادرة على معالجة طلبات القراءة والكتابة.

  • وسيط الرسائل

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

للحصول على اعتبارات البيانات الأخرى، راجع إرشادات ميزون الحرجة في إطار عمل جيد التصميم: اعتبارات النظام الأساسي للبيانات.

قاعدة البيانات

تستخدم هذه البنية Azure Cosmos DB ل NoSQL. يتم اختيار هذا الخيار لأنه يوفر معظم الميزات المطلوبة في هذا التصميم:

  • الكتابة متعددة المناطق

    يتم تمكين الكتابة متعددة المناطق مع النسخ المتماثلة المنشورة في كل منطقة يتم فيها نشر طابع. يمكن لكل طابع الكتابة محليا ويعالج Azure Cosmos DB النسخ المتماثل للبيانات والمزامنة بين الطوابع. تقلل هذه الإمكانية بشكل كبير من زمن الانتقال للمستخدمين النهائيين الموزعين جغرافيا للتطبيق. يستخدم التنفيذ المرجعي ل Azure Mission-Critical تقنية متعددة المستويات لتوفير أقصى قدر من المرونة والتوافر.

    يتم تمكين تكرار المنطقة أيضا داخل كل منطقة منسوخة نسخا متماثلا.

    للحصول على تفاصيل حول عمليات الكتابة متعددة المناطق، راجع تكوين عمليات الكتابة متعددة المناطق في تطبيقاتك التي تستخدم Azure Cosmos DB.

  • إدارة التعارضات

    مع القدرة على إجراء عمليات الكتابة عبر مناطق متعددة تأتي ضرورة اعتماد نموذج إدارة التعارض حيث يمكن للكتابات المتزامنة أن تقدم تعارضات في السجلات. Last Writer Wins هو النموذج الافتراضي ويستخدم لتصميم Mission Critical. الكاتب الأخير، كما هو محدد بواسطة الطوابع الزمنية المقترنة بالسجلات يفوز بالتعارض. يسمح Azure Cosmos DB ل NoSQL أيضا بتعريف خاصية مخصصة.

  • تحسين الاستعلام

    توصية كفاءة الاستعلام العامة للحاويات كثيفة القراءة مع عدد كبير من الأقسام هي إضافة عامل تصفية المساواة مع معرف العنصر المحدد. يمكن العثور على مراجعة متعمقة لتوصيات تحسين الاستعلام في استكشاف مشكلات الاستعلام وإصلاحها عند استخدام Azure Cosmos DB.

  • ميزة النسخ الاحتياطي

    يوصى باستخدام ميزة النسخ الاحتياطي الأصلية ل Azure Cosmos DB لحماية البيانات. تدعم ميزة النسخ الاحتياطي ل Azure Cosmos DB النسخ الاحتياطي عبر الإنترنت واستعادة البيانات عند الطلب.

إشعار

معظم أحمال العمل ليست OLTP فقط. وهناك طلب متزايد على الإبلاغ في الوقت الحقيقي، مثل تشغيل التقارير مقابل النظام التشغيلي. ويشار إلى هذا أيضاً باسم HTAP (المعالجة المختلطة للعمليات والتحليلات). يدعم Azure Cosmos DB هذه الإمكانية عبر Azure Synapse Link ل Azure Cosmos DB.

نموذج البيانات لحمل العمل

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

حمل العمل له خصائص الوصول إلى البيانات هذه:

  • نمط القراءة:
    • قراءات النقاط - إحضار سجل واحد. يتم استخدام معرف العنصر ومفتاح القسم مباشرة لتحقيق أقصى قدر من التحسين (1 RU لكل طلب).
    • قراءات القائمة - الحصول على عناصر الكتالوج لعرضها في قائمة. FeedIterator مع الحد من عدد النتائج يتم استخدام.
  • نمط الكتابة:
    • عمليات الكتابة الصغيرة - عادة ما تدرج الطلبات عددا واحدا أو صغيرا من السجلات في المعاملة.
  • مصمم للتعامل مع نسبة استخدام الشبكة العالية من المستخدمين النهائيين مع القدرة على التوسع للتعامل مع الطلب على نسبة استخدام الشبكة بترتيب الملايين من المستخدمين.
  • حمولة صغيرة أو حجم مجموعة البيانات - عادة بترتيب KB.
  • وقت استجابة منخفض (بالترتيب بالمللي ثانية).
  • زمن انتقال منخفض (بالترتيب بالمللي ثانية).

التكوين

تم تكوين Azure Cosmos DB على النحو التالي:

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

    إشعار

    يوفر مستوى تناسق الجلسة مقايضة معقولة لزمن الانتقال والتوافر وضمانات التناسق لهذا التطبيق المحدد. من المهم أن نفهم أن مستوى التناسق القوي غير متوفر لقواعد بيانات الكتابة متعددة المستويات الرئيسية.

  • تم تعيين مفتاح القسم إلى /id لكافة المجموعات. يستند هذا القرار إلى نمط الاستخدام، والذي يكون في الغالب "كتابة مستندات جديدة باستخدام GUID كمعرف" و"قراءة مجموعة واسعة من المستندات حسب المعرفات". توفير التعليمات البرمجية للتطبيق يحافظ على تفرد المعرف الخاص به، يتم توزيع البيانات الجديدة بالتساوي في أقسام بواسطة Azure Cosmos DB، ما يتيح مقياسا لا نهائي.

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

فيما يلي مثال من التنفيذ يعرض إعدادات نهج الفهرسة باستخدام Terraform:

indexing_policy {

  excluded_path {
    path = "/description/?"
  }

  excluded_path {
    path = "/comments/text/?"
  }

  included_path {
    path = "/*"
  }

}

للحصول على معلومات حول الاتصال من التطبيق إلى Azure Cosmos DB في هذه البنية، راجع اعتبارات النظام الأساسي للتطبيق لأحمال العمل الحرجة للمهام

خدمات المراسلة

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

  • يوصى ناقل خدمة Azure لأحمال العمل المستندة إلى الرسائل عند معالجة الرسائل عالية القيمة.
  • يوصى باستخدام Azure Event Hubs للأنظمة المستندة إلى الأحداث التي تعالج كميات كبيرة من الأحداث أو بيانات تتبع الاستخدام.

فيما يلي اعتبارات التصميم والتوصيات ناقل خدمة Azure المتميزة ومراكز أحداث Azure في بنية مهمة مهمة.

معالجة التحميل

يجب أن يكون نظام المراسلة قادرا على معالجة معدل النقل المطلوب (كما هو الحال في ميغابايت في الثانية). النظر في ما يلي:

  • يجب أن تحدد المتطلبات غير الوظيفية (NFRs) للنظام متوسط حجم الرسالة وأقصى عدد من الرسائل/الثانية التي يجب أن يدعمها كل طابع. يمكن استخدام هذه المعلومات لحساب ذروة MB/second المطلوبة لكل طابع.
  • يجب مراعاة تأثير تجاوز الفشل عند حساب الذروة المطلوبة MB/second لكل طابع.
  • على سبيل ناقل خدمة Azure، يجب أن تحدد NFRs أي ميزات متقدمة لناقل خدمة Microsoft Azure مثل الجلسات ورسائل إلغاء ال duping. ستؤثر هذه الميزات على معدل نقل ناقل خدمة Microsoft Azure.
  • يجب حساب معدل نقل ناقل خدمة Microsoft Azure بالميزات المطلوبة من خلال الاختبار كميغابايت/ثانية لكل وحدة مراسلة (MU). لمزيد من المعلومات حول هذا الموضوع، راجع مستويات المراسلة المميزة والقياسية لناقل خدمة Microsoft Azure.
  • يجب حساب معدل نقل Azure Event Hubs من خلال الاختبار كميغابايت/ثانية لكل وحدة إنتاجية (TU) للمستوى القياسي أو وحدة المعالجة (PU) للطبقة المتميزة. لمزيد من المعلومات حول هذا الموضوع، راجع التحجيم باستخدام مراكز الأحداث.
  • يمكن استخدام العمليات الحسابية أعلاه للتحقق من أن خدمة المراسلة يمكنها معالجة الحمل المطلوب لكل طابع، والعدد المطلوب من وحدات المقياس المطلوبة لتلبية هذا التحميل.
  • سيناقش قسم العمليات التحجيم التلقائي.

يجب معالجة كل رسالة

ناقل خدمة Azure المستوى المتميز هو الحل الموصى به للرسائل عالية القيمة التي يجب ضمان المعالجة لها. فيما يلي تفاصيل حول هذا المطلب عند استخدام ناقل خدمة Azure المميز:

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

  • لضمان معالجة الرسائل على الحافلة، يجب استخدام وضع تلقي PeekLock. يتيح هذا الوضع المعالجة مرة واحدة على الأقل. يوضح ما يلي العملية:

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

  • نظرا لأنه من المحتمل أن تتم معالجة الرسائل أكثر من مرة واحدة، يجب جعل معالجات الرسائل غير فعالة.

معالجة الرسائل المتكررة

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

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

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

قابلية الوصول العالية والتعافي من الكوارث

يجب أن يكون وسيط الرسائل متاحا للمنتجين لإرسال الرسائل والمستهلكين لتلقيها. فيما يلي تفاصيل حول هذا المطلب:

  • لضمان أعلى توفر مع ناقل خدمة Microsoft Azure، استخدم المستوى المتميز، الذي يحتوي على دعم لمناطق التوفر في المناطق الداعمة. مع مناطق التوفر، يتم نسخ الرسائل وبيانات التعريف عبر ثلاثة مراكز بيانات متباينة في نفس المنطقة.
  • استخدم ناقل خدمة Microsoft Azure أو مجموعات SDK لمراكز الأحداث المدعومة لإعادة محاولة فشل القراءة أو الكتابة تلقائيا.
  • ضع في اعتبارك النسخ المتماثل النشط-النشط أو أنماط النسخ المتماثل النشط-السلبي للعزل ضد الكوارث الإقليمية.

إشعار

ناقل خدمة Azure التعافي من الكوارث الجغرافية ينسخ بيانات التعريف عبر المناطق فقط. لا تقوم هذه الميزة بنسخ الرسائل نسخا متماثلا.

مراقبة‬

يعمل نظام المراسلة كمخزن مؤقت بين منتجي الرسائل والمستهلكين. هناك أنواع مؤشرات رئيسية يجب مراقبتها في نظام مهم يوفر رؤى قيمة موضحة أدناه:

  • التقييد - يشير التقييد إلى أن النظام ليس لديه الموارد المطلوبة لمعالجة الطلب. يدعم كل من ناقل خدمة Microsoft Azure ومراكز الأحداث مراقبة الطلبات المقيدة. يجب التنبيه على هذا المؤشر.
  • عمق قائمة الانتظار - يمكن أن يشير عمق قائمة الانتظار المتزايد إلى أن معالجات الرسائل لا تعمل أو لا توجد معالجات كافية للتعامل مع الحمل الحالي. يمكن استخدام عمق قائمة الانتظار لإبلاغ منطق التحجيم التلقائي للمعالجات.
    • بالنسبة لناقل خدمة Microsoft Azure، يتم عرض عمق قائمة الانتظار كعدد رسائل
    • بالنسبة لمراكز الأحداث، يتعين على المستهلكين حساب عمق قائمة الانتظار لكل قسم ودفع المقياس إلى برنامج المراقبة الخاص بك. لكل قراءة، يحصل المستهلك على رقم تسلسل الحدث الحالي، وخصائص الحدث لآخر حدث مدرج في قائمة الانتظار. يمكن للمستهلك حساب الإزاحة.
  • قائمة انتظار غير مستخدمة - تمثل الرسائل الموجودة في قائمة انتظار الرسائل غير المستخدمة الرسائل التي تعذرت معالجتها. عادة ما تتطلب هذه الرسائل تدخلا يدويا. يجب تعيين التنبيهات على قائمة انتظار الرسائل غير المستخدمة.
    • يحتوي ناقل خدمة Microsoft Azure على قائمة انتظار غير مستخدمة ومقياس DeadLetteredMessages.
    • بالنسبة لمراكز الأحداث، يجب أن تكون هذه الوظيفة منطقا مخصصا مضمنا في المستهلك.
  • استخدام وحدة المعالجة المركزية/الذاكرة - يجب مراقبة وحدة المعالجة المركزية والذاكرة لضمان أن نظام المراسلة يحتوي على موارد كافية لمعالجة الحمل الحالي. يعرض كل من ناقل خدمة Microsoft Azure المتميز ومراكز الأحداث المتميزة استخدام وحدة المعالجة المركزية والذاكرة.
    • يتم استخدام وحدات المراسلة (MUs) في ناقل خدمة Microsoft Azure لعزل الموارد مثل وحدة المعالجة المركزية والذاكرة لمساحة الاسم. يمكن أن تشير وحدة المعالجة المركزية والذاكرة التي تزيد عن الحد إلى عدم وجود وحدات MUs كافية تم تكوينها، بينما يمكن أن يشير انخفاضها إلى أقل من الحدود الأخرى إلى وجود عدد كبير جدا من وحدات MUs التي تم تكوينها. يمكن استخدام هذه المؤشرات لتوسيع نطاق وحدات MUs تلقائيا.
    • يستخدم المستوى المتميز لمراكز الأحداث وحدات المعالجة (PUs) لعزل الموارد، بينما يستخدم المستوى القياسي وحدات معدل النقل (TUs). لا تتطلب هذه المستويات التفاعل مع وحدة المعالجة المركزية/الذاكرة للتضخيم التلقائي لوحدات المعالجة المركزية أو وحدات TUs.

فحص الصحة

يجب النظر في صحة نظام المراسلة في عمليات التحقق من الصحة لتطبيق مهم للمهمة. تأمل العوامل التالية:

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

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

انشر التنفيذ المرجعي للحصول على فهم كامل للموارد وتكوينها المستخدم في هذه البنية.

التنفيذ: مهمة حرجة على الإنترنت