الأسئلة المتداولة FAQ حول تكوين تطبيق Azure

تجيب هذه المقالة عن الأسئلة المتداولة حول تكوين تطبيق Azure.

كيف يختلف تكوين التطبيق عن Azure Key Vault؟

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

يدعم تكوين التطبيق:

  • مساحات الاسم الهرمية
  • التسمية
  • استفسارات واسعة النطاق
  • استرجاع الدفعة
  • عمليات الإدارة المتخصصة
  • واجهة مستخدم لإدارة الميزات

يكمل تكوين التطبيق Key Vault، ويجب استخدام الاثنَين جنبًا إلى جنب في معظم عمليات نشر التطبيقات.

هل يجب عليّ تخزين الأسرار في تكوين التطبيق؟

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

يمكنك إنشاء قيم مفاتيح تكوين التطبيق التي تشير إلى الأسرار المخزنة في Key Vault. لمزيد من المعلومات، راجع استخدام مراجع Key Vault في تطبيق ASP.NET Core.

هل يقوم تكوين التطبيق بتشفير بياناتي؟

نعم. يقوم تكوين التطبيق دائمًا بتشفير جميع البيانات في أثناء النقل وفي حالة الثبات. جميع اتصالات الشبكة عبر TLS 1.2 أو TLS 1.3. يدعم تكوين التطبيق التشفير في وضع الثبات إما باستخدام المفاتيح التي تديرها Microsoft أو المفاتيح التي يديرها العميل.

كيف يختلف تكوين التطبيق عن إعدادات خدمة تطبيقات Azure؟

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

في المقابل، يسمح لك تكوين تطبيق Azure بتحديد الإعدادات التي يمكن مشاركتها بين تطبيقات متعددة. يتضمن ذلك التطبيقات التي تعمل في خدمة التطبيقات، بالإضافة إلى الأنظمة الأساسية الأخرى. يصل رمز التطبيق الخاص بك إلى هذه الإعدادات من خلال موفري التكوين لـ .NET وJava، من خلال Azure SDK، أو مباشرة عبر REST APIs.

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

هل توجد قيود على حجم المفاتيح والقيم المخزنة في تكوين التطبيق؟

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

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

للحصول على قائمة كاملة بالحدود، راجع حدود الاشتراك والخدمة في Azure.

كيف يمكنني تخزين التكوينات لبيئات متعددة (اختبار، مرحلي، إنتاج، وما إلى ذلك)؟

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

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

ما هي الطرق الموصى بها لاستخدام تكوين التطبيق؟

ما هي تكلفة تكوين التطبيق؟

هناك ثلاثة مستويات للتسعير: Free وStandard وPremium. للحصول على معلومات التسعير التفصيلية ، راجع صفحة تسعير App Configuration.

ما هي فئة تكوين التطبيق التي يجب أن أستخدمها؟

توفر جميع مستويات تكوين التطبيق وظائف أساسية، بما في ذلك إعدادات التكوين وعلامات الميزات ومراجع Key Vault ولقطات التكوين وعمليات الإدارة الأساسية والمقاييس والسجلات.

