توزيع Azure Spring Apps إلى مناطق متعددة

تصف هذه البنية المرجعية نهجا لتشغيل مثيلات Azure Spring Apps المتعددة عبر المناطق في تكوين نشط-نشط.

يعتمد هذا التصميم على البنية الأساسية ل Azure Spring Apps. ينشر الأساس تطبيق Java Spring Boot إلى مناطق توفر متعددة داخل منطقة واحدة. تنشر المناطق المتعددة حمل عمل التطبيق عبر مواقع منفصلة بحيث يمكن أن يتسامح حمل العمل مع حالات الفشل المحلية داخل منطقة Azure.

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

هذه البنية مفيدة لتحقيق الأهداف التالية:

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

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

يتمثل التحدي الأكبر في إعداد متعدد المناطق في النسخ المتماثل للبيانات للتطبيق الخاص بك بين مناطق متعددة. هذه المشكلة ليست مصدر قلق مع الإعداد متعدد المناطق. يتم توصيل مناطق توفر Azure بواسطة شبكة عالية الأداء مع زمن انتقال ذهابا وإيابا أقل من 2 مللي ثانية. فترة زمن الانتقال هذه كافية لمعظم التطبيقات.

بناء الأنظمة

يوضح الرسم التخطيطي التالي بنية هذا النهج:

المكونات

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

• يعمل Azure Front Door كموازن تحميل عمومي. يتم استخدام هذه الخدمة بسبب قدرتها على توفير توفر أعلى مع زمن انتقال أقل ومقياس أكبر والتخزين المؤقت على الحافة.

‏‏سير العمل‬

تنفذ البنية المرجعية سير العمل التالي:

1. يرسل المستخدم طلبا إلى اسم مضيف HTTP للتطبيق، مثل www.contoso.com. يحل Azure DNS طلب اسم المضيف هذا إلى Azure Front Door.

2. يستخدم Azure Front Door تكوينات موازنة التحميل المختلفة لإعادة توجيه الطلبات الواردة إلى نقطة النهاية العامة لبوابة تطبيق Azure في كل منطقة. يتم تكوين مثيلات Application Gateway بنفس اسم المجال المخصص واسم شهادة TLS مثل Azure Front Door.

3. تقوم بوابة التطبيق مع Azure Web Application Firewall المتكامل بفحص الطلب. يسمح Web Application Firewall بالطلبات الواردة فقط من ملف تعريف Azure Front Door المحدد.

4. تقوم بوابة التطبيق بإعادة توجيه نسبة استخدام الشبكة المسموح بها إلى عنوان IP لموازن التحميل في مثيل Spring Apps المتوفر.

5. يقوم موازن التحميل الداخلي بتوجيه نسبة استخدام الشبكة فقط من بوابة التطبيق إلى الخدمات الخلفية. تتم استضافة هذه الخدمات في مثيل Spring Apps داخل شبكة ظاهرية في كل منطقة.

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

التوزيع العالمي

إذا كنت تصمم لقابلية وصول عالية، يمكنك إعداد هذه البنية في وضع الاستعداد النشط النشط، أو النشط-السلبي مع وضع الاستعداد السريع، أو نشط-سلبي مع وضع الاستعداد البارد.

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

نشط-نشط

في الوضع النشط-النشط، تعالج جميع المناطق الطلبات في وقت واحد. يتمثل التحدي الأكبر في الوضع النشط-النشط في الاحتفاظ بمزامنة البيانات بين المناطق. هذا الوضع هو نهج مكلف لأنك تدفع مرتين مقابل جميع المكونات تقريبا.

نشط-سلبي مع وضع الاستعداد السريع

في الوضع النشط-السلبي مع وضع الاستعداد السريع، لا تتلقى المنطقة الثانوية أي طلبات من Azure Front Door طالما أن المنطقة الأساسية نشطة. تأكد من نسخ بيانات التطبيق من منطقتك الأساسية إلى منطقتك الثانوية. إذا حدث فشل في منطقتك الأساسية، فأنت بحاجة إلى تغيير أدوار قواعد البيانات الخلفية الخاصة بك وتجاوز الفشل عبر نسبة استخدام الشبكة عبر Azure Front Door إلى منطقتك الثانوية.

في الوضع النشط-السلبي، من المتوقع أن يستغرق تجاوز الفشل بعض الوقت، مما يسهل التأكد من بقاء جميع البيانات متزامنة. ومع ذلك، فإن الوضع النشط-السلبي مع وضع الاستعداد السريع مكلف مثل العمل مع الوضع النشط-النشط.

