مبحثی که در این مقاله قصد داریم مورد بررسی قرار بدیم، مقایسه دو رویکرد ارتباطی (Integration) متفاوت میان سرویسهای مختلف توی معماری ماکروسرویسه. یکی Orchestration و دیگری Choreography.
هر زمان که شروع به مدلسازی بیزینس‌های پیچیده میکنیم، باید با چالش‌های ایجاد شده توسط این پیچیدگی، دست و پنجه نرم کنیم.
با معماری ماکروسرویس، سریعتر به این چالش‌ها برمیخوریم.
به عنوان مثال یک فروشگاه اینترنتی فروش آهنگ داریم. زمانی که یک نفر در فروشگاه ما ثبت نام میکند اتفاق‌های زیر باید رخ دهند:
اگر بخواهیم این فرآیند را در یک فلوچارت نمایش دهیم کار بسیار راحتی داریم:
اما زمانی که میخواهیم این فرآیند را بصورت عملی پیاده‌سازی کنیم؛ دو رویکرد مختلف معماری وجود دارد که میتوانیم استفاده کنیم،Orchestration و Choreography.
با Orchestration میتوانیم وظیفه پیشبرد فرآیند را به یک سرویس مرکزی محول کنیم تا این سرویس، مراحل را به ترتیب و با صدا زدن سرویسهای دیگر به پیش ببرد. اما در رویکرد Choreography، هر سرویس میداند در زمان وقوع یک اتفاق مشخص، چه وظیفه ای دارد و چه عملیاتی را باید انجام دهد و دیگر چیزی به نام سرویس مرکزی نداریم و هر سرویس بصورت مستقل کار میکند.
حال اگر بخواهیم با روش Orchestration فرآیند را پیش ببریم، احتمالا ساده‌ترین کاری که میتوانیم انجام دهیم این است که سرویس Customer، وظیفه سرویس مرکزی را برعهده بگیرد. زمان ثبت نام و ایجاد مشتری، با سیستم حسابداری، پست و ایمیل از طریق Request/Response ارتباط برقرار کند.
سرویس Customer خودش وظیفه رهگیری وضعیت مشتری در فرآیند را دارد. میتواند وضعیت ثبت مشتری در سیستم حسابداری، وضعیت ارسال ایمیل و اینکه بسته پستی Delivered شده است یا خیر را چک کند.
فلوچارت این مدل بصورت زیر است و ما میتوانیم دقیقا به همین شکل در کد عمل کنیم.
معایب رویکرد Orchestration این است که سرویس Customer میتواند به عنوان اصلی ترین سرویس ما باشد و تمام فرآیندها و بیزینس‌ها از این سرویس شروع شوند که این احتمالا باعث میشود یک سرویس به عنوان "god" در سیستم ما وجود داشته باشد و به بقیه سرویسهای Anemic، دستوراتی در سطح عملیات CRUD بدهد.
اما با رویکرد Choreography میتوانیم به سرویس Customer فقط وظیفه ایجاد یک Event با عنوان مثلا CustomerCreated بدهیم. حالا سرویسهای حسابداری، ارسال ایمیل و پست، به این Event که ارسال شده Subscribe میکنند و عملیات مورد نظر خود را انجام میدهند، مانند شکل پایین. این نوع رویکرد بصورت فوق‌العاده‌ای Decouple است. هر سرویس دیگری که هنگام ایجاد یک مشتری، نیاز داشته باشد عملیاتی را انجام دهد، فقط کافیست به CustomerCreated، گوش دهد و Subscribe کند تا بتواند زمانی که این Event از سرویس Customer ما Raise شد، عملیات مورد نظر خود را انجام دهد.
این به این معنا است که در این رویکرد، کار بیشتری برای مانیتور کردن فرآیند داریم تا مطمئن شویم عملیات‌های صحیحی اتفاق افتاده است. برای مثال، ما چطور میتوانیم متوجه شویم که در سیستم حسابداری، باگی وجود داشته و حساب مشتری به درستی ایجاد نشده؟ میتوانیم برای مدیریت فرآیندمان ابزاری ایجاد کنیم که در صورت رخداد یک اتفاق غیر منتظره، Log بزند تا ما بتوانیم راحت تر باگ را شناسایی و رفع کنیم.
بصورت کلی، به نظرمن سیستم‌هایی که بیشتر فرآیندها را بصورت Choreographed پیش میبرند، بیشتر Loosely Coupled هستند و برای اعمال تغییرات، انعظاف پذیری بیشتری دارند. اما این را در نظر بگیرید که برای مدیریت و مانیتور فرآیندها باید کار بیشتری انجام دهید.
البته سیستم‌هایی وجود دارند که با اعمال Choreography بسیار شکننده شده‌اند، با CostOfChange های بسیار بالاتر. اما با این حال، ترجیح من به استفاده از رویکرد Choreography است، رویکردی که در آن هر قسمت از سیستم میداند چه کاری باید انجام دهد تا در نهایت فرآیند ما با موفقیت به پایان برسد.
یک بحث دیگر هم هست که میتوانیم اینجا به آن بپردازیم.
اینکه Call کردن سرویسهای دیگر بصورت Synchronous ساده است و اگر Call های سریع و ساده‌ای داریم از آن استفاده کنیم. اما اگر بخواهیم با روش Request/Response پیش برویم و با فرآیند‌هایی که مدت زمان اجرای آن زیاد است مواجهیم، میتوانیم در اینجا بصورت Asynchronous انجام دهیم اما منتظر Callback آن بمانیم.
از سویی دیگر ارتباط Asynchronous Event میتواند مارا به سمت پیاده‌سازی هر چه بهتر رویکرد Choreography سوق دهد که باعث توسعه سرویسهای Decoupled میشود.
نهایتا چیزی که ما میخواهیم به آن برسیم، اطمینان از آنکه بتوانیم سرویس‌هایمان را بصورت کاملا مستقل Deploy کنیم.
چالش بعدی که با آن مواجه میشویم، نحوه پیاده‌سازی و ارتباط بصورت Choreography است که بحث آن از این مقاله خارج است و در آینده در یک مقاله دیگر به آن خواهیم پرداخت.
برگرفته از کتاب Building Microservices - Designing Fine Grained Systems
حمیدرضا علیاری