فيما يلي اعتبارات لاختيار الطبقة.

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

  • الموارد لكل اشتراك: يتكون المورد من مخزن تكوين واحد. يقتصر كل اشتراك على مخزن تكوين واحد لكل منطقة في المستوى المجاني. يمكن أن تحتوي الاشتراكات على عدد غير محدود من مخازن التكوين في المستويات القياسية والمتميزة.

  • التخزين لكل مورد: في المستوى المجاني، يقتصر كل مخزن تكوين على 10 ميغابايت من التخزين العادي و10 ميغابايت من تخزين اللقطة. في المستوى القياسي، يمكن لكل مخزن تكوين استخدام ما يصل إلى 1 غيغابايت من التخزين العادي و1 غيغابايت إضافية من تخزين اللقطة. في المستوى المتميز، يمكن لكل مخزن تكوين استخدام ما يصل إلى 4 غيغابايت من التخزين العادي و4 غيغابايت إضافية من تخزين اللقطة.

  • محفوظات المراجعة: يخزن App Configuration محفوظات لجميع التغييرات التي تم إجراؤها على المفاتيح. في المستوى المجاني، يتم تخزين هذا السجل لمدة سبعة أيام. في المستويين Standard وPremium، يتم تخزين هذه المحفوظات لمدة 30 يوما.

  • الحصة النسبية للطلبات: تقتصر مخازن الطبقة المجانية على 1000 طلب في اليوم. عندما يصل المتجر إلى 1000 طلب، فإنه يُرجع HTTP رمز حالة 429 لجميع الطلبات حتى منتصف الليل بالتوقيت العالمي المنسق.

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

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

  • معدل النقل: تحتوي مخازن App Configuration في جميع المستويات على بدل معدل النقل. تتلقى الطلبات التي تتجاوز هذا البدل استجابة رمز حالة HTTP 429. لا تحتوي المتاجر في المستوى المجاني على معدل نقل مضمون.

    تسمح المتاجر في المستوى القياسي بمعدل التشغيل† ما يصل إلى 300 طلب في الثانية (RPS) لطلبات القراءة وما يصل إلى 60 RPS لطلبات الكتابة.

    تسمح المتاجر في المستوى المتميز بمعدل التشغيل† حتى 450 RPS لطلبات القراءة وما يصل إلى 100 RPS لطلبات الكتابة.

    †يقاس معدل التشغيل عادة كمتوسط عدد الطلبات التي يعالجها متجر App Configuration دون تقييد خلال فترة محددة.

  • اتفاقية مستوى الخدمة: لا يحتوي المستوى المجاني على اتفاقية مستوى الخدمة. يحتوي المستوى القياسي على اتفاقية مستوى الخدمة (SLA) بنسبة توفر 99.9٪ وتوافر بنسبة 99.95٪ مع تمكين النسخ المتماثل الجغرافي. يحتوي المستوى المتميز على اتفاقية مستوى الخدمة (SLA) بنسبة توفر بنسبة 99.9٪ وتوافر بنسبة 99.99٪ مع تمكين النسخ المتماثل الجغرافي.

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

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

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

    تحتوي مخازن المستوى المتميز أيضا على رسوم استخدام يومية وتتضمن نسخة متماثلة. يتم تضمين أول 800,000 طلب للأصل وأول 800,000 طلب للنسخة المتماثلة كل يوم في الرسوم اليومية. تتحمل الطلبات التي تتجاوز هذا التخصيص اليومي رسوما زائدة.

هل يمكنني ترقية متجر App Configuration أو الرجوع إليه؟

يمكنك ترقية متجر App Configuration في أي وقت، على سبيل المثال، من المستوى المجاني إلى المستوى القياسي أو المتميز، أو من المستوى القياسي إلى المستوى المتميز.

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

أين توجد البيانات المخزنة في تكوين التطبيق؟

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

كيف يضمن تكوين التطبيق توفرًا عاليًا للبيانات؟

يدعم Azure App Configuration النسخ المتماثل الجغرافي لتحسين المرونة في الانقطاعات الإقليمية.

Azure App Configuration يدعم Azure availability zones لحماية التطبيق والبيانات من حالات فشل مركز البيانات الفردي. تتكون جميع المناطق الممكنة لمنطقة التوفر من ثلاث مناطق توفر كحد أدنى، حيث يكون كل منها مركز بيانات مستقلا ماديا. من أجل المرونة، يتم تمكين هذا الدعم في تكوين التطبيق لجميع العملاء دون أي تكلفة إضافية. فيما يلي المناطق التي مكّن فيها App Configuration دعم منطقة توفر. لمزيد من المعلومات، راجع المناطق وAvailability Zones في Azure.

