این نوشته برداشت‌های شخصی من از کتاب Microservices Patterns است.
خیلی وقت هست که دوست داشتم این متن رو منتشر کنم و متاسفانه فرصتی پیدا نمی‌کردم.
اما بالاخره امروز تصمیم گرفتم شروعش کنم.
میکروسرویس، واژه‌ای که این روزها شاید در اکثر شرکت‌های تکلونوژی دنیا اسمش شنیده می‌شود.
در این نوشته به تعریف این معماری از منظر خودم و مزایا و معایب آن می‌پردازم و در نوشته‌های بعدی جزئیاتی را هم در این باره منتشر میکنم.
من به موجودیتی سرویس می‌گویم که به تنهایی قابل توسعه، دیپلوی، تست و scale باشد.
برخلاف اسمش که میکرو در آن وجود دارد، هیچ‌وقت این تصور را نداشته باشید که یک سرویس هر چه قدر کوچک‌تر باشد بهتر است.
خب حالا سوالات اساسی:
خب بدیهی‌ترین فرق این است که در معماری مونولوتیک، یک سیستم از یک سرویس تشکیل شده است ولی در معماری میکروسرویس‌ها از چند سرویس.
حالا برخی مزایای مهم معماری میکروسرویس‌ها را بیان میکنم:
ابتدا از تعریفی که ارائه دادم شروع میکنم و کمی توضیحش میدهم:
شاید بگویید مگر در بقیه حالت‌ها قابل توسعه نیست؟ در جواب باید بگویم که بله در برخی حالت‌ها اگر در زمان مناسبش اقدام درستی انجام نشود سرویس توانایی توسعه‌اش را از دست می‌دهد. حالا چگونه؟
فرض کنید که سیستم خیلی بزرگ دارید و چند تیم روی آن کار می‌کنند. حالا زیاد هم نگوییم مثلا سه تیم پنج نفره. هر چقدر هم کد یک پروژه تمیز باشد و وابستگی در آن کم باشد، یک برنامه‌نویس چون یک آدم است، می‌تواند اشتباه کند و اگر جایی اشتباه کند همین اشتباه او باعث کرش در سیستم شده و کل مجموعه را از کار می‌اندازد. و از جنبه دیگر، وقتی با یک سرویس سر و کار دارید و یک برنامه‌نویسی باشید که تازه به آن مجموعه اضافه شده‌اید شاید سال‌ها طول بکشد که از همه جای آن سر در بیاورید و عملا نمی‌توانید توسعه خاصی روی آن انجام دهید. ولی اگر این سیستم به چند سرویس شکسته شده باشد شما در یک تیم مجزا به توسعه سرویس خودتان می‌پردازید. و با بقیه کاری ندارید. :)
همین سرویس بزرگ قبلی را تصور کنید، شما یک کامیت روی برنچ مستر انجام می‌دهید. در بهترین حالت احتمالا دو روز طول بکشد که کدی که شما زده‌اید بر روی نسخه پروداکشن اجرا شود. به نظرتان زمان خوبی است؟ اگر کدی که شما زده‌اید فقط یک خط باشد چه؟ واقعا فاجعه است! اما در میکروسرویس فاصله مرج تا دیپلوی می‌تواند حتی کمتر از یک دقیقه باشد. این یعنی چابکی به معنای واقعی کلمه. :)
شما یک کدی میزنید و انتظار دارید کارایی که می‌خواهید را داشته باشد و حتی برایش تست هم نوشته‌اید. اما از کجا می‌دانید که کد شما قسمت‌های مختلفی که سایر تیم‌ها روی آن‌ها کار می‌کنند تاثیر نمی‌گذارد آن‌ها را خراب نمی‌کند و برعکس. اما در میکروسرویس شما توسعه را در سرویسی که برای خودتان است پیش می‌برید و تست‌های خودتان که پاس شد روی نسخه عملیاتی اجرایش میکنید. و حتی اگر خراب هم شود فقط روی این سرویس تاثیر می‌گذارد و کل سیستم مختل نمی‌شود.
در حالت مونولوتیک اگر بار روی سرویس‌تان زیاد شود و بخواهید آن را حالا با هر روشی scale کنید، مجبور هستید برای همه سیستم این کار را انجام دهید. و این در حالی است که احتمال زیاد همه قسمت‌های آن مثلا همه apiها، بار زیادی ندارند و فی‌الواقع نیازی نیست که scale شوند.
ولی در معماری میکروسرویس‌ها شما می‌توانید هر سرویس را به طور جداگانه و در حد نیازش scale کرده و خروجی خوبی را به کاربران خود بدهید.
کلا معماری میکروسرویس‌ها نکته‌های خوب زیاد دارد که در این حجم از کلام نمی‌گنجد و همین کتابی که اول نوشته معرفی کردم یکی از منابع خوب برای شناختن هر چه بهتر آن است.
اما در میان مزایا، این معماری مانند هر چیز دیگری معایبی را دارد. که به نظر من مهم‌ترین آن‌ها پیچیدگی است که به مجموعه اضافه می‌کند. از این جهت که اگر یک کسب و کار نوپا در همان اول کار دنبال میکروسرویس بودن باشد احتمال زیاد هم وقت زیادی صرف می‌کند و هم خطاها و شکست‌هایی در پی خواهد داشت. مهم‌ترین نکته در بین مرز معماری میکروسریس‌ها و مونولوتیک، شناختن و درک عمیق زمان درست مهاجرت از مونولوتیک به میکروسرویس‌ها است که اگر این زمان درست انتخاب شود، اتفاقات خوبی را برای یک کسب و کار نوپا از نظر فنی رقم می‌زند.
خب این نوشته را اینجا تمام میکنم با این نکته که چیزی که خواندید: اقتباسی از کتاب اشاره شده که آکنده از نظرات و تجربه‌ها و برداشت‌های شخصی من بود. و مثل همیشه مشتاق شنیدن نظرات و پیشنهادات هستم.
انشالله در نوشته‌های آینده در این معماری ریز می‌شوم و درباره نحوه ارتباط بین سرویس‌ها و نقش دیتابیس و نحوه جداسازی و مهاجرت و ... حرف می‌زنم.
