در مورد چی حرف میزنیم؟
تو دنیای امروز یکی از buzz wordها کلمه microservice هست. کلمه‌ای که شاید زیاد شنیده باشیدش یک نوع طراحی سیستم هست که در اون اجزای مختلف اصطلاحا loosely coupled هستن و هر کدوم به تنهایی قابلیت scale شدن رو دارن.
داستان از اونجایی شروع میشه که ما هر وقت سیستممون نمی‌کشه میایم و ارتقا میدیم. سرعت پردازنده رو زیاد می‌کنیم، رم رو افزایش میدیم یا فضای هارد بیشتری خریداری می‌کنیم، اما واقعیت اینه که بالاخره هر چقدر هم قوی کنیم سیستم رو تعداد کاربرها که زیاد بشن باز کم میاریم. خب پس چاره چیه؟
یکی از راه حل‌ها scale کردن سیستم هست. به این معننا که شما به جای یک کامپیوتر خیلی قوی و خفن میای ۱۰ تا کامپیوتر نسبتا قوی میزاری، یکیش به عنوان load balance یا master یا هر اسم دیگه‌ای که دوست دارین که کارش میشه تقسیم درخواست‌ها بین ۹ سیستم دیگه. این روش خیلی خوب عمل کرد و الگوریتم‌های جدیدی تعریف شد برای استفاده بهینه ازش و کلی مسئله برامون به وجود اومد مثل مسائل race condition و transaction. اما باز مشکل خوردیم! هزینه کامپیوترهای نسبتا قوی هم کم نیستن و با افزایش کاربرها این هزینه خیلی سریع زیاد میشه.
اینجا بود که بعضی از مهندسا به این نتیجه رسیدن که نیازی نیست کل سیستم رو scale کرد و کافیه بخشی از اون scale شه. مثلا بخش مربوط به ایمیل زدن تبریک تولد به کاربرها نیازی نیست روی همه سرورها اجرا بشه و روی بعضی از اون‌ها کفایت می‌کنه، و از طرفی بخش مربوط به جواب دادن به api محبوب cat recognizer به شدت مورد استفاده قرار می‌گیره باید روی تعداد بیشتری سرور اجرا بشه. اینجا مهندس‌ها شروع کردن به بخش کردن نرم‌افزارهاشون به سرویس‌های کوچکتری که با هم صحبت می‌کنند و این شروعی از میکروسرویس‌هاست.
بحث دیگه‌ای که در زمینه میکروسرویس‌هاست بحث توسعه هست. تو تیم‌های بزرگ و نرم‌افزارهای پیچیده تغییر دادن چیزهای نامربوط ممکنه باعث خرابی کل سیستم بشه. اما توسعه ماژولار بسیار کمک می‌کنه که این مشکل‌ها کمتر پیش بیان. میکروسرویس‌ها که به نوعی خودشون ماژول‌ها هستن تو این زمینه به شدت به کمک توسعه دهنده‌ها میان.
تو این پست و پست‌های بعدی این سری میخوام در مورد این که چه مسائلی تو زمینه میکروسرویس‌ها هست و هرکدوم چه راهکارهایی دارن براتون بنویسم. بیشتر این مسائل از تجربه شخصیم تو پروژه‌های متفاوت حاصل شده، اگر جاییش مشکلی هست حتما بهم بگید اصلاح می‌کنم!
چه چیزی باید سرویس باشه؟
سوال بسیار جالبی هست. تو فلسفه یونیکس گفته میشه هر نرم‌افزار باید یک کار، و فقط یک کار، را انجام دهد و آن را به خوبی انجام دهد. این حرف شاید برای نرم‌افزارهای کامندلاین یونیکس مناسب باشه اما برای سرویس‌ها واقعا مناسب نیست. هر میکروسرویس هزینه توسعه جدایی داره و وجودش سربار برای سیستم تولید می‌کنه. هزینه پشتیبانی و مانیتورینگ و غیره بماند.
خب پس چه کار باید کرد؟ راهکار اینه که actionهایی که برای کاربرها تعریف می‌کنید رو گروه بندی کرد.
- اولین رویکرد نزدیکی سیستمی هست مثلا وارد شدن به سیستم و ثبت‌نام کردن نزدیکی زیادی به هم دارن، هم از کتابخونه‌های یکسانی استفاده می‌کنند(برای رمزنگاری و تایید رمز)، هم سرویس های مشترکی رو(دیتابیس).
- رویکرد دوم نزدیکی از لحاظ بار و فشار سیستم هست. مثلا سرویس ثبت‌نام و آپلود عکس کاربری معمولا با هم استفاده میشن و اگه تعداد زیادی کاربر یکهو تصمیم بگیرند ثبت‌نام کنند (مثلا بعد آگهی تلویزیونی در آخر یک سریال محبوب) شما کافیه این سرویس رو scale کنید.
تجربه من نشون داده رویکرد دوم معمولا عملکرد بهتری داره، تو پست بعدی در مورد این که چطوری این گروه‌ها رو تشخیص بدیم بیشتر صحبت می‌کنم.