کتاب Microservices Patterns: With Examples in Java نوشته Chris Richardson یکی از قشنگ‌ترین کتاب‌های فنی هست که تا الان خوندم. اولین بار 7 فصل از این کتاب رو به عنوان پروژه درس معماری نرم‌افزار پیشرفته دکتر علی اکبری در دانشگاه شهید بهشتی ارائه دادم. بعد یکی دو ماه این مفاهیم سر کار لازمم شد :) و این شد که تصمیم گرفتم یه بار دیگه کتاب رو عمیق‌تر و دقیق‌تر بخونم. از اون جایی که نیاز به یه انگیزه داشتم، تصمیم گرفتم دانشم رو در این جا با شما به اشتراک بذارم. اینجوری یک تیر و چند نشونه! هم کتاب رو میخونم و اینجا می‌نویسم که شاید به درد یکی دیگه بخوره و هم اینکه از نظرات ارزشمندتون استفاده می کنم.
شروع کتاب با مثالی درباره شرکت FTGO است. Mary مدیر ارشد فنی(CTO) اونجاست و در یک کنفرانس درباره آخرین دستاوردهای مهندسی نرم‌افزار شرکت می‌کند. در این کنفرانس درباره معماری میکروسرویس صحبت می‌شود.
ماری پس از شرکت در این کنفرانس یک هفته کاری را شروع می‌کند و طبق معمول یک جلسه ناخوشایند با برنامه‌نویس ارشد و افراد کسب و کار دارد. آن‌ها دو ساعت درباره تیم فنی صحبت کردند و اینکه باز هم قرار بود یک ددلاین مهم را از دست بدهند.
متاسفانه این نوع جلسات طولانی و اکثرا بی‌فایده در چند سال اخیر در این شرکت زیاد شده بود و این مغایر با چابک بودن اجایل بود. در این صورت دسترسی به اهداف کسب و کار مرتبا به تعویق می افتد. وضعیت دشواری که به نظر نمی‌رسید راه حل ساده ای برای آن وجود داشته باشد.
شرکت در کنفرانس سبب شده بود که ماری بفهمد چیزی که FTGO از آن رنج می برد، معماری یکپارچه است و تنها یک راه وجود دارد: معماری میکروسرویس!
این که چگونه می‌توان به میکروسرویس مهاجرت کرد و از آن برای بهبود FTGO کمک گرفت، چیزی است که در این کتاب می‌آموزیم.
ابتدا بهتر است کمی درباره معماری یکپارچه بدانیم و اینکه چگونه FTGO بدین جا رسید.
در اواخر سال 2005 FTGO شروع به رشد کرد تا بدانجا که امروزه یکی از کمپانی های معروف سفارش غذا در ایالات متحده است. (Food To GO)
کار با FTGO ساده است. کاربر از طریق وب سایت یا اپلیکیشن موبایل درخواست خود را در یکی از رستوران‌های اطرافش ثبت می‌کند. این درخواست به رستوران می‌رسد. مدیریت رستوران می‌تواند منو را ایجاد کرده یا تغییر دهد، درخواست‌ها را دریافت کرده و به آن ها پاسخ دهد. غذا برای مشتری با پیک ارسال می‌شود و صورتحساب برای او ایمیل می‌شود. همچنین مشتری می‌تواند از سرویس‌های پرداخت آنلاین استفاده کند. (مشابه اسنپ فود و ریحون در ایران)
اپلیکیشن FTGO مانند خیلی دیگر از نرم‌افزارهای سازمانی (Enterprise) دارای یک معماری یکپارچه است به گونه ای که در نهایت یک فایل WAR که مخفف Java Web Application Archive است، تولید می‌شود. در طول زمان این فایل پیچیده و بزرگ شده است. علیرغم همه تلاش تیم فنی در نهایت این نرم‌افزار به یک مثال خوب از الگوی Big Ball of Mud تبدیل شد. (Big Ball of Mud چیست؟) به طور خلاصه این الگو یعنی جنگلی از کدهای اسپاگتی! چنین کدی باعث می‌شود که deliveryها کند به دست آیند.
معماری یکپارچه این نرم‌افزار بدین شکل است:
در این معماری از استایل شش‌ضلعی استفاده شده است که در فصل دوم این کتاب با جزئیات بررسی می‌شود. در یک معماری از نوع شش‌ضلعی، هسته اپلیکیشن Business Logic یا قوانین کسب و کار است. در اطراف آن، Adapterهای مختلف برای پیاده سازی UI و ارتباط با سیستم های خارج از این سیستم وجود دارد. (مثلا ارتباط با پرداخت بانکی، ایمیل، پیامک و ...)
در شکل بالا Business logic از ماژول‌هایی تشکیل می‌شود که این ماژول‌ها مجموعه‌ای از اشیا هستند.
مثال از ماژول در این نرم‌افزار:
همانطور که گفته شد، چندین adapters در اطراف Business logic قرار دارد که در دو دسته کلی قرار می‌گیرند:
مانند web ui و rest api که به درخواست‌ها با فراخوانی business logic پاسخ می دهند.
که برای ارتباط با خارج از business logic مانند پایگاه داده، کلود، پرداخت و ... به کار می روند.
علیرغم ماژولار بودن FTGO، نتیجه نهایی در یک فایل WAR وجود دارد و مثالی از استایل یکپارچه در معماری نرم‌افزار است. در معماری یکپارچه ساختار یک سیستم در نهایت با یک فایل قابل اجرا تعریف می‌شود. یعنی در اینجا تنها یک فایل WAR! البته به خودی خود یکپارچه بودن بد نیست. بلکه کاملا بستگی به کاربرد دارد. برای شروع، توسعه دهندگان FTGO انتخاب درستی کرده‌اند اما در ادامه بهتر است استراتژی خود را عوض کنند!
در پست بعدی برایتان از مزایا و معایب یکپارچگی و راهکار معماری میکروسرویس می‌نویسم. امیدوارم تا اینجا برایتان مفید بوده باشد.
منبع:
Microservices Patterns: With Examples in Java Book by Chris Richardson.
