تحرير

مشاركة عبر

نظام المراسلة الديناميكي لـ pub-sub لمركز النقل

Azure Cache for Redis
Azure Cosmos DB
Azure Event Hubs
Azure Functions
Azure Service Bus

أفكار الحل

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

توضح هذه المقالة نموذجا مرنا ومرنا للنشر والاشتراك لمنتجي البيانات والمستهلكين لإنشاء محتوى أو بيانات تم التحقق من صحتها أو تجميعها واستهلاكها.

بناء الأنظمة

رسم تخطيطي لنظام المراسلة للنشر والاشتراك في Transit Hub.

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

تدفق البيانات

  1. ينشر تطبيق منتج البيانات البيانات إلى Azure Event Hubs، والذي يرسل البيانات إلى وظيفة Azure Functions معالجة الحدث.

  2. يرسل منتج البيانات أيضا مخطط JSON للتخزين في حاوية Azure Storage.

  3. تسترد الوظيفة معالجة الحدث مخطط JSON من Azure Cache for Redis لتقليل زمن الانتقال، وتستخدم المخطط للتحقق من صحة البيانات.

    إذا لم يتم تخزين المخطط مؤقتا بعد، تسترد الوظيفة معالجة الحدث المخطط من حاوية Azure Storage. يخزن طلب المخطط أيضا المخطط في Azure Cache for Redis للاسترداد المستقبلي.

    إشعار

    يمكن أن يكون Azure Schema Registry في مراكز الأحداث بديلا قابلا للتطبيق لتخزين مخططات JSON وتخزينها مؤقتا. لمزيد من المعلومات، راجع سجل مخطط Azure في مراكز الأحداث.

  4. إذا كان هناك موضوع موجود بالفعل وكانت البيانات صالحة، فإن الوظيفة معالجة الحدث تدمج البيانات في الموضوع ناقل خدمة Azure البيانات الصالحة الموجود، وترسل الموضوع إلى تطبيق Data Consumer.

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

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

  7. إذا كانت البيانات الجديدة صالحة، تقوم وظيفة معالجة الأحداث أيضا بإدراج البيانات كسجل بيانات لقطة جديد في Azure Cosmos DB.

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

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

  10. يعمل معالج ملف Snapshot Data Flat في Azure Data Factory على جدول لاستخراج جميع بيانات اللقطة من قاعدة بيانات Snapshot Data Azure Cosmos DB. ينشئ المعالج ملفا مسطحا وينشره على ملف Snapshot Data Flat في Azure Storage للتنزيلات.

  11. يسترد تطبيق مستهلك البيانات قائمة بجميع مواضيع ناقل خدمة Azure التي يتوفر فيها مدير موضوع ناقل الخدمة للاشتراك. يسجل التطبيق مع مدير موضوع ناقل الخدمة للاشتراك في مواضيع ناقل الخدمة.

المكونات

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

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

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

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

هذا النموذج مفيد بشكل خاص في السيناريوهات التالية:

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

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