مشاركة عبر

مقياس توزيع جغرافي مع بيئات خدمة التطبيق

  • مقالة

نظرة عامة

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

تعد App Service Environments نظاماً أساسياً مثالياً للتوسع الأفقي. بعد تحديد تكوين بيئة App Service الذي يمكنه دعم معدل طلب معروف، يمكن للمطورين توزيع App Service Environments الإضافية بطريقة "قاطعة ملفات تعريف الارتباط" لتحقيق أقصى سعة تحميل مرغوبة.

على سبيل المثال، لنفترض أن أحد التطبيقات قيد التشغيل على تكوين بيئة خدمة التطبيق قد تم اختباره للتعامل مع 20 ألف طلب في الثانية (RPS). إذا كانت سعة التحميل القصوى المطلوبة هي 100K RPS، فيمكن إنشاء خمس (5) بيئات خدمة تطبيقات وتهيئتها لضمان قدرة التطبيق على التعامل مع الحد الأقصى للحمل المتوقع.

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

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

يوضح الرسم التخطيطي المفاهيمي أدناه تطبيقاً تم قياسه أفقياً عبر ثلاث بيئات لخدمة التطبيقات داخل منطقة واحدة.

Conceptual architecture diagram of geo-distributed app service with Traffic Manager.

يستعرض الجزء المتبقي من هذا الموضوع الخطوات المتضمنة في إعداد طبولوجيا موزعة لعينة التطبيق باستخدام بيئات خدمة تطبيقات متعددة.

تخطيط الطوبولوجيا

قبل إنشاء بصمة تطبيق موزعة، من المفيد الحصول على معلومات قليلة في وقت مبكر.

  • المجال المخصص للتطبيق: ما اسم المجال المخصص الذي سيستخدمه العملاء للوصول إلى التطبيق؟ بالنسبة إلى نموذج التطبيق، اسم المجال المخصص هو www.asabuludemo.com.
  • مجال Traffic Manager: اختر اسم نطاق عند إنشاء ملف تعريف Azure Traffic Manager. سيتم دمج هذا الاسم مع لاحقة trafficmanager.net لتسجيل إدخال مجال تتم إدارته بواسطة Traffic Manager. بالنسبة إلى تطبيق العينة، الاسم الذي تم اختياره هو scalable-ase-demo. نتيجة لذلك، فإن اسم المجال الكامل الذي يديره Traffic Manager هو scalable-ase-demo.trafficmanager.net.
  • إستراتيجية لتوسيع نطاق تأثير التطبيق: هل سيتم توزيع أثر التطبيق عبر بيئات خدمة تطبيقات متعددة في منطقة واحدة؟ مناطق متعددة؟ مزيج ومطابقة من كلا النهجين؟ اتخذ القرار بناءً على توقعات من أين ستنشأ حركة مرور العملاء، ومدى جودة البنية الأساسية الخلفية الداعمة للتطبيق. على سبيل المثال، مع تطبيق عديم الحالة بنسبة 100%، يمكن زيادة حجم التطبيق على نطاق واسع باستخدام مجموعة من العديد من App Service Environments في كل منطقة Azure، مضروبة في بيئات خدمة التطبيق المنتشرة عبر العديد من مناطق Azure. مع وجود أكثر من 15 منطقة Azure عالمية متاحة للاختيار من بينها، يمكن للعملاء حقاً نشر بصمة تطبيق واسعة النطاق على مستوى العالم. بالنسبة إلى نموذج التطبيق المستخدم في هذه المقالة، تم إنشاء ثلاث بيئات لخدمة التطبيقات في منطقة Azure واحدة (جنوب وسط الولايات المتحدة).
  • اصطلاح التسمية لبيئات خدمة التطبيق: تتطلب كل بيئة خدمة تطبيق اسماً فريداً. بالإضافة إلى بيئة خدمة تطبيق واحدة أو اثنتين، من المفيد أن يكون لديك اصطلاح تسمية للمساعدة في تحديد كل بيئة خدمة تطبيق. بالنسبة لعينة التطبيق، تم استخدام اصطلاح تسمية بسيط. أسماء App Service Environments الثلاثة هي fe1ase وfe2ase وfe3ase.
  • اصطلاح التسمية للتطبيقات: نظرًا لأنه سيتم نشر مثيلات متعددة من التطبيق، يلزم وجود اسم لكل مثيل من التطبيق المنشور. ميزة واحدة غير معروفة ولكنها مناسبة لـApp Service Environments هي أنه يمكن استخدام نفس اسم التطبيق عبر App Service Environments المتعددة. نظراً لأن لكل بيئة خدمة تطبيق لاحقة مجال فريدة، يمكن للمطورين اختيار إعادة استخدام اسم التطبيق نفسه بالضبط في كل بيئة. على سبيل المثال، قد يكون لدى المطور تطبيقات مسماة على النحو التالي:، وما إلى ذلك. بالنسبة إلى نموذج التطبيق، يكون لكل مثيل تطبيق أيضاً اسم فريد. أسماء مثيل التطبيق المستخدمة هي webfrontend1، وwebfrontend2، وwebfrontend3.

إعداد ملف Traffic Manager

بمجرد توزيع مثيلات متعددة من التطبيق في العديد من App Service Environments، يمكن تسجيل مثيلات التطبيق الفردية مع Traffic Manager. بالنسبة إلى نموذج التطبيق، يلزم وجود ملف تعريف Traffic Manager لـ scalable-ase-demo.trafficmanager.net الذي يمكنه توجيه العملاء إلى أي من مثيلات التطبيق المنشورة التالية:

  • webfrontend1.fe1ase.p.azurewebsites.net: مثيل من نموذج التطبيق الذي تم توزيعه في بيئة خدمة التطبيق الأولى.
  • webfrontend2.fe2ase.p.azurewebsites.net: مثيل من نموذج التطبيق الذي تم توزيعه في بيئة خدمة التطبيق الثانية.
  • webfrontend3.fe3ase.p.azurewebsites.net: مثيل من نموذج التطبيق الذي تم توزيعه في بيئة خدمة التطبيق الثالثة.

أسهل طريقة لتسجيل عدة نقاط نهاية لخدمة Azure App Service، وجميعها تعمل في نفس منطقة Azure، هي باستخدام PowerShell دعم Azure Resource Manager Traffic Manager.

تتمثل الخطوة الأولى في إنشاء ملف تعريف Azure Traffic Manager. توضح التعليمة البرمجية أدناه كيف تم إنشاء ملف التعريف لعينة التطبيق:

$profile = New-AzTrafficManagerProfile –Name scalableasedemo -ResourceGroupName yourRGNameHere -TrafficRoutingMethod Weighted -RelativeDnsName scalable-ase-demo -Ttl 30 -MonitorProtocol HTTP -MonitorPort 80 -MonitorPath "/"

لاحظ كيف تم تعيين معلمة RelativeDnsName على scalable-ase-demo. تتسبب هذه المعلمة في إنشاء اسم المجال scalable-ase-demo.trafficmanager.net وربطه بملف تعريف Traffic Manager.

تحدد المعلمة TrafficRoutingMethod نهج موازنة التحميل التي سيستخدمها Traffic Manager لتحديد كيفية توزيع حمل العميل عبر جميع نقاط النهاية المتاحة. في هذا المثال، تم اختيار طريقة المرجح. بسبب هذا الاختيار، سيتم نشر طلبات العملاء عبر جميع نقاط نهاية التطبيق المسجلة بناءً على الأوزان النسبية المرتبطة بكل نقطة نهاية.

مع إنشاء ملف التعريف، تتم إضافة كل مثيل تطبيق إلى ملف التعريف كنقطة نهاية Azure أصلية. تجلب التعليمة البرمجية التالية مرجعاً لكل تطبيق ويب أمامي. ثم تضيف كل تطبيق كنقطة نهاية Traffic Manager من خلال معلمة TargetResourceId.

$webapp1 = Get-AzWebApp -Name webfrontend1
Add-AzTrafficManagerEndpointConfig –EndpointName webfrontend1 –TrafficManagerProfile $profile –Type AzureEndpoints -TargetResourceId $webapp1.Id –EndpointStatus Enabled –Weight 10

$webapp2 = Get-AzWebApp -Name webfrontend2
Add-AzTrafficManagerEndpointConfig –EndpointName webfrontend2 –TrafficManagerProfile $profile –Type AzureEndpoints -TargetResourceId $webapp2.Id –EndpointStatus Enabled –Weight 10

$webapp3 = Get-AzWebApp -Name webfrontend3
Add-AzTrafficManagerEndpointConfig –EndpointName webfrontend3 –TrafficManagerProfile $profile –Type AzureEndpoints -TargetResourceId $webapp3.Id –EndpointStatus Enabled –Weight 10

Set-AzTrafficManagerProfile –TrafficManagerProfile $profile

لاحظ كيف توجد مكالمة واحدة لـ Add-AzureTrafficManagerEndpointConfig لكل مثيل تطبيق فردي. تشير المعلمة TargetResourceId في كل أمر PowerShell إلى أحد مثيلات التطبيق الثلاثة التي تم توزيعها. سينشر ملف Traffic Manager الحمل عبر جميع نقاط النهاية الثلاث المسجلة في ملف التعريف.

تستخدم جميع نقاط النهاية الثلاث نفس القيمة (10) لمعلمة Weight. يؤدي هذا الموقف إلى قيام Traffic Manager بنشر طلبات العملاء عبر جميع مثيلات التطبيق الثلاثة بشكل متساوٍ نسبياً.

توجيه المجال المخصص للتطبيق في مجال Traffic Manager

الخطوة الأخيرة اللازمة هي توجيه المجال المخصص للتطبيق إلى مجال Traffic Manager. بالنسبة إلى نموذج التطبيق، أشر www.asabuludemo.com إلى scalable-ase-demo.trafficmanager.net. أكمل هذه الخطوة مع مسجل المجال الذي يدير المجال المخصص.

باستخدام أدوات إدارة المجال الخاصة بالمسجل، يلزم إنشاء سجلات CNAME والتي تشير إلى المجال المخصص في مجال Traffic Manager. تُظهر الصورة أدناه مثالاً لما يبدو عليه تكوين CNAME هذا:

Screenshot of configuring CNAME record on DNS.

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

في هذا المثال، المجال المخصص هو www.asabuludemo.com، ولكل مثيل تطبيق المجال المخصص المرتبط به.

Screenshot of App Service custom domain setting.

للحصول على ملخص لتسجيل مجال مخصص باستخدام تطبيقات Azure App Service، راجع تسجيل المجالات المخصصة.

تجربة الطوبولوجيا الموزَّعة

النتيجة النهائية لتكوين Traffic Manager وDNS هي أن طلبات www.asabuludemo.com ستتدفق عبر التسلسل التالي:

  1. سيقوم المتصفح أو الجهاز ببحث DNS عن www.asabuludemo.com
  2. يؤدي إدخال CNAME في مسجل المجال إلى إعادة توجيه بحث DNS إلى Azure Traffic Manager.
  3. يتم إجراء بحث DNS عن scalable-ase-demo.trafficmanager.net على أحد خوادم DNS Azure Traffic Manager.
  4. استناداً إلى نهج موازنة التحميل المحددة مسبقاً في معلمة TrafficRoutingMethod، يحدد Traffic Manager إحدى نقاط النهاية التي تم تكوينها. ثم تقوم بإرجاع FQDN لنقطة النهاية هذه إلى المتصفح أو الجهاز.
  5. نظراً لأن FQDN لنقطة النهاية هو عنوان URL لمثيل تطبيق يتم تشغيله في بيئة خدمة التطبيق، سيطلب المستعرض أو الجهاز من خادم Microsoft Azure DNS حل FQDN إلى عنوان IP.
  6. سيرسل المتصفح أو الجهاز طلب HTTP/S إلى عنوان IP.
  7. سيصل الطلب إلى أحد مثيلات التطبيق التي تعمل على أحد App Service Environments.

تُظهر صورة وحدة التحكم أدناه عملية بحث DNS للمجال المخصص للتطبيق النموذجي. يتحول بنجاح إلى مثيل تطبيق يتم تشغيله في واحدة من نماذج بيئات خدمة التطبيق الثلاث (في هذه الحالة، الثانية من App Service Environments الثلاثة):

Screenshot of DNS lookup result.

وثائق على PowerShell ​​دعم Azure Resource Manager Traffic Manager.

إشعار

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