بنية الخدمات المصغرة على Azure Service Fabric

تعرض هذه البنية المرجعية بنية الخدمات المُصغرة المنشورة في Azure Service Fabric. تُظهر تكوينًا أساسيًا لنظام المجموعة الذي يمكن أن يكون بمثابة نقطة البداية لمعظم عمليات النشر.

يتوفر تنفيذ مرجعي لهذه البنية على GitHub.

البنية

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

‏‏سير العمل‬

يتكون التصميم من المكونات التالية. للحصول على المصطلحات أُخرى، راجع نظرة عامة على مصطلحات Service Fabric.

• مجموعة Service Fabric. المجموعة هي مجموعة متصلة بالشبكة من الأجهزة الظاهرية (VMs) التي تقوم بنشر الخدمات المصغرة وإدارتها فيها.

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

• العُقد. إن العُقد هي الأجهزة الظاهرية التي تنتمي إلى مجموعة Service Fabric.

• أنواع العقد. يمثل نوع العقدة مجموعة من مقاييس الأجهزة الظاهرية التي تنشر مجموعة من العُقد. لدى مجموعة Service Fabric نوع واحد على الأقل من العُقد.

  في نظام مجموعة يحتوي على أنواع عقد متعددة، يجب تعريف نوع العقدة الأساسية. يشغّل نوع العقدة الأساسي في نظام المجموعة خدمات نظام Service Fabric. توفر هذه الخدمات إمكانيات النظام الأساسي لـ Service Fabric. يعمل نوع العقدة الأساسية أيضا كعقد أولية، وهي العقد التي تحافظ على توفر نظام المجموعة الأساسي.

  قم بتكوين الأنواع الإضافية للعُقد لتشغيل خدماتك.

• الخدمات. تؤدي الخدمة وظيفة مستقلة يمكن بدأها وتشغيلها على نحوٍ مستقلٍ عن الخدمات الأخرى. يتم نشر مثيلات الخدمات إلى العُقد في نظام المجموعة. هناك نوعان من الخدمات في Service Fabric:

  • خدمات عديمة الحالة. لا تحتفظ الخدمة عديمة الحالة بالحالة داخل الخدمة. إذا تطلب الأمر استمرار الحالة، تتم كتابة الحالة في محزن خارجي واستردادها منه، مثل Azure Cosmos DB.
  • الخدمات ذات الحالة. يتم الاحتفاظ بحالة الخدمة ضمن الخدمة نفسها. تقوم معظم الخدمات ذات الحالة بتنفيذ ذلك من خلال مجموعات موثوقة في Service Fabric.

• Service Fabric Explorer. Service Fabric Explorerهو أداة مفتوحة المصدر لفحص مجموعات Service Fabric وإدارتها.

• Azure Pipelines. تعد Azure Pipelines جزءا من خدمات Azure DevOps وتدير البنيات والاختبارات والنشرات التلقائية. يمكنك أيضا استخدام حلول التكامل المستمر والتسليم المستمر (CI/CD) التابعة لجهة خارجية مثل Jenkins.

• Azure Monitor. يجمع Azure Monitor المقاييس والسجلات ويخزنها، بما في ذلك مقاييس النظام الأساسي لخدمات Azure في الحل وبيانات تتبع استخدام التطبيق. استخدم هذه البيانات لمراقبة التطبيق، وإعداد التنبيهات، ولوحات المعلومات، وإجراء تحليل السبب الجذري لحالات الفشل. يتكامل Azure Monitor مع Service Fabric لجمع المقاييس من وحدات التحكم والعقد والحاويات، جنبا إلى جنب مع سجلات الحاوية والعقدة.

• Azure Key Vault. استخدم Key Vault لتخزين أي أسرار تطبيق تستخدمها الخدمات المصغرة، مثل سلسلة الاتصال.

• إدارة Azure APIM. في هذه البنية، تعمل API Management بصفتها بوابة لواجهة برمجة التطبيقات تقبل الطلبات من العملاء وتوجهها إلى خدماتك.

الاعتبارات

تنفذ هذه الاعتبارات ركائز إطار عمل Azure Well-Architected، وهو مجموعة من المبادئ التوجيهية لتحسين جودة حمل العمل.

اعتبارات التصميم

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

يوفر Service Fabric بنية أساسية لبناء الخدمات المصغرة، ونشرها، وترقيتها بكفاءة. كما يوفر خيارات للتحجيم التلقائي وإدارة الحالة ومراقبة الصحة وإعادة تشغيل الخدمات في حالة الفشل.

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

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

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

لمزيد من المعلومات، راجع هل تريد التعرف على Service Fabric؟.

نموذج التعبئة والتغليف من تطبيق إلى خدمة

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

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

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

نماذج برمجة Service Fabric

عند إضافة خدمة مُصغرة إلى تطبيق Service Fabric، حدّد ما إذا كان يحتوي على حالة أو بيانات تحتاج إلى إتاحة وموثوقية عالية. إذا كان ذلك هو الأمر، فهل يمكن تخزين البيانات خارجيًا أم أن البيانات الواردة متضمنة في الخدمة؟ اختر خدمة عديمة الحالة إذا لم تكن بحاجة إلى تخزين البيانات أو إذا كنت تريد تخزين البيانات في موقع تخزين خارجي. ضع في اعتبارك اختيار خدمة ذات حالة إذا كانت إحدى هذه العبارات تنطبق:

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

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

يقوم Service Fabric بصياغة نماذج لكلاً من الحاويات والملفات التنفيذية للضيف كخدمات عديمة الحالة. للحصول على إرشادات حول اختيار نموذج، راجع نظرة عامة على نموذج برمجة Service Fabric.

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

للوصول إلى ضيف قابل للتنفيذ من خلال وكيل عكسي، تأكد من إضافة السمة UriScheme إلى Endpoint العنصر في بيان خدمة الضيف القابل للتنفيذ.

    <Endpoints>
      <Endpoint Name="MyGuestExeTypeEndpoint" Port="8090" Protocol="http" UriScheme="http" PathSuffix="api" Type="Input"/>
    </Endpoints>

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

    <Endpoints>
      <Endpoint Name="MyGuestExeTypeEndpoint" Port="8090" Protocol="http" PathSuffix="api" Type="Input"/>
    </Endpoints>

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

• حزم تطبيق
• حزم ملف قابل للتنفيذ موجود إلى Service Fabric وتوزيعه

بوابة API

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

نوصي بإدارة واجهة برمجة تطبيقات Azure لمعظم السيناريوهات، ولكن Traefik هو بديل مفتوح المصدر شائع. يتم دمج كلا الخيارين للتكنولوجية مع Service Fabric.

• إدارة واجهة برمجة التطبيقات. يعرض عنوان IP عاما ويوجه نسبة استخدام الشبكة إلى خدماتك. يتم تشغيلها في شبكة فرعية مخصصة في الشبكة الظاهرية نفسها مثل مجموعة Service Fabric.

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

  لمزيد من المعلومات، راجع Service Fabric في نظرة عامة على «إدارة واجهة برمجة تطبيقات» Azure.

• (ترافيك) يدعم ميزات مثل التوجيه والتتبع والسجلات والمقاييس. يتم تشغيل Traefik كخدمة عديمة الحالة في مجموعة Service Fabric. يمكن دعم تعيين إصدار الخدمة من خلال التوجيه.

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

لا يمتلك Traefik الوظيفة، على عكس Azure API Management، لحل قسم الخدمة ذات الحالة (في أكثر من قسم واحد) يتم توجيه الطلب إليه. لمزيد من المعلومات، راجع إضافة مطابق لخدمات التقسيم.

تتضمن خيارات إدارة واجهة برمجة التطبيقات الأخرى Azure Application Gateway و Azure Front Door. يمكنك استخدام هذه الخدمات بالاقتران مع APIM لتنفيذ مهام مثل التوجيه وإنهاء SSL وجدار الحماية.

الاتصال المشترك بين الخدمات

لتسهيل الاتصال من خدمة إلى خدمة، ضع في اعتبارك التوصيات التالية:

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

  بالنسبة لمعظم أحمال العمل، نوصي باستخدام HTTP بدلا من الاتصال عن بعد بالخدمة المضمنة في Service Fabric.

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

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

تتضمن الخيارات الأخرى للاتصال بين الخدمات ما يلي:

• Traefik للتوجيه المتقدم.
• DNS لسيناريوهات التوافق حيث تتوقع الخدمة استخدام نظام DNS.
• فئة ServicePartitionClient<TCommunicationClient>، التي تخزن نقاط نهاية الخدمة مؤقتا. يمكن أن يتيح أداء أفضل، لأن المكالمات تنتقل مباشرة بين الخدمات دون وسطاء أو بروتوكولات مخصصة.

قابلية التوسع

يدعم Service Fabric تحجيم كيانات نظام المجموعة التالية:

• تحجيم عدد العقد لكل نوع عقدة
• خدمات التحجيم

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

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

عند إنشاء مجموعة Service Fabric، قم بتوفير أنواع العُقد بناءً على احتياجاتك في الأمان والقابلية للتوسع. يتم تعيين كل نوع من أنواع العُقد لمجموعة مقاييس الأجهزة الظاهرية ويمكن تغيير حجمها بشكل مستقل.

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

تحجيم العُقد

يدعم Service Fabric التحجيم التلقائي للتحجيم والتوسيع. يمكنك تكوين كل نوع عقدة للتحجيم التلقائي بشكل مستقل.

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

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

لمزيد من المعلومات حول التحجيم على مستوى العقدة أو المجموعة، راجع تحجيم مجموعات Azure Service Fabric.

خدمات التحجيم

تطبق الخدمات عديمة الحالة وذات الحالة سياسات مختلفة للتحجيم.

لخدمة عديمة الحالة (التحجيم التلقائي):

• قم باستخدم مشغل متوسط تحميل القسم. يحدد هذا المشغل وقت تحجيم الخدمة أو تصغيرها، استنادا إلى قيمة حد التحميل المحددة في نهج التحجيم. يمكنك أيضًا تعيين عدد مرات فحص المُشغّل. راجع مشغل متوسط​ تحميل القسم مع التحجيم المستند إلى المثيل. يسمح لك هذا الأسلوب بزيادة عدد العقد المتاحة.
• اضبط InstanceCount على -1 في بيان الخدمة، الذي يخبر Service Fabric بتشغيل مثيل للخدمة على كل عقدة. تُمكّن الخدمة بهذا الأسلوب من تغيير الحجم بشكل ديناميكي فيما يتغير حجم نظام المجموعة. مع تغير عدد العُقد في نظام المجموعة، يقوم Service Fabric تلقائيًا بإنشاء مثيلات الخدمة وحذفها لمطابقتها.

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

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

  للحصول على معلومات حول السيناريوهات التي تستفيد من هذه الاستراتيجية، راجع تغيير الحجم في Service Fabric.

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

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

• تحجيم مجموعة Service Fabric داخل أو خارج باستخدام قواعد التحجيم التلقائي أو يدويا
• تغيير حجم مجموعة Service Fabric برمجيا
• توسيع نطاق مجموعة Service Fabric عن طريق إضافة مجموعة مقياس جهاز ظاهري

استخدام المقاييس لموازنة الحمل

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

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

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

التوافر

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

ضع في اعتبارك تقييد موارد خدماتك. راجع آلية إدارة الموارد.

فيما يلي الاعتبارات الشائعة:

• لا تخلط الخدمات التي تحكمها الموارد والخدمات التي ليست موردا محكوما على نفس نوع العقدة. قد تستهلك الخدمات غير المحكومة موارد كثيرة جدا وتؤثر على الخدمات المحكومة. حدد قيود الموضع للتأكد من أن هذه الأنواع من الخدمات لا تعمل على نفس مجموعة العقد. (ذلك مثال على نمط الفواصل.)
• حدّد نواة «وحدة المعالجة المركزية» والذاكرة لحجزها لمثيل الخدمة. للحصول على معلومات حول استخدام سياسات إدارة الموارد وقيودها، راجع إدارة الموارد.

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

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

لمزيد من المعلومات، راجع توافر خدمات Service Fabric.

الأمان

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

فيما يلي بعض النقاط الرئيسية لتأمين تطبيقك على Service Fabric.

الشبكة الظاهرية

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

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

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

نقاط النهاية والاتصال المشترك بين الخدمات

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

للمساعدة في تأمين الاتصالات بين الخدمات:

• فكّر في تمكين نقاط نهاية HTTPS في خدمات الويب لـ ASP.NET Core أو Java.
• قم بإنشاء اتصال آمن بين الوكيل العكسي والخدمات. للحصول على التفاصيل، راجع الاتصال إلى الخدمة الآمنة.

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

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

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

البيانات السرية والشهادات

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

1. مصادقة وصول الخدمة إلى مخزن المفاتيح.

   تمكين الهوية المُدارة على مجموعة مقاييس الأجهزة الظاهرية المستضيفة للخدمة.

2. قم بتخزين أسرارك في مخزن المفاتيح.

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

3. قم بالوصول إلى هذه البيانات السرية في خدمتك.

   أضف key vault URI في ملف app الإعدادات.json. في خدمتك، أضف موفر التكوين الذي يقرأ من مخزن المفاتيح، ويبني التكوين، ويوصول إلى السر من التكوين المضمن.

فيما يلي مثال حيث تقوم خدمة سير العمل بتخزين سر في مخزن المفاتيح بالتنسيق CosmosDB--Database.

namespace Fabrikam.Workflow.Service
{
    public class ServiceStartup
    {
        public static void ConfigureServices(StatelessServiceContext context, IServiceCollection services)
        {
            var preConfig = new ConfigurationBuilder()
                …
                .AddJsonFile(context, "appsettings.json");

            var config = preConfig.Build();

            if (config["AzureKeyVault:KeyVaultUri"] is var keyVaultUri && !string.IsNullOrWhiteSpace(keyVaultUri))
            {
                preConfig.AddAzureKeyVault(keyVaultUri);
                config = preConfig.Build();
            }
    }
}

للوصول إلى السر، حدد الاسم السري في التكوين المضمن.

       if(builtConfig["CosmosDB:Database"] is var database && !string.IsNullOrEmpty(database))
       {
            // Use the secret.
       }

لا تستخدم شهادات العميل للوصول إلى Service Fabric Explorer. بدلا من ذلك، استخدم معرف Microsoft Entra. راجع خدمات Azure التي تدعم مصادقة Microsoft Entra.

لا تستخدم الشهادات الموقعة ذاتيا للإنتاج.

حماية البيانات الثابتة

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

لمزيد من المعلومات حول تأمين Service Fabric، راجع:

• نظرة عامة على أمان Azure Service Fabric
• أفضل ممارسات أمان Azure Service Fabric
• قائمة تدقيق أمان Azure Service Fabric

مرونة

لإصلاح حالات الفشل والحفاظ على حالة العمل التام، يجب على التطبيق تنفيذ أنماط معينة من المرونة. فيما يلي بعض الأنماط الشائعة:

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

يستخدم التنفيذ المرجعي Polly، وهو خيار مفتوح المصدر، لتنفيذ جميع هذه الأنماط.

مراقبة‬

قبل استكشاف خيارات المراقبة، نوصي بقراءة هذه المقالة حول تشخيص السيناريوهات الشائعة باستخدام Service Fabric. يمكنك التفكير في مراقبة البيانات في هذه المجموعات:

• سجلات ومقاييس التطبيق
• صحة Service Fabric وبيانات الحدث
• مقاييس البنية الأساسية وسجلاتها
• المقاييس والسجلات في الخدمات غير المستقلة

هذان خياران رئيسيان لتحليل تلك البيانات:

• Application Insights
• Log Analytics

يمكنك استخدام Azure Monitor لإعداد لوحات المعلومات للقيام بالمراقبة وإرسال التنبيهات إلى المُشغّلين. كما يتم دمج بعض أدوات المراقبة التابعة لجهة خارجية مع Service Fabric، مثل Dynatrace. للحصول على التفاصيل، راجع شركاء مراقبة Azure Service Fabric.

سجلات ومقاييس التطبيق

يوفر القياس عن بعد للتطبيق بيانات يمكن أن تساعدك على مراقبة صحة خدمتك وتحديد المشكلات. لإضافة الآثار والأحداث إلى خدمتك:

• استخدم Microsoft.Extensions.Logging إذا كنت تقوم بتطوير خدمتك باستخدام ASP.NET Core. بالنسبة لأطر العمل الأخرى، استخدم مكتبة تسجيل من اختيارك، مثل Serilog.
• أضف الأجهزة الخاصة بك باستخدام فئة TelemetryClient في SDK، واعرض البيانات في Application Insights. راجع إضافة أدوات مُخصصة إلى تطبيقك.
• سجل تتبع الأحداث لأحداث Windows (ETW) باستخدام EventSource. يتوفر هذا الخيار بشكل افتراضي في حل Visual Studio Service Fabric.

يوفر Application Insights الكثير من بيانات تتبع الاستخدام المُضمنة: الطلبات، والتتبعات، والأحداث، والاستثناءات، والمقاييس، والتبعيات. إذا كانت خدمتك تعرض نقاط نهاية HTTP، فقم بتمكين Application Insights عن طريق استدعاء UseApplicationInsights أسلوب الملحق ل Microsoft.AspNetCore.Hosting.IWebHostBuilder. للحصول على معلومات حول وضع علامة على الخدمة الخاصة بك على Application Insights، راجع هذه المقالات:

• البرنامج التعليمي: مراقبة وتشخيص تطبيق ASP.NET Core على Service Fabric باستخدام Application Insights
• Application Insights ل ASP.NET Core
• Application Insights .NET SDK
• Application Insights SDK على Service Fabric

لعرض التتبعات وسجلات الأحداث، استخدم Application Insights كأحد المتلقيات للتسجيل المنظم. تكوين Application Insights باستخدام مفتاح تقرير عن حالة النظام عن طريق استدعاء أسلوب الملحق AddApplicationInsights . في هذا المثال، يتم تخزين مفتاح تقرير عن حالة النظام كبيانات سرية في مخزن المفاتيح.

    .ConfigureLogging((hostingContext, logging) =>
        {
            logging.AddApplicationInsights(hostingContext.Configuration ["ApplicationInsights:InstrumentationKey"]);
        })

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

تستخدم خدمات ASP.NET Core واجهة ILogger لسجل التطبيقات. لتوفير سجلات التطبيقات في Azure Monitor، أرسل ILogger الأحداث إلى Application Insights. يمكن ل Application Insights إضافة خصائص الارتباط إلى ILogger الأحداث، وهو أمر مفيد لتصور التتبع الموزع.

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

• تسجيل التطبيق
• إضافة تسجيل إلى تطبيق Service Fabric

صحة Service Fabric وبيانات الحدث

يتضمن بيانات تتبع استخدام Service Fabric مقاييس الصحة وأحداث حول تشغيل وأداء مجموعة Service Fabric وكياناتها: العُقد، والتطبيقات، والخدمات، والأقسام، والنسخ المتماثلة. يمكن أن تأتي بيانات الصحة والحدث من:

• EventStore. تجمع خدمة النظام ذات الحالة هذه الأحداث المتعلقة بالمجموعة وكياناتها. يستخدم Service Fabric EventStore لكتابة أحداث Service Fabric لتوفير معلومات حول مجموعتك لتحديثات الحالة واستكشاف الأخطاء وإصلاحها والمراقبة. يمكن ل EventStore أيضا ربط الأحداث من كيانات مختلفة في وقت معين لتحديد المشكلات في نظام المجموعة. تعرض الخدمة هذه الأحداث من خلال «واجهة برمجة تطبيقات» REST.

  للحصول على معلومات حول كيفية الاستعلام عن «واجهات برمجة التطبيقات» EventStore، راجع الاستعلام عن «واجهات برمجة تطبيقات» EventStore لأحداث نظام المجموعة. يمكنك عرض الأحداث من EventStore في Log Analytics عن طريق تكوين مجموعتك باستخدام ملحق تشخيص Azure ل Windows (WAD).

• HealthStore. توفر هذه الخدمة ذات الحالة لقطة لصحة نظام المجموعة الحالية. وهو يجمع جميع البيانات الصحية التي تم الإبلاغ عنها من قبل الكيانات في التسلسل الهرمي. يتم تصور البيانات في Service Fabric Explorer. كما يراقب HealthStore ترقيات التطبيقات. يمكنك استخدام استعلامات الصحة في PowerShell، أو تطبيق .NET، أو «واجهات برمجة تطبيقات» REST. راجع مقدمة لمراقبة صحة Service Fabric.

• تقارير صحية مخصصة. ضع في اعتبارك تنفيذ خدمات المراقبة الداخلية التي يمكنها الإبلاغ عن البيانات الصحية المخصصة بشكل دوري، مثل الحالات الخاطئة لتشغيل الخدمات. يمكنك قراءة تقارير الحماية في Service Fabric Explorer.

مقاييس البنية الأساسية وسجلاتها

تساعدك مقاييس البنية الأساسية على فهم تخصيص الموارد في نظام المجموعة. فيما يلي الخيارات الرئيسية لجمع هذه المعلومات:

• WAD. قم بجمع السجلات والمقاييس على مستوى العُقدة على Windows. يمكنك استخدام WAD عن طريق تكوين ملحق IaaSDiagnostics VM على أي مجموعة مقياس جهاز ظاهري تم تعيينها إلى نوع عقدة لتجميع أحداث التشخيص. يمكن أن تتضمن هذه الأحداث سجلات أحداث Windows وعدادات الأداء ونظام ETW/البيان والأحداث التشغيلية والسجلات المخصصة.
• عامل Log Analytics. قم بتكوين ملحق «الأجهزة الظاهرية» MicrosoftMonitoringAgent لإرسال سجلات أحداث Windows، وعدّادات الأداء، والسجلات المخصصة إلى Log Analytics.

هناك بعض التداخل في أنواع المقاييس التي تم جمعها من خلال الآليات السابقة، مثل عدادات الأداء. عند وجود تداخل، نوصي باستخدام عامل Log Analytics. نظرا لأن عامل Log Analytics لا يستخدم تخزين Azure، فإن زمن الانتقال منخفض. أيضا، لا يمكن تغذية عدادات الأداء في IaaSDiagnostics في Log Analytics بسهولة.

لمزيد من المعلومات حول ملحقات «الأجهزة الظاهرية»، راجع ملحقات وميزات الأجهزة الظاهرية.

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

يمكنك أيضًا عرض سجلات الأداء وبيانات تتبع الاستخدام المتعلقة بمجموعة Service Fabric، وأحمال العمل، وحركة مرور الشبكة، والتحديثات المعلقة، والمزيد. راجع مراقبة الأداء باستخدام Log Analytics.

يوفر حل Service Map في Log Analytics معلومات حول طبولوجيا نظام المجموعة (أي العمليات التي تعمل في كل عقدة). أرسل البيانات في حساب التخزين إلى Application Insights. قد يحدث بعض التأخير في إدخال البيانات إلى Application Insights. إذا كنت ترغب في رؤية البيانات في الوقت الفعلي، ففكر في تكوين مراكز الأحداث باستخدام المتلقيات والقنوات. لمزيد من المعلومات، راجع تجميع الأحداث وجمعها باستخدام WAD.

مقاييس الخدمة غير المستقلة

• يوفر Application Map في Application Insights طوبولوجيا التطبيق باستخدام استدعاءات تبعية HTTP التي تم إجراؤها بين الخدمات، مع Application Insights SDK المثبت.
• توفر Service Map في Log Analytics معلومات حول نسبة استخدام الشبكة الواردة والصادرة من وإلى الخدمات الخارجية. يتكامل Service Map مع حلول أخرى، مثل التحديثات أو الأمان.
• يمكن لمراقبة مخصصة الإبلاغ عن حالات الخطأ على الخدمات الخارجية. على سبيل المثال، يمكن أن توفر الخدمة تقريرا عن حالة الخطأ إذا لم تتمكن من الوصول إلى خدمة خارجية أو تخزين بيانات (Azure Cosmos DB).

تتبع موزع

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

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

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

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

• تنفيذ استعلام عبر موارد متعددة
• ارتباط بيانات تتبع الاستخدام في Application Insights

التنبيهات ولوحات المعلومات

يدعم Application Insights و Log Analytics لغة استعلام واسعة النطاق (لغة استعلام Kusto) التي تتيح لك استرداد بيانات السجل وتحليلها. استخدم الاستعلامات لإنشاء مجموعات بيانات وتصورها في لوحات معلومات التشخيص.

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

تسمح لك قواعد التنبيه في بحث السجل بتعريف استعلام Kusto وتشغيله مقابل مساحة عمل Log Analytics على فترات منتظمة. يتم إنشاء التنبيه إذا تطابقت نتيجة الاستعلام مع شرط معين.

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

استخدم حاسبة تسعير Azure لتقدير التكاليف. يتم وصف اعتبارات أخرى في ركيزة تحسين التكلفة لإطار عمل Microsoft Azure Well-Architected.

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

Azure Service Fabric

يتم تحصيل رسوم منك مقابل مثيلات الحوسبة والتخزين وموارد الشبكات وعناوين IP التي تختارها عند إنشاء مجموعة Service Fabric. توجد رسوم توزيع في Service Fabric.

مجموعات توسيع الجهاز الافتراضي

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

إدارة Azure API

Azure API Management هي بوابة لتوجيه الطلبات من العملاء إلى خدماتك في نظام المجموعة.

هناك خيارات تسعير مختلفة. يتم فرض رسوم على خيار الاستهلاك على أساس الدفع عند الاستخدام ويتضمن مُكّون البوابة. استنادا إلى حمل العمل الخاص بك، اختر خيارا موصوفا في تسعير APIM.

Application Insights

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

Azure Monitor

بالنسبة إلى Azure Monitor Log Analytics، تتم محاسبتك على استيعاب البيانات والاحتفاظ بها. لمزيد من المعلومات، راجعAzure Monitor pricing.

Azure Key Vault

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

خدمات Azure DevOps

تستخدم هذه البنية المرجعية Azure Pipelines للنشر. تسمح خدمة Azure Pipelines بوظيفة مجانية تستضيفها Microsoft مع 1800 دقيقة شهريا ل CI/CD ووظيفة واحدة مستضافة ذاتيا مع دقائق غير محدودة شهريا. الوظائف الإضافية لها رسوم. لمزيد من المعلومات، راجع تسعير خدمات Azure DevOps.

للحصول على اعتبارات DevOps في بنية الخدمات المصغرة، راجع CI/CD للخدمات المصغرة.

لمعرفة كيفية نشر تطبيق حاوية باستخدام CI/CD إلى مجموعة Service Fabric، راجع هذا البرنامج التعليمي.

نشر هذا السيناريو

لنشر تنفيذ المرجع لهذا الهيكل، اتبع الخطوات في GitHub repo.

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

• التدريب: مقدمة إلى Azure Service Fabric
• نظرة عامة على Azure Service Fabric
• وثائق خدمة API Management
• ما هو Azure Pipelines؟

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

• استخدام تحليل النطاق لنمذجة الخدمات الصغيرة
• ⁧تصميم بنية الخدمات المُصغّرة⁧⁩