آموزش میکروسرویس Microservice - ویژگی های اصلی میکروسرویس (بخش دوم)

بخش اول : آشنایی با مفهوم میکروسرویس
بخش دوم : ویژگی های اصلی یک میکروسرویس (همین مقاله)
بخش سوم : تحلیل یک پروژه کوچک بر اساس میکروسرویس ها
بخش چهارم : شروع پیاده سازی یک پروژه فروشگاهی
پیشنیاز 1 بخش پنجم : آموزش Node و Typescript برای تولید api
پیشنیاز 2 بخش پنجم : آموزش داکر و مفاهیم اولیه
بخش پنجم : پیاده سازی یک میکروسرویس برای نمایش کالاها
پیشنیاز 1 بخش ششم : آشنایی با Asp.net core 6
بخش ششم : پیاده سازی یک میکروسرویس برای کار با سبد خرید
بخش هفتم : پیاده سازی یک میکروسرویس برای محاسبه قیمت و تخفیفات
بخش هشتم: پیاده سازی یک میکروسرویس برای ثبت سفارش

برای دیدن ویدیوهای من در مورد برنامه نویسی عضو این کانال شوید :
https://t.me/mediapub_channel

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

تک وظیفه بودن (RESPONSIBLE FOR A SINGLE CAPABILITY)

یک میکروسرویس مسئول انجام یک و تنها یک وظیفه از کل سیستم است.

میتوانیم این عبارت را به شکل زیر به دو موضوع تقسیم بندی کنیم :

• میکروسرویس باید تک مسئولیتی باشد (Single Responsibility)
• مسئولیت میکروسرویس معطوف به قابلیتی است که به عهده دارد.

این تک مسئولیتی با موضوع Single Responsibility در کد نویسی و در حوزه کلاس ها به دلیل مفهوم مشابه است.

اینکه میکروسرویس تنها مسئول یک قابلیت از کل سیستم است یعنی اگر تغییری در آن قابلیت صورت گیرد، فقط میکروسرویس مربوط به آن دستخوش تغییر خواهد شد.

این موضوع را رابرت سی مارتین در حوزه برنامه نویسی اینگونه بیان میکند.

چیزهایی که به «دلایل مشابه» ممکن است تغییر کنند را یکجا بگذارید و چیزهایی که به «دلایل مختلف» تغییر میکنند را از هم جدا کنید.

یک سیستم میکروسرویسی، تک وظیفه بودن را در دو حوزه تقسیم می کند :

• قابلیت بیزنسی : کاری که هر میکروسرویس در جهت اهداف سیستم انجام میدهد. مثلا پیگیری سبد خرید کاربر و محاسبه قیمت.
• قابلیت فنی : قابلیت هایی که چندین میکروسرویس از آن استفاده می کنند. مثل توسعه یک سیستم بیرونی (third-party) برای پاسخگویی به نیاز میکروسرویس ها. این نوع قابلیت، عامل اصلی تفکیک یک سیستم به میکروسرویس ها نیست. زمانی این قابلیت ها شناسایی میشوند که چندین میکروسرویس به یک قابلیت تکنیکالی مشترک نیاز داشته باشند. مثل ماژول ارسال ایمیل یا اس ام اس.

قابلیت انتشار به شکل مستقل (INDIVIDUALLY DEPLOYABLE)

یعنی وقتی یک میکروسرویس نیاز به اصلاح یا تغییر داشته باشد بدون اینکه بقیه سیستم را تحت تاثیر قرار دهد میتواند اصلاح شده و به طور مستقل پابلیش شود. در طول این فرایند، بقیه میکروسرویس ها بدون مشکل به کار خود ادامه میدهند.

یک وب سایت e-commerce را در نظر بگیرید. با تغییر میکروسرویس مربوط به سبد خرید، اولا تنها نیاز به پابلیش همین میکروسرویس است و ثانیا با پابلیش بقیه میکروسرویس ها بدون تغییر باقی میمانند و به کار خود ادامه میدهند.

توانایی پابلیش مستقل در یک سیستم میکروسرویسی، بسیار اهمیت دارد. چون تعداد زیادی میکروسرویس در تعامل با هم در حال کار کردن هستند و هزینه متوقف کردن همه ی آنها زیاد است.

برای اینکه این ویژگی در سیستم وجود داشته باشد باید نکات زیر رعایت شود :

• هر میکروسرویس باید محیط اجرایی مستقل داشته باشد. (داکر کانتینر جدا)
• پروسه انتشار باید طوری تنظیم شود که هر میکروسرویس بطور مستقل منتشر شود در حالی که بقیه میکروسرویس ها به کارشان ادامه میدهند.

شامل یک یا چند پراسس است (CONSISTS OF ONE OR MORE PROCESSES)

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

• هر میکروسرویس باید در یک پراسس جدا از دیگر سرویس ها اجرا شود.
• یک میکروسرویس میتواند بیشتر از یک پراسس داشته باشد.

میکروسرویس Shopping Cart را دوباره درنظر بگیرید. اگر در پراسس مشابه با میکروسرویس product catalog اجرا شود (همانطور که در شکل زیر نشان داده شده) باعث میشود که ساید افکت برای product catalog ایجاد شود. به این معنی که یک کوپل و اتصال ناخوشایند بین shopping cart و product catalog بوجود می آید که در مواقع حساس (مثل انتشار یا خطای سروری) باعث downtime یا باگ در هر دو میشود.

حالا در نظر بگیرید که یک نسخه جدید از میکروسرویس shopping cart منتشر کرده ایم. مجبوریم میکروسرویس product catalog را دوباره پابلیش کنید.

چرا یک میکروسرویس بیش از یک پراسس داشته باشد؟
قرار بود هر میکروسرویس به ساده ترین شکل پیاده سازی شود اما میکروسرویس ممکن است به دیتابیس نیاز داشته باشد. مثلا میکروسرویس recommendation را درنظر بگیرید که در یک سیستم e-commerce قرار است به کمک الگوریتم از دیتابیس پیشنهاداتی برای کاربر استخراج کند. پراسسی که دیتابیس را هندل میکند و در برخی جاها background service ها، نیازمند پراسس جدا هستند.

منبع ذخیره سازی خودش را داشته باشد (OWNS ITS OWN DATA STORE)

میکروسرویس باید دیتابیس خودش را داشته باشد. مثلا میکروسرویس product catalog نیاز به مقداری اطلاعات از کالاها دارد که باید ذخیره شوند. برای اینکه اطلاعات کالاها به شکل loosly coupled از بقیه میکروسرویس ها ذخیره شود باید میکروسرویس product catalog دیتابیس خودش را داشته باشد. این میکرسرویس است که تصمیم میگیرد دیتای خودش را چطور ذخیره یا استفاده کند.

میکروسرویسی مثل shopping cart فقط از طریق اینترفیسی که میکروسرویس product catalog در اختیارش قرار میده با کالا ها ارتباط دارد و نمیتواند به شکل مستقیم به دیتابیس میکروسرویس product catalog دسترسی داشته باشد.

این ویژگی باعث میشود که هر کدام از میکروسرویس ها اختیار استفاده از تکنولوژی متفاوت برای ذخیره دیتا داشته باشند. مثلا میکروسرویس product catalog میتواند از SQL Server استفاده کند یا میکروسرویس shopping cart میتواند از Redis برای نگهداری اطلاعات سبد هر کاربر استفاده کند یا میکروسرویس recommandation میتواند از ElasticSearch و ایندکس کردن در الاستیک برای ذخیره پیشنهادات استفاده کند.

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

نگهداری با تیم کوچک (MAINTAINED BY A SMALL TEAM)

با اینکه کلمه "میکرو" نمایانگر کوچکی سرویس است اما این کوچکی دقیقا چه مقدار است؟

این موضوع تنها به تعداد خطوط کد شما بستگی ندارد. حتا به نیازمندیها و usecase ها و فانکشن ها به طور مستقیم مربوط نیست. کوچک بودن یک میکروسرویس تنها بستگی به میزان پیچیدگی قابلیت هایی دارد که توسط میکروسرویس فراهم میشود.

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

قابلیت تعویض (REPLACEABLE)

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

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

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