تعیین حدود و مرزبندی‌های میکروسرویس

بهترین اندازه‌ای که برای یک میکروسرویس وجود دارد چه اندازه‌ای است؟ تا به حال در ارتباط با ساختن میکروسرویس این جمله را شنیده‌اید: «نه زیاد بزرگ و نه زیاد کوچک»؟ البته که این جمله کاملا درست است اما ما را به لحاظ عملی به جای درست و کاملی نمی‌رساند. پس راهکار چیست؟

اگر شما قدم‌های ابتدای خود را به دقت بردارید و Domain Model را به درستی حساب کنید، بهتر می‌توانیم به آنچه که هدف‌مان است برسیم.

همانطور که می‌دانید ما در این مجموعه مقاله از مثال یک اپلیکیشن تحویل بسته با استفاده از پهپاد استفاده کرده‌ایم. اگر اطلاعی دقیق از این پروژه ندارید پس بهتر است به عقب برگشته و مقالات قبلی را مطالعه کنید.

از Domain Model به سوی میکروسرویس

در مقاله قبلی ما یکسری زمینه محدود شده را برای اپلیکیشن‌مان ایجاد کردیم. همچنین به این زمینه‌ها و محتواها نگاه دقیقی انداخته و با مفاهیم موجودیت و توده‌ها آشنا شدیم.

حال نوبت آن است که وارد فاز جدیدی از توسعه اپلیکیشن شده و از Domain Model به سوی طراحی خود اپلیکیشن و ساختن میکروسرویس‌ها برویم. برای انجام چنین کاری ما به یک نقشه راه یا یک راهنمای قدم به قدم نیاز داریم. در زیر می‌توانید این راهنما را مشاهده کنید:

1. کار خود را با یک زمینه محدود شده یا Bounded Context شروع کنید. به صورت کلی کارکرد و وظیفه یک میکروسرویس نباید بیشتر از یک زمینه باشد. بنا به تعریف، یک زمینه محدود شده وظیفه دارد تا مرزبندی‌های یک Domain Model را نشان دهد. اگر زمانی به این نتیجه رسیدید که میکروسرویس شما از زمینه‌های مختلفی برخوردار بوده و Domain Modelهای مختلفی را با همدیگر ترکیب می‌کند باید بدانید که این نشانه خوبی نیست. در این شرایط باید به عقب برگشته و فرایند آنالیز اپلیکیشن را از ابتدا انجام دهید.
2. در قدم بعدی به توده‌ها در Domain Model نگاه کنید. توده‌ها معمولا کاندیداهای خوبی برای میکروسرویس‌ها هستند. زمانی که توده شما دارای ویژگی‌های زیر باشد در آن صورت می‌تواند منجر به یک طراحی خوب در میکروسرویس شود:
   • توده شما از نقطه نظر کسب و کار، منطق و کارایی کلی اپلیکیشن گرفته شود.
   • یک توده باید از نظر کارایی انسجام بالایی داشته باشد.
   • یک توده باید روی زمینه محدود شده خود باقی بماند.
   • یک توده باید قوانین پایه‌ای میکروسرویس از جمله Loosely Coupled بودن را رعایت کند. در ارتباط با این موضوع در اولین مقاله از این مجموعه صحبت کردیم.
3. Domain Serviceها نیز کاندیدا خوبی برای میکروسرویس‌ها به حساب می‌آیند. این موارد می‌توانند روی چندین توده به صورت همزمان کار کنند.
4. در نهایت، به اطلاعات و غیر فانکشنال که خارج از محدوده محتوایی خود اپلیکیشن هستند به دقت نگاه بیاندازید. برای مثال اندازه تیم توسعه شما می‌تواند روی اینکه میکروسرویس‌های شما چقدر می‌توانند مستقل عمل کنند تاثیر بگذارد.

بعد از آنکه پروسه مربوط به میکروسرویس در اپلیکیشن‌تان پیاده‌سازی شد باید مطمئن شوید که اپلیکیشن‌تان براساس موارد زیر استانداردسازی می‌شود:

• هر سرویس در میکروسرویس باید یک وظیفه داشته باشد و تنها برای یک عمل خاص پیاده‌سازی شود.
• از ارتباطات نزدیک بین سرویس‌ها خودداری کنید. منظور از این کار این است که نباید دو سرویس کارهای‌شان کاملا شبیه به همدیگر باشد. در این حالت بهتر است از یک سرویس استفاده کنید.
• سرویس‌ها باید به لحاظ دیپلوی و میزبانی شدن مستقل باشند. در این شرایط دیپلوی کردن یک سرویس نباید وابسته به دیپلوی کردن یک سرویس دیگر باشد.
• سرویس‌ها مستقل از همدیگر هستند و نباید به همدیگر وابسته باشند.
• مرزبندی سرویس‌ها به لحاظ کارایی نباید روی یکپارچگی داده‌ها تاثیرگذار باشد. در واقع داده‌ها چیزی هستند که باید به آسانی در بین سرویس‌ها رد و بدل شده و در نهایت اصول یکپارچگی را حفظ کنند. از آنجایی که در یک سیستم یکپارچه همه چیز در یک کد-بیس موجود است اصل یکپارچگی می‌تواند به سادگی انجام شود اما در میکروسرویس یکپارچگی داده‌ها کار نسبتا مشکلی است.

مهمتر از همه این موارد این است که شما باید عملگرا باشید. معماری DDD به صورتی است که شما همواره باید در فرایند بهبود و توسعه آن مشارکت داشته باشید چرا که این یک پروسه تکرار شدنی است. سرویس‌های جدید با ایجاد کارایی‌های جدید اضافه خواهند شد و در این حالت باید بسیار مراقب باشید.

در نظر داشته باشیم که تیم توسعه چهار توده را برای اپلیکیشن در نظر گرفته است که عبارتند از: Delivery, Package, Drone, and Account. همچنین در این اپلیکیشن دو Domain Service برای بخش‌های Schedular و Supervisor در نظر گرفته شده است.

Delivery و Package دو کاندید پیش بینی شده و واضح برای میکروسرویس‌ها به حساب می‌آیند. Scheduler و Supervisor نیز کارهای انجام شده را هماهنگ می‌کنند به همین دلیل انتخاب‌های مناسبی برای Domain Service به حساب می‌آیند.

Drone و Account در این ساختار از یک زمینه محدود استفاده می‌کنند از این نظر فرایند پیاده‌سازی چالش برانگیزی خواهند داشت. برای پیاده‌سازی این دو مورد می‌توان از راه‌های مختلفی عمل کرد. یک روش فراخوانی مستقیم هر دو مورد است و راهکار دیگر ایجاد میکروسرویس‌های Drone و Account در داخل زمینه محدود شده Shipping است.

البته یک موضوع را در نظر داشته باشید و آن این است که اطلاعات مربوط به زمینه‌های محدود شده Drone و Account از حیطه خودشان فراتر می‌رود به همین دلیل ما تصمیم گرفته‌ایم که یکسری سرویس را برای آن‌ها ایجاد کنیم. برای این موضوع چندین فاکتور وجود دارد که شما باید آن‌ها را در نظر بگیرید:

• میزان و حجم انتقالات در شبکه زمانی که بخواهیم آن‌ها را مستقیم از دیگر زمینه‌های محدود فراخوانی کنیم چقدر است؟
• آیا Data Schema دیگر زمینه‌های محدود شده برای این قسمت نیز مناسب است؟
• ساختار تیم توسعه به چه شکل است؟ آیا ارتباط برقرار کردن با تیم‌های دیگر که مسئولیت زمینه‌هایم حدود دیگر را دارند آسان است؟

حال جدای از این موارد یکی از موضوعاتی که از آن صحبت نشده است نیازمندی‌های غیر فانکشنال است. نیازمندی‌های غیر فانکشنال به تیم‌ها کمک می‌کند تا بتوانند یک سرویس اضافی را نیز ایجاد کنند. تمام میکروسرویس‌هایی که ما تا به حال قصد ایجاد کردنشان را داشتیم هدف‌شان ایجاد زمان‌بندی و تحویل محصولات به صورت بلادرنگ بوده است اما این سیستم به یک مکان برای ذخیره تاریخچه محصولات تحویل شده نیاز دارد. تیم در ابتدا تصمیم می‌گیرد تا این قسمت را در داخل سرویس Delivery قرار دهد اما متوجه می‌شود که ساختار داده‌ای و بانک اطلاعاتی مربوط به تاریخچه محصولات کمی متفاوت است. بنابراین تیم در نهایت تصمیم می‌گیرد که یک سرویس تاریخچه تحویل را به صورت جداگانه درست کند.

در تصویر زیر می‌توانید دیاگرامی را از چیزی که تا به حال ایجاد کرده‌ایم مشاهده کنید:

تا به اینجا کار به یک ایده کلی و واضح از اپلیکیشن و سیستم میکروسرویسی که قصد ایجاد کردنش را داریم رسیدیم. حال باید سراغ معماری خود سیستم برویم.