Azure Spring Apps المتكاملة مع المناطق المنتقل إليها

Azure Application Gateway
Azure Key Vault
Azure Spring Apps

تنشر هذه البنية المرجعية البنية الأساسية ل Azure Spring Apps في مناطق هبوط Azure.

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

هام

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

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

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

نوصي بشدة بفهم مفهوم مناطق هبوط Azure.

يتم تغطية اختيارات التصميم التي تم إجراؤها في هذه البنية في مجالات التصميم التقني الرئيسية لهذا المسرع. لمزيد من المعلومات، راجع مسرع المنطقة المنتقل إليها في Azure Spring Apps.

تلميح

GitHub logo يتم دعم البنية من خلال تطبيق مثال على GitHub يوضح بعض خيارات التصميم. ضع في اعتبارك التنفيذ كخطوة أولى نحو الإنتاج.

الهندسة

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

Diagram that shows an architecture for an Azure Spring Apps workload in a landing zone.

تتضمن الاستخدامات النموذجية لهذه البنية الأساسية هذه الحَالات:

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

حالات الاستخدام هذه متشابهة باستثناء تكوين قواعد الأمان وحركة مرور الشبكة.

المكونات

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

الموارد المملوكة لفريق التطبيق

فريقك مسؤول عن إنشاء الموارد التالية وصيانتها.

  • يستضيف Azure Spring Apps Standard تطبيقات Java Spring Boot في Azure.

  • Azure Application Gateway Standard_v2 هو الوكيل العكسي الذي يوجه حركة مرور الويب الواردة إلى Azure Spring Apps. قامت وحدة SKU هذه بدمج Azure Web Application Firewall الذي يفحص نسبة استخدام الشبكة بحثا عن ثغرات مشروع أمان تطبيق الويب المفتوح (OWASP).

  • تعمل أجهزة Azure الظاهرية كمربع انتقال لعمليات الإدارة.

  • تخزن Azure Database for MySQL بيانات التطبيق.

  • يخزن Azure Key Vault الأسرار والتكوين، مثل سلسلة الاتصال إلى قاعدة البيانات.

  • Log Analytics هي ميزة في Azure Monitor يشار إليها أيضا باسم سجلات Azure Monitor. Log Analytics هو مصدر المراقبة الذي يخزن السجلات والمقاييس من التطبيق وخدمات Azure.

  • يتم استخدام Azure Application Insights كأداة إدارة أداء التطبيق (APM) لجمع جميع بيانات مراقبة التطبيق وتخزينها مباشرة داخل Log Analytics.

الموارد المملوكة لفريق النظام الأساسي

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

  • يفحص جدار حماية Azure حركة الخروج ويقيدها.

  • يوفر Azure Bastion وصولا آمنا إلى مربع الانتقال السريع للإدارة.

  • يوفر Azure ExpressRoute اتصالا خاصا من محلي إلى البنية الأساسية ل Azure.

  • يوفر Azure DNS تحليلا للاسم في أماكن متعددة.

  • تقوم بوابة Azure VPN بتوصيل التطبيق بفرق بعيدة في شبكتك المحلية.

اعتبارات التطبيق

يتضمن التنفيذ المرجعي نموذج تطبيق يوضح تطبيق خدمات مصغرة نموذجي مستضاف في مثيل Azure Spring Apps. توفر الأقسام التالية تفاصيل حول التطبيق المستضاف. لمزيد من المعلومات، راجع نموذج مخزن PetClinic.

اكتشاف الخدمة

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

يجب أن تكون الخدمات قادرة على التواصل مع الخدمات الأخرى. عند إنتاج مثيلات جديدة، تتم إضافتها إلى السجل حتى يمكن اكتشافها ديناميكيا. في هذه البنية، يتم تمكين سجل خدمة Spring Cloud المدار (OSS) ل Azure Spring Apps. تحتفظ هذه الخدمة بسجل لمثيلات التطبيق المباشر، وتمكن موازنة التحميل من جانب العميل، وفصل موفري الخدمة عن العملاء دون الاعتماد على خدمة اسم المجال (DNS).

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

خادم التكوين

بالنسبة للخدمات المصغرة، يجب فصل بيانات التكوين عن التعليمات البرمجية. في هذه البنية، يتيح Azure Spring Apps Config Server إدارة الموارد من خلال مستودع قابل للتوصيل يدعم التخزين المحلي ومستودعات Git.

التكرار

يمكنك استخدام مناطق التوفر عند إنشاء مثيل Azure Spring Apps.

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

