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

  • مقالة
  • قراءة خلال 7 دقائق

نظرة عامة

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

تعد بيئات خدمة التطبيقات نظاما أساسيا مثاليا للتوسع الأفقي. بعد تحديد تكوين بيئة خدمة التطبيق التي يمكن أن تدعم معدل طلب معروف، يمكن للمطورين نشر بيئات خدمة تطبيقات إضافية بطريقة "قاطع ملفات تعريف الارتباط" لتحقيق سعة تحميل الذروة المطلوبة.

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

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

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

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

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

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

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

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

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

إعداد الملف الشخصي لمدير الزيارات

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

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

أسهل طريقة لتسجيل نقاط نهاية خدمة Azure App متعددة، تعمل جميعها في نفس منطقة 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.trafficmanager.net اسم المجال وإقرانه بملف تعريف مدير حركة المرور.

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

مع إنشاء ملف التعريف، تتم إضافة كل مثيل تطبيق إلى ملف التعريف كنقطة نهاية Azure أصلية. تجلب التعليمة البرمجية التالية مرجعا إلى كل تطبيق ويب أمامي. ثم يضيف كل تطبيق كنقطة نهاية لإدارة حركة المرور من خلال المعلمة 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 إلى أحد مثيلات التطبيقات الثلاثة المنشورة. سيوزع الملف الشخصي لمدير حركة المرور الحمل عبر جميع نقاط النهاية الثلاث المسجلة في الملف الشخصي.

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

توجيه النطاق المخصص للتطبيق إلى نطاق مدير الزيارات

الخطوة الأخيرة الضرورية هي توجيه النطاق المخصص للتطبيق إلى نطاق إدارة حركة المرور. بالنسبة إلى نموذج التطبيق، أشر إلى www.asabuludemo.comscalable-ase-demo.trafficmanager.net. أكمل هذه الخطوة باستخدام جهة تسجيل المجالات التي تدير المجال المخصص.

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

Screenshot of configuring CNAME record on DNS.

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

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

Screenshot of App Service custom domain setting.

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

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

النتيجة النهائية لتكوين إدارة حركة المرور و DNS هي أن طلبات الحصول على www.asabuludemo.com سوف تتدفق من خلال التسلسل التالي:

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

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

Screenshot of DNS lookup result.

وثائق حول دعم PowerShell Azure Resource Manager إدارة حركة المرور.

ملاحظة

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