نشط-سلبي مع وضع الاستعداد البارد

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

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

إذا كان إعداد الحل بأكمله يستخدم قوالب، يمكنك بسهولة نشر منطقة ثانوية في وضع الاستعداد البارد عن طريق إنشاء مواردها حسب الحاجة. يمكنك استخدام قوالب Terraform أو Bicep أو Azure Resource Manager، وأتمتة إعداد البنية الأساسية في مسار تكامل/نشر مستمر (CI/CD). يجب عليك اختبار التكوين بانتظام عن طريق إعادة إنشاء منطقتك الثانوية للتأكد من أن القوالب قابلة للنشر في حالات الطوارئ.

يوصى بنمط طوابع التوزيع لأنه يمكن نشر نسخ مستقلة متعددة من تطبيق أو مكون من قالب واحد إلى مناطق متعددة.

مقارنة الوضع

يلخص الجدول التالي الجهد المطلوب لمزامنة البيانات لكل وضع ويقارن التكلفة.

التوجيه بين المناطق

تستخدم هذه البنية المرجعية العقد الجغرافية (Geodes) حيث يمكن لأي منطقة خدمة أي طلب.

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

يستخدم مثال البنية المرجعية قاعدة موازنة تحميل متساوية الوزن بين المنطقتين. تم تكوين Azure Front Door باستخدام:

• مجال مخصص وشهادة أمان طبقة النقل (TLS) بنفس اسم مضيف التطبيق مثل www.contoso.com.

• أصل واحد لكل منطقة يتم فيها نشر التطبيق، حيث كل أصل هو مثيل Azure Application Gateway .

تخطيط مجموعة الموارد

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

يوضح الرسم التخطيطي التكوين التالي لمجموعات الموارد:

• يتم نشر Azure Front Door في Application-shared مجموعة الموارد.
• يتم نشر جميع الموارد المستضافة في منطقة غرب أوروبا (weu) في Application-weu مجموعة الموارد.
• تتم استضافة الموارد المستضافة في منطقة شرق الولايات المتحدة (eus) في Application-eus مجموعة الموارد.
• تتم استضافة الموارد المستضافة في منطقة شرق اليابان (jae) في Application-jae مجموعة الموارد.

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

عكس إعداد الوكيل

يقوم Azure Front Door بموازنة التحميل العمومي بين المناطق. يساعد هذا الوكيل العكسي في توزيع نسبة استخدام الشبكة إذا قمت بنشر حمل عمل إلى مناطق متعددة. كبديل، يمكنك استخدام Azure Traffic Manager. Traffic Manager هو موازن تحميل نسبة استخدام الشبكة المستند إلى DNS الذي يوازن التحميل فقط على مستوى المجال.

يحتوي Azure Front Door على شبكات تسليم محتوى متكاملة (CDNs) تقدم محتوى من شبكة الحافة العالمية لشركة Microsoft مع نقاط حضور (PoPs) موزعة في جميع أنحاء العالم.

يستخدم الحل الحالي اثنين من الوكلاء العكسيين للحفاظ على الاتساق مع البنية الأساسية. Azure Front Door هو الموجه العمومي. تعمل بوابة التطبيق كموازن تحميل لكل منطقة. في معظم الحالات، هذا الإعداد غير مطلوب. يمكنك إزالة Application Gateway إذا كنت تعالج المتطلبات التالية:

• نظرا لإرفاق Azure Web Application Firewall ب Application Gateway، تحتاج إلى إرفاق Web Application Firewall بخدمة Azure Front Door بدلا من ذلك.
• تحتاج إلى طريقة للتأكد من أن المكالمات الواردة تنشأ فقط من مثيل Azure Front Door. يمكنك إضافة X-Azure-FDID header الفحص والتحقق من نطاقات IP ل Azure Front Door في تطبيق Spring Cloud Gateway. لمزيد من المعلومات، راجع استخدام Azure Front Door كوكيل عكسي مع Spring Cloud Gateway.

للحصول على معلومات حول سيناريوهات الوكيل العكسي المختلفة، وكيفية إعدادها، واعتبارات الأمان الخاصة بها، راجع كشف Azure Spring Apps من خلال وكيل عكسي.

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

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

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

يمكنك استخدام هذه الميزة في السيناريوهات التالية:

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

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

النشر بشكل تلقائي

أتمتة نشر البنية الأساسية ونشر التعليمات البرمجية للتطبيق قدر الإمكان.

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

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

الأداء وقابلية التوسع

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

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

يحتوي هذا التصميم المرجعي على العديد من المكونات التي يمكنها التحجيم التلقائي استنادا إلى المقاييس:

• يمكن ل Azure Front Door التحجيم التلقائي بناء على الطلب. يمكنك استخدام ميزات Azure Front Door الأخرى مثل تسريع حركة المرور وقدرات التخزين المؤقت لتقريب الأصول من المستخدمين النهائيين.
• تدعم بوابة التطبيق التحجيم التلقائي. لمزيد من المعلومات، راجع Scale Application Gateway v2 وWeb Application Firewall v2.
• تدعم Azure Spring Apps أيضا التحجيم التلقائي. لمزيد من المعلومات، راجع إعداد التحجيم التلقائي للتطبيقات.

اعتبارات التكلفة

يضاعف هذا الحل بشكل فعال تقديرات التكلفة للبنية الأساسية.

تتضمن المحركات الرئيسية للتكاليف المرتبطة بالحل متعدد المناطق ما يلي:

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

لإدارة هذه التكاليف، ضع في اعتبارك هذه التوصيات لتنفيذك:

• استخدم إصدارات موسعة من الموارد مثل Azure Spring Apps وApplication Gateway في منطقة الاستعداد، وقم بتوسيع نطاق الموارد فقط عندما تصبح الاستعداد نشطة.
• إذا كانت سيناريوهات عملك تسمح بذلك، فبادر بإنشاء إعداد نشط-سلبي لتوفير التكاليف.
• تنفيذ إعداد متعدد المناطق في منطقة واحدة لتلبية احتياجات الأعمال من حيث التوفر والمرونة. يمكن أن يكون هذا الخيار أكثر فعالية من حيث التكلفة لأنك تدفع لمعظم الموارد مرة واحدة فقط.
• اختر الإعداد البديل الذي يستخدم وكيلا عكسيا واحدا فقط للمساعدة في توفير التكاليف. ضع في اعتبارك أنك بحاجة إلى تطبيق تكوين إضافي للحفاظ على أمان هذا البديل.

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

اعتبارات أخرى

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

• أمان الشبكة. من المهم التحكم في الاتصال من خلال الشبكة. يسمح هذا الحل بالمكالمات الواردة من Azure Front Door فقط، حيث يتم توجيه المكالمات إلى بوابة التطبيق في كل منطقة. من Application Gateway، توجه المكالمات إلى خدمة Azure Spring Apps الخلفية. يتم أيضا التحكم في الاتصال من Azure Spring Apps إلى خدمات الدعم مثل Key Vault باستخدام نقاط النهاية الخاصة. لمزيد من المعلومات، راجع بنية الأساس: أمان الشبكة.

• إدارة الوصول والهوية. تنفيذ وصول أكثر أمانا باستخدام الهويات المدارة للاتصال بين مكونات مختلفة. مثال على ذلك هو كيفية استخدام Azure Spring Apps لهوية مدارة للاتصال ب Key Vault. لمزيد من المعلومات، راجع البنية الأساسية: إدارة الهوية والوصول.

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

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

نشر السيناريو

يتوفر نشر لهذه البنية المرجعية في بنية مرجعية متعددة المناطق في Azure Spring Apps على GitHub. يستخدم التوزيع قوالب Terraform.

لنشر البنية، اتبع الإرشادات خطوة بخطوة.

المساهمون

تحتفظ Microsoft بهذا المحتوى. قام المساهم التالي بتطوير المحتوى الأصلي.

الكاتب الرئيسي:

• Gitte Vermeiren | FastTrack لمهندس Azure

لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.

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

لدمج حمل العمل هذا مع الخدمات المشتركة التي تديرها الفرق المركزية في مؤسستك، قم بنشره في منطقة هبوط تطبيق Azure.

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

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

• Azure Spring Apps
• Azure Front Door
• Azure Application Gateway v2
• Azure Database for MySQL
• Azure Key Vault
• Azure DNS
• Azure Web Application Firewall
• Azure Private Link
• الهويات المدارة من Microsoft Entra لموارد Azure

نوصي بالأدلة التالية لفهم أعمق حول خيارات التكوين المتضمنة في هذه البنية:

• كشف Azure Spring Apps من خلال وكيل عكسي
• النشر الأزرق/الأخضر عالي التوفر للتطبيقات
• الاحتفاظ باسم مضيف HTTP الأصلي بين وكيل عكسي وتطبيق الويب الخلفي الخاص به

تم تصميم هذه البنية وفقا لركائز Microsoft Azure Well-Architected Framework. نوصي بمراجعة مبادئ التصميم لكل ركيزة.