يسمح نمط Claim-Check لأحمال العمل بنقل الحمولات دون تخزين الحمولة في نظام مراسلة. يخزن النمط الحمولة في مخزن بيانات خارجي ويستخدم "فحص المطالبة" لاسترداد الحمولة. يعد التحقق من المطالبة رمزا مميزا أو مفتاحا فريدا وغامقا. لاسترداد الحمولة، تحتاج التطبيقات إلى تقديم الرمز المميز للتحقق من المطالبة إلى مخزن البيانات الخارجي.
السياق والمشكلة
تم تحسين أنظمة المراسلة التقليدية لإدارة حجم كبير من الرسائل الصغيرة وغالبا ما يكون لها قيود على حجم الرسالة التي يمكنها التعامل معها. لا تخاطر الرسائل الكبيرة بتجاوز هذه الحدود فحسب، بل قد تؤدي أيضا إلى تدهور أداء النظام بأكمله عندما يخزنها نظام المراسلة.
حل
استخدم نمط Claim-Check، ولا ترسل رسائل كبيرة إلى نظام المراسلة. بدلا من ذلك، أرسل الحمولة إلى مخزن بيانات خارجي وأنتج رمزا مميزا للتحقق من المطالبة لتلك الحمولة. يرسل نظام المراسلة رسالة مع الرمز المميز للتحقق من المطالبة إلى تلقي التطبيقات حتى تتمكن هذه التطبيقات من استرداد الحمولة من مخزن البيانات. لا يرى نظام المراسلة الحمولة أو يخزنها أبدا.
- الحمولة
- حفظ الحمولة في مخزن البيانات.
- إنشاء رمز مميز للتحقق من المطالبة وإرسال رسالة مع الرمز المميز للتحقق من المطالبة.
- تلقي رسالة وقراءة الرمز المميز للتحقق من المطالبة.
- استرداد الحمولة.
- معالجة الحمولة.
المشكلات والاعتبارات المتعلقة بنمط التحقق من المطالبة
ضع في اعتبارك التوصيات التالية عند تنفيذ نمط Claim-Check:
حذف الرسائل المستهلكة. إذا لم تكن بحاجة إلى أرشفة الرسالة، فاحذف الرسالة والحمولة بعد أن تستهلكها التطبيقات المتلقية. استخدم إما استراتيجية حذف متزامنة أو غير متزامنة:
الحذف المتزامن: يحذف التطبيق المستهلك الرسالة والحمولة مباشرة بعد الاستهلاك. يربط الحذف بسير عمل معالجة الرسائل ويستخدم سعة حساب سير عمل المراسلة.
الحذف غير المتزامن: عملية خارج سير عمل معالجة الرسائل تحذف الرسالة والحمولة. يقوم بفصل عملية الحذف عن سير عمل معالجة الرسائل ويقلل من استخدام حساب سير عمل المراسلة.
تنفيذ النمط بشكل مشروط. دمج المنطق في تطبيق الإرسال الذي يطبق نمط Claim-Check إذا تجاوز حجم الرسالة حد نظام المراسلة. بالنسبة للرسائل الأصغر، تجاوز النمط وإرسال الرسالة الأصغر إلى نظام المراسلة. يقلل هذا النهج الشرطي من زمن الانتقال، ويحسن استخدام الموارد، ويحسن معدل النقل.
متى تستخدم نمط التحقق من المطالبة
السيناريوهات التالية هي حالات الاستخدام الأساسية لنمط Claim-Check:
قيود نظام المراسلة: استخدم نمط Claim-Check عندما تتجاوز أحجام الرسائل حدود نظام المراسلة. إلغاء تحميل الحمولة إلى التخزين الخارجي. أرسل الرسالة فقط مع الرمز المميز للتحقق من المطالبة إلى نظام المراسلة.
أداء نظام المراسلة: استخدم نمط Claim-Check عندما تجهد الرسائل الكبيرة نظام المراسلة وتتدهور أداء النظام.
السيناريوهات التالية هي حالات استخدام ثانوية لنمط Claim-Check:
حماية البيانات الحساسة: استخدم نمط التحقق من المطالبة عندما تحتوي الحمولات على بيانات حساسة لا تريد أن تكون مرئية لنظام المراسلة. تطبيق النمط على جميع المعلومات الحساسة أو أجزاء منها في الحمولة. تأمين البيانات الحساسة دون إرسالها مباشرة من خلال نظام المراسلة.
سيناريوهات التوجيه المعقدة: يمكن أن تتسبب الرسائل التي تجتاز مكونات متعددة في ازدحام الأداء بسبب مهام التسلسل وإلغاء التسلسل والتشفير وفك التشفير. استخدم نمط Claim-Check لمنع معالجة الرسائل المباشرة بواسطة المكونات الوسيطة.
تصميم حمل العمل مع نمط التحقق من المطالبة
يجب على المهندس المعماري تقييم كيفية استخدام نمط Claim-Check في تصميم حمل العمل الخاص بهم لمعالجة الأهداف والمبادئ التي تغطيها ركائز Azure Well-Architected Framework. على سبيل المثال:
| الركيزة | كيف يدعم هذا النمط أهداف الركيزة |
|---|---|
| تساعد قرارات تصميم الموثوقية حمل العمل الخاص بك على أن يصبح مرنا في مواجهة الخلل ويضمن استرداده بالكامل بعد الفشل. | لا توفر أنظمة المراسلة نفس الموثوقية والتعافي من الكوارث التي غالبا ما تكون موجودة في مخازن البيانات المخصصة. يمكن أن يوفر فصل البيانات عن الرسالة مزيدا من الموثوقية للحمولة. يسهل هذا الفصل تكرار البيانات الذي يسمح لك باسترداد الحمولات بعد وقوع كارثة. - RE:03 تحليل وضع الفشل - RE:09 التعافي من الكوارث |
| تساعد قرارات تصميم الأمان على ضمان سرية بيانات وأنظمة حمل العمل وسلامتها وتوافرها. | يمكن لنمط Claim-Check استخراج البيانات الحساسة من الرسائل وتخزينها في مخزن بيانات آمن. يسمح لك هذا الإعداد بتنفيذ عناصر تحكم وصول أكثر إحكاما، مما يضمن أن الخدمات التي تهدف إلى استخدام البيانات الحساسة فقط يمكنها الوصول إليها. في الوقت نفسه، فإنه يخفي هذه البيانات من الخدمات غير المرتبطة، مثل تلك المستخدمة لمراقبة قائمة الانتظار. - تصنيف البيانات SE:03 - تجزئة SE:04 |
| يركز تحسين التكلفة على الحفاظ على عائد حمل العمل على الاستثمار وتحسينه. | غالبا ما تفرض أنظمة المراسلة حدودا على حجم الرسالة، وغالبا ما تكون حدود الحجم المتزايدة ميزة متميزة. قد يتيح لك تقليل حجم هيئات الرسائل استخدام حل مراسلة أرخص. - تكاليف مكون CO:07 - تكاليف تدفق CO:09 |
| تساعد كفاءة الأداء حمل العمل الخاص بك على تلبية الطلبات بكفاءة من خلال تحسين التحجيم ونقل البيانات وتنفيذ التعليمات البرمجية. | يعمل نمط التحقق من المطالبة على تحسين كفاءة إرسال التطبيقات واستقبالها ونظام المراسلة من خلال إدارة الرسائل الكبيرة بشكل أكثر فعالية. فهو يقلل من حجم الرسائل المرسلة إلى نظام المراسلة ويضمن وصول التطبيقات إلى الرسائل الكبيرة فقط عند الحاجة. - PE:05 التحجيم والتقسيم - PE:12 تحسين الأداء المستمر |
كما هو الحال مع أي قرار تصميم، ضع في اعتبارك أي مفاضلات ضد أهداف الركائز الأخرى التي يمكن إدخالها مع هذا النمط.
أمثلة على نمط التحقق من المطالبة
توضح الأمثلة التالية كيف يسهل Azure تنفيذ نمط التحقق من المطالبة:
أنظمة مراسلة Azure: تغطي الأمثلة أربعة سيناريوهات مختلفة لنظام مراسلة Azure: Azure Queue Storage وAzure Event Hubs (Standard API) ناقل خدمة Azure وAzure Event Hubs (Kafka API).
إنشاء رمز مميز تلقائي مقابل يدوي للتحقق من المطالبة: توضح هذه الأمثلة أيضا طريقتين لإنشاء الرمز المميز للتحقق من المطالبة. في أمثلة التعليمات البرمجية 1-3، تقوم Azure Event Grid تلقائيا بإنشاء الرمز المميز عندما يقوم التطبيق المرسل بنقل الحمولة إلى Azure Blob Storage. يوضح المثال 4 للتعليمات البرمجية عملية إنشاء رمز مميز يدوي باستخدام عميل سطر أوامر قابل للتنفيذ.
اختر المثال الذي يناسب احتياجاتك واتبع الارتباط المتوفر لعرض التعليمات البرمجية على GitHub:
| التعليمة البرمجية العينة | سيناريوهات نظام المراسلة | منشئ الرمز المميز | تلقي التطبيق | مخزن البيانات |
|---|---|---|---|---|
| مثال على التعليمات البرمجية 1 | Azure Queue Storage | Azure Event Grid | الدالة | Azure Blob Storage |
| مثال على التعليمات البرمجية 2 | مراكز أحداث Azure (واجهة برمجة التطبيقات القياسية) | Azure Event Grid | عميل سطر الأوامر القابل للتنفيذ | Azure Blob Storage |
| مثال على التعليمات البرمجية 3 | ناقل خدمة Azure | Azure Event Grid | الدالة | Azure Blob Storage |
| مثال على التعليمات البرمجية 4 | Azure Event Hubs (Kafka API) | عميل سطر الأوامر القابل للتنفيذ | الدالة | Azure Blob Storage |
الخطوات التالية
- يحتوي موقع Enterprise Integration Patterns على وصف لهذا النمط.
- للحصول على مثال آخر، راجع التعامل مع رسائل ناقل خدمة Microsoft Azure الكبيرة باستخدام نمط التحقق من المطالبة (منشور المدونة).
- النمط البديل للتعامل مع الرسائل الكبيرة هو تقسيم وتجميع.
- توفر المكتبات مثل NServiceBus الدعم لهذا النمط الجاهز مع وظائف "ناقل البيانات".