سلام هابر امروز من یک سری از انتشاراتی را که به طور خاص برای شروع یک جریان جدید از دوره نوشتم ادامه می دهم. .
معرفی
انتخاب سبک معماری یکی از تصمیمات فنی اساسی در هنگام ساخت یک سیستم اطلاعاتی است. در این سری از مقالات، من پیشنهاد می کنم محبوب ترین سبک های معماری برای کاربردهای ساختمانی را تجزیه و تحلیل کنیم و به این سوال پاسخ دهیم که چه زمانی سبک معماری بیشتر ترجیح داده می شود. در روند ارائه، من سعی خواهم کرد یک زنجیره منطقی ترسیم کنم که توسعه سبک های معماری از یکپارچه تا میکروسرویس را توضیح می دهد.
آخرین بار در مورد انواع مختلف یکپارچه ها و استفاده از کامپوننت ها برای ساخت آنها صحبت کردیم، هم اجزای ساخت و هم اجزای استقرار. ما معماری سرویس گرا را درک می کنیم.
حال در نهایت ویژگی های اصلی یک معماری میکروسرویس را تعریف می کنیم.
رابطه معماری ها
درک این نکته ضروری است که بر اساس تعاریف ارائه شده در مقالات قبلی، هر سرویسی یک جزء است، اما هر سرویسی یک میکروسرویس نیست.
ویژگی های معماری میکروسرویس
ویژگی های اصلی معماری میکروسرویس عبارتند از:
- سازماندهی شده پیرامون قابلیت های تجاری
- محصولات نه پروژه ها
- نقاط انتهایی هوشمند و لوله های گنگ
- حکومت غیرمتمرکز
- مدیریت غیرمتمرکز داده
- اتوماسیون زیرساخت
- طراحی برای شکست
- معماری با توسعه تکاملی (Evolutionary Design)
نکته اول از معماری سرویس گرا ناشی می شود زیرا میکروسرویس ها مورد خاصی از خدمات هستند. سایر نکات قابل بررسی جداگانه هستند.
سازماندهی شده پیرامون قابلیت های تجاری
اکنون لازم است قانون کانوی را به خاطر بسپاریم: سازمان‌هایی که سیستم‌هایی را ایجاد می‌کنند، معماری آن را سازماندهی می‌کنند و ساختار تعامل درون این سازمان‌ها را کپی می‌کنند. به عنوان مثال، می‌توانیم مورد ایجاد یک کامپایلر را به خاطر بیاوریم: یک تیم هفت نفره یک کامپایلر هفت پاسی و یک تیم پنج نفره یک کامپایلر پنج پاسی را توسعه دادند.
اگر در مورد یکپارچه‌ها و ریزسرویس‌ها صحبت می‌کنیم، اگر توسعه توسط بخش‌های عملکردی (باطن، فرانت‌اند، مدیران پایگاه‌داده) سازماندهی شود، یک مونولیت کلاسیک دریافت می‌کنیم.
برای به دست آوردن میکروسرویس ها، تیم ها باید بر اساس قابلیت های تجاری (سفارش ها، ارسال ها، تیم کاتالوگ) سازماندهی شوند. این سازمان به تیم ها اجازه می دهد تا بر ساخت بخش های خاصی از برنامه تمرکز کنند.
محصولات نه پروژه ها
رویکرد پروژه ای که در آن یک تیم عملکرد توسعه یافته را به تیم های دیگر منتقل می کند در مورد معماری میکروسرویس کاملاً نامناسب است. تیم باید از سیستم در طول چرخه عمر آن پشتیبانی کند. آمازون، یکی از رهبران در اجرای میکروسرویس ها، اظهار داشت: "شما می سازید، شما آن را اجرا می کنید." رویکرد محصول به تیم اجازه می دهد تا نیازهای کسب و کار را احساس کند.
نقاط انتهایی هوشمند و لوله های گنگ
معماری SOA توجه زیادی به کانال‌های ارتباطی، به‌ویژه گذرگاه خدمات سازمانی داشت. که اغلب منجر به جعبه اسپاگتی اشتباه می شود، یعنی پیچیدگی یکپارچه به پیچیدگی ارتباطات بین خدمات تبدیل می شود. معماری میکروسرویس تنها از روش های ارتباطی ساده استفاده می کند.
حکومت غیرمتمرکز
تصمیمات کلیدی در مورد میکروسرویس ها باید توسط افرادی گرفته شود که در واقع میکروسرویس ها را توسعه می دهند. در اینجا، تصمیمات کلیدی به معنای انتخاب است
زبان های برنامه نویسی، روش استقرار، قراردادهای رابط عمومی و غیره.
مدیریت غیرمتمرکز داده
رویکرد استاندارد، که در آن برنامه کاربردی بر یک پایگاه داده واحد تکیه می کند، نمی تواند ویژگی های هر سرویس خاص را در نظر بگیرد. MSA شامل مدیریت غیرمتمرکز داده، از جمله استفاده از فناوری های مختلف است.
اتوماسیون زیرساخت
MSA از فرآیندهای استقرار و تحویل مداوم پشتیبانی می کند. این امر تنها با خودکارسازی فرآیندها قابل دستیابی است. در عین حال، استقرار تعداد زیادی از خدمات دیگر چیزی ترسناک به نظر نمی رسد. فرآیند استقرار باید خسته کننده شود. جنبه دوم به مدیریت خدمات در محیط محصول مربوط می شود. بدون اتوماسیون، مدیریت فرآیندهای در حال اجرا در محیط‌های عملیاتی مختلف غیرممکن می‌شود.
طراحی برای شکست
بسیاری از خدمات MSA مستعد شکست هستند. در عین حال، رسیدگی به خطا در یک سیستم توزیع شده یک کار بی اهمیت نیست. معماری برنامه باید در برابر چنین شکست هایی مقاوم باشد. ربکا پارسونز فکر می کند بسیار مهم است که ما دیگر حتی از ارتباطات درون فرآیندی بین سرویس ها استفاده نکنیم؛ در عوض، برای ارتباط به HTTP متوسل می شویم که تقریباً قابل اعتماد نیست.
معماری با توسعه تکاملی (Evolutionary Design)
معماری سیستم MSA باید به صورت تکاملی توسعه یابد. توصیه می شود تغییرات لازم را به مرزهای یک سرویس محدود کنید. تأثیر آن بر سایر خدمات نیز باید در نظر گرفته شود. رویکرد سنتی تلاش برای حل این مشکل با نسخه‌سازی است، اما MSA پیشنهاد می‌کند از نسخه‌سازی در داخل استفاده کنید
به عنوان آخرین چاره.
نتیجه
پس از تمام موارد فوق، می توانیم فرمول بندی کنیم که میکروسرویس ها چیست. معماری میکروسرویس رویکردی برای توسعه یک برنامه کاربردی به عنوان مجموعه‌ای از سرویس‌های کوچک است که هر کدام در فرآیند خاص خود اجرا می‌شوند و از طریق مکانیسم‌های سبک وزن، اغلب یک API منبع HTTP، در تعامل هستند. این سرویس‌ها بر اساس قابلیت‌های تجاری ساخته شده‌اند و می‌توانند به‌طور مستقل و با استفاده کامل به کار گرفته شوند
مکانیزم استقرار خودکار حداقل سطح مدیریت متمرکز این سرویس ها وجود دارد که می تواند به زبان های برنامه نویسی مختلف نوشته شود و از فناوری های مختلف ذخیره سازی داده ها استفاده کند.
منبع: www.habr.com