نمط تطبيق ويب موثوق به ل Java - تطبيق النمط

توضح لك هذه المقالة كيفية تطبيق نمط Reliable Web App. نمط Reliable Web App هو مجموعة من المبادئ وتقنيات التنفيذ التي تحدد كيفية تعديل تطبيقات الويب (replatform) عند الترحيل إلى السحابة. وهو يركز على الحد الأدنى من تحديثات التعليمات البرمجية التي تحتاج إلى إجراءها لتكون ناجحا في السحابة.

لتسهيل تطبيق هذا التوجيه، هناك تنفيذ مرجعي لنمط Reliable Web App الذي يمكنك نشره.

بنية بنية التنفيذ المرجعي. قم بتنزيل ملف Visio لهذه البنية.

تستخدم الإرشادات التالية التنفيذ المرجعي كمثال طوال الوقت. لتطبيق نمط Reliable Web App، اتبع هذه التوصيات المتوافقة مع ركائز إطار العمل المصمم جيدا:

الموثوقيه

تضمن الموثوقية أن التطبيق الخاص بك يمكن أن يفي بالالتزامات التي تتعهد بها لعملائك. لمزيد من المعلومات، راجع قائمة اختيار مراجعة التصميم للموثوقية. يقدم نمط Reliable Web App نمطين رئيسيين للتصميم على مستوى التعليمات البرمجية لتعزيز الموثوقية: نمط إعادة المحاولة ونمط قاطع الدائرة.

استخدام نمط إعادة المحاولة

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

استخدم Resilience4j لتنفيذ نمط إعادة المحاولة في Java. Resilience4j هي مكتبة خفيفة الوزن التسامح مع الخطأ. يوفر وظائف ذات ترتيب أعلى (مصممات) لتحسين الواجهات الوظيفية وتعبيرات lambda ومراجع الأسلوب باستخدام قاطع الدائرة أو محدد المعدل أو إعادة المحاولة أو نمط تصميم Bulkhead.

مثال: يضيف التنفيذ المرجعي نمط إعادة المحاولة عن طريق تزيين طريقة listServicePlans لوحدة تحكم خطة الخدمة مع التعليقات التوضيحية لإعادة المحاولة. تعيد التعليمات البرمجية محاولة الاستدعاء إلى قائمة خطط الخدمة من قاعدة البيانات إذا فشل الاستدعاء الأولي.

    @GetMapping("/list")
    @PreAuthorize("hasAnyAuthority('APPROLE_AccountManager')")
    @CircuitBreaker(name = SERVICE_PLAN)
    @Retry(name = SERVICE_PLAN)
    public String listServicePlans(Model model) {
        List<serviceplandto> servicePlans = planService.getServicePlans();
        model.addAttribute("servicePlans", servicePlans);
        return "pages/plans/list";
    }

يقوم التنفيذ المرجعي بتكوين نهج إعادة المحاولة بما في ذلك الحد الأقصى للمحاولات ومدة الانتظار والاستثناءات التي يجب إعادة محاولة تنفيذها. تم تكوين نهج إعادة المحاولة في application.properties.

استخدم نمط قاطع الدوائر

يؤدي إقران نمطي "إعادة المحاولة" و"قاطع الدوائر" إلى توسيع قدرة التطبيق على معالجة اضطرابات الخدمة غير المرتبطة بالأخطاء العابرة. يمنع نمط قاطع الدائرة أحد التطبيقات من محاولة الوصول باستمرار إلى خدمة غير مستجيبة. يصدر نمط قاطع الدائرة التطبيق ويتجنب إضاعة دورات وحدة المعالجة المركزية حتى يحتفظ التطبيق بسلامة أدائه للمستخدمين النهائيين. لمزيد من المعلومات، راجع Spring Circuit Breaker، ووثائق Resilience4j.

مثال: ينفذ التنفيذ المرجعي نمط قاطع الدائرة عن طريق تزيين الأساليب باستخدام سمة قاطع الدائرة.

