نمط جسر المراسلة

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

السياق والمشكلة

يمكن أن يكون لدى العديد من المؤسسات وأحمال العمل عن غير قصد أنظمة تكنولوجيا المعلومات التي تستخدم بنى أساسية متعددة للمراسلة مثل قائمة انتظار الرسائل من Microsoft (MSMQ) و RabbitMQ ناقل خدمة Azure وAmazon SQS. يمكن أن تحدث هذه المشكلة بسبب عمليات الاندماج أو الاستحواذ أو بسبب توسيع الأنظمة المحلية الحالية لتشمل المكونات المستضافة على السحابة لفعالية التكلفة وسهولة الصيانة.

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

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

حل

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

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

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

المزايا

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

العيوب

• قد لا تتوفر ميزات متقدمة لتقنية مراسلة واحدة أو كلتيهما على المسار الموصول.
• يحتاج المسار الذي تم جسره إلى النظر في قيود كلتا التقنيتين. على سبيل المثال، قد يكون الحد الأقصى لحجم الرسالة 4 ميغابايت في MSMQ ولكن 64 كيلوبايت فقط في قوائم انتظار Azure Storage.

المسائل والاعتبارات

ضع في اعتبارك النقاط التالية عند تنفيذ نمط Messaging Bridge:

• إذا كان أحد الأنظمة المتكاملة يعتمد على المعاملات الموزعة، على سبيل المثال Microsoft Distributed Transaction Coordinator (DTC)، من أجل التصحيح، يجب تنفيذ آلية إلغاء التكرار في الجسر.

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

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

• من أجل تلبية اتفاقيات مستوى خدمة التوفر المطلوبة (SLAs)، قد تحتاج إلى توسيع جسر المراسلة باستخدام نهج المستهلكين المتنافسين .

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

موعد استخدام النمط

استخدم نمط Messaging Bridge عندما تحتاج إلى:

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

قد لا يكون هذا النمط مناسبا إذا:

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

تصميم حمل العمل

يجب على المهندس المعماري تقييم كيفية استخدام نمط جسر المراسلة في تصميم حمل العمل الخاص بهم لمعالجة الأهداف والمبادئ التي تغطيها ركائز Azure Well-Architected Framework. على سبيل المثال:

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

مثال

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

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

يقرر الفريق استخدام نمط جسر المراسلة لتوصيل النظامين. يتكون النمط من جزأين. يتلقى جزء واحد رسائل من قائمة انتظار MSMQ الموجودة ويحيلها إلى ناقل خدمة Microsoft Azure. يأخذ الجزء الآخر الرسائل من ناقل خدمة Microsoft Azure ويحيلها إلى قائمة انتظار MSMQ الموجودة.

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

المساهمون

تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.

الكتاب الرئيسيون:

• روب باغبي | عميل متوقع لمحتوى البنية الأساسية
• كايل بيلي | مهندس برامج
• أودي داهان | المؤسس والرئيس التنفيذي لبرنامج معين
• تشاد كيتل | مهندس برامج رئيسي
• برايان لاموس | علاقات المطور
• Szymon Pobiega | مهندس

لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.

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

• وصف نمط جسر المراسلة من مجتمع أنماط تكامل المؤسسة.
• تعرف على كيفية تنفيذ جسر المراسلة في إطار عمل Spring Java.
• يمكن استخدام جسر QPid لوصل تقنيات المراسلة التي تدعم AMQP.
• يعد جسر مراسلة NServiceBus تطبيق .NET لوصلة قائمة انتظار إلى قائمة انتظار تدعم مجموعة من البنية الأساسية للمراسلة بما في ذلك MSMQ ونقل الخدمة وAzure Queue Storage.
• NServiceBus.Router هو مشروع مفتوح المصدر ينفذ نمط جسر المراسلة. كما أنه يسمح بربط أكثر من اثنين من التقنيات في مثيل واحد ولديه قدرات متقدمة لتوجيه الرسائل.

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

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