فيما يلي المناطق حيث مكّن فيها App Configuration دعم منطقة توفر.

الأمريكتان ‏‏أوروبا الشرق الأوسط أفريقيا آسيا/المحيط الهادئ
جنوب البرازيل وسط فرنسا قطر الوسطى شرق أستراليا
وسط كندا منطقة شمال إيطاليا شمال الإمارات العربية المتحدة وسط الهند‬
Central US وسط غرب ألمانيا إسرائيل الوسطى شرق اليابان
شرق الولايات المتحدة أوروبا الشمالية وسط كوريا
East US 2 شرق النرويج جنوب شرق آسيا
South Central US جنوب المملكة المتحدة شرق آسيا
ولاية فرجينيا الأمريكية أوروبا الغربية منطقة شمال الصين 3
West US 2 منطقة السويد الوسطى
غرب الولايات المتحدة الأمريكية 3 شمال سويسرا
وسط المكسيك بولندا الوسطى
وسط إسبانيا

هل هناك أي قيود على عدد الطلبات التي يتم إجراؤها على تكوين التطبيق؟

تحتوي مخازن App Configuration على حصص طلب مختلفة استنادا إلى طبقتها. تقتصر مخازن الطبقة المجانية على 1000 طلب يوميا، ومخازن المستوى القياسي إلى 30000 طلب في الساعة، ولا تحتوي مخازن المستوى المتميز على حدود للطلبات، ما يضمن الوصول دون انقطاع.

تحتوي مخازن App Configuration على بدلات معدل النقل استنادا إلى مستوياتها. لا تحتوي مخازن الطبقة المجانية على معدل نقل مضمون. تدعم مخازن المستوى القياسي معدل التشغيل حتى 300 طلب في الثانية (RPS) لعمليات القراءة وما يصل إلى 60 RPS لعمليات الكتابة. تدعم مخازن المستوى المتميز معدل التشغيل حتى 450 RPS لعمليات القراءة وما يصل إلى 100 RPS لعمليات الكتابة.

كيف أعمل تقدير عدد الطلبات التي قد يرسلها تطبيقي إلى App Configuration؟

لنأخذ مثالا ونفترض أن لديك تطبيقا يحتوي على 1000 إعداد تكوين. يقوم تطبيقك بتحميل كل هذه الإعدادات من App Configuration عند بدء التشغيل. بعد ذلك، يتحقق من مفتاح sentinel لتغييرات التكوين كل 30 ثانية. سواء كنت تعمل على Kubernetes أو App Service أو VMs، فلنفترض أن لديك 50 مثيلا من تطبيقك قيد التشغيل في وقت واحد.

أولا، دعونا نقدر طلبات مراقبة التكوين. يرسل كل مثيل من تطبيقك طلبا واحدا لمفتاح sentinel إلى App Configuration كل 30 ثانية، لذلك يرسل 120 طلبا (=3600/30) في ساعة واحدة. نظرا لأن لديك 50 مثيلا للتطبيق الخاص بك، يرسل التطبيق الخاص بك إجمالي 6000 طلب (=120x50) كل ساعة لمراقبة التكوين. لاحظ أنه نظرا لأن طلبات مفتاح sentinel متكررة وغير متغيرة في الغالب، فإن معظمها لا تحسب مقابل حدود الحصة النسبية للساعة للمتجر† لمتجر المستوى القياسي.

ثانيا، لنقدر طلبات تحميل/إعادة تحميل التكوين. يقوم التطبيق الخاص بك بتحميل جميع الإعدادات عند بدء التشغيل أو كلما تم الكشف عن تغيير مفتاح sentinel. يمكن لكل طلب إلى App Configuration استرداد ما يصل إلى 100 قيمة مفتاح، لذلك يستغرق تحميل جميع الإعدادات 10 طلبات (=1000/100). نظرا لأن لديك 50 مثيلا للتطبيق، فإنك ترسل إجمالي 500 طلب (=10x50) عند إعادة تشغيل التطبيق أو إعادة تحميل التكوين الخاص به.

