توفر هذه البنية إرشادات لتصميم حمل عمل مهم للمهمة على Azure. ويستخدم قدرات السحابة الأصلية لزيادة الموثوقية والفعالية التشغيلية إلى أقصى حد. وهو يطبق منهجية التصميم لأحمال العمل المهمة ذات التصميم الجيد على تطبيق مواجه للإنترنت، حيث يتم الوصول إلى حمل العمل عبر نقطة نهاية عامة ولا يتطلب اتصال شبكة خاصة بموارد الشركة الأخرى.
هام
يتم دعم الإرشادات من خلال تطبيق مثال على مستوى الإنتاج يعرض تطوير التطبيقات الهامة للمهمة على Azure. يمكن استخدام هذا التنفيذ كأساس لمزيد من تطوير الحلول في خطوتك الأولى نحو الإنتاج.
مستوى الموثوقية
الموثوقية هي مفهوم نسبي، ولكى يكون حمل العمل موثوقا به بشكل مناسب، يجب أن يعكس متطلبات العمل المحيطة به، بما في ذلك أهداف مستوى الخدمة (SLO) واتفاقيات مستوى الخدمة (SLA)، لتسجيل النسبة المئوية للوقت الذي يجب أن يكون فيه التطبيق متاحا.
تستهدف هذه البنية SLO بنسبة 99.99٪، والذي يتوافق مع وقت تعطل سنوي مسموح به من 52 دقيقة و35 ثانية. ولذلك تهدف جميع قرارات التصميم الشاملة إلى تحقيق هذا الهدف SLO.
تلميح
لتحديد SLO واقعي، من المهم فهم أهداف الموثوقية لجميع مكونات Azure والعوامل الأخرى ضمن نطاق البنية. لمزيد من المعلومات، راجع توصيات لتحديد أهداف الموثوقية. يجب تجميع هذه الأرقام الفردية لتحديد SLO مركب يجب أن يتوافق مع أهداف حمل العمل.
راجع أحمال العمل المهمة ذات التصميم الجيد: التصميم لمتطلبات الأعمال.
استراتيجيات التصميم الرئيسية
يمكن أن تؤثر العديد من العوامل على موثوقية التطبيق، مثل القدرة على التعافي من الفشل والتوافر الإقليمي وفعالية النشر والأمان. تطبق هذه البنية مجموعة من استراتيجيات التصميم العامة التي تهدف إلى معالجة هذه العوامل وضمان تحقيق مستوى الموثوقية الهدف.
التكرار في الطبقات
التوزيع إلى مناطق متعددة في نموذج نشط-نشط. يتم توزيع التطبيق عبر منطقتين أو أكثر من مناطق Azure التي تتعامل مع حركة مرور المستخدم النشطة.
استخدم مناطق التوفر لجميع الخدمات المدروسة لتحقيق أقصى قدر من التوفر داخل منطقة Azure واحدة، وتوزيع المكونات عبر مراكز بيانات منفصلة فعليا داخل منطقة.
اختر الموارد التي تدعم التوزيع العمومي.
طوابع التوزيع
نشر طابع إقليمي كوحدة مقياس حيث يمكن توفير مجموعة منطقية من الموارد بشكل مستقل لمواكبة التغييرات في الطلب. يطبق كل طابع أيضا وحدات مقياس متداخلة متعددة، مثل واجهات برمجة التطبيقات الأمامية ومعالجات الخلفية التي يمكن توسيع نطاقها وتصغيرها بشكل مستقل.
راجع أحمال العمل ذات المهام الحرجة المصممة جيدا: بنية وحدة المقياس.
عمليات نشر موثوقة وقابلة للتكرار
تطبيق مبدأ البنية الأساسية كتعليق برمجي (IaC) باستخدام تقنيات، مثل Terraform، لتوفير التحكم في الإصدار ونهج تشغيلي موحد لمكونات البنية الأساسية.
تنفيذ مسارات توزيع صفر وقت تعطل أزرق/أخضر. يجب أن تكون البنية الأساسية لبرنامج ربط العمليات التجارية للإنشاء والإصدار تلقائية بالكامل لنشر الطوابع كوحدة تشغيلية واحدة، باستخدام عمليات النشر الزرقاء/الخضراء مع تطبيق التحقق المستمر.
تطبيق تناسق البيئة عبر جميع البيئات المدروسة، بنفس التعليمات البرمجية لمسار التوزيع عبر بيئات الإنتاج وما قبل الإنتاج. هذا يلغي المخاطر المرتبطة بالنشر ومعالجة الاختلافات عبر البيئات.
تحقق من الصحة المستمر من خلال دمج الاختبار التلقائي كجزء من عمليات DevOps، بما في ذلك التحميل المتزامن واختبار الفوضى، للتحقق الكامل من صحة كل من التعليمات البرمجية للتطبيق والبنية الأساسية.
نتائج التحليلات التشغيلية
لديك مساحات عمل متحدة لبيانات إمكانية المراقبة. يتم تخزين بيانات المراقبة للموارد العالمية والموارد الإقليمية بشكل مستقل. لا ينصح بمخزن مركزي لقابلية الملاحظة لتجنب نقطة فشل واحدة. يستخدم الاستعلام عبر مساحة العمل لتحقيق متلقي بيانات موحد وجزء واحد من الزجاج للعمليات.
إنشاء نموذج صحة الطبقات الذي يعين صحة التطبيق إلى نموذج إشارة المرور لوضعها في سياقها. يتم حساب درجات الصحة لكل مكون فردي ثم تجميعها على مستوى تدفق المستخدم ودمجها مع المتطلبات الرئيسية غير الوظيفية، مثل الأداء، كمعاملات لتحديد صحة التطبيق كميا.
راجع أحمال العمل ذات المهام الحرجة المصممة جيدا: نمذجة الصحة.
بناء الأنظمة
*قم بتنزيل ملف Visio لهذه البنية.
يمكن تصنيف مكونات هذه البنية على نطاق واسع بهذه الطريقة. للحصول على وثائق المنتج حول خدمات Azure، راجع الموارد ذات الصلة.
الموارد العمومية
والموارد العالمية تعيش حياة طويلة وتتقاسم مدة بقاء النظام. لديهم القدرة على أن تكون متاحة عالميا في سياق نموذج نشر متعدد المناطق.
فيما يلي الاعتبارات عالية المستوى حول المكونات. للحصول على معلومات مفصلة حول القرارات، راجع الموارد العالمية.
موازن التحميل العمومي
يعد موازن التحميل العالمي أمرا بالغ الأهمية لتوجيه نسبة استخدام الشبكة بشكل موثوق إلى عمليات النشر الإقليمية مع مستوى معين من الضمان استنادا إلى توفر خدمات الواجهة الخلفية في منطقة ما. أيضا، يجب أن يكون لهذا المكون القدرة على فحص حركة مرور الدخول، على سبيل المثال من خلال جدار حماية تطبيق الويب.
يتم استخدام Azure Front Door كنقطة دخول عمومية لجميع حركة مرور HTTP(S) العميل الواردة، مع تطبيق قدرات جدار حماية تطبيق الويب (WAF) لتأمين حركة مرور دخول الطبقة 7. ويستخدم TCP Anycast لتحسين التوجيه باستخدام شبكة Microsoft الأساسية ويسمح بتجاوز الفشل الشفاف في حالة تدهور الصحة الإقليمية. يعتمد التوجيه على فحوصات السلامة المخصصة التي تتحقق من الحرارة المركبة للموارد الإقليمية الرئيسية. يوفر Azure Front Door أيضا شبكة تسليم محتوى مضمنة (CDN) لتخزين الأصول الثابتة لمكون موقع الويب مؤقتا.
خيار آخر هو Traffic Manager، وهو موازن تحميل الطبقة 4 المستندة إلى DNS. ومع ذلك، الفشل غير شفاف لكافة العملاء حيث يجب أن يحدث نشر DNS.
راجع أحمال العمل المهمة ذات التصميم الجيد: توجيه نسبة استخدام الشبكة العالمية.
قاعدة البيانات
يتم تخزين جميع الحالات المتعلقة بعبء العمل في قاعدة بيانات خارجية، Azure Cosmos DB ل NoSQL. تم اختيار هذا الخيار لأنه يحتوي على مجموعة الميزات اللازمة لضبط الأداء والموثوقية، سواء من جانب العميل أو الخادم. يوصى بشدة بتمكين الكتابة متعددة الأشكال الرئيسية للحساب.
إشعار
في حين أن تكوين الكتابة متعددة المناطق يمثل المعيار الذهبي للموثوقية، هناك مفاضلة كبيرة على التكلفة، والتي ينبغي النظر فيها بشكل صحيح.
يتم نسخ الحساب إلى كل طابع إقليمي كما تم تمكين التكرار النطاقي. أيضا، يتم تمكين التحجيم التلقائي على مستوى الحاوية بحيث تقوم الحاويات تلقائيا بتحجيم معدل النقل المقدم حسب الحاجة.
لمزيد من المعلومات، راجع النظام الأساسي للبيانات لأحمال العمل الحرجة للمهام.
راجع أحمال العمل المهمة ذات التصميم الجيد: مخزن البيانات متعدد الكتابة الموزع عالميا.
سجل الحاوية
يستخدم Azure Container Registry لتخزين جميع صور الحاوية. لديها قدرات النسخ المتماثل الجغرافي التي تسمح للموارد بالعمل كسجل واحد، تخدم مناطق متعددة مع سجلات إقليمية متعددة الرئيس.
كإجراء أمني، اسمح فقط بالوصول إلى الكيانات المطلوبة ومصادقة هذا الوصول. على سبيل المثال، في التنفيذ، يتم تعطيل وصول المسؤول. لذلك، يمكن لمجموعة الحوسبة سحب الصور فقط مع تعيينات دور Microsoft Entra.
الموارد الإقليمية
يتم توفير الموارد الإقليمية كجزء من طابع توزيع إلى منطقة Azure واحدة. لا تشترك هذه الموارد في أي شيء مع الموارد في منطقة أخرى. يمكن إزالتها بشكل مستقل أو نسخها نسخا متماثلا إلى مناطق إضافية. ومع ذلك، فإنها تتقاسم الموارد العالمية بين بعضها البعض.
في هذه البنية، يوزع مسار التوزيع الموحد طابعا بهذه الموارد.
فيما يلي الاعتبارات عالية المستوى حول المكونات. للحصول على معلومات مفصلة حول القرارات، راجع موارد الطوابع الإقليمية.
Frontend
تستخدم هذه البنية تطبيق صفحة واحدة (SPA) يرسل طلبات إلى خدمات الواجهة الخلفية. الميزة هي أن الحساب المطلوب لتجربة موقع الويب يتم إلغاء تحميله إلى العميل بدلا من خوادمك. تتم استضافة SPA ك موقع ويب ثابت في حساب تخزين Azure.
خيار آخر هو Azure Static Web Apps، الذي يقدم اعتبارات إضافية، مثل كيفية عرض الشهادات، والاتصال بموازن تحميل عمومي، وعوامل أخرى.
عادة ما يتم تخزين المحتوى الثابت مؤقتا في متجر قريب من العميل، باستخدام شبكة تسليم المحتوى (CDN)، بحيث يمكن تقديم البيانات بسرعة دون الاتصال مباشرة بخوادم الواجهة الخلفية. إنها طريقة فعالة من حيث التكلفة لزيادة الموثوقية وتقليل زمن انتقال الشبكة. في هذه البنية، يتم استخدام قدرات CDN المضمنة في Azure Front Door لتخزين محتوى موقع الويب الثابت مؤقتا في شبكة الحافة.
نظام مجموعة الحساب
تقوم الحوسبة الخلفية بتشغيل تطبيق يتكون من ثلاث خدمات مصغرة وهو عديم الحالة. لذلك، تعد التعبئة في حاويات استراتيجية مناسبة لاستضافة التطبيق. تم اختيار خدمة Azure Kubernetes (AKS) لأنها تلبي معظم متطلبات العمل ويتم اعتماد Kubernetes على نطاق واسع عبر العديد من الصناعات. تدعم AKS تخطيطات قابلية التوسع والتوزيع المتقدمة. يوصى بشدة بمستوى AKS Uptime SLA لاستضافة التطبيقات الهامة للمهمة لأنه يوفر ضمانات توفر لمستوى تحكم Kubernetes.
يقدم Azure خدمات حوسبة أخرى، مثل Azure Functions وAzure App Services. تقوم هذه الخيارات بإلغاء تحميل مسؤوليات الإدارة الإضافية إلى Azure على حساب المرونة والكثافة.
إشعار
تجنب تخزين الحالة على مجموعة الحوسبة، مع الأخذ في الاعتبار الطبيعة المؤقتة للطوابع. قدر الإمكان، استمر في الحالة في قاعدة بيانات خارجية للحفاظ على عمليات التحجيم والاسترداد خفيفة الوزن. على سبيل المثال في AKS، تتغير الحجيرات بشكل متكرر. سيؤدي إرفاق الحالة إلى pods إلى إضافة عبء تناسق البيانات.
راجع أحمال العمل المهمة ذات التصميم الجيد: تزامن الحاويات وKubernetes.
وسيط الرسائل الإقليمية
لتحسين الأداء والحفاظ على الاستجابة أثناء ذروة الحمل، يستخدم التصميم المراسلة غير المتزامنة للتعامل مع تدفقات النظام المكثفة. كما يتم التعرف بسرعة على الطلب مرة أخرى إلى واجهات برمجة التطبيقات الأمامية، يتم أيضا وضع الطلب في قائمة الانتظار في وسيط الرسائل. يتم استهلاك هذه الرسائل لاحقا بواسطة خدمة خلفية، على سبيل المثال، تعالج عملية كتابة إلى قاعدة بيانات.
الطابع بأكمله عديم الحالة إلا في نقاط معينة، مثل وسيط الرسائل هذا. يتم وضع البيانات في قائمة الانتظار في الوسيط لفترة قصيرة من الوقت. يجب أن يضمن وسيط الرسائل التسليم مرة واحدة على الأقل. وهذا يعني أن الرسائل ستكون في قائمة الانتظار، إذا أصبح الوسيط غير متوفر بعد استعادة الخدمة. ومع ذلك، تقع على عاتق المستهلك مسؤولية تحديد ما إذا كانت هذه الرسائل لا تزال بحاجة إلى المعالجة. يتم استنزاف قائمة الانتظار بعد معالجة الرسالة وتخزينها في قاعدة بيانات عمومية.
في هذا التصميم، يتم استخدام Azure Event Hubs . يتم توفير حساب Azure Storage إضافي لنقاط التفتيش. مراكز الأحداث هي الخيار الموصى به لحالات الاستخدام التي تتطلب إنتاجية عالية، مثل تدفق الأحداث.
بالنسبة لحالات الاستخدام التي تتطلب ضمانات رسائل إضافية، يوصى ناقل خدمة Azure. يسمح بالتثبيت على مرحلتين مع مؤشر من جانب العميل، بالإضافة إلى ميزات مثل قائمة انتظار غير مستخدمة مضمنة وقدرات إلغاء التكرار.
لمزيد من المعلومات، راجع خدمات المراسلة لأحمال العمل الحرجة للمهام.
راجع أحمال العمل المهمة ذات التصميم الجيد: البنية المستندة إلى الحدث بشكل فضفاض.
مخزن البيانات السرية الإقليمي
كل طابع له Azure Key Vault الخاص به الذي يخزن الأسرار والتكوين. هناك أسرار شائعة مثل سلسلة الاتصال إلى قاعدة البيانات العمومية ولكن هناك أيضا معلومات فريدة من نوعها لطابع واحد، مثل مراكز الأحداث سلسلة الاتصال. كما أن الموارد المستقلة تتجنب نقطة فشل واحدة.
راجع أحمال العمل المهمة ذات التصميم الجيد: حماية تكامل البيانات.
البنية الأساسية لبرنامج ربط العمليات التجارية للتوز
يجب أن تكون البنية الأساسية لبرنامج ربط العمليات التجارية للإنشاء والإصدار لتطبيق المهام الحرجة مؤتمتة بالكامل. لذلك لا ينبغي تنفيذ أي إجراء يدويا. يوضح هذا التصميم البنية الأساسية لبرنامج ربط العمليات التجارية المؤتمتة بالكامل التي تنشر طابعا تم التحقق من صحته باستمرار في كل مرة. نهج بديل آخر هو نشر التحديثات المتداولة فقط إلى طابع موجود.
مستودع التعليمات البرمجية المصدر
يتم استخدام GitHub للتحكم بالمصادر، ما يوفر نظاما أساسيا يستند إلى git عالي التوفر للتعاون في التعليمات البرمجية للتطبيق ورمز البنية الأساسية.
البنية الأساسية لبرنامج ربط العمليات التجارية للتكامل المستمر/التسليم المستمر (CI/CD)
البنية الأساسية لبرنامج ربط العمليات التجارية المؤتمتة مطلوبة لبناء واختبار ونشر حمل عمل البعثة في بيئات ما قبل الإنتاج والإنتاج . يتم اختيار Azure Pipelines نظرا لمجموعة أدواتها الغنية التي يمكنها استهداف Azure والأنظمة الأساسية السحابية الأخرى.
خيار آخر هو GitHub Actions لتدفقات CI/CD. الميزة المضافة هي أنه يمكن تجميع التعليمات البرمجية المصدر والمسار. ومع ذلك، تم اختيار Azure Pipelines بسبب إمكانات CD الأغنى.
بناء العوامل
يستخدم هذا التنفيذ عوامل البناء المستضافة من قبل Microsoft لتقليل التعقيد والنفقات العامة للإدارة. يمكن استخدام العوامل المستضافة ذاتيا للسيناريوهات التي تتطلب وضعا أمنيا مشددا.
إشعار
ويدل على استخدام الوكلاء المستضافين ذاتيا في التنفيذ المرجعي للمهمة الحرجة - المتصلة .
موارد إمكانية المراقبة
يجب أن تكون البيانات التشغيلية من التطبيق والبنية الأساسية متاحة للسماح بعمليات فعالة وزيادة الموثوقية إلى أقصى حد. يوفر هذا المرجع أساسا لتحقيق إمكانية المراقبة الشاملة للتطبيق.
متلقي بيانات موحد
- يتم استخدام Azure Log Analytics كمتلقي موحد لتخزين السجلات والمقاييس لجميع مكونات التطبيق والبنية الأساسية.
- يتم استخدام Azure Application Insights كأداة إدارة أداء التطبيق (APM) لجمع جميع بيانات مراقبة التطبيق وتخزينها مباشرة داخل Log Analytics.
وينبغي تخزين بيانات الرصد للموارد العالمية والموارد الإقليمية بشكل مستقل. لا ينصح بمخزن واحد ومركزي لقابلية الملاحظة لتجنب نقطة فشل واحدة. يتم استخدام الاستعلام عبر مساحة العمل لتحقيق جزء واحد من الزجاج.
في هذه البنية، يجب أن تكون موارد المراقبة داخل المنطقة مستقلة عن الطابع نفسه، لأنه إذا قمت بهدم طابع، فإنك لا تزال ترغب في الحفاظ على إمكانية المراقبة. يحتوي كل طابع إقليمي على Application Insights ومساحة عمل Log Analytics المخصصة الخاصة به. يتم توفير الموارد لكل منطقة ولكنها تفوق الطوابع.
وبالمثل، يتم تخزين البيانات من الخدمات المشتركة مثل Azure Front Door وAzure Cosmos DB و Container Registry في مثيل مخصص لمساحة عمل Log Analytics.
أرشفة البيانات وتحليلاتها
يتم تصدير البيانات التشغيلية غير المطلوبة للعمليات النشطة من Log Analytics إلى حسابات تخزين Azure لأغراض استبقاء البيانات وتوفير مصدر تحليلي ل AIOps، والذي يمكن تطبيقه لتحسين نموذج صحة التطبيق والإجراءات التشغيلية.
راجع أحمال العمل الحرجة للمهام المصممة جيدا: العمل التنبؤي والعمليات الذكاء الاصطناعي.
تدفقات الطلب والمعالج
تعرض هذه الصورة تدفق معالج الطلب والخلفية للتنفيذ المرجعي.
يتم وصف هذا التدفق في الأقسام التالية.
تدفق طلب موقع الويب
يتم إرسال طلب لواجهة مستخدم الويب إلى موازن تحميل عمومي. لهذه البنية، موازن التحميل العمومي هو Azure Front Door.
يتم تقييم قواعد WAF. تؤثر قواعد WAF بشكل إيجابي على موثوقية النظام من خلال الحماية من مجموعة متنوعة من الهجمات مثل البرمجة النصية عبر المواقع (XSS) وحقن SQL. سيعيد Azure Front Door خطأ إلى الطالب إذا تم انتهاك قاعدة WAF وتوقفت المعالجة. إذا لم يتم انتهاك قواعد WAF، يستمر Azure Front Door في المعالجة.
يستخدم Azure Front Door قواعد التوجيه لتحديد تجمع الواجهة الخلفية لإعادة توجيه الطلب إليه. كيفية مطابقة الطلبات مع قاعدة التحويل. في هذا التنفيذ المرجعي، تسمح قواعد التوجيه ل Azure Front Door بتوجيه طلبات واجهة المستخدم وواجهة برمجة التطبيقات الأمامية إلى موارد خلفية مختلفة. في هذه الحالة، يطابق النمط "/*" قاعدة توجيه واجهة المستخدم. توجه هذه القاعدة الطلب إلى تجمع خلفية يحتوي على حسابات تخزين مع مواقع ويب ثابتة تستضيف تطبيق الصفحة الواحدة (SPA). يستخدم Azure Front Door الأولوية والوزن المعينين للخلفيات في التجمع لتحديد الواجهة الخلفية لتوجيه الطلب. أساليب توجيه نسبة استخدام الشبكة إلى الأصل. يستخدم Azure Front Door فحوصات السلامة لضمان عدم توجيه الطلبات إلى الخلفيات غير السليمة. يتم تقديم SPA من حساب التخزين المحدد مع موقع ويب ثابت.
إشعار
تسمى مصطلحات تجمعات الخلفية والواجهات الخلفية في Azure Front Door Classic مجموعات الأصل والأصول في مستويات Azure Front Door القياسية أو المتميزة.
يقوم SPA باستدعاء واجهة برمجة التطبيقات إلى مضيف الواجهة الأمامية ل Azure Front Door. نمط عنوان URL لطلب واجهة برمجة التطبيقات هو "/api/*".
تدفق طلب واجهة برمجة التطبيقات الأمامية
يتم تقييم قواعد WAF كما في الخطوة 2.
يطابق Azure Front Door الطلب مع قاعدة توجيه واجهة برمجة التطبيقات حسب نمط "/api/*". توجه قاعدة توجيه واجهة برمجة التطبيقات الطلب إلى تجمع الواجهة الخلفية الذي يحتوي على عناوين IP العامة لوحدات تحكم دخول NGINX التي تعرف كيفية توجيه الطلبات إلى الخدمة الصحيحة في خدمة Azure Kubernetes (AKS). كما كان الحال من قبل، يستخدم Azure Front Door الأولوية والوزن المعينين للخلفيات لتحديد الخلفية الصحيحة لوحدة تحكم دخول NGINX.
بالنسبة لطلبات GET، تنفذ واجهة برمجة التطبيقات الأمامية عمليات قراءة على قاعدة بيانات. بالنسبة لهذا التنفيذ المرجعي، قاعدة البيانات هي مثيل Azure Cosmos DB عمومي. يحتوي Azure Cosmos DB على العديد من الميزات التي تجعله خيارا جيدا لحمل عمل مهم للمهمة بما في ذلك القدرة على تكوين مناطق متعددة الكتابة بسهولة، ما يسمح بتجاوز الفشل التلقائي للقراءة والكتابة إلى المناطق الثانوية. تستخدم واجهة برمجة التطبيقات SDK العميل الذي تم تكوينه باستخدام منطق إعادة المحاولة للاتصال ب Azure Cosmos DB. تحدد SDK الترتيب الأمثل لمناطق Azure Cosmos DB المتوفرة للاتصال بها استنادا إلى معلمة ApplicationRegion.
بالنسبة لطلبات POST أو PUT، تقوم واجهة برمجة تطبيقات الواجهة الأمامية بإجراء عمليات الكتابة إلى وسيط الرسائل. في التنفيذ المرجعي، وسيط الرسائل هو Azure Event Hubs. يمكنك اختيار ناقل خدمة Microsoft Azure بدلا من ذلك. سيقوم المعالج لاحقا بقراءة الرسائل من وسيط الرسائل وتنفيذ أي عمليات كتابة مطلوبة إلى Azure Cosmos DB. تستخدم واجهة برمجة التطبيقات SDK العميل لتنفيذ عمليات الكتابة. يمكن تكوين العميل لإعادة المحاولة.
تدفق معالج الخلفية
تعالج معالجات الخلفية الرسائل من وسيط الرسائل. تستخدم معالجات الخلفية SDK العميل لإجراء القراءات. يمكن تكوين العميل لإعادة المحاولة.
تقوم معالجات الخلفية بتنفيذ عمليات الكتابة المناسبة على مثيل Azure Cosmos DB العمومي. تستخدم معالجات الخلفية SDK العميل الذي تم تكوينه مع إعادة المحاولة للاتصال ب Azure Cosmos DB. يمكن تكوين قائمة المنطقة المفضلة للعميل مع مناطق متعددة. في هذه الحالة، إذا فشلت الكتابة، إعادة المحاولة في المنطقة المفضلة التالية.
مناطق التصميم
نقترح عليك استكشاف مجالات التصميم هذه للحصول على توصيات وإرشادات أفضل الممارسات عند تحديد البنية الحرجة للمهمة.
| منطقة التصميم | الوصف |
|---|---|
| تصميم التطبيق | تصميم أنماط تسمح بالتحجيم ومعالجة الأخطاء. |
| النظام الأساسي للتطبيق | خيارات البنية الأساسية والتخفيف من حالات الفشل المحتملة. |
| النظام الأساسي للبيانات | الخيارات في تقنيات مخزن البيانات، مستنيرة من خلال تقييم خصائص الحجم والسرعة والتنوع والصدق المطلوبة. |
| الشبكات والاتصال | اعتبارات الشبكة لتوجيه نسبة استخدام الشبكة الواردة إلى الطوابع. |
| نمذجة الصحة | ترتبط اعتبارات إمكانية المراقبة من خلال تحليل تأثير العميل بالمراقبة لتحديد صحة التطبيق بشكل عام. |
| النشر والاختبار | استراتيجيات لتدفقات CI/CD واعتبارات الأتمتة، مع سيناريوهات اختبار مدمجة، مثل اختبار التحميل المتزامن واختبار حقن الفشل (الفوضى). |
| الأمان | التخفيف من مخاطر الهجوم من خلال نموذج Microsoft ثقة معدومة. |
| الإجراءات التشغيلية | العمليات المتعلقة بالنشر وإدارة المفاتيح والتصحيح والتحديثات. |
** يشير إلى اعتبارات منطقة التصميم الخاصة بهذه البنية.
الموارد ذات الصلة
للحصول على وثائق المنتج حول خدمات Azure المستخدمة في هذه البنية، راجع هذه المقالات.
- Azure Front Door
- Azure Cosmos DB
- Azure Container Registry
- Azure Log Analytics
- Azure Key Vault
- ناقل خدمة Azure
- Azure Kubernetes Service
- Azure Application Insights
- مراكز أحداث Azure
- مخزن البيانات الثنائية كبيرة الحجم لـ Azure
توزيع هذا الهيكل
نشر التنفيذ المرجعي للحصول على فهم كامل للموارد المدروسة، بما في ذلك كيفية تشغيلها في سياق بالغ الأهمية للمهمة. يحتوي على دليل توزيع يهدف إلى توضيح نهج موجه نحو الحل لتطوير التطبيقات ذات المهام الحرجة على Azure.
الخطوات التالية
إذا كنت ترغب في توسيع بنية الأساس مع عناصر تحكم الشبكة في حركة مرور الدخول والخروج، فشاهد هذه البنية.