معرفی

بسیاری از سازمان ها و تیم ها ممکن است ریزسرویس ها را بهترین رویکرد برای یک مشکل تعیین شده ببینند. این پست 5 مفهوم اساسی را پوشش می دهد که باید در هنگام اجرای این نوع معماری به آنها فکر کنید. ایده این است که در برخی از مفاهیم تجدید نظر شود که به شما کمک می کند تا نیاز به این رویکرد را زیر سوال ببرید.

1. خدمات ارتباطی

میکروسرویس ها خدماتی هستند که در یک دامنه خاص حضور دارند و به طور مستقل منتشر می شوند. سپس این سرویس‌ها می‌توانند از طریق API، کارگزاران سرویس یا سایر خدمات ارتباطی در معرض سایر خدمات قرار گیرند.

شکل 1 – میکروسرویس ها از طریق API

2. قابلیت استقرار مستقل

بسیاری قابلیت استقرار مستقل را مهمترین بخش میکروسرویس ها می دانند. استفاده از این مفهوم برای اعتبار سنجی برنامه هایی که به طور سست کوپل شده اند ضروری است. برای تأیید این مورد باید بتوان بدون نیاز به تغییر سایر سرویس‌های غیرمرتبط، تغییراتی در میکروسرویس ایجاد کرد.

شکل 2 – انتشار

3. به اشتراک گذاری پایگاه های داده

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

شکل 3 – پایگاه های داده

4. دامنه کسب و کار

با رویکرد میکروسرویس، هر میکروسرویس باید مستقل و سازماندهی شود تا به طور موثر امکان استقلال را فراهم کند. تکنیک‌های طراحی مانند معماری لایه‌ای، معماری پاک، طراحی مبتنی بر دامنه (DDD) و غیره. این رویکردها ممکن است به تیم‌ها اجازه دهد تا کد را با زمینه‌سازی مستقل به طور کارآمد ساختار دهند.

شکل 4 – دامنه کسب و کار

5. ارتباط با مشتری

با رشد کسب و کار و فرآیندهای درون یک سازمان، تمایل این است که تعداد خدمات نیز افزایش یابد. با این حال، مصرف‌کنندگان این میکروسرویس‌ها باید بتوانند به طور مؤثر ارتباط برقرار کنند یا با میکروسرویس برای شغل مورد نظر تماس بگیرند. چند استراتژی برای حل این مشکل وجود دارد. داشتن یک دروازه API یک استراتژی برای نمایش، نسخه و تکامل موثر میکروسرویس ها است.

شکل 5 – دروازه API

نتیجه

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

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

ریزسرویس ها زمانی موثر هستند که در سناریوهای مناسب مورد استفاده، برنامه ریزی و اجرا شوند، اما من همیشه تمایل دارم از خودم بپرسم که چرا میکروسرویس ها نه؟

منابع

1. Building Microservices: Designing Fine Grain Systems