تحرير

مشاركة عبر

نظام وسائط الشبكة السحابية Gridwich

Azure Blob Storage
Azure Event Grid
Azure Functions
Azure Logic Apps

تعالج مسارات Gridwich أصول الوسائط وتعالجها وتخزنها وتقدمها بمساعدة طريقتين جديدتين، هما Azure Event Grid Sandwich وTerraform Sandwich.

بناء الأنظمة

تتميز بنية Gridwich بسندويتشين يعالجان متطلبات معالجة الأحداث غير المتزامنة والبنية الأساسية كتعلم برمجي:

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

    رسم تخطيطي يوضح شطيرة معالج Event Grid.

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

  • Terraform Sandwich هو نمط Terraform متعدد المراحل تم تحديثه لدعم البنية الأساسية كتعليمة برمجية. يعني فصل إصدارات البنية الأساسية والبرامج أنه يجب إصدار تطبيق Azure Functions وتشغيله قبل أن يتمكن Terraform من توزيع اشتراك «شبكة الأحداث». لمعالجة هذا المتطلب، هناك وظيفتان Terraform في مسار CI/CD:

    رسم تخطيطي يوضح وظائف شطيرة Terraform.

    • ينشئ Terraform 1 جميع الموارد باستثناء اشتراكات شبكة أحداث Azure.
    • ينشئ Terraform 2 اشتراكات شبكة الأحداث بعد تشغيل البرنامج.

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

‏‏سير العمل‬

تغطي عملية طلب واستجابة Gridwich الطلبات التالية:

  • إنشاء
  • النقل
  • الاستقبال
  • إرسال إلى مكونات Gridwich
  • الإقرار والإجراءات
  • الاستجابات

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

رسم تخطيطي يوضح عملية استجابة طلب Gridwich.

  1. ينشئ النظام الخارجي طلباً ويرسله إلى وسيط الطلب.

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

  3. ويستهلك تطبيق Gridwich Azure Functions الأحداث من شبكة الأحداث. للحصول على معدل نقل أفضل، يعرف Gridwich نقطة نهاية HTTP كنموذج دفع تبدأه شبكة الأحداث، بدلاً من نموذج التحقق من ربط شبكة الأحداث الذي توفره Azure Functions.

  4. يقرأ تطبيق Azure Functions خصائص الحدث ويرسل الأحداث إلى أجزاء من التعليمات البرمجية Gridwich التي تتعامل مع نوع الحدث وإصداره.

  5. يستخدم أي معالج سيعمل مع الطلب الحالي فئة EventGridHandlerBase الشائعة لإرسال رسالة إعلام على الفور عندما يتلقى الطلب. ثم يرسل المعالج العمل إلى الفئة المشتقة.

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

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

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

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

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

بينما يسبق الإقرار كلاً من الاستجابتين «نجاح» و«جدولة»، لا يضمن Gridwich أن الاستجابة المجدولة ستسبق دائماً استجابة النجاح المقابلة. يمكن أن يكون تسلسل الاستجابة الصالح إما إقرار> جدولة > نجاح أو إقرار > نجاح > جدولة.

حالات فشل الطلب

يمكن أن يكون سبب فشل الطلب هو الطلبات غير الصالحة أو الشروط المسبقة المفقودة أو فشل المعالجة أو استثناءات الأمان أو الاستثناءات غير المعالجة. تحتوي جميع حالات الفشل تقريباً على نفس نموذج الرسالة، وتتضمن قيمة سياق العملية الأصلية. ترسل فئة EventGridHandlerBase الشائعة عادة استجابات الفشل إلى شبكة الأحداث عبر واجهة ناشر حدث Azure Functions. Application Insights يقوم أيضًا بتسجيل حالات الفشل عبر التسجيل المنظم.

سياق العملية

قد يقوم النظام الخارجي بإنشاء آلاف الطلبات يومياً أو في الساعة أو في الثانية. يجب أن يتضمن كل حدث طلب إلى Gridwich خاصية كائن JSON باسم operationContext.

إذا كان الطلب يحتوي على سياق عملية، مثل {"id"="Op1001"}، يجب أن تتضمن كل استجابة Gridwich سياق عملية معتماً مطابقاً، سواء أكان الطلب قصير الأمد أم طويل الأمد عند تشغيله. يستمر سياق العملية هذا طوال مدة بقاء الطلبات طويلة الأمد.

متطلبات الاستجابة هي لعنصر JSON "المطابق" بدلا من كائن JSON "نفسه". تستفيد ميزات Gridwich، مثل كتم السياق من حقيقة أن النظام الخارجي يعالج كائن JSON الذي تم إرجاعه بطريقة من أعلى لأسفل.

على وجه التحديد، يحتوي النظام الخارجي على:

  • لا توجد تبعية على ترتيب الخصائص، لذلك يمكن لـ Gridwich إرسال عنصر بنفس الخصائص، ربما بترتيب مختلف. على سبيل المثال،{"a":1,"b":2} مقابل {"b":2,"a":1}.

  • لا توجد مشكلة في وجود خصائص إضافية، لذلك يمكن أن يرجع Gridwich {"b":2,"a":1} بعد تلقيه {"a":1,"b":2,"~somethingExtra":"yes"}، بشكل صحيح. لتقليل احتمالية حدوث تصادمات، يسبق Gridwich أسماء الخصائص المضافة بعلامة الكشيدة (~)، على سبيل المثال ~muted.

  • لا توجد تبعيات بتنسيق JSON. على سبيل المثال، لا توجد افتراضات حول المكان الذي قد يقع فيه ترك مساحة بيضاء ضمن تمثيل سلسلة JSON. يستفيد Gridwich من هذا النقص في تبعية التنسيق عن طريق ضغط المسافات البيضاء غير الضرورية في تمثيلات السلسلة لعناصر JSON. راجع JSONHelpers.SerializeOperationContext.

المشاركون في ساجا وسياق العملية

في نظام تنسيق ساجا من Gridwich يساهم كل مشارك ساجا بنشاط عمل واحد أو أكثر في النظام. يعمل كل مشارك في ساجا بشكل مستقل عن المشاركين الآخرين، وقد يعمل أكثر من مشارك واحد في ساجا بناء على طلب واحد.

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

  • تحتفظ العمليات المتزامنة قصيرة المدى بسياق العملية.
  • يوفر Azure Storage خاصية سلسلة مبهمة تسمى ClientRequestId لمعظم العمليات.
  • بعض الخدمات لها خاصية Job.CorrelationData .
  • توفر واجهات برمجة التطبيقات السحابية الأخرى مفاهيم مشابهة لسياق عملية مبهمة يمكنها إرجاعها عند الإشارة إلى التقدم أو الاكتمال أو الفشل.

لمزيد من المعلومات حول المشاركين في والأحداث، راجع تنسيق ساجا.

معالجات متزامنة وغير متزامنة

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

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

رسم تخطيطي يوضح تدفق رسالة الإقرار.

معالجة الأحداث المتزامنة

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

رسم تخطيطي يوضح تدفق رسالة طلب-استجابة متزامن..

على سبيل المثال، ChangeBlobTierHandler هو تدفق متزامن بسيط. يحصل المعالج على طلب عنصر نقل البيانات (DTO)، ويستدعي وينتظر خدمة واحدة للقيام بالعمل، ويعيد استجابة «نجاح» أو «الفشل».

رسم تخطيطي يوضح مثال التدفق المتزامن ChangeBlobTierHandler.

معالجة حدث غير متزامن

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

رسم تخطيطي يوضح تدفق رسالة طلب-استجابة غير متزامن.

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

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

رسم تخطيطي يوضح مثال التدفق غير المتزامن BlobCopyHandler مع جدولة الحدث.

لإكمال تدفق الطلب طويل الأمد، يستهلك BlobCreatedHandler حدث النظام الأساسي Microsoft.Storage.BlobCreated، ويستخرج سياق العملية الأصلي، وينشر استجابة إتمام «نجاح» أو «فشل».

رسم تخطيطي يوضح مثال تدفق BlobCopyHandler غير المتزامن مع نجاح الحدث.

الوظائف طويلة الأمد

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

يجب أن يتسم الحل بما يلي:

  • عدم الاحتفاظ بحالة تشغيل مثيلات تطبيق Gridwich.
  • عدم إنهاء العمليات لمجرد توزيع شيء جديد أو رسالة جديدة تطلب نفس النشاط.
  • عدم استدعاء أي أحمال عمل Azure إضافية، مثل Durable Functions أو Functions Apps أو Logic Apps أو Azure Container Instances.

يستخدم Gridwich الرموز المميزة لتوزيع وإلغاء الفتحات في Azure Functions لتلبية هذه المتطلبات لوظائف موثوقة وطويلة التشغيل.

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

رسم تخطيطي يوضح وظائف قصيرة الأمد وطويلة الأمد.

يضيف وقت تشغيل Functions رمز الإلغاء المميز عند إيقاف تشغيل التطبيق. يكتشف Gridwich الرمز المميز، ويعيد رموز الخطأ لجميع الطلبات والعمليات قيد التشغيل حالياً.

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

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

لمزيد من المعلومات، راجع ما يحدث أثناء تبديل الفتحات لـ Azure Functions وفتحات توزيع Azure Functions.

المكونات

يستخدم حل معالجة وسائط Gridwich Azure Event Grid وAzure Functions وAzure Blob Storage وAzure Logic Apps وAzure Key Vault. تستخدم عمليات تنسيق CI/CD وساجا كلاً من Azure Repos وAzure Pipelines وTerraform.

  • شبكة أحداث Azure تدير توجيه أحداث Gridwich، مع وظيفتين من مهام «شبكة الأحداث» المسندة التي تسمح بمعالجة أحداث الوسائط غير المتزامنة. تعبر شبكة الأحداث عن نقطة نهاية تسليم طلب موثوق بها للغاية. يوفر النظام الأساسي لـ Azure وقت تشغيل نقطة نهاية تسليم الطلب الضروري والاستقرار.

    تغلف Gridwich الأحداث داخل كائن خاصية مخطط Event.Data Event Grid، وهو معتم إلى وسيط شبكة الأحداث وطبقة النقل. يستخدم Gridwich أيضا حقلي العنصر eventType وdataVersion لتوجيه الأحداث. حتى يمكن استبدال وسيط طلبات شبكة الأحداث بوسطاء حدث اشتراك النشر والاشتراك الآخرين، يعتمد Gridwich على أقل عدد ممكن من حقول الأحداث، ولا يستخدم الحقل topic أو الحقل subject.

  • Azure Functions – تتيح لك Azure Functions تشغيل التعليمات البرمجية التي يتم تشغيلها بواسطة الحدث دون الحاجة إلى توفير البنية الأساسية أو إدارتها بشكل صريح. Gridwich عبارة عن Azure Functions App يستضيف تنفيذ دالات مختلفة.

  • Azure Blob Storage يوفر تخزيناً سحابياً قابلاً للتوسعة وفعالاً من حيث التكلفة والوصول للبيانات غير المنظمة، مثل أصول الوسائط. يستخدم Gridwich كلاً من الكائنات الثنائية كبيرة الحجم لكتلة Azure Storage والحاويات.

  • يحمي Azure Key Vault مفاتيح التشفير وكلمات المرور والأسرار الأخرى التي تستخدمها تطبيقات وخدمات Azure والجهات الخارجية.

  • Azure DevOps عبارة عن مجموعة من خدمات المطورين والعمليات، بما في ذلك مستودعات التعليمات البرمجية المستندة إلى Git ومسارات الإنشاء والإصدار المؤتمتة، والتي تتكامل مع Azure. يستخدم Gridwich تطبيق Azure Repos لتخزين وتحديث مشاريع التعليمات البرمجية، وAzure Pipelines لعمليات CI/CD ومهام سير العمل الأخرى.

  • Terraform هي أداة مفتوحة المصدر تستخدم البنية الأساسية كتعليمة برمجية لتوفير البنى الأساسية والخدمات وإدارتها.

البدائل

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

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

  • تحتوي مكتبة Gridwich.SagaParticipants.Storage.AzureStorage أيضاً على خدمات تخزين يستخدمها مشاركو ساجا الآخرون. يؤدي وجود واجهات في مشروع أساسي إلى تجنب مشكلات انعكاس التحكم (IoC)، ولكن يمكنك استخراج الواجهات في مكتبة بوابة لبنية أساسية لموقع تخزين أساسي منفصل.

  • يستخدم Gridwich Functions App إدخال التبعية لتسجيل واحد أو أكثر من معالجات الطلبات لأنواع أحداث وإصدارات بيانات محددة. يقوم التطبيق بإدخال EventGridDispatcher مع مجموعة معالجات أحداث شبكة الأحداث، ويعلم المرسل المعالجات من أجل تحديد المعالجات التي ستعالج الحدث.

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

  • للحصول على خدمة مصغرة بديلة بدلا من بنية Gridwich المتجانسة، راجع بديل الخدمات المصغرة.

تفاصيل السيناريو

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

  • استيعاب ملفات الفيديو البسيطة ومعالجتها ونشرها وتلبية طلبات الوسائط.
  • تحسين كل من الترميز وإمكانات الإدخال والتوزيع الجديدة على نطاق واسع وبنهج مصمم بشكل نظيف.
  • تنفيذ التكامل والتسليم المستمر (CI/CD) لمسار إدارة أصول الوسائط (MAM).

لتحقيق هذه الأهداف، طور فريق Microsoft الهندسي Gridwich، وهو إطار عمل لمعالجة الأحداث عديم الحالة مدفوع بنظام تنسيق سير عمل ساجا خارجية.

حالات الاستخدام المحتملة

طور الفريق الهندسي Gridwich ليتوافق مع المبادئ ومعايير الصناعة من أجل:

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

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