مشاركة عبر

نظرة عامة على Service Fabric مع إدارة واجهة برمجة التطبيقات API من Azure

  • مقالة

تحتاج التطبيقات السحابية عادة إلى بوابة أمامية لتوفير نقطة دخول واحدة للمستخدمين أو الأجهزة أو التطبيقات الأخرى. في Service Fabric، يمكن أن تكون البوابة أي خدمة عديمة الحالة مثل تطبيق ASP.NET Core أو خدمة أخرى مصممة لدخول نسبة استخدام الشبكة مثل مركز الأحداث أو مركز إنترنت الأشياء أو إدارة واجهة برمجة التطبيقات API من Azure.

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

التوافر

هام

تتوفر هذه الميزة في Premium ومستويات المطورين في API Management نظرا لدعم الشبكة الافتراضية المطلوب.

بناء الأنظمة

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

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

رسم تخطيطي يظهر كيفية عمل خدمة الويب عديمة الحالة كبوابة لتطبيق

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

في هذا السيناريو، لا يزال يتم تقديم واجهة مستخدم الويب من خلال خدمة ويب، بينما تتم إدارة استدعاءات واجهة برمجة تطبيقات HTTP وتوجيهها من خلال إدارة واجهة برمجة تطبيقات Azure، كما هو موضح في الرسم التخطيطي التالي:

رسم تخطيطي يظهر كيفية استمرار تقديم واجهة مستخدم الويب من خلال خدمة ويب، بينما تُدار استدعاءات واجهة برمجة تطبيقات HTTP وتُوجه من خلال إدارة واجهة برمجة تطبيقات Azure.

سيناريوهات التطبيق

الخدمات في Service Fabric إما عديمة الحالة أو ذات حالة خاصة، وقد يتم تقسيمها باستخدام أحد المخططات الثلاثة: مفردة ونطاق int-64 ومُسماة. تتطلب دقة نقطة نهاية الخدمة تحديد قسم معين من مثيل خدمة معين. عند حل نقطة نهاية خدمة، يجب تحديد كل من اسم مثيل الخدمة (على سبيل المثال fabric:/myapp/myservice) وكذلك القسم المحدد للخدمة، إلا في حالة القسم الأحادي.

يمكن استخدام إدارة واجهة برمجة التطبيقات من Azure مع أي مجموعة من الخدمات عديمة الحالة والخدمات ذات الحالة الخاصة وأي نظام تقسيم.

إرسال نسبة استخدام الشبكة إلى خدمة عديمة الحالة

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

مثال

في السيناريو التالي، يحتوي تطبيق "تصميم الخدمة" على خدمة عديمة الحالة مسماة fabric:/app/fooservice تعرض واجهة برمجة تطبيقات HTTP داخلية. اسم مثيل الخدمة معروف ويمكن ترميزه بتعليمة برمجية مباشرة في نهج المعالجة الواردة لإدارة واجهة برمجة التطبيقات.

رسم تخطيطي يظهر تطبيق

إرسال نسبة استخدام الشبكة إلى خدمة ذات حالة خاصة

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

مثال

في السيناريو التالي، يحتوي تطبيق Service Fabric على خدمة مُقسمة ذات حالة خاصة باسم fabric:/app/userservice، والتي تعرض واجهة برمجة تطبيقات HTTP داخلية. اسم مثيل الخدمة معروف ويمكن ترميزه بتعليمة برمجية مباشرة في نهج المعالجة الواردة لإدارة واجهة برمجة التطبيقات.

يتم تقسيم الخدمة باستخدام نظام تقسيم Int64 مع قسمين ونطاق مفاتيح يمتد من Int64.MinValue إلى Int64.MaxValue. يقوم نهج الواجهة الخلفية بحساب مفتاح قسم ضمن هذا النطاق عن طريق تحويل id القيمة المتوفرة في مسار طلب عنوان URL إلى عدد صحيح 64 بت، على الرغم من أنه يمكن استخدام أي خوارزمية هنا لحساب مفتاح القسم.

نظرة عامة على

إرسال نسبة استخدام الشبكة إلى خدمات متعددة عديمة الحالة

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

لتحقيق ذلك، تحتوي عملية إدارة واجهة برمجة التطبيقات على نهج معالجة وارد مع واجهة خلفية لـ Service Fabric تقوم بالتعيين إلى مثيل خدمة عديمة الحالة معين في الواجهة الخلفية لـ Service Fabric استنادًا إلى القيم التي تم استردادها من طلب HTTP الوارد. يتم إرسال الطلبات المرسلة إلى تلك الخدمة إلى مثيل عشوائي للخدمة.

مثال

في هذا المثال، يتم إنشاء مثيل خدمة عديمة الحالة جديد لكل مستخدم لتطبيق باسم تم إنشاؤه ديناميكيًا باستخدام الصيغة التالية:

  • fabric:/app/users/<username>

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

    • يتم توجيه طلب إلى /api/users/foo مثيل الخدمة fabric:/app/users/foo
    • يتم توجيه طلب إلى /api/users/bar مثيل الخدمة fabric:/app/users/bar

رسم تخطيطي يعرض مثالًا حيث يُنشأ مثيل خدمة عديمة الحالة جديد لكل مستخدم لتطبيق باسم مُنشأ ديناميكيًا.

إرسال نسبة استخدام الشبكة إلى خدمات متعددة ذات حالة خاصة

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

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

مثال

في هذا المثال، يتم إنشاء مثيل خدمة ذات حالة خاصة جديد لكل مستخدم لتطبيق باسم تم إنشاؤه ديناميكيًا باستخدام الصيغة التالية:

  • fabric:/app/users/<username>

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

    • يتم توجيه طلب إلى /api/users/foo مثيل الخدمة fabric:/app/users/foo
    • يتم توجيه طلب إلى /api/users/bar مثيل الخدمة fabric:/app/users/bar

يتم تقسيم كل مثيل خدمة أيضًا باستخدام نظام تقسيم Int64 مع قسمين ونطاق مفاتيح يمتد من Int64.MinValue إلى Int64.MaxValue. يقوم نهج الواجهة الخلفية بحساب مفتاح قسم ضمن هذا النطاق عن طريق تحويل id القيمة المتوفرة في مسار طلب عنوان URL إلى عدد صحيح 64 بت، على الرغم من أنه يمكن استخدام أي خوارزمية هنا لحساب مفتاح القسم.

رسم تخطيطي يوضح أن كل مثيل خدمة مقسم أيضًا باستخدام نظام التقسيم Int64 مع قسمين ونطاق مفاتيح يمتد من Int64.MinValue إلى Int64.MaxValue.

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

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