توضح هذه البنية المرجعية كيفية تشغيل أحمال عمل Java Spring Boot على Azure Spring Apps. يستخدم التصميم التكرار في المنطقة لتحقيق قابلية وصول عالية. نفذ هذا التصميم لمنع فشل أحد التطبيقات إذا كان هناك انقطاع في جميع مراكز البيانات في منطقة ما.
تساعدك هذه البنية على:
- زيادة توفر التطبيق الخاص بك عبر توزيع منطقة واحدة.
- زيادة المرونة الشاملة وهدف مستوى الخدمة (SLO) لتطبيقك.
يقدم هذا الحل استراتيجية أساسية لنشر Azure Spring Apps. للحصول على حلول أخرى تعتمد على هذه البنية، راجع نشر Azure Spring Apps في مناطق متعددة وAzure Spring Apps المتكاملة مع المناطق المنتقل إليها.
تلميح
راجع مثالا على التنفيذ الذي يوضح بعض خيارات التصميم لهذه البنية. ضع في اعتبارك هذا التنفيذ كخطوة أولى نحو الإنتاج.
بناء الأنظمة
يوضح الرسم التخطيطي التالي بنية هذا النهج:
قم بتنزيل ملف Visio لهذه البنية.
سير العمل
يتوافق سير العمل هذا مع الرسم التخطيطي السابق:
يصل المستخدم إلى التطبيق باستخدام اسم مضيف HTTP للتطبيق، مثل
www.contoso.com. يتم استخدام Azure DNS لحل طلب اسم المضيف هذا إلى نقطة النهاية العامة لبوابة تطبيق Azure.يتم استخدام بوابة التطبيق لفحص الطلب. كما يتم استخدامه لإعادة توجيه نسبة استخدام الشبكة المسموح بها إلى عنوان IP لموازن التحميل الموجود في مثيل Azure Spring Apps المتوفر. تم دمج Application Gateway مع Azure Web Application Firewall.
يتم استخدام موازن التحميل الداخلي لتوجيه نسبة استخدام الشبكة إلى الخدمات الخلفية.
أثناء معالجة الطلب، يتصل التطبيق بخدمات Azure الأخرى داخل الشبكة الظاهرية. على سبيل المثال، قد يتلقى التطبيق أسرارا من Azure Key Vault أو حالة التخزين من قاعدة البيانات.
المكونات
خدمات Azure التالية هي المكونات في هذه البنية:
يتم استخدام الإصدار القياسي من Azure Spring Apps لاستضافة نموذج تطبيق Java Spring Boot الذي يتم تنفيذه كخدمات مصغرة.
يتم استخدام الإصدار الثاني القياسي من Application Gateway لإدارة نسبة استخدام الشبكة إلى التطبيقات. يعمل كوكيل عكسي محلي في المنطقة التي يعمل بها التطبيق الخاص بك.
يحتوي SKU هذا على Web Application Firewall مدمج للمساعدة في حماية تطبيقات الويب الخاصة بك من الاستغلالات والثغرات الأمنية. يتتبع جدار حماية تطبيق الويب على بوابة التطبيق عمليات استغلال مشروع أمان تطبيق الويب المفتوح (OWASP).
يتم استخدام Azure DNS لحل الطلبات التي يتم إرسالها إلى اسم مضيف التطبيق. يحل هذه الطلبات إلى نقطة النهاية العامة لبوابة التطبيق. تستخدم مناطق Azure DNS الخاصة لحل الطلبات إلى نقاط النهاية الخاصة التي تصل إلى موارد Azure Private Link المسماة.
يتم استخدام قاعدة بيانات Azure ل MySQL لتخزين الحالة في قاعدة بيانات ارتباطية خلفية.
يتم استخدام Key Vault لتخزين أسرار التطبيق وشهاداته. تستخدم الخدمات المصغرة التي تعمل في Azure Spring Apps أسرار التطبيق. تستخدم تطبيقات Azure Spring وبوابة التطبيق الشهادات لحفظ اسم المضيف.
البدائل
قاعدة بيانات Azure ل MySQL ليست الخيار الوحيد لقاعدة البيانات. يمكنك أيضا استخدام:
التكرار
قم بإنشاء التكرار في حمل العمل لتقليل نقاط الفشل الفردية. في هذه البنية، يمكنك نسخ المكونات عبر مناطق داخل منطقة. في البنية الخاصة بك، تأكد من استخدام مناطق التوفر لجميع المكونات في الإعداد الخاص بك.
خدمات Azure غير مدعومة في جميع المناطق وليس جميع المناطق التي تدعم المناطق. قبل تحديد منطقة، تحقق من دعم المنطقة والمنطقة الخاصة بها.
تقوم الخدمات المتكررة في المنطقة تلقائيا بنسخ الموارد أو توزيعها عبر المناطق. تتوفر الخدمات المتوفرة دائما عبر جميع مناطق Azure الجغرافية وهي مرنة في مواجهة الانقطاعات على مستوى المنطقة وعلى مستوى المنطقة.
يوضح الجدول التالي أنواع المرونة للخدمات في هذه البنية:
| الخدمة | مرونة |
|---|---|
| Azure DNS | متوفر دائما |
| Application Gateway | المتكرر على مستوى المنطقة |
| Azure Spring Apps | المتكرر على مستوى المنطقة |
| قاعدة بيانات Azure لـ MySQL | المتكرر على مستوى المنطقة |
| Key Vault | المتكرر على مستوى المنطقة |
| الشبكة الافتراضية في Azure | المتكرر على مستوى المنطقة |
| نقاط النهاية الخاصة ل Azure | المتكرر على مستوى المنطقة |
تدعم Azure Spring Apps التكرار في المنطقة. مع تكرار المنطقة، تنتشر جميع البنية الأساسية للخدمة عبر مناطق توفر متعددة، ما يوفر توفرا أعلى للتطبيق. تتوسع التطبيقات أفقيا دون أي تغييرات في التعليمات البرمجية. تربط شبكة عالية الأداء مناطق توفر Azure. الاتصال لديه زمن انتقال ذهابا وإيابا أقل من 2 مللي ثانية (مللي ثانية). لا يتعين عليك الاعتماد على النسخ المتماثل غير المتزامن لأحمال عمل البيانات، والذي غالبا ما يمثل تحديات في التصميم.
يتم إعداد مناطق توفر متعددة لبوابة التطبيق، بما في ذلك عنوان IP العام الذي تستخدمه بوابة التطبيق. عناوين IP العامة مع مناطق توفر دعم SKU قياسية.
تستخدم هذه البنية قاعدة بيانات Azure ل MySQL مع خيار نشر الخادم المرن لدعم قابلية الوصول العالية مع تجاوز الفشل التلقائي. اعتمادا على متطلبات زمن الانتقال الخاصة بك، اختر قابلية وصول عالية زائدة عن الحاجة للمنطقة أو نفس التوفر العالي للمنطقة. مع تكوين قابلية وصول عالية، يقوم خيار Flexible Server تلقائيا بتوفير وإدارة نسخة متماثلة احتياطية. إذا كان هناك انقطاع، فلن تفقد البيانات الملتزم بها.
يعد Key Vault زائدا عن الحاجة تلقائيا في أي منطقة تتوفر فيها مناطق التوفر. يتم نشر مثيل Key Vault المستخدم في هذه البنية لتخزين البيانات السرية للخدمات الخلفية.
قابلية التوسع
تشير قابلية التوسع إلى قدرة حمل العمل على تلبية الطلبات التي يضعها المستخدمون عليه بكفاءة. النهج متعدد المناطق أفضل لقابلية التوسع من توزيع منطقة واحدة لأنه ينشر الحمل عبر مناطق التوفر.
تحتوي هذه البنية على العديد من المكونات التي يمكنها التحجيم التلقائي استنادا إلى المقاييس:
تدعم بوابة التطبيق التحجيم التلقائي. لمزيد من المعلومات، راجع Scale Application Gateway v2 وWeb Application Firewall v2.
تدعم Azure Spring Apps التحجيم التلقائي. لمزيد من المعلومات، راجع إعداد التحجيم التلقائي للتطبيقات.
اعتمادا على إعداد قاعدة البيانات الخاصة بك، قد تتحمل زمن انتقال إضافي عندما تحتاج إلى مزامنة البيانات بين المناطق.
أمن الشبكة
حماية تطبيقك من الوصول غير المصرح به من الإنترنت والأنظمة في الشبكات الخاصة وخدمات Azure الأخرى والتبعيات المقترنة بإحكام.
الشبكة الظاهرية هي اللبنة الأساسية لشبكة خاصة في Azure. تستخدم هذه البنية شبكة ظاهرية لمنطقة التوزيع. ضع المكونات في الشبكات الفرعية لإنشاء المزيد من العزل. تتطلب Azure Spring Apps شبكة فرعية مخصصة لوقت تشغيل الخدمة وشبكة فرعية منفصلة لتطبيقات Java Spring Boot.
حماية الشبكات الظاهرية باستخدام Azure DDoS Protection. اجمع بين الحماية الموزعة لحجب الخدمة (DDoS) وأفضل ممارسات تصميم التطبيق لتوفير عوامل تخفيف محسنة للدفاع ضد هجمات DDoS.
يتضمن تصميم البنية العديد من حلول النظام الأساسي كخدمة (PaaS) التي تساعد في معالجة طلب المستخدم. ضع عناصر تحكم صارمة في الشبكة على هذه الخدمات للتأكد من عدم تأثر التطبيق.
اتصال خاص
استخدم نقاط النهاية الخاصة أو تكامل الشبكة لتوفير الاتصال من Azure Spring Apps إلى الخدمات الداعمة، مثل Key Vault وقاعدة بيانات Azure ل MySQL.
استخدم نقاط النهاية الخاصة للتحكم في الوصول. تستخدم واجهات الشبكة عناوين IP خاصة لنقل الخدمات إلى الشبكة الظاهرية. تستخدم هذه البنية خدمات Azure التي تقوم تلقائيا بإعداد نقاط النهاية الخاصة.
نشر Azure Spring Apps في الشبكة عبر عملية حقن الشبكة الظاهرية. يتم الوصول إلى التطبيق عن طريق الوصول إلى عنوان IP الخاص.
تتبع قاعدة البيانات نموذجا مشابها. يدعم وضع نشر الخادم المرن في قاعدة بيانات Azure ل MySQL تكامل الشبكة الظاهرية عبر شبكة فرعية مخصصة.
يتم توصيل خدمات أخرى، مثل Key Vault، بالشبكة الظاهرية عبر Private Link. بالنسبة إلى Private Link، تحتاج إلى تمكين نقطة نهاية خاصة لتعطيل الوصول إلى الشبكة العامة. لمزيد من المعلومات، راجع دمج Key Vault مع Private Link.
لا تتطلب نقاط النهاية الخاصة شبكة فرعية مخصصة، ولكن من الجيد وضعها في شبكة فرعية منفصلة. يتم تعيين عناوين IP الخاصة إلى نقاط النهاية الخاصة من تلك الشبكة الفرعية.
تستخدم نقطة النهاية الخاصة والاتصالات المتكاملة للشبكة منطقة خاصة ل Azure DNS.
عناصر التحكم في تدفق نسبة استخدام الشبكة
باستخدام هذه البنية، يسمح بالطلبات الواردة فقط من خلال نقطة النهاية العامة التي تعرضها بوابة التطبيق. لا تزال نسبة استخدام الشبكة بحاجة إلى فحص لمنع عمليات الاستغلال والثغرات الأمنية. جدار حماية تطبيق الويب على بوابة التطبيق يتعقب الثغرات الأمنية OWASP. يتم فحص نسبة استخدام الشبكة الواردة استنادا إلى القواعد المكونة مع إجراء يجب اتباعه.
يحتوي مثيل Azure Spring Apps على موازن تحميل داخلي يوجه حركة المرور ويوزعها على الخدمات الخلفية. تم تكوين موازن التحميل لقبول نسبة استخدام الشبكة فقط من بوابة التطبيق.
قد يحتاج التطبيق إلى الاتصال بنقاط النهاية الأخرى عبر الإنترنت العام. لتقييد هذا التدفق، ضع في اعتبارك وضع جدار حماية Azure على مسار الخروج.
عكس إعداد الوكيل
يستخدم هذا الحل Application Gateway كوكيل عكسي. ولكن يمكنك استخدام وكلاء عكسيين مختلفين أمام Azure Spring Apps. يمكنك دمج Application Gateway مع Azure Front Door، أو يمكنك استخدام Azure Front Door بدلا من Application Gateway.
للحصول على معلومات حول سيناريوهات الوكيل العكسي، وكيفية إعدادها، واعتبارات الأمان الخاصة بها، راجع كشف Azure Spring Apps من خلال وكيل عكسي.
إدارة الهوية والوصول
بالإضافة إلى استخدام عناصر التحكم في الشبكة، قم بتعزيز الوضع الأمني باستخدام الهوية كمحيط.
يجب أن يصادق التطبيق نفسه عند اتصاله بالخدمات الخلفية، مثل ما إذا كان التطبيق يسترد الأسرار من Key Vault. في التطبيق، النهج الموصى به هو تمكين هويات Microsoft Entra المدارة لموارد Azure. يعين أسلوب التكوين هذا هوية للتطبيق حتى يتمكن من الحصول على الرموز المميزة لمعرف Microsoft Entra، ما يقلل من الحمل الزائد لإدارة بيانات الاعتماد.
تستخدم هذه البنية الهويات المدارة المعينة من قبل النظام للعديد من التفاعلات.
يجب أن تسمح الخدمات الخلفية بالوصول إلى كيان الخدمة المخصص للهوية المدارة. يجب أن تحدد الخدمة الحد الأدنى من نهج الوصول لإجراءات معينة. في هذه البنية، يتم استخدام Key Vault لمنح التطبيق حق الوصول إلى الأسرار والشهادات والمفاتيح.
إدارة البيانات السرية
تخزن هذه البنية أسرار التطبيق وشهاداته في مخزن مفاتيح واحد. أسرار التطبيق وشهادات الاحتفاظ باسم المضيف هي مخاوف مختلفة، لذلك قد ترغب في تخزين هذه العناصر في خزائن مفاتيح منفصلة. يضيف هذا النهج البديل مخزن مفاتيح آخر إلى البنية الخاصة بك.
مراقبة
Azure Monitor هو حل مراقبة لجمع بيانات المراقبة وتحليلها والاستجابة لها من البيئات السحابية والبيئات المحلية.
إضافة تقرير عن حالة النظام إلى التطبيق الخاص بك لإرسال السجلات والمقاييس على مستوى التعليمات البرمجية. ضع في اعتبارك تمكين التتبع الموزع لتوفير إمكانية المراقبة عبر الخدمات داخل مثيل Azure Spring Apps. استخدم أداة إدارة أداء التطبيق (APM) لجمع السجلات وبيانات المقاييس. يعد عامل Application Insights Java ل Azure Monitor خيارا جيدا لأداة APM.
استخدم تشخيصات النظام الأساسي للحصول على سجلات ومقاييس من جميع خدمات Azure، مثل قاعدة بيانات Azure ل MySQL. دمج جميع البيانات مع Azure Monitor Logs لتوفير رؤية شاملة للتطبيق الخاص بك وخدمات النظام الأساسي.
مساحة عمل Azure Log Analytics هي متلقي بيانات المراقبة الذي يجمع السجلات والمقاييس من موارد Azure وApplication Insights. يوفر حل التسجيل هذا الرؤية، ما يساعد عمليات الأتمتة على توسيع نطاق المكونات في الوقت الفعلي. يمكن أن يكشف تحليل بيانات السجل أيضا عن أوجه القصور في التعليمات البرمجية للتطبيق التي يمكنك معالجتها لتحسين التكاليف والأداء.
للحصول على إرشادات المراقبة الخاصة بتطبيق Spring، راجع مراقبة التطبيقات من طرف إلى طرف ومراقبة باستخدام Dynatrace Java OneAgent.
النشر بشكل تلقائي
أتمتة نشر البنية الأساسية ونشر التعليمات البرمجية للتطبيق قدر الإمكان.
يضمن أتمتة عمليات نشر البنية الأساسية تطابق تكوين البنية الأساسية، مما يساعد على تجنب انحراف التكوين، وربما بين البيئات. يمكنك أيضا استخدام أتمتة البنية الأساسية لاختبار عمليات تجاوز الفشل.
يمكنك استخدام استراتيجية توزيع أزرق أخضر أو كناري لتطبيقاتك.
الاعتبارات
تنفذ هذه الاعتبارات ركائز Azure Well-Architected Framework، وهو عبارة عن مجموعة من المبادئ التوجيهية التي يمكن استخدامها لتحسين جودة حمل العمل. لمزيد من المعلومات، يرجى مراجعةMicrosoft Azure Well-Architected Framework.
توفر الاعتبارات التالية إرشادات لتنفيذ ركائز Azure Well-Architected Framework في سياق هذه البنية.
الموثوقيه
تضمن الموثوقية أن التطبيق الخاص بك يمكنه الوفاء بالالتزامات التي قطعتها على عملائك. لمزيد من المعلومات، يرجى مراجعة نظرة عامة على ركيزة الموثوقية.
تنفيذ الاقتراحات التالية لإنشاء تطبيق أكثر موثوقية:
استخدم نشر أزرق أخضر لتسهيل العودة إلى الحالة الصحية السابقة في حالة حدوث مشكلات حرجة.
إعداد التحجيم التلقائي للتطبيقات لمساعدة تطبيقك على الأداء بشكل أفضل عند تغيير الطلب.
تمكين إيقاف تشغيل ويب Spring Boot بأمان وتكوين الإنهاء الآمن ل Azure Spring Apps لإيقاف العمليات التي تعمل في مثيل التطبيق قسرا.
الأمان
ويوفر عامل الأمان ضمانات للحماية من الهجمات المتعمدة واستغلال البيانات والأنظمة القيمة الخاصة بك. للمزيد من المعلومات، يرجى الرجوع إلى نظرة عامة على ركيزة الأمان.
تنفيذ الاقتراحات التالية لإنشاء تطبيق أكثر أمانا:
استخدم حلول الهوية الناضجة وإدارة الوصول (IAM)، مثل معرف Microsoft Entra. تمكين المصادقة متعددة العوامل. لمزيد من المعلومات، راجع:
تجنب استخدام كلمات المرور عندما يكون ذلك ممكنا. لمزيد من المعلومات، راجع:
للحصول على توصيات حول كيفية تأمين تطبيق Azure Spring، راجع أساس أمان Azure لتطبيقات Azure Spring.
تحسين التكلفة
يركز تحسين التكلفة على البحث عن طرق للحد من النفقات غير الضرورية وتحسين الكفاءة التشغيلية. لمزيد من المعلومات، راجع نظرة عامة على ركيزة تحسين التكلفة.
بالنسبة إلى هذه البنية، توقع تكلفة أعلى لأنك تنشر المكونات في مناطق متعددة. بدلا من مثيل واحد من Azure Spring Apps، يمكنك تشغيل مثيلين أو حتى ثلاثة مثيلات. ولكن لا توجد تكلفة إضافية لتمكين تكرار المنطقة على الخدمة. لمزيد من المعلومات، راجع تسعير Azure Spring Apps.
ضع في اعتبارك خيارات التنفيذ التالية لمعالجة التكاليف:
يمكنك توزيع تطبيقات وأنواع تطبيقات مختلفة في مثيل واحد من Azure Spring Apps. عند نشر تطبيقات متعددة، تتم مشاركة تكلفة البنية الأساسية عبر التطبيقات.
تدعم Azure Spring Apps التحجيم التلقائي للتطبيق الذي يتم تشغيله بواسطة المقاييس أو الجداول الزمنية، ما يمكن أن يحسن الاستخدام وكفاءة التكلفة.
يمكنك استخدام Application Insights في Azure Monitor لخفض التكاليف التشغيلية. يمكن أن تساعد المراقبة المستمرة في معالجة المشكلات بشكل أسرع وتحسين التكاليف والأداء.
اختر أفضل مستوى تسعير استنادا إلى متطلباتك:
استخدم التحجيم التلقائي للتطبيقات لتوسيع نطاقها وتقليصها بناء على الطلب.
للحصول على تكلفة تقديرية للخدمات لهذه البنية، راجع حاسبة تسعير Azure. يستخدم هذا التقدير قيما افتراضية معقولة لتطبيق صغير الحجم. يمكنك تحديث التقدير استنادا إلى قيم معدل النقل المتوقعة للتطبيق الخاص بك.
التميز التشغيلي
يغطي التميز التشغيلي عمليات التشغيل التي تحافظ على تشغيل التطبيق في الإنتاج. لمزيد من المعلومات، يرجى مراجعةنظرة عامة على ركيزة التميز التشغيلي.
بالإضافة إلى إرشادات المراقبة التي تمت تغطيتها سابقا، قم بتنفيذ الاقتراحات التالية لمساعدتك في نشر التطبيق ومراقبته.
أتمتة عمليات توزيع التطبيقات باستخدام Azure DevOps أو GitHub Actions.
مراقبة تطبيقات Azure Spring Apps باستخدام السجلات والمقاييس والتتبع.
مراقبة المقاييس على قاعدة بيانات Azure ل PostgreSQL باستخدام Flexible Server.
استخدم Azure Managed Grafana لعرض وتحليل بيانات تتبع الاستخدام للتطبيق والبنية الأساسية في الوقت الفعلي.
كفاءة الأداء
كفاءة الأداء هي قدرة حمل عملك على تغيير الحجم لتلبية المطالب التي يضعها المستخدمون عليها بطريقة فعالة. لمزيد من المعلومات، راجع نظرة عامة على ركيزة كفاءة الأداء.
تنفيذ الاقتراحات التالية لإنشاء تطبيق أكثر كفاءة:
نشر هذا السيناريو
لنشر هذه البنية، اتبع الإرشادات خطوة بخطوة في البنية المرجعية متعددة المناطق في Azure Spring Apps. يستخدم التوزيع قوالب Terraform.
المساهمون
تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.
الكاتب الرئيسي:
- Gitte Vermeiren | FastTrack لمهندس Azure
لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.