مشاركة عبر

تخطيط الشبكة والاتصال لمسرع المنطقة المنتقل إليها في Azure Spring Apps

  • مقالة

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

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

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

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

اعتبارات التصميم

  • العزلة. يمكن للفريق المركزي توفير شبكة ظاهرية لفريق التطبيق لتشغيل أحمال العمل الخاصة بهم. إذا كان حمل عمل Spring Boot يحتوي على فصل بين المخاوف وأحمال العمل الأخرى، ففكر في توفير شبكتك الظاهرية الخاصة لوقت تشغيل خدمة Spring App والتطبيق.

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

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

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

  • حركة مرور الخروج (الصادرة). يجب توجيه نسبة استخدام الشبكة التي تنتقل من الشبكة الظاهرية من خلال جدار حماية Azure أو الجهاز الظاهري للشبكة (NVA).

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

  • نسبة استخدام الشبكة للدخول (الواردة). ضع في اعتبارك استخدام وكيل عكسي لنسبة استخدام الشبكة التي تنتقل إلى Azure Spring Apps. استنادا إلى متطلباتك، اختر الخيارات الأصلية، مثل Azure Application Gateway، و Front Door، أو الخدمات الإقليمية، مثل API Management (APIM). إذا كانت هذه الخيارات لا تلبي احتياجات حمل العمل، يمكن النظر في الخدمات غير التابعة ل Azure.

توصيات التصميم

وتوفر هذه التوصيات إرشادات توجيهية لمجموعة الاعتبارات السابقة.

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

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

  • توفر Azure Spring Apps المنشورة في شبكة خاصة اسم مجال مؤهل بالكامل (FQDN) يمكن الوصول إليه فقط داخل الشبكة الخاصة. إنشاء منطقة DNS خاصة ل Azure لعنوان IP لتطبيق Spring الخاص بك. اربط DNS الخاص بشبكتك الظاهرية عن طريق تعيين FQDN خاص داخل Azure Spring Apps. للحصول على إرشادات خطوة بخطوة، راجع الوصول إلى التطبيق الخاص بك في شبكة خاصة.

  • تتطلب Azure Spring Apps شبكتين فرعيتين مخصصتين. تحتوي إحدى الشبكات الفرعية على وقت تشغيل الخدمة، والشبكة الفرعية الأخرى لتطبيقات Spring Boot.

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

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

  • استخدم مجموعات أمان الشبكة (NSGs) على الشبكات الفرعية لتصفية نسبة استخدام الشبكة بين الشرق والغرب لتقييد نسبة استخدام الشبكة إلى الشبكة الفرعية لوقت تشغيل الخدمة.

  • يجب عدم تعديل مجموعات الموارد والشبكات الفرعية التي يديرها توزيع Azure Spring Apps.

استخدام الشبكة الخارج:⁦⁩

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

    ملاحظة

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

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

  • يحتاج التطبيق إلى الاتصال بخدمات Azure الأخرى في الحل. استخدم Azure Private Link للخدمات المدعومة إذا كانت تطبيقاتك تتطلب اتصالا خاصا.

استخدام الشبكة الداخل:⁦⁩

  • استخدم وكيلا عكسيا للتأكد من منع المستخدمين الضارين من تجاوز جدار حماية تطبيق الويب (WAF) أو التحايل على حدود التقييد. يوصى باستخدام Azure Application Gateway مع WAF المتكامل.

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

    أضف NSG على الشبكة الفرعية لوقت تشغيل الخدمة التي تسمح بنسبة استخدام الشبكة فقط من الشبكة الفرعية ل Application Gateway والشبكة الفرعية Azure Spring Apps وAzure Load Balancer.

    ملاحظة

    يمكنك اختيار بديل للوكيل العكسي، مثل Azure Front Door أو الخدمات غير Azure. للحصول على معلومات حول خيارات التكوين، راجع كشف Azure Spring Apps من خلال وكيل عكسي.

  • يمكن نشر Azure Spring Apps في شبكة ظاهرية من خلال حقن VNet أو خارج الشبكة. لمزيد من المعلومات، راجع ملخص التكوين.

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

اعتبارات الأمان لمسرع المنطقة المنتقل إليها في Azure Spring Apps