يضمن التكرار في المنطقة توزيع عقد الجهاز الظاهري (VM) الأساسية بالتساوي عبر جميع مناطق التوفر. ومع ذلك، لا يضمن التكرار في المنطقة التوزيع المتساوي لمثيلات التطبيق. إذا فشل مثيل تطبيق بسبب تعطل منطقته الموجودة، تقوم Azure Spring Apps بإنشاء مثيل تطبيق جديد لهذا التطبيق على عقدة في منطقة توفر أخرى.

إذا قمت بتمكين المورد الخاص بك في Azure Spring Apps، مثل التخزين المستمر الخاص بك، فمكن تكرار المنطقة للمورد. لمزيد من المعلومات، راجع كيفية تمكين التخزين المستمر الخاص بك في Azure Spring Apps.

مناطق التوفر غير مدعومة في جميع المناطق. لمعرفة المناطق التي تدعم مناطق التوفر، راجع مناطق Azure التي تدعم منطقة التوفر.

قابلية التوسع

توفر Azure Spring Apps إمكانات التحجيم التلقائي خارج الصندوق التي تمكن التطبيقات من التوسع استنادا إلى حدود القياس أو خلال نافذة زمنية محددة. يوصى بالتحجيم التلقائي عندما تحتاج التطبيقات إلى التوسع أو التوسع استجابة للطلب المتغير.

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

هام

يختلف تحجيم التطبيقات يدويا عن طريق ضبط الإعدادات عن خيار المقياس اليدوي لإعداد التحجيم التلقائي في مدخل Microsoft Azure.

اعتبارات الشبكات

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

طبولوجيا الشبكة

يحدد فريق النظام الأساسي مخطط الشبكة. يفترض تخطيط الشبكة المحورية في هذه البنية.

شبكة افتراضية للموزع

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

  • يتحكم جدار حماية Azure في نسبة استخدام الشبكة الصادرة إلى الإنترنت.
  • يؤمن Azure Bastion الوصول إلى مربع الانتقال السريع للإدارة.
الشبكة الظاهرية المركزية

تحتوي منطقة هبوط التطبيق على شبكة ظاهرية واحدة على الأقل تم توفيرها مسبقا يتم إقرانها بشبكة المركز. أنت تملك الموارد في هذه الشبكة، مثل موازن التحميل الذي يوجه ويحمي اتصالات HTTP/s الواردة إلى Azure Spring Apps من الإنترنت.

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

هام

فريق النظام الأساسي

  • تعيين حقوق موفر Owner موارد Azure Spring Apps على الشبكة الظاهرية التي تم إنشاؤها.
  • توفير عناوين مميزة للشبكات الظاهرية التي تشارك في النظراء.
  • تخصيص مساحات عناوين IP كبيرة بما يكفي لاحتواء وقت تشغيل الخدمة وموارد النشر ودعم قابلية التوسع أيضا.

حقن الشبكة الظاهرية والشبكات الفرعية

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

يتم تحقيق العزلة من خلال الشبكات الفرعية. أنت مسؤول عن تخصيص الشبكات الفرعية في الشبكة الظاهرية المحورية. تتطلب Azure Spring Apps شبكتين فرعيتين مخصصتين لوقت تشغيل الخدمة وتطبيقات Java Spring Boot.

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

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

التحذير

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

عناصر التحكم في الشبكة

يقيد Azure Application Gateway مع Web Application Firewall نسبة استخدام الشبكة الواردة إلى الشبكة الظاهرية المحورية من الإنترنت. تسمح قواعد جدار حماية تطبيق الويب باتصالات HTTP/s أو ترفضها.

يتم التحكم في حركة المرور داخل الشبكة باستخدام مجموعات أمان الشبكة (NSGs) على الشبكات الفرعية. تقوم مجموعات أمان الشبكة بتصفية نسبة استخدام الشبكة وفقا لعناوين IP والمنافذ المكونة. في هذا التصميم، يتم وضع مجموعات أمان الشبكة على جميع الشبكات الفرعية. تسمح الشبكة الفرعية Azure Bastion بنسبة استخدام الشبكة HTTPS من الإنترنت وخدمات البوابة وموازنات التحميل والشبكة الظاهرية. يسمح فقط بالاتصال RDP وSSH بالشبكات الظاهرية من الشبكة الفرعية.

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

يجب تخزين سجلات DNS لمضيف التطبيق في Azure Private DNS لضمان استمرار التوفر أثناء فشل جغرافي.

على الرغم من أن اشتراك الاتصال يحتوي على مناطق DNS خاصة، قم بإنشاء مناطق Azure Private DNS الخاصة بك لدعم الخدمات التي يتم الوصول إليها بواسطة نقاط النهاية الخاصة.

هام

فريق النظام الأساسي

  • تفويض مناطق Azure Private DNS إلى فريق التطبيق.
  • في شبكة المركز، قم بتعيين قيمة خادم DNS إلى الافتراضي (المقدم من Azure) لدعم مناطق DNS الخاصة التي يديرها فريق التطبيق.

يجب تقييد نسبة استخدام الشبكة الصادرة من الشبكة الظاهرية لمنع هجمات النقل غير المصرح للبيانات. يتم توجيه حركة المرور هذه من خلال جدار حماية Azure المركزي (الوثبة التالية) الذي يسمح بالتدفق أو يرفضه باستخدام اسم مجال مؤهل بالكامل (FQDN).

هام

فريق النظام الأساسي

  • إنشاء UDRs للمسارات المخصصة.
  • تعيين نهج Azure لمنع فريق التطبيق من إنشاء شبكات فرعية لا تحتوي على جدول التوجيه الجديد.
  • منح أذونات كافية للتحكم في الوصول استنادا إلى الدور (RBAC) لفريق التطبيق حتى يتمكنوا من توسيع المسارات استنادا إلى متطلبات حمل العمل.

إدارة الهوية والوصول

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

يوصى بمعرف Microsoft Entra لمصادقة المستخدمين والخدمات التي تتفاعل مع مثيل Azure Spring Apps.

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

للحصول على تخويل، استخدم التحكم في الوصول المستند إلى دور Azure (RBAC) عن طريق تطبيق مبدأ الامتياز الأقل عند منح الأذونات.

اعتبارات المراقبة

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

تنشئ هذه البنية الموارد التالية:

  • Azure Application Insights هو حل مراقبة أداء التطبيق (APM) وهو متكامل بالكامل في الخدمة من خلال وكيل Java. يوفر هذا العامل رؤية لجميع التطبيقات والتبعيات المنشورة دون الحاجة إلى تعليمات برمجية إضافية.
  • مساحة عمل Azure Log Analytics هي المتلقي الموحد لجميع السجلات والمقاييس التي تم جمعها من خدمات Azure والتطبيق.

تكوين مثيل Azure Spring Apps لإرسال سجلات التشخيص من التطبيق إلى مساحة عمل Log Analytics المتوفرة. لمزيد من المعلومات، راجع مراقبة التطبيقات من طرف إلى طرف.

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

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

ارتباط البيانات من مساحات عمل متعددة

يتم حفظ السجلات والمقاييس التي تم إنشاؤها بواسطة حمل العمل ومكونات بنيته الأساسية في مساحة عمل Log Analytics لحمل العمل. ومع ذلك، يتم حفظ السجلات والمقاييس التي تم إنشاؤها بواسطة الخدمات المركزية مثل Active Directory وAzure Firewall في مساحة عمل Log Analytics مركزية تديرها فرق النظام الأساسي. يمكن أن يؤدي ربط البيانات من متلقيات مختلفة إلى تعقيدات.

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

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

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

هام

فريق النظام الأساسي

  • امنح RBAC للاستعلام عن متلقيات السجل وقراءتها لموارد النظام الأساسي ذات الصلة.
  • تمكين السجلات ل AzureFirewallApplicationRuleو AzureFirewallNetworkRuleو.AzureFirewallDnsProxy يحتاج فريق التطبيق إلى مراقبة تدفقات نسبة استخدام الشبكة من التطبيق والطلبات إلى خادم DNS.
  • امنح فريق التطبيق أذونات كافية للقيام بعملياته.

لمزيد من المعلومات، راجع مسرع المنطقة المنتقل إليها في Azure Spring Apps: مراقبة العمليات.

تحقيقات الصحة

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

اعتبارات الأمان

توفر الفرق المركزية عناصر التحكم في الشبكات والهوية كجزء من النظام الأساسي. ومع ذلك، يجب أن يكون لحمل العمل تكاليف أمان لتقليل سطح الهجوم. لمزيد من المعلومات، راجع مسرع المنطقة المنتقل إليها في Azure Spring Apps: الأمان.

البيانات في الراحة

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

نقل البيانات

يجب تشفير البيانات التي يتم نقلها. يجب تشفير حركة المرور بين متصفح المستخدم وAzure Application Gateway لضمان بقاء البيانات دون تغيير أثناء النقل. في هذه البنية، تقبل بوابة تطبيق Azure نسبة استخدام الشبكة HTTPS فقط وتتفاوض على تأكيد اتصال TLS. يتم فرض هذا الفحص من خلال قواعد NSG على الشبكة الفرعية لبوابة التطبيق. يتم تحميل شهادة TLS مباشرة أثناء النشر.

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

يمكنك اختيار تنفيذ اتصال TLS من طرف إلى طرف من خلال Azure Spring Apps. ضع في اعتبارك التنازلات المتبادلة (المقايضة). قد يكون هناك تأثير سلبي على زمن الانتقال والعمليات.

وينبغي فحص البيانات المتنقلة بحثا عن الثغرات الأمنية. تم دمج جدار حماية تطبيق الويب مع بوابة التطبيق ويفحص حركة المرور التي تمنع ثغرات OWASP. يمكنك تكوين Web Application Firewall للكشف عن تنبيهات التهديد ومراقبتها وتسجيلها. أو يمكنك إعداد الخدمة لحظر الاختراقات والهجمات التي تم الكشف عنها بواسطة القواعد.

حماية DDoS

يمكن أن يؤدي رفض الخدمة الموزع (DDoS) إلى إسقاط نظام عن طريق إثقاله بالطلبات. يتم تمكين حماية DDoS الأساسية على مستوى البنية الأساسية لجميع خدمات Azure للدفاع ضد مثل هذه الهجمات. ضع في اعتبارك الترقية إلى خدمة Azure DDoS Protection للاستفادة من ميزات مثل المراقبة والتنبيهات والحدود المحددة للقدرة للتطبيق. لمزيد من المعلومات، راجع الأسئلة المتداولة حول خدمة حماية Azure DDoS.

إدارة البيانات السرية

يتطلب نهج أمان Microsoft's Zero Trust تخزين البيانات السرية والشهادات وبيانات الاعتماد في مخزن آمن. الخدمة الموصى بها هي Azure Key Vault.

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

  • يتم تحميل الشهادات أثناء النشر.
  • يتم تنفيذ الاتصال ب MySQL باستخدام Service الاتصال or.

استراتيجيات تحسين التكلفة

نظراً لطبيعة تصميم النظام الموزع، فإن توسع البنية الأساسية أصبح حقيقة واقعة. ينتج عن هذا الواقع تكاليف غير متوقعة ولا يمكن السيطرة عليها. تم إنشاء Azure Spring Apps باستخدام المكونات التي تتوسع للمساعدة في تلبية الطلب وتحسين التكلفة. أساس هذه البنية هو خدمة Azure Kubernetes (AKS). تم تصميم الخدمة لتقليل التعقيد والنفقات التشغيلية لإدارة Kubernetes وتتضمن كفاءات في التكلفة التشغيلية للمجموعة.

يمكنك توزيع تطبيقات وأنواع تطبيقات مختلفة في مثيل واحد من Azure Spring Apps. تدعم الخدمة القياس التلقائي للتطبيقات التي يتم تشغيلها بواسطة القياسات أو الجداول الزمنية التي يمكنها تحسين الاستخدام وكفاءة التكلفة.

يمكنك أيضاً استخدام Application Insights وAzure Monitor لخفض تكلفة العملية. من خلال الرؤية التي يوفرها حل التسجيل الشامل، يمكنك تنفيذ التنفيذ التلقائي لتوسيع نطاق مكونات النظام في الوقت الفعلي. يمكنك أيضاً تحليل بيانات السجل للكشف عن أوجه القصور في التعليمة البرمجية للتطبيق التي يمكنك معالجتها لتحسين التكلفة الإجمالية وأداء النظام.

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

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

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

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

دعم VMware مع مستوى المؤسسة

إذا كنت تريد دعم VMware Tanzu® المدار للتوزيع المباشر، ففكر في الترقية إلى طبقة Azure Spring Apps Enterprise. تم دمج سجل خدمة VMware Tanzu® ل Azure Spring Apps، والذي يسمح باكتشاف الخدمة وتسجيلها.

لتوجيه البوابة، يمكنك التبديل إلى VMware Spring Cloud Gateway. يوفر مجموعة ميزات تتضمن المصادقة والتخويل وميزات المرونة وتحديد المعدل.

في طبقة Enterprise، تتيح خدمة تكوين التطبيق ل Tanzu® إدارة موارد ConfigMap الأصلية Kubernetes التي يتم ملؤها من الخصائص المحددة في مستودع Git واحد أو أكثر.

هناك خدمات VMware أخرى مدعومة على هذا المستوى. لمزيد من المعلومات، راجع مستوى المؤسسة في Azure Marketplace.

يدعم التنفيذ المرجعي Azure Spring Apps Enterprise SKU كخيار نشر. في هذا الخيار، هناك بعض التغييرات في البنية. يستخدم مثيلا لقاعدة بيانات Azure لخادم PostgreSQL المرن الموزع مع تكامل شبكة Azure الظاهرية وذاكرة التخزين المؤقت Azure ل Redis مع نقطة نهاية خاصة. نموذج التطبيق هو تطبيق Fitness Store.

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

  • راجع مناطق التصميم الخاصة بمسرع المنطقة المنتقل إليها في Azure Spring Apps.

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

للاطلاع على سيناريوهات التنفيذ الأخرى، راجع المقالات التالية: