نمط الخوادم المخصصة للتوزيع

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

السياق والمشكلة

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

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

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

حل

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

يمكن أن تطبق طوابع النشر ما إذا كان الحل الخاص بك يستخدم البنية التحتية كخدمة (IaaS) أو مكونات النظام الأساسي كخدمة (PaaS)، أو مزيج من كليهما. عادةً ما تتطلب أحمال عمل IaaS المزيد من التدخل لتوسيع النطاق، لذلك قد يكون النمط مفيداً لأحمال العمل الثقيلة ل IaaS للسماح بالتوسع.

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

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

يتم استخدام نمط طابع النشر داخلياً من قبل العديد من خدمات Azure، بما في ذلك App ServiceوAzure StackوAzure Storage.

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

التوزيع

نظرًا للتعقيد الذي ينطوي عليه نشر نسخ متطابقة من نفس المكونات، فإن ممارسات DevOps الجيدة ضرورية لضمان النجاح عند تنفيذ هذا النمط. ضع في اعتبارك وصف البنية الأساسية كتعلم برمجي، مثل استخدام BicepوJSON Azure Resource Manager (قوالب ARM)وTerraform والبرامج النصية. باستخدام هذا النهج، يمكنك التأكد من أن نشر كل طابع يمكن التنبؤ به وقابل للتكرار. كما أنه يقلل من احتمال حدوث أخطاء بشرية مثل عدم التطابق العرضي في التكوين بين الطوابع.

يمكنك نشر التحديثات تلقائياً على جميع الطوابع بالتوازي، وفي هذه الحالة قد تفكر في تقنيات مثل Bicep أو قوالب Resource Manager لتنسيق نشر البنية الأساسية والتطبيقات الخاصة بك. بدلاً من ذلك، قد تقرر طرح التحديثات تدريجياً لبعض الطوابع أولاً، ثم تدريجيا للآخرين. ضع في اعتبارك استخدام أداة إدارة إصدار مثل Azure Pipelines أو GitHub Actions لتنسيق عمليات النشر لكل طابع. لمزيد من المعلومات، راجع:

• دمج Bicep مع Azure Pipelines
• يدمج قوالب ARM مع مسارات Azure

ضع في اعتبارك بعناية طبولوجيا اشتراكات Azure ومجموعات الموارد الخاصة عمليات النشر الخاصة بك:

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

تخطيط القدرة الإنتاجية

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

توجيه حركة المرور

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

• unit1.aus.myapi.contoso.com توجيه نسبة استخدام الشبكة إلى الطابع unit1 داخل منطقة أسترالية.
• unit2.aus.myapi.contoso.com توجيه نسبة استخدام الشبكة إلى الطابع unit2 داخل منطقة أسترالية.
• unit1.eu.myapi.contoso.com توجيه نسبة استخدام الشبكة إلى الطابع unit1 داخل منطقة أوروبية.

ثم يكون العملاء مسؤولين عن الاتصال بالطابع الصحيح.

إذا كانت نقطة دخول واحدة لجميع حركة المرور مطلوبة، يمكن استخدام خدمة توجيه نسبة استخدام الشبكة لحل الطابع لطلب معين أو عميل أو مستأجر. إما أن توجه خدمة توجيه نسبة استخدام الشبكة العميل إلى عنوان URL ذي الصلة للطابع (على سبيل المثال، باستخدام رمز حالة استجابة HTTP 302)، أو قد تعمل كوكيل عكسي وإعادة توجيه نسبة استخدام الشبكة إلى الطابع ذي الصلة، دون أن يكون العميل على علم.

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

على سبيل المثال، يمكن نشر Azure API Management للعمل في دور خدمة توجيه نسبة استخدام الشبكة. يمكنه تحديد الطابع المناسب لطلب من خلال البحث عن البيانات في مجموعة Azure Cosmos DB التي تخزن التعيين بين المستأجرين والطوابع. يمكن لإدارة واجهة برمجة التطبيقات بعد ذلك تعيين عنوان URL الخلفي ديناميكياً إلى خدمة واجهة برمجة التطبيقات للطابع ذي الصلة.

لتمكين التوزيع الجغرافي للطلبات والتكرار الجغرافي لخدمة توجيه نسبة استخدام الشبكة، يمكن نشر إدارة واجهة برمجة التطبيقات عبر مناطق متعددة، أو يمكن استخدام Azure Front Door لتوجيه نسبة استخدام الشبكة إلى أقرب مثيل. يمكن تكوين Front Door مع تجمع الواجهة الخلفية، ما يتيح توجيه الطلبات إلى أقرب مثيل APIM متوفر. إذا لم يتم كشف التطبيق الخاص بك عبر HTTP/S، يمكنك استخدام موازن تحميل Azure عبر المناطق لتوزيع المكالمات الواردة إلى موازنات تحميل Azure الإقليمية. يمكن استخدام ميزة التوزيع العمومي لـ Azure Cosmos DB للحفاظ على تحديث معلومات التعيين عبر كل منطقة.

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

مثال على بنية توجيه نسبة استخدام الشبكة

ضع في اعتبارك المثال التالي لبنية توجيه حركة المرور، والتي تستخدم Azure Front Door و Azure API Management و Azure Cosmos DB لتوجيه حركة المرور العالمية، ثم سلسلة من الطوابع الخاصة بالمنطقة:

لنفترض أن المستخدم يقيم عادة في نيويورك. يتم تخزين بياناتهم في الطابع 3، في منطقة شرق الولايات المتحدة.

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

المسائل والاعتبارات

يجب مراعاة النقاط التالية عند تحديد كيفية تنفيذ هذا النمط:

• عملية التوزيع. عند نشر طوابع متعددة، من المستحسن للغاية أن يكون لديك عمليات توزيع تلقائية وقابلة للتكرار بالكامل. ضع في اعتبارك استخدام قوالب Bicep أو JSON ARM أو وحدات Terraform النمطية لتعريف الطوابع بشكل تعريفي، وللحفاظ على اتساق التعريفات.
• عمليات الطوابع المتقاطعة. عندما يتم نشر الحل الخاص بك بشكل مستقل عبر طوابع متعددة، يمكن أن تصبح الأسئلة مثل "كم عدد العملاء لدينا عبر جميع طوابعنا؟" أكثر تعقيداً للإجابة. قد تحتاج الاستعلامات إلى تنفيذها مقابل كل طابع وتجميع النتائج. بدلاً من ذلك، النظر في جعل جميع الطوابع تنشر البيانات في مستودع بيانات مركزي للإبلاغ الموحد.
• تحديد نهج توسيع النطاق. الطوابع لها سعة محدودة، والتي قد يتم تعريفها باستخدام مقياس وكيل مثل عدد المستأجرين الذين يمكن توزيعهم على الطابع. من المهم مراقبة السعة المتاحة والسعة المستخدمة لكل طابع، ونشر طوابع إضافية بشكل استباقي للسماح بتوجيه المستأجرين الجدد إليهم.
• الحد الأدنى لعدد الطوابع. عند استخدام نمط Deployment Stamp، ينصح بنشر طابعين على الأقل من الحل الخاص بك. إذا قمت بنشر طابع واحد فقط، فمن السهل افتراضات تعليمات برمجية مضمنة عن طريق الخطأ في التعليمات البرمجية أو التكوين الذي لن ينطبق عند التوسع.
• التكلفة. يتضمن نمط ختم النشر نشر نسخ متعددة من مكون البنية التحتية الخاص بك، والتي من المحتمل أن تنطوي على زيادة كبيرة في تكلفة تشغيل الحل الخاص بك.
• التنقل بين الطوابع. يتم نشر كل طابع وتشغيله بشكل مستقل، لذلك قد يكون من الصعب نقل المستأجرين بين الطوابع. سيحتاج تطبيقك إلى منطق مخصص لنقل المعلومات حول عميل معين إلى طابع مختلف، ثم لإزالة معلومات المستأجر من الطابع الأصلي. وقد تتطلب هذه العملية مسودة خلفية للاتصال بين الطوابع، مما يزيد من تعقيد الحل الشامل.
• توجيه حركة المرور. كما هو موضح سابقا في هذه المقالة، يمكن أن يتطلب توجيه نسبة استخدام الشبكة إلى الطابع الصحيح لطلب معين مكونا إضافيا لحل المستأجرين إلى الطوابع. قد يحتاج هذا المكون بدوره إلى إتاحة عالية.
• المكونات المشتركة. قد يكون لديك بعض المكونات التي يمكن مشاركتها عبر الطوابع. على سبيل المثال، إذا كان لديك تطبيق مشترك من صفحة واحدة لجميع المستأجرين، ففكر في نشر ذلك في منطقة واحدة واستخدام Azure CDN لنسخه بشكل عام.

موعد استخدام النمط

هذا النمط مفيد عندما:

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

هذا النمط غير مناسب لـ:

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

تصميم حمل العمل

يجب على المهندس المعماري تقييم كيفية استخدام نمط طوابع النشر في تصميم حمل العمل الخاص بهم لمعالجة الأهداف والمبادئ التي تغطيها ركائز Azure Well-Architected Framework. على سبيل المثال:

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

تقنيات الدعم

• البنية الأساسية كتعليمة برمجية. على سبيل المثال، Bicep، Resource Manager القوالب، Azure CLI، Terraform، PowerShell، Bash.
• Azure Front Door، الذي يمكنه توجيه نسبة استخدام الشبكة إلى طابع معين أو إلى خدمة توجيه نسبة استخدام الشبكة.

مثال

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

انقر فوق الارتباط التشعبي أدناه لتوزيع الحل.

مثال على نهج توجيه نسبة استخدام الشبكة

ينشر المثال التالي تنفيذ حل توجيه نسبة استخدام الشبكة الذي يمكن استخدامه مع مجموعة من طوابع النشر لتطبيق واجهة برمجة تطبيقات افتراضي. للسماح بالتوزع الجغرافي للطلبات الواردة، يتم نشر Front Door جنبا إلى جنب مع مثيلات متعددة من APIM على مستوى الاستهلاك. يقرأ كل مثيل APIM معرف المستأجر من عنوان URL للطلب ثم يبحث عن الطابع ذي الصلة للطلب من مخزن بيانات Azure Cosmos DB الموزع جغرافيا. ثم تتم إعادة توجيه الطلب إلى الطابع الخلفي ذي الصلة.

انقر فوق الارتباط التشعبي أدناه لتوزيع الحل.

المساهمون

تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.

الكاتب الرئيسي:

• جون داونز | مدير البرنامج الأساسي

مساهمون آخرون:

• دانيال لارسن | مهندس العملاء الرئيسي، FastTrack ل Azure
• أنجيل لوبيز | مهندس برامج أول، أنماط وممارسات Azure
• باولو سالفاتوري | مهندس العملاء الرئيسي، FastTrack for Azure
• Arsen Vladimirskiy | مهندس العملاء الرئيسي، FastTrack for Azure

لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.

الموارد ذات الصلة

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