وأخيرا، دعونا نضعها معا. بافتراض أنك قمت بتحديث مفتاح sentinel مرتين في غضون ساعة، سيتلقى متجر App Configuration 7000 طلب إجمالي لتلك الساعة (=6000+500x2). لاحظ أنه من بين هذه الطلبات، يستخدم حوالي 1000 طلب فقط (=500x2) الحصة النسبية المتوفرة بالساعة لمخزن المستوى القياسي. قم بتحديث الأرقام الموجودة في هذا المثال لمطابقة الإعداد والتصميم المحددين وفقا لذلك بحيث يكون لديك مخزن مؤقت كاف مقابل حد الحصة النسبية بالساعة.

لا تحتوي متاجر †Free tier على طلبات متكررة ومتكررة مستبعدة من حدها اليومي.

يتلقى تطبيقي استجابات HTTP رمز حالة 429. لماذا؟

قد يتلقى تطبيقك استجابة رمز حالة HTTP 429 في ظل الظروف التالية:

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

تحقق من نص الاستجابة 429 لمعرفة السبب المحدد لفشل الطلب. يمكنك أيضا جمع سجلات لمخزن App Configuration في Azure Monitor وإعداد تنبيهات لمقياس استخدام الحصة النسبية للطلب.

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

  • ترقية متجرك إلى المستوى المتميز: لا يحتوي هذا المستوى على حد الحصة النسبية للطلبات وقد زاد من الحصة النسبية للتخزين وبدل معدل النقل الأعلى.
  • استخدام موفري تكوين التطبيقات: يتمتع الموفرون بقدرات إعادة المحاولة والتخزين المؤقت المضمنة جنبا إلى جنب مع العديد من ميزات المرونة الأخرى. تأكد من التحديث إلى أحدث إصدار من الموفر للحصول على جميع التحسينات الأخيرة.
  • استخدم حزم SDK لتكوين التطبيق إذا كان التطبيق الخاص بك يحتاج إلى إرسال طلبات الكتابة. على الرغم من أن SDKs قد لا تكون غنية بالميزات مثل الموفرين، فإنها تعيد المحاولة تلقائيا على استجابات رمز حالة HTTP 429 والأخطاء العابرة الأخرى.
  • قم بتضمين منطق إعادة المحاولة في العملاء المخصصين إذا لم تتمكن من استخدام موفري تكوين التطبيق أو SDKs. retry-after-ms يوفر العنوان في الاستجابة وقت انتظار مقترح (بالمللي ثانية) قبل إعادة محاولة الطلب.
  • توزيع الطلبات عبر مثيلات عميل متعددة: يساعد هذا في تحقيق أقصى معدل نقل من متجر App Configuration.
  • تقليل الطلبات المقدمة إلى App Configuration: اتبع الإرشادات لتقليل عدد الطلبات.
  • تحسين مرونة التطبيق الخاص بك: ضع في اعتبارك دمج النسخ المتماثل الجغرافي للسماح بتجاوز الفشل وموازنة التحميل. تحقق من أفضل الممارسات لإنشاء تطبيقات مرنة للغاية.

لماذا لا يمكنني إنشاء متجر تكوين التطبيق بنفس الاسم الذي قمت بحذفه للتو؟

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

كيف يمكنني استعادة متجر تكوين التطبيق الذي حذفته عن طريق الخطأ؟

تدعم جميع مخازن App Configuration في المستويين Standard وPremium ميزة الحذف المبدئي، والتي لا يمكن تعطيلها. يمكنك استعادة مخزن محذوف خلال فترة الاستبقاء به. اتبع هذه الإرشادات لاستعادة مخزن تكوين التطبيق المحذوف عن طريق الخطأ.

هل يمكنني إنشاء علامات الميزات أو مراجع Key Vault وتحديثها برمجيا؟

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

يتطلب تقييم علامات الميزات واستهلاكها في التطبيق الخاص بك موفر تكوين التطبيق ومكتبات إدارة الميزات، والتي تتوفر في .NET وJava Spring. راجع قسم إدارة الميزات ضمن التشغيل السريع والبرامج التعليمية لمزيد من المعلومات.

كيفية استخدام ملفات تعريف Java Spring في تكوين التطبيق؟

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

يوصى بتعيين تسمية قيم المفاتيح الخاصة بك لمطابقة ملفات تعريف Spring الخاصة بك. بشكل افتراضي، تقوم مكتبة موفر Spring لتكوين التطبيق بتحميل قيم المفاتيح مع التسمية (التسميات) المطابقة لملف (ملفات) Spring النشط الحالي (${spring.profiles.active}) إذا لم يتم تعيين عامل تصفية التسمية بشكل صريح. إذا لم تكن هناك مجموعة ملفات تعريف Spring نشطة، تحميل قيم المفاتيح التي تحتوي على "بلا تسمية".

على سبيل المثال، باستخدام ملفات التعريف dev و prod، يمكنك إنشاء قيم المفاتيح وفقا لذلك باستخدام التسميات التالية.

مفتاح Label القيمة‬
/application/config.message dev مرحبا من dev
/application/config.message المنتج مرحبا من prod

عند تعيين ملف تعريف Spring إلى dev، ستكون Hello from devقيمة config.message . عند تعيين ملف تعريف Spring إلى prod، ستكون Hello from prodقيمة config.message .

يمكن تجاوز هذا السلوك الافتراضي عن طريق تعيين عامل تصفية التسمية في ملف bootstrap. تقوم مكتبة موفر Spring بتحميل قيم المفاتيح بالتسمية (التسميات) المحددة بغض النظر عن ملف تعريف Spring النشط.

spring.cloud.azure.appconfiguration.stores[0].selects[0].label-filter: my-label

لتحديد تسميات أخرى وملف تعريف (ملفات) Spring، يمكنك استخدام عامل تصفية تسمية مثل ',${spring.profiles.active}'، والذي سيحدد جميع المفاتيح بدون تسمية وتلك التي تطابق ملفات تعريف Spring. تأخذ التسمية (التسميات) الموجودة في أقصى اليمين الأولوية عند العثور على مفاتيح مكررة.

كيفية تمكين إدارة الميزات في تطبيقات Blazor أو كخدمات محددة النطاق في تطبيقات .NET؟

بدءا من الإصدار 3.1.0، Microsoft.FeatureManagement تسمح المكتبة بتشغيل خدمات إدارة الميزات، بما في ذلك عوامل تصفية الميزات، كخدمات محددة النطاق في تطبيقات .NET المستندة إلى حقن التبعية. للاستفادة من هذه الميزة، يمكنك ببساطة استبدال AddFeatureManagement الاستدعاء في التعليمات البرمجية الخاصة بك ب AddScopedFeatureManagement، كما هو موضح في القصاصة البرمجية التالية:

services.AddScopedFeatureManagement();

يمكن لعوامل تصفية الميزات تقييم علامة ميزة استنادا إلى خصائص طلب HTTP. يتم تنفيذ هذا عادة عن طريق فحص HttpContext من خلال نمط singleton IHttpContextAccessor . ومع ذلك، لا يعمل هذا النمط لتطبيقات خادم Blazor حيث يجب استخدام الخدمات محددة النطاق بدلا من ذلك. في هذه الحالة، AddScopedFeatureManagement يجب استخدام الأسلوب.

كيف يمكنني تلقي إعلانات عن الإصدارات الجديدة وغيرها من المعلومات المتعلقة بتكوين التطبيق؟

اشترك في مستودع إعلانات GitHub.

كيف يمكنني الإبلاغ عن مشكلة أو تقديم اقتراح؟

يمكنك الوصول إلينا مباشرة على GitHub.

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