ارتباط ناهمزمان مبتنی بر پیام در میکروسرویس ها

پیام‌های ناهمزمان و ارتباطات مبتنی بر رویداد هنگام انتشار تغییرات در چندین ریزسرویس و مدل‌های دامنه مرتبط با آن‌ها حیاتی هستند. همانطور که قبلاً در بحث میکروسرویس ها و زمینه های محدود (BCs) ذکر شد، مدل ها (کاربر، مشتری، محصول، حساب و غیره) می توانند معانی مختلفی برای میکروسرویس ها یا BC های مختلف داشته باشند. این بدان معناست که وقتی تغییرات رخ می دهد، شما به روشی برای تطبیق تغییرات در مدل های مختلف نیاز دارید. یک راه حل، ارتباط نهایی و رویداد محور مبتنی بر پیام رسانی ناهمزمان است.هنگام استفاده از پیام رسانی، فرآیندها با تبادل پیام به صورت ناهمزمان با یکدیگر ارتباط برقرار می کنند. یک کلاینت با ارسال پیام به سرویس، دستور یا درخواستی را برای آن ارسال می کند. اگر سرویس نیاز به پاسخگویی داشته باشد، پیام دیگری به مشتری ارسال می کند. از آنجایی که این یک ارتباط مبتنی بر پیام است، مشتری فرض می‌کند که پاسخ بلافاصله دریافت نمی‌شود و ممکن است اصلاً پاسخی وجود نداشته باشد.یک پیام توسط یک سربرگ (فراداده مانند اطلاعات شناسایی یا امنیتی) و یک بدنه تشکیل شده است. پیام ها معمولاً از طریق پروتکل های ناهمزمان مانند AMQP ارسال می شوند.زیرساخت ارجح برای این نوع ارتباط در جامعه میکروسرویس، یک واسطه پیام سبک وزن است که با کارگزاران و ارکسترهای بزرگ مورد استفاده در SOA متفاوت است. در یک کارگزار پیام سبک، زیرساخت معمولاً "گنگ" است و تنها به عنوان یک واسطه پیام عمل می کند، با پیاده سازی های ساده مانند RabbitMQ یا یک گذرگاه خدمات مقیاس پذیر در ابر مانند Azure Service Bus. در این سناریو، بیشتر تفکر «هوشمند» هنوز در نقاط پایانی که پیام‌ها را تولید و مصرف می‌کنند زندگی می‌کنند، یعنی در میکروسرویس‌ها.قانون دیگری که باید سعی کنید تا حد امکان از آن پیروی کنید این است که فقط از پیام‌های ناهمزمان بین سرویس‌های داخلی استفاده کنید و از ارتباطات همزمان (مانند HTTP) فقط از برنامه‌های سرویس گیرنده به سرویس‌های فرانت‌اند (API Gateways به علاوه سطح اول میکروسرویس ها).دو نوع ارتباط پیام رسانی ناهمزمان وجود دارد: ارتباط مبتنی بر پیام گیرنده تکی و ارتباط مبتنی بر پیام گیرنده های متعدد. در بخش های بعدی جزئیاتی در مورد آنها ارائه می شود.ارتباط مبتنی بر پیام تک گیرندهارتباط ناهمزمان مبتنی بر پیام با یک گیرنده به این معنی است که یک ارتباط نقطه به نقطه وجود دارد که پیامی را دقیقاً به یکی از مصرف‌کنندگانی که از کانال می‌خواند می‌رساند و این پیام فقط یک بار پردازش می‌شود. با این حال، شرایط خاصی وجود دارد. به عنوان مثال، در یک سیستم ابری که سعی می‌کند به طور خودکار خرابی‌ها را بازیابی کند، یک پیام می‌تواند چندین بار ارسال شود. به دلیل مشکلات شبکه یا سایر خرابی‌ها، کلاینت باید بتواند مجدداً پیام‌ها را ارسال کند، و سرور باید برای پردازش یک پیام خاص، عملیاتی را اجرا کند که ناتوان باشد.ارتباطات مبتنی بر پیام تک گیرنده مخصوصاً برای ارسال دستورات ناهمزمان از یک میکروسرویس به سرویس دیگر مناسب است.هنگامی که شروع به ارسال ارتباطات مبتنی بر پیام (چه با دستورات یا رویدادها) کردید، باید از ترکیب ارتباطات مبتنی بر پیام با ارتباطات HTTP همزمان خودداری کنید.هنگامی که دستورات از برنامه های مشتری می آیند، می توانند به عنوان دستورات همزمان HTTP پیاده سازی شوند. هنگامی که به مقیاس پذیری بالاتری نیاز دارید یا زمانی که در حال حاضر در یک فرآیند تجاری مبتنی بر پیام هستید، از دستورات مبتنی بر پیام استفاده کنید.ارتباطات مبتنی بر پیام چند گیرندهبه عنوان یک رویکرد انعطاف‌پذیرتر، ممکن است بخواهید از مکانیزم انتشار/اشتراک استفاده کنید تا ارتباط شما از فرستنده برای میکروسرویس‌های مشترک اضافی یا برنامه‌های خارجی در دسترس باشد. بنابراین، به شما کمک می کند تا از اصل باز/بسته در سرویس ارسال پیروی کنید. به این ترتیب، می‌توان در آینده بدون نیاز به تغییر سرویس فرستنده، مشترکین بیشتری اضافه کرد.وقتی از ارتباط انتشار/اشتراک استفاده می‌کنید، ممکن است از رابط اتوبوس رویداد برای انتشار رویدادها برای هر مشترکی استفاده کنید.ارتباط ناهمزمان رویداد محورهنگام استفاده از ارتباطات مبتنی بر رویداد ناهمزمان، یک میکروسرویس یک رویداد یکپارچه‌سازی را زمانی منتشر می‌کند که چیزی در دامنه آن اتفاق می‌افتد و میکروسرویس دیگری باید از آن آگاه باشد، مانند تغییر قیمت در یک ریزسرویس کاتالوگ محصول. میکروسرویس‌های اضافی در رویدادها مشترک می‌شوند تا بتوانند آنها را به صورت ناهمزمان دریافت کنند. هنگامی که این اتفاق می افتد، گیرنده ها ممکن است موجودیت های دامنه خود را به روز کنند، که می تواند باعث انتشار رویدادهای ادغام بیشتر شود. این سیستم انتشار/اشتراک با استفاده از پیاده‌سازی گذرگاه رویداد انجام می‌شود. اتوبوس رویداد می تواند به عنوان یک انتزاع یا رابط طراحی شود، با API که برای اشتراک یا لغو اشتراک رویدادها و انتشار رویدادها مورد نیاز است. گذرگاه رویداد همچنین می‌تواند یک یا چند پیاده‌سازی بر اساس هر واسطه بین فرآیندی و پیام‌رسانی داشته باشد، مانند صف پیام یا گذرگاه سرویس که از ارتباطات ناهمزمان و مدل انتشار/اشتراک پشتیبانی می‌کند.اگر یک سیستم از ثبات نهایی ناشی از رویدادهای یکپارچه سازی استفاده می کند، توصیه می شود که این رویکرد برای کاربر نهایی روشن شود. سیستم نباید از رویکردی استفاده کند که رویدادهای یکپارچه سازی را تقلید کند، مانند SignalR یا سیستم های نظرسنجی از مشتری. کاربر نهایی و مالک کسب و کار باید به صراحت از ثبات نهایی در سیستم استقبال کنند و بدانند که در بسیاری از موارد کسب و کار با این رویکرد مشکلی ندارد، تا زمانی که صریح باشد. این رویکرد مهم است زیرا کاربران ممکن است انتظار داشته باشند برخی از نتایج را فورا ببینند و این جنبه ممکن است با ثبات نهایی اتفاق نیفتد.همانطور که قبلاً در بخش چالش ها و راه حل ها برای مدیریت داده های توزیع شده ذکر شد، می توانید از رویدادهای یکپارچه سازی برای اجرای وظایف تجاری که چندین میکروسرویس را در بر می گیرند استفاده کنید. بنابراین، شما در نهایت سازگاری بین آن خدمات خواهید داشت. یک تراکنش در نهایت سازگار از مجموعه ای از اقدامات توزیع شده تشکیل شده است. در هر اقدام، میکروسرویس مربوطه یک موجودیت دامنه را به‌روزرسانی می‌کند و رویداد یکپارچه‌سازی دیگری را منتشر می‌کند که اقدام بعدی را در همان کار تجاری انتها به انتها افزایش می‌دهد.یک نکته مهم این است که ممکن است بخواهید با چندین میکروسرویس که در یک رویداد مشترک هستند ارتباط برقرار کنید. می توانید از پیام های انتشار/اشتراک بر اساس ارتباطات رویداد محور استفاده کنید. این مکانیسم انتشار/اشتراک منحصر به معماری میکروسرویس نیست. این شبیه به روشی است که Context های محدود در DDD باید با هم ارتباط برقرار کنند، یا به روشی که شما به روز رسانی ها را از پایگاه داده نوشتن به پایگاه داده خوانده شده در الگوی معماری Command and Query Responsibility Segregation (CQRS) منتشر می کنید. هدف این است که در نهایت بین منابع داده چندگانه در سراسر سیستم توزیع شده شما سازگاری داشته باشید.در ارتباطات ناهمزمان رویداد محور، یک میکروسرویس رویدادها را در یک اتوبوس رویداد منتشر می‌کند و بسیاری از میکروسرویس‌ها می‌توانند در آن مشترک شوند تا مطلع شوند و بر اساس آن عمل کنند. پیاده سازی شما تعیین می کند که از چه پروتکلی برای ارتباطات پیام محور و مبتنی بر رویداد استفاده کنید. AMQP می تواند به دستیابی به ارتباطات صف قابل اعتماد کمک کند.هنگامی که از یک گذرگاه رویداد استفاده می کنید، ممکن است بخواهید از یک سطح انتزاعی (مانند رابط اتوبوس رویداد) بر اساس پیاده سازی مرتبط در کلاس ها با کد با استفاده از API از یک واسطه پیام مانند RabbitMQ یا یک گذرگاه خدمات مانند Azure Service Bus با موضوعات استفاده کنید. . از طرف دیگر، ممکن است بخواهید از یک گذرگاه خدمات سطح بالاتر مانند NServiceBus، MassTransit یا Brighter برای بیان اتوبوس رویداد خود و سیستم انتشار/اشتراک استفاده کنید.یادداشتی در مورد فن آوری های پیام رسانی برای سیستم های تولیدفن آوری های پیام رسانی موجود برای اجرای گذرگاه رویداد انتزاعی شما در سطوح مختلف هستند. به عنوان مثال، محصولاتی مانند RabbitMQ (یک حمل و نقل واسطه پیام رسانی) و Azure Service Bus در سطح پایین تری نسبت به سایر محصولات مانند NServiceBus، MassTransit یا Brighter قرار دارند که می توانند در بالای RabbitMQ و Azure Service Bus کار کنند. انتخاب شما به تعداد ویژگی های غنی در سطح برنامه و مقیاس پذیری خارج از جعبه برای برنامه خود بستگی دارد. برای پیاده‌سازی یک گذرگاه رویداد اثبات مفهوم برای محیط توسعه‌تان، همانطور که در نمونه eShopOnContainers انجام شد، یک پیاده‌سازی ساده در بالای RabbitMQ در حال اجرا بر روی یک ظرف Docker ممکن است کافی باشد.با این حال، برای سیستم‌های تولیدی و حیاتی که نیاز به مقیاس‌پذیری بیش از حد دارند، ممکن است بخواهید Azure Service Bus را ارزیابی کنید. برای انتزاع‌ها و ویژگی‌های سطح بالا که توسعه برنامه‌های کاربردی توزیع‌شده را آسان‌تر می‌کنند، توصیه می‌کنیم سایر اتوبوس‌های خدمات تجاری و منبع باز مانند NServiceBus، MassTransit و Brighter را ارزیابی کنید. البته، می‌توانید ویژگی‌های سرویس اتوبوس خود را بر روی فناوری‌های سطح پایین‌تر مانند RabbitMQ و Docker ایجاد کنید. اما این کار لوله کشی ممکن است برای یک برنامه سازمانی سفارشی هزینه زیادی داشته باشد.در حال انتشار به اتوبوس رویدادچالشی که هنگام پیاده‌سازی یک معماری رویداد محور در چندین میکروسرویس وجود دارد این است که چگونه به‌صورت اتمی وضعیت را در میکروسرویس اصلی به‌روزرسانی کنیم و در عین حال رویداد یکپارچه‌سازی مرتبط آن را به‌گونه‌ای بر اساس تراکنش‌ها منتشر کنیم. در زیر چند راه برای انجام این عملکرد وجود دارد، اگرچه می‌تواند رویکردهای دیگری نیز وجود داشته باشد.با استفاده از صف معاملاتی (مبتنی بر DTC) مانند MSMQ. (با این حال، این یک رویکرد قدیمی است.)استفاده از استخراج لاگ تراکنشبا استفاده از الگوی کامل رویداد منبع یابی.استفاده از الگوی صندوق خروجی: یک جدول پایگاه داده تراکنشی به عنوان یک صف پیام که پایه یک مؤلفه ایجاد کننده رویداد است که رویداد را ایجاد و منتشر می کند.