الأمان

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

فرض أقل الامتيازات

لضمان الأمان والكفاءة، امنح المستخدمين (هويات المستخدمين) وخدمات Azure (هويات حمل العمل) الأذونات التي يحتاجونها فقط.

تعيين أذونات لهويات المستخدم

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

تعيين أذونات لهويات حمل العمل

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

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

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

لمزيد من المعلومات، راجع:

• الوصول إلى Azure Storage
• الوصول إلى Key Vault
• الوصول إلى قاعدة بيانات Azure ل PostgreSQL

تكوين مصادقة المستخدم وتخويله

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

تكوين مصادقة المستخدم

تأمين تطبيق الويب الخاص بك عن طريق تمكين مصادقة المستخدم من خلال ميزات النظام الأساسي الخاص بك. تدعم Azure App Service المصادقة مع موفري الهوية مثل معرف Microsoft Entra، ما يؤدي إلى إلغاء تحميل حمل عمل المصادقة من التعليمات البرمجية الخاصة بك.

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

resource "azuread_application" "app_registration" {
  display_name     = "${azurecaf_name.app_service.result}-app"
  owners           = [data.azuread_client_config.current.object_id]
  sign_in_audience = "AzureADMyOrg"  # single tenant

  app_role {
    allowed_member_types = ["User"]
    description          = "Account Managers"
    display_name         = "Account Manager"
    enabled              = true
    id                   = random_uuid.account_manager_role_id.result
    value                = "AccountManager"
  }
}

يخزن Key Vault بيانات تكوين العميل بأمان ويعرض النظام الأساسي ل App Service المعلومات لتطبيقنا كمتغيرات بيئة.

التكامل مع موفر الهوية

دمج تطبيق الويب الخاص بك مع معرف Microsoft Entra للمصادقة الآمنة والتخويل. يعمل Spring Boot Starter لمعرف Microsoft Entra على تبسيط هذه العملية، باستخدام Spring Security وSpring Boot للإعداد السهل. يوفر تدفقات مصادقة متنوعة وإدارة تلقائية للرمز المميز ونهج تخويل قابلة للتخصيص، جنبا إلى جنب مع قدرات التكامل مع مكونات Spring Cloud. وهذا يتيح مباشرة Microsoft Entra ID وOAuth 2.0 التكامل في تطبيقات Spring Boot دون مكتبة يدوية أو تكوين الإعدادات.

مثال: يستخدم التنفيذ المرجعي النظام الأساسي للهويات في Microsoft (معرف Microsoft Entra) كموفر هوية لتطبيق الويب. يستخدم منحة رمز التخويل OAuth 2.0 لتسجيل الدخول إلى مستخدم باستخدام حساب Microsoft Entra. يعرف مقتطف XML التالي التبعيتين المطلوبتين لتدفق منح رمز التخويل OAuth 2.0. تمكن التبعية com.azure.spring: spring-cloud-azure-starter-active-directory مصادقة Microsoft Entra والتخويل في تطبيق Spring Boot. تدعم التبعية org.springframework.boot: spring-boot-starter-oauth2-client مصادقة OAuth 2.0 والتخويل في تطبيق Spring Boot.

<dependency>
    <groupid>com.azure.spring</groupid>
    <artifactid>spring-cloud-azure-starter-active-directory</artifactid>
</dependency>
<dependency>
    <groupid>org.springframework.boot</groupid>
    <artifactid>spring-boot-starter-oauth2-client</artifactid>
</dependency>

لمزيد من المعلومات، راجع دعم Spring Cloud Azure ل Spring Security.

تنفيذ قواعد عمل المصادقة والتخويل

