این مقاله الگوی پل پیام‌رسانی را شرح می‌دهد که در واقع یک روشی است و با کمک آن می‌توانید برای ادغام سیستمهای متفاوتی که بر روی زیرساختهای پیام‌رسانی مختلف ساخته شده‌اند، بهره‌برداری موردنظر را انجام دهید.
بسیاری از سازمان‌ها و workloadها می‌توانند به طور ناخواسته سیستمهای فناوری اطلاعاتی را داشته باشند که از زیرساختهای پیام‌رسانی متعددی مانند Microsoft Message Queuing (MSMQ) RabbitMQ، Azure Service Bus و Amazon SQS استفاده می‌کنند که تنوع زیاد این سرویس‌‌های می‌تواند باعث مشکلاتی مانند:
- یکپارچهسازی فرایندها
- گسترش و توسعه سیستمهای on-premises یا داخلی نسبت سیستمهای توسعه مبتنی بر میزبان ابری (cloud-hosted) بسیار پیچیده‌تر است.
- کاهش هزینه‌ها و سهولت نگهداری برنامه و داده‌ها که در محیط ابری مناسب‌تر است.
توسعه‌دهندگان ممکن است با اصلاح سیستمهایی که برای برقراری ارتباط با استفاده از سرویس‌‌های وب مبتنی بر HTTP یکپارچه شده‌اند، این چالش را برطرف کنند. بااین‌حال، این رویکرد دارای معایبی مثل موارد زیر است: * سیستم‌ها باید با افزودن یک سرویس‌گیرنده HTTP در یک طرف و یک کنترل‌کننده درخواست HTTP در طرف دیگر اصلاح شوند. سپس سیستم‌ها باید مجدداً آزمایش شده و مجدداً مستقر شوند.
* آن دسته از endpointهای HTTP باید میزبانی یا host شوند که وقتی این وب‌سرویس‌ها را با امکاناتی مثل ایمنی و دسترسی سطح بالا قرار می‌دهید، پیچیدگی آن افزایش می‌یابد.
* مشکلات مکرر اتصال به شبکه که نیازمند مکانیزم‌‌های retry است.
اگر سیستمهای در حال ادغام از اجزایی تشکیل شده باشند که از طریق تبادل پیام‌ها با هم ارتباط برقرار می‌کنند، الگوی پل پیام‌رسانی ادغام سازی را بهبود می‌بخشد و مشکلات را کاهش می‌دهد. در این سناریو، هر سیستم به یک زیرساخت پیام‌رسانی متصل می‌شود. برای ادغام در زیرساختهای پیام‌رسانی مختلف همیشه یک جزء پل یا واسط را معرفی کنید که به دو یا چند زیرساخت پیام‌رسانی به طور هم‌زمان متصل می‌شود. پل پیام‌ها را از یکی pull می‌کند و بدون تغییر آن پیام به دیگری push می‌دهد. سیستمهایی که یکپارچه یا ادغام می‌شوند نیازی به شناسایی سایر سرویس‌ها حتی سرویس پل یا واسط ندارند. سیستم فرستنده طوری پیکربندی شده است که پیام‌های خاصی را به یک صف تعیین شده در زیرساخت پیام‌رسانی محلی خود ارسال کند. پل آن پیام‌ها را دریافت می‌کند و آنها را به صف دیگری در زیرساخت پیام‌رسانی دیگری که سیستم گیرنده آنها را دریافت می‌کند را ارسال می‌کند.
* سیستمهایی که از طریق پل پیام (Messaging Bridge) ادغام می‌شوند نیازی به اصلاح ندارند. در حالت ایده‌آل، نقاط پایانی(endpoints) از پل زدن پیام‌ها آگاه نیستند.
* ادغام در مقایسه با جایگزینی آن با HTTP به دلیل تضمین مکانیزم تحویل پیام به میزان حداقل یک‌بار، بسیار قابل‌اعتمادتر است.
* سناریوهای مهاجرت(Migration) می‌توانند انعطاف‌پذیرتر باشند. به‌عنوان‌مثال، نقاط پایانی (endpoints) را می‌توان از یک زیرساخت پیام‌رسانی به زیرساخت دیگری منتقل یا migrate کرد چنانچه برنامه زمان‌بندی‌شده (schedule) این اجازه را می‌دهد و این مورد جایگزین روش‌های قدیمی‌تر مانند همه endpointها به یکباره منتقل شوند است.
* ویژگی‌‌های پیشرفته یک یا هر دو فناوری پیام‌رسانی ممکن است در مسیر پل (bridged route) در دسترس نباشد.
* مسیر پل شده باید محدودیت‌های هر دو فناوری را در نظر بگیرد. به‌عنوان‌مثال، حداکثر اندازه پیام ممکن است ۴ مگابایت در MSMQ باشد؛ اما این مقدار فقط برابر ۶۴ کیلوبایت در صف‌های ذخیره‌سازی Azure است.
هنگام اجرای الگوی پل پیام‌رسانی به نکات زیر توجه کنید:
* اگر یکی از سیستمهای یکپارچه یا ادغام سازی به تراکنش‌های توزیع شده متکی است، به‌عنوان‌مثال Microsoft Distributed Transaction Coordinator (DTC)، برای صحت سنجی بیشتر، باید یک سازوکار کپی‌برداری (deduplication) را در پل پیاده‌سازی کنید. * اگر یکی از سیستمهای در حال ادغام از هیچ زیرساخت پیام‌رسانی استفاده نمی‌کند و نمی‌توان آن را تغییر داد، می‌توانید بین زیرساختی که توسط سیستم دیگر استفاده می‌شود و یک صف شبیه‌سازی شده توسط SQL Server، پل پیام‌رسانی ایجاد کنید. سیستم قدیمی می‌تواند پیام‌ها را با استفاده از قابلیت تغییر ضبط داده (change data capture) برای SQL Server ارسال کند تا تغییرات خود را به یک جدول صف اختصاصی منتقل کند. پل می‌تواند این پیام‌ها را به زیرساخت پیام‌رسانی واقعی ارسال کند. * شما می‌توانید در هر زیرساخت پیام‌رسانی از یک صف استفاده کنید که به‌عنوان صف پل (bridging queue) زدن تعیین شده است. در این توپولوژی، سیستم ارسال را پیکربندی کنید تا از آن صف خاص به‌عنوان مقصد برای انواع پیامهایی که به سیستم دیگر ارسال می‌شوند استفاده کند. همچنین می‌توانید از چندین جفت صف در هر زیرساخت پیام‌رسانی استفاده کنید، بنابراین فرستنده از وجود پل بی‌اطلاع است. با این کار یک صف سایه(shadow queue) برای هر صف مقصد در زیرساخت پیام‌رسانی سیستم مقصد ایجاد می‌شود. پل پیام‌ها را بین صف‌های سایه و همتایان آنها ارسال می‌کند. * به‌منظور دستیابی به توافقنامه‌‌های سطح سرویس دردسترس‌بودن (service-level agreements (SLAs))، ممکن است لازم باشد پل پیام‌رسانی را با استفاده از رویکرد مصرف‌کنندگان رقابتی(Competing consumers) کوچک کنید. * اجزای معمولی پردازش پیام‌ها از الگوی Retry برای رسیدگی به خرابیهای گذرا استفاده می‌کنند. محدودیت شمارنده retry به اجزای سازنده امکان می‌دهد پیام‌های سمی را شناسایی کرده و آنها را از صف حذف کنند تا پردازش را رفع انسداد کنند. اگر خرابی زیرساخت رخ دهد، ممکن است پل به سیاست retry متفاوتی نیاز داشته باشد تا از شناسایی نادرست پیام‌ها به‌عنوان سم جلوگیری کند. ممکن است از الگوی Circuit Breaker برای توقف موقت ارسال استفاده کنید.
در صورت نیاز از الگوی پل پیام‌رسانی استفاده کنید:
* سیستمهای موجود را با حداقل نیاز به اصلاح یکپارچه یا ادغام کنید.
* برنامه‌های قدیمی را که نمی‌توانند از سایر فناوری‌های پیام‌رسانی استفاده کنند، ادغام کنید.
* برنامه‌های موجود در محل یا on-premises را با مؤلفه‌های میزبان ابری گسترش دهید.
* هنگامی که اتصال اینترنت پایدار نیست، سیستمهای توزیع‌شده جغرافیایی (geo-distributed) را متصل کنید.
* انتقال تدریجی یک سیستم توزیع شده از یک زیرساخت پیام‌رسانی به زیرساخت دیگر بدون نیاز به انتقال یک‌مرتبه کل سیستم.
این الگو ممکن است مناسب نباشد اگر:
* حداقل یکی از سیستمهای درگیر به ویژگی یکی از زیرساختهای پیام‌رسانی متکی است که در دیگری وجود ندارد.
* ادغام سازی ماهیت هم‌زمان دارد و سیستم آغازگر نیاز به پاسخ فوری دارد.
* ادغام سازی الزامات عملکردی یا غیرعملکردی خاصی مانند نگرانی‌های امنیتی یا حفظ حریم خصوصی دارد.
* حجم داده برای یکپارچهسازی بیش از ظرفیت سیستم پیام‌رسانی است یا پیام‌رسانی را به یک راه‌حل گران‌قیمت برای حل این مشکل تبدیل می‌کند.
این مثال در مورد یک برنامه یا application است که با NET framework برای مدیریت برنامه‌ریزی کارمندان به‌صورت میزبانی در محل (hosted on-premises) نوشته شده است. این برنامه با مؤلفه‌های جداگانه از طریق MSMQ به‌خوبی ساختاریافته است. این برنامه به‌خوبی کار می‌کند و تیم مربوط به مسائل workload قصد بازنویسی آن را ندارد. برای تأمین نیازمندی‌های تجاری، یک مصرف‌کننده جدید از داده‌های برنامه‌ریزی‌شده باید ساخته شود و راهبُرد IT خواستار ساختن نرم‌افزار جدید به‌عنوان cloud-native application برای بهینه‌سازی هزینه‌ها و زمان پاسخ‌دهی‌ها است. معماری مبتنی بر صف ناهم‌زمان (asynchronous queue-based) درگذشته برای تیم workload کار می‌کرد، بنابراین تیم قصد دارد از همان رویکرد معماری اما با فناوری مدرن Service Bus استفاده کند. تیم workload نمی‌خواهد ارتباطات هم‌زمان بین محیط ابری و محیط استقرار در محل (on-premises deployment) را برای کاهش تأخیر یا عدم دسترسی به شخص تحت‌تأثیر دیگری معرفی کند. این تیم تصمیم می‌گیرد از الگوی پل پیام‌رسانی برای اتصال این دو سیستم استفاده کند. این الگوی از دو بخش تشکیل شده است. یک قسمت پیامهایی را از صف MSMQ موجود دریافت می‌کند و آنها را به Service Bus منتقل می‌کند. بخش دیگر پیامهایی را از Service Bus می‌گیرد و آنها را به صف MSMQ موردنظر منتقل می‌کند.
هنگامی که تیم پیاده‌سازی از این رویکرد استفاده می‌کند، در واقع از زیرساخت موجود در برنامه برای ادغام با اجزای جدید استفاده می‌کند. برنامه موجود نمی‌داند که اجزای جدید در Azure میزبانی می‌شوند. به طور مشابه، اجزای جدید با برنامه قدیمی به همان روشی که بین خود ارتباط برقرار می‌کنند با ارسال پیام‌های Service Bus ارتباط برقرار می‌کنند در نتیجه پل پیام‌ها را بین دو سیستم ارسال می‌کند.
این مقاله توسط مایکروسافت نگهداری می‌شود. در اصل توسط مشارکت‌کنندگان زیر نوشته شده است.
نویسندگان اصلی:
- Rob Bagby | Principal Architecture Content Lead
- Kyle Baley | Software Engineer
- Udi Dahan | Founder & CEO of Particular Software
- Chad Kittel | Principal Software Engineer
- Bryan Lamos | Developer Relations
- Szymon Pobiega | Engineer
- شرح الگوی پل پیام‌رسانی (Messaging Bridge pattern description) از الگوهای یکپارچهسازی سازمانی.
- یاد بگیرید که چگونه یک پل پیام‌رسانی (Messaging Bridge) را در چارچوب Spring Java پیاده‌سازی کنید.
- می‌توان از QPid bridge برای پل زدن فناوری‌های پیام‌رسانی با AMQP فعال کرد.
- یک NServiceBus Messaging Bridge که بیانگر پیاده‌سازی دات‌نت از یک پل صف به صف است و از طیفی از زیرساختهای پیام‌رسانی از جمله MSMQ، Service Bus و Azure Queue Storage پشتیبانی می‌کند.
- استفاده از NServiceBus.Router یک پروژه متن‌باز است که الگوی Messaging Bridge را پیاده‌سازی می‌کند. همچنین امکان پل زدن بیش از دو فناوری را در یک نمونه واحد فراهم می‌کند و دارای قابلیت‌های پیشرفته مسیریابی پیام است.
- الگوی مصرف‌کنندگان رقابتی (Competing Consumers) تضمین می‌کند که پیاده‌سازی پل پیام‌رسان می‌تواند انواع بار را تحمل کند.
- الگوی Retry به پل پیام‌رسانی اجازه می‌دهد تا خرابیهای گذرا را مدیریت کند.
- الگوی Circuit Breaker زمانی که هر طرف پل دچار خرابی می‌شود، منابع مصرفی را حفظ و مدیریت می‌کند.