يتضمن تنفيذ قواعد عمل المصادقة والتخويل تحديد نهج التحكم في الوصول والأذونات لمختلف وظائف التطبيق وموارده. تحتاج إلى تكوين Spring Security لاستخدام Spring Boot Starter لمعرف Microsoft Entra. تسمح هذه المكتبة بالتكامل مع معرف Microsoft Entra وتساعدك على التأكد من مصادقة المستخدمين بشكل آمن. يوفر تكوين مكتبة مصادقة Microsoft (MSAL) وتمكينها الوصول إلى المزيد من ميزات الأمان. تتضمن هذه الميزات التخزين المؤقت للرمز المميز وتحديث الرمز المميز التلقائي.

مثال: ينشئ التنفيذ المرجعي أدوار التطبيق التي تعكس أنواع أدوار المستخدم في نظام إدارة حساب Contoso Fiber. تترجم الأدوار إلى أذونات أثناء التخويل. تتضمن أمثلة الأدوار الخاصة بالتطبيق في CAMS مدير الحساب وممثل دعم المستوى الأول (L1) وممثل الخدمة الميدانية. دور إدارة الحسابات لديه أذونات لإضافة مستخدمين وعملاء جدد للتطبيق. يمكن لممثل Field Service إنشاء تذاكر دعم. PreAuthorize تقيد السمة الوصول إلى أدوار محددة.

    @GetMapping("/new")
    @PreAuthorize("hasAnyAuthority('APPROLE_AccountManager')")
    public String newAccount(Model model) {
        if (model.getAttribute("account") == null) {
            List<ServicePlan> servicePlans = accountService.findAllServicePlans();
            ServicePlan defaultServicePlan = servicePlans.stream().filter(sp -> sp.getIsDefault() == true).findFirst().orElse(null);
            NewAccountRequest accountFormData = new NewAccountRequest();
            accountFormData.setSelectedServicePlanId(defaultServicePlan.getId());
            model.addAttribute("account", accountFormData);
            model.addAttribute("servicePlans", servicePlans);
        }
        model.addAttribute("servicePlans", accountService.findAllServicePlans());
        return "pages/account/new";
    }
    ...

للتكامل مع معرف Microsoft Entra، يستخدم التنفيذ المرجعي تدفق منح رمز التخويل OAuth 2.0. يمكن هذا التدفق المستخدم من تسجيل الدخول باستخدام حساب Microsoft. يوضح لك مقتطف التعليمات البرمجية التالي كيفية تكوين SecurityFilterChain لاستخدام معرف Microsoft Entra للمصادقة والتخويل.

@Configuration(proxyBeanMethods = false)
@EnableWebSecurity
@EnableMethodSecurity
public class AadOAuth2LoginSecurityConfig {
    @Bean
    SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http.apply(AadWebApplicationHttpSecurityConfigurer.aadWebApplication())
            .and()
                .authorizeHttpRequests()
            .requestMatchers(EndpointRequest.to("health")).permitAll()
            .anyRequest().authenticated()
            .and()
                .logout(logout -> logout
                            .deleteCookies("JSESSIONID", "XSRF-TOKEN")
                            .clearAuthentication(true)
                            .invalidateHttpSession(true));
        return http.build();
    }
}
...

لمزيد من المعلومات، راجع:

• تسجيل تطبيق باستخدام النظام الأساسي للهويات في Microsoft
• سمة AppRoles
• دليل مطور Spring Boot Starter ل Microsoft Entra
• إضافة تسجيل الدخول باستخدام حساب Microsoft Entra إلى تطبيق ويب Spring
• إضافة أدوار التطبيق إلى التطبيق الخاص بك وتلقيها في الرمز المميز
• مدة بقاء الرمز المميز القابل للتكوين في النظام الأساسي للهويات في Microsoft

تكوين مصادقة الخدمة وتخويلها

قم بتكوين مصادقة الخدمة والتخويل بحيث يكون لدى الخدمات في بيئتك الأذونات اللازمة لأداء الوظائف الضرورية. استخدم الهويات المدارة في معرف Microsoft Entra لأتمتة إنشاء هويات الخدمة وإدارتها، مما يلغي إدارة بيانات الاعتماد اليدوية. تسمح الهوية المدارة لتطبيق الويب الخاص بك بالوصول بأمان إلى خدمات Azure، مثل Azure Key Vault وقواعد البيانات. كما أنه يسهل تكامل البنية الأساسية لبرنامج ربط العمليات التجارية CI/CD للتوزيع إلى Azure App Service. ومع ذلك، في سيناريوهات مثل عمليات النشر المختلطة أو مع الأنظمة القديمة، استمر في استخدام حلول المصادقة المحلية لتبسيط الترحيل. الانتقال إلى الهويات المدارة عندما يكون نظامك جاهزا لنهج حديث لإدارة الهوية. لمزيد من المعلومات، راجع مراقبة الهويات المدارة.

مثال: يحافظ التنفيذ المرجعي على آلية المصادقة المحلية لقاعدة البيانات (اسم المستخدم وكلمة المرور). ونتيجة لذلك، يخزن التنفيذ المرجعي سر قاعدة البيانات في Key Vault. يستخدم تطبيق الويب هوية مدارة (تم تعيين النظام) لاسترداد الأسرار من Key Vault.

استخدام مخزن بيانات سرية مركزي لإدارة الأسرار

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

مثال: يخزن التنفيذ المرجعي البيانات السرية التالية في Key Vault: (1) اسم المستخدم وكلمة المرور لقاعدة بيانات PostgreSQL، و(2) كلمة مرور Redis Cache، و(3) سر العميل لمعرف Microsoft Entra المرتبط بتنفيذ MSAL.

لا تضع Key Vault في تدفق طلب HTTP

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

استخدام طريقة واحدة للوصول إلى الأسرار في Key Vault

عند تكوين تطبيق ويب للوصول إلى الأسرار في Key Vault، لديك خياران أساسيان:

• إعداد تطبيق App Service: استخدم إعداد تطبيق في App Service لإدخال السر مباشرة كمتغير بيئة.

• مرجع السر المباشر: الرجوع مباشرة إلى السر داخل التعليمات البرمجية للتطبيق الخاص بك. أضف مرجعا محددا في ملف خصائص التطبيق الخاص بك، مثل application.properties تطبيقات Java، بحيث يتصل تطبيقك ب Key Vault.

من المهم اختيار إحدى هذه الطرق والتمسك بها من أجل البساطة وتجنب التعقيد غير الضروري. لدمج Key Vault مع تطبيق Spring، تتضمن العملية ما يلي:

1. أضف Azure Spring Boot Starter لتبعية أسرار Azure Key Vault في ملف pom.xml.
2. تكوين نقطة نهاية Key Vault في التطبيق الخاص بك. يمكن القيام بذلك إما من خلال ملف application.properties أو كمتغير بيئة.

مثال: يستخدم التنفيذ المرجعي إعداد تطبيق في App Service ويضخ البيانات السرية.

استخدم نقاط النهاية الخاصة

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

مثال: يستخدم التنفيذ المرجعي نقاط نهاية خاصة ل Key Vault وذاكرة التخزين المؤقت Azure ل Redis وقاعدة بيانات Azure ل PostgreSQL.

استخدام جدار حماية تطبيق ويب

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

يمكن للمنصة App Service وJava Spring التصفية حسب قيمة العنوان. يجب عليك استخدام App Service كخيار أول. تمنع التصفية على مستوى النظام الأساسي الطلبات غير المرغوب فيها من الوصول إلى التعليمات البرمجية الخاصة بك. تحتاج إلى تكوين حركة المرور التي تريد تمريرها عبر جدار حماية تطبيق الويب الخاص بك. يمكنك التصفية استنادا إلى اسم المضيف وعنوان IP للعميل والقيم الأخرى. لمزيد من المعلومات، راجع الاحتفاظ باسم مضيف HTTP الأصلي.

مثال: يستخدم التنفيذ المرجعي نقطة نهاية خاصة في بيئة الإنتاج وقيمة X-Azure-FDID العنوان في بيئة التطوير.

تكوين أمان قاعدة البيانات

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

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

• لا تمنح التطبيق أذونات مرتفعة. لا تمنح الوصول على مستوى المسؤول إلى هوية التطبيق. تكوين الوصول الأقل امتيازا للتطبيق إلى قاعدة البيانات. إنه يحد من نصف قطر الانفجار للأخطاء والخروقات الأمنية. لديك طريقتان أساسيتان للوصول إلى قاعدة بيانات Azure PostgreSQL. يمكنك استخدام مصادقة Microsoft Entra أو مصادقة PostgreSQL. لمزيد من المعلومات، راجع JDBC مع Azure PostgreSQL.

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

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

حقوق الموارد لكل بيئة

فهم مستويات الأداء المختلفة لخدمات Azure واستخدام SKU المناسب فقط لاحتياجات كل بيئة. تحتاج بيئات الإنتاج إلى وحدات SKU تفي باتفاقيات مستوى الخدمة (SLA) والميزات والحجم اللازم للإنتاج. لا تحتاج البيئات غير المنتجة عادة إلى نفس القدرات. لتحقيق وفورات إضافية، ضع في اعتبارك خيارات تسعير Azure Dev/Test وAzure Reservations وخطط توفير Azure للحساب.

مثال: لا يستخدم التنفيذ المرجعي تسعير Azure Dev/Test نظرا لأن تسعير Azure Dev/Test لم يغطي أي من المكونات. قاعدة بيانات Azure ل PostgreSQL هي المرشح الرئيسي لمثيل محجوز استنادا إلى خطة الالتزام بمحرك قاعدة البيانات هذا لمدة عام على الأقل بعد هذا التقارب الأولي على مرحلة السحابة. يحتوي التنفيذ المرجعي على معلمة اختيارية تنشر وحدات SKU مختلفة. معلمة البيئة ترشد قالب Terraform لتحديد وحدات SKU للتطوير. تظهر التعليمات البرمجية التالية معلمة البيئة هذه.

azd env set APP_ENVIRONMENT prod

تستخدم Contoso Fiber قوالب البنية الأساسية كتعليق برمجي (IaC) للتطوير وتوزيع الإنتاج. بيئة التطوير محسنة من حيث التكلفة، باستخدام وحدات SKU الأقل تكلفة اللازمة لتطوير التطبيقات. تستخدم بيئة الإنتاج وحدات SKU التي تلبي متطلبات هدف مستوى خدمة الإنتاج للتطبيق.

استخدام التحجيم التلقائي

يعمل التحجيم التلقائي على أتمتة التحجيم الأفقي لبيئات الإنتاج. التحجيم التلقائي استنادا إلى مقاييس الأداء. تعد مشغلات أداء استخدام وحدة المعالجة المركزية نقطة بداية جيدة إذا كنت لا تفهم معايير التحجيم للتطبيق الخاص بك. تحتاج إلى تكوين مشغلات التحجيم وتكييفها (وحدة المعالجة المركزية وذاكرة الوصول العشوائي والشبكة والقرص) لتتوافق مع سلوك تطبيق الويب الخاص بك. لا تتوسع عموديا لتلبية التغييرات المتكررة في الطلب. إنها أقل كفاءة من حيث التكلفة. لمزيد من المعلومات، راجع التحجيم في Azure App Service والتحجيم التلقائي في Microsoft Azure.

استخدام الموارد بكفاءة

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

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

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

• وظيفة Colocate. عندما تكون هناك سعة احتياطية، قم ب colocate application resources and functiony على مورد Azure واحد. على سبيل المثال، يمكن لتطبيقات ويب متعددة استخدام خادم واحد (خطة خدمة التطبيقات) أو يمكن أن تدعم ذاكرة التخزين المؤقت واحدة أنواع بيانات متعددة.

التميز التشغيلي

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

تكوين المراقبة

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

مراقبة مقاييس الأساس

يجب أن يراقب حمل العمل مقاييس الأساس. تتضمن المقاييس المهمة التي يجب قياسها معدل نقل الطلب ومتوسط مدة الطلب والأخطاء وتبعيات المراقبة. نوصي باستخدام Application Insights لجمع بيانات تتبع الاستخدام هذه.

مثال: يستخدم التنفيذ المرجعي Application Insights. يتم تمكين Application Insights من خلال Terraform كجزء من تكوين app_settings App Service.

app_settings = {
    APPLICATIONINSIGHTS_CONNECTION_STRING = var.app_insights_connection_string
    ApplicationInsightsAgent_EXTENSION_VERSION = "~3"
    ...
}

يسجل Spring Boot العديد من المقاييس الأساسية في Application Insights مثل الجهاز الظاهري Java (JVM) وCPU وTomcat وغيرها. تجمع Application Insights تلقائيا من أطر عمل التسجيل مثل Log4j وLogback. لمزيد من المعلومات، راجع:

• تكوين Azure Monitor Application Insights ل Spring Boot
• خيارات التكوين - Azure Monitor Application Insights ل Java - Azure Monitor
• تمكين Azure Monitor OpenTelemetry لتطبيقات Java
• استخدام Azure Monitor Application Insights مع Spring Boot.

إنشاء بيانات تتبع الاستخدام المخصصة والمقاييس حسب الحاجة

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

جمع المقاييس المستندة إلى السجل

تتبع المقاييس المستندة إلى السجل للحصول على مزيد من الرؤية في صحة التطبيق الأساسي والمقاييس. يمكنك استخدام استعلامات Kusto Query Language (KQL) في Application Insights للبحث عن البيانات وتنظيمها. لمزيد من المعلومات، راجع المقاييس المستندة إلى سجل Azure Application Insights والمقاييسالمستندة إلى السجل والمجمعة مسبقا في Application Insights.

تمكين تشخيصات النظام الأساسي

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

• تمكين التشخيص لجميع الخدمات المدعومة. تنشئ خدمات Azure سجلات النظام الأساسي تلقائيا، ولكن الخدمة لا تخزنها تلقائيا. يجب تمكين إعداد التشخيص لكل خدمة، ويجب تمكينه لكل خدمة Azure تدعم التشخيص.

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

مثال: يستخدم التنفيذ المرجعي Terraform لتمكين تشخيصات Azure على جميع الخدمات المدعومة. تقوم التعليمات البرمجية Terraform التالية بتكوين إعدادات التشخيص لخدمة التطبيقات.

# Configure Diagnostic Settings for App Service
resource "azurerm_monitor_diagnostic_setting" "app_service_diagnostic" {
  name                           = "app-service-diagnostic-settings"
  target_resource_id             = azurerm_linux_web_app.application.id
  log_analytics_workspace_id     = var.log_analytics_workspace_id
  #log_analytics_destination_type = "AzureDiagnostics"

  enabled_log {
    category_group = "allLogs"

  }

  metric {
    category = "AllMetrics"
    enabled  = true
  }
}

استخدام البنية الأساسية لبرنامج ربط العمليات التجارية CI/CD

لأتمتة عمليات التوزيع الخاصة بك، قم بدمج البنية الأساسية لبرنامج ربط العمليات التجارية للتكامل المستمر/النشر المستمر (CI/CD). يجب أن تمتد هذه الأتمتة من التحكم بالمصادر مباشرة إلى بيئات App Service المختلفة، بما في ذلك الاختبار والتقسيم المرحلي والإنتاج. استخدم Azure Pipelines إذا كنت تعمل مع Azure DevOps أو GitHub Actions لمشاريع GitHub.

• دمج اختبار الوحدة. تحديد أولويات تنفيذ واجتياز جميع اختبارات الوحدة (باستخدام JUnit) داخل البنية الأساسية لبرنامج ربط العمليات التجارية الخاصة بك قبل أي نشر إلى App Services. دمج أدوات جودة التعليمات البرمجية وتغطيتها مثل SonarQube وJaCoCo لتحقيق تغطية اختبار شاملة.

• اعتماد إطار عمل Java للسخرية. للاختبار الذي يتضمن نقاط نهاية خارجية، استخدم أطر عمل السخرية Java (Mockito، EasyMock). تسمح لك أطر العمل هذه بإنشاء نقاط نهاية محاكاة. إنها تلغي الحاجة إلى تكوين نقاط النهاية الخارجية الحقيقية وضمان ظروف الاختبار الموحدة عبر البيئات.

• إجراء عمليات فحص الأمان. استخدم اختبار أمان التطبيق الثابت (SAST) للعثور على عيوب الأمان وأخطاء الترميز في التعليمات البرمجية المصدر. بالإضافة إلى ذلك، قم بإجراء تحليل تكوين البرامج (SCA) لفحص مكتبات ومكونات الجهات الخارجية للمخاطر الأمنية. يتم دمج أدوات هذه التحليلات بسهولة في كل من GitHub وAzure DevOps.

التحكم في عمليات توزيع الإنتاج

تحتاج إلى إنشاء إرشادات لنشر التعليمات البرمجية في الإنتاج وإنشاء عملية الموافقة على جميع عمليات نشر الإنتاج.

كفاءة الأداء

كفاءة الأداء هي قدرة حمل عملك على تغيير الحجم لتلبية المطالب التي يضعها المستخدمون عليها بطريقة فعالة. لمزيد من المعلومات، راجع قائمة اختيار مراجعة التصميم لكفاءة الأداء. يستخدم نمط Reliable Web App نمط Cache-Aside لتقليل زمن الانتقال للبيانات المطلوبة بشدة.

استخدام نمط Cache-Aside

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

تمكين التخزين المؤقت

لتمكين التخزين المؤقت، أضف الحزمة spring-boot-starter-cache كتبعية في الملف.pom.xml تقوم spring-boot-starter-cache الحزمة بتكوين ذاكرة التخزين المؤقت Redis بالقيم الافتراضية. يجب تحديث هذه القيم في application.properties ملف أو متغيرات البيئة لتلبية احتياجات تطبيق الويب الخاص بك. على سبيل المثال، spring.cache.redis.time-to-live يحدد (الممثل بالمللي ثانية) مقدار الوقت الذي تبقى فيه البيانات في ذاكرة التخزين المؤقت قبل الإخلاء. تحتاج إلى توفير قيمة تلبي احتياجات تطبيق الويب الخاص بك. وأخيرا، تحتاج إلى تخزين البيانات المطلوبة مؤقتا في التعليمات البرمجية باستخدام التعليق التوضيحي @Cacheable .

ذاكرة التخزين المؤقت للبيانات عالية الحاجة

تحديد أولويات التخزين المؤقت للبيانات التي يتم الوصول إليها بشكل متكرر. تحديد نقاط البيانات الرئيسية التي تدفع تفاعل المستخدم وأداء النظام. تنفيذ استراتيجيات التخزين المؤقت خصيصا لهذه المجالات لتحسين فعالية نمط Cache-Aside، ما يقلل بشكل كبير من زمن الانتقال وتحميل قاعدة البيانات. استخدم Azure Monitor لتعقب وحدة المعالجة المركزية والذاكرة وتخزين قاعدة البيانات. تساعدك هذه المقاييس على تحديد ما إذا كان يمكنك استخدام SKU قاعدة بيانات أصغر.

الحفاظ على بيانات ذاكرة التخزين المؤقت حديثة

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

ضمان تناسق البيانات

تنفيذ آليات لتحديث ذاكرة التخزين المؤقت مباشرة بعد أي عملية كتابة قاعدة بيانات. استخدم التحديثات المستندة إلى الحدث أو فئات إدارة البيانات المخصصة لضمان اتساق ذاكرة التخزين المؤقت. تعد مزامنة ذاكرة التخزين المؤقت باستمرار مع تعديلات قاعدة البيانات أمرا أساسيا لنمط Cache-Aside.

مثال: تضيف التعليمات البرمجية التالية الحزمة spring-boot-starter-cache كتبعية إلى pom.xml الملف لتمكين التخزين المؤقت.

<dependency>
    <groupid>org.springframework.boot</groupid>
    <artifactid>spring-boot-starter-cache</artifactid>
</dependency>

يتيح التنفيذ المرجعي ل Redis في application.properties الملف.

# Redis
spring.data.redis.ssl.enabled=true
spring.session.redis.namespace=spring:session

تعرف التعليمات البرمجية التالية أسلوبا يسمى getAccountDetail. يسترد الأسلوب إعدادات المستخدم المقترنة باسم مستخدم معين. التعليق @Cacheable(value="account-details", key="#id") التوضيحي على getAccountDetailالأسلوب وإخبار تطبيق الويب بذاكرة التخزين المؤقت لإعدادات المستخدم في ذاكرة التخزين المؤقت.

    @Cacheable(value="account-details", key="#id")
    public AccountDetail getAccountDetail(Long id) {
        Optional<Account> optionalAccount = accountRepository.findById(id);
        if (optionalAccount.isEmpty()) {
            throw new IllegalArgumentException("Account ID " + id + " does not exist");
        }

        Account account = optionalAccount.get();
        AccountDetail accountDetail = mapToAccountDetail(account);

        return accountDetail;
    }

أداء قاعدة البيانات

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

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

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

• قم باستخدام Application Insights. يوفر Application Insights مقاييس مفصلة حول استعلامات قاعدة البيانات وأي واجهات JDBC. يجب عليك استخدامها للتأكد من أن قاعدة البيانات المنفذة تفي باتفاقيات مستوى الخدمة الخاصة بها أو للعثور على الاستعلامات التي تحتاج إلى ضبطها. يجب ألا تستخدم Dynamic SQL أبدا لأنه ينشئ مشكلات في الأمان والأداء.

• استخدم تجمعات الاتصال. يجب عليك استخدام تجمعات اتصال JDBC وضبطها استنادا إلى مقاييس المعاملات في الثانية (TPS) واتفاقيات مستوى الخدمة. يجب استخدام أدوات مراقبة أداء قاعدة البيانات لاختبار أداء قاعدة البيانات وتقييمه تحت التحميل.

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

انشر التنفيذ المرجعي باتباع الإرشادات الموجودة في مستودع GitHub. استخدم الموارد التالية لمعرفة المزيد حول أفضل الممارسات السحابية والترحيل.

أفضل ممارسات السحابة. للحصول على اعتماد Azure والإرشادات المعمارية، راجع:

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

بالنسبة للتطبيقات التي تتطلب هدف مستوى خدمة أعلى (SLO)، راجع أحمال العمل الحرجة للمهام.

إرشادات الترحيل. يمكن أن تساعدك الأدوات والموارد التالية في ترحيل الموارد المحلية إلى Azure:

• يوفر Azure Migrate خدمة ترحيل وتحديث وتحسين مبسطة ل Azure التي تتعامل مع تقييم تطبيقات الويب وSQL Server والأجهزة الظاهرية وترحيلها.
• توفر Azure Database Migration Guides موارد لمختلف أنواع قواعد البيانات والأدوات المصممة لسيناريو الترحيل الخاص بك.
• يوفر مسرع المنطقة المنتقل إليها في Azure App Service إرشادات لتقوية عمليات نشر App Service وتوسيع نطاقها.