الگو: معماری میکروسرویس

شما در حال توسعه یک برنامه سازمانی سمت سرور هستید. باید از انواع کلاینت‌های مختلف از جمله مرورگرهای دسکتاپ، مرورگرهای موبایل و برنامه‌های کاربردی تلفن همراه بومی پشتیبانی کند. این برنامه همچنین ممکن است یک API را برای اشخاص ثالث در معرض دید قرار دهد. همچنین ممکن است از طریق سرویس های وب یا واسطه پیام با سایر برنامه ها ادغام شود. برنامه درخواست ها (درخواست ها و پیام های HTTP) را با اجرای منطق تجاری مدیریت می کند. دسترسی به پایگاه داده؛ تبادل پیام با سیستم های دیگر؛ و یک پاسخ HTML/JSON/XML را برمی گرداند. اجزای منطقی مربوط به حوزه های عملکردی مختلف برنامه وجود دارد.

معماری استقرار برنامه چیست؟

نیروها

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

اعضای جدید تیم باید به سرعت سازنده شوند

برنامه باید به راحتی قابل درک و اصلاح باشد

شما می خواهید استقرار مداوم برنامه را تمرین کنید

شما باید چندین نمونه از برنامه را روی چندین ماشین اجرا کنید تا نیازهای مقیاس پذیری و در دسترس بودن را برآورده کنید.

شما می خواهید از فناوری های نوظهور (فریم ورک ها، زبان های برنامه نویسی و غیره) استفاده کنید.

راه حل

معماري را تعريف كنيد كه برنامه را به عنوان مجموعه‌اي از سرويس‌هاي مشاركت كننده به هم متصل مي‌كند. این رویکرد با محور Y مکعب مقیاس مطابقت دارد. هر سرویس عبارت است از:

بسیار قابل نگهداری و آزمایش - توسعه و استقرار سریع و مکرر را امکان پذیر می کند

به طور ضعیف با سایر سرویس ها همراه است - یک تیم را قادر می سازد تا اکثر اوقات به طور مستقل بر روی سرویس(های) خود کار کند بدون اینکه تحت تأثیر تغییرات سایر سرویس ها و بدون تأثیر بر سایر خدمات قرار گیرد.

به طور مستقل قابل استقرار - یک تیم را قادر می سازد تا سرویس خود را بدون نیاز به هماهنگی با سایر تیم ها مستقر کند

قابلیت توسعه توسط یک تیم کوچک - برای بهره وری بالا با اجتناب از ارتباطات بالای تیم های بزرگ ضروری است

سرویس ها با استفاده از پروتکل های همزمان مانند HTTP/REST یا پروتکل های ناهمزمان مانند AMQP ارتباط برقرار می کنند. خدمات می توانند مستقل از یکدیگر توسعه یافته و مستقر شوند. هر سرویس پایگاه داده خود را دارد تا از سرویس های دیگر جدا شود. سازگاری داده ها بین خدمات با استفاده از الگوی Saga حفظ می شود

برای کسب اطلاعات بیشتر در مورد ماهیت یک سرویس، لطفاً این مقاله را بخوانید :

مثال ها

برنامه تجارت الکترونیک ساختگی

بیایید تصور کنیم که در حال ساخت یک برنامه تجارت الکترونیک هستید که سفارشات مشتریان را می گیرد، موجودی و اعتبار موجود را تأیید می کند و آنها را ارسال می کند. این برنامه شامل چندین مؤلفه از جمله StoreFrontUI است که رابط کاربری را پیاده‌سازی می‌کند، همراه با برخی از خدمات پشتیبانی برای بررسی اعتبار، نگهداری موجودی و سفارش‌های حمل و نقل. برنامه شامل مجموعه ای از خدمات است.

لطفاً نمونه برنامه های توسعه یافته توسط کریس ریچاردسون را ببینید. این مثال‌ها در Github جنبه‌های مختلف معماری میکروسرویس را نشان می‌دهند.

زمینه حاصل

فواید

این راه حل دارای چندین مزیت است:

تحویل و استقرار مداوم برنامه های کاربردی بزرگ و پیچیده را امکان پذیر می کند.

قابلیت نگهداری بهبود یافته - هر سرویس نسبتاً کوچک است و بنابراین درک و تغییر آسان تر است

آزمایش پذیری بهتر - خدمات کوچکتر و سریعتر برای آزمایش هستند

قابلیت استقرار بهتر - خدمات را می توان به طور مستقل مستقر کرد

این به شما امکان می دهد تا تلاش های توسعه را حول تیم های متعدد و مستقل سازماندهی کنید. هر تیم (به اصطلاح دو پیتزا) مالک و مسئول یک یا چند سرویس است. هر تیم می‌تواند خدمات خود را مستقل از سایر تیم‌ها توسعه، آزمایش، استقرار و مقیاس‌بندی کند.

هر میکروسرویس نسبتاً کوچک است:

درک آن برای یک توسعه دهنده آسان تر است

IDE سریعتر باعث بهره وری توسعه دهندگان می شود

برنامه سریع‌تر شروع می‌شود، که باعث بهره‌وری توسعه‌دهندگان می‌شود و سرعت اجرای آن را افزایش می‌دهد

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

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

این راه حل دارای تعدادی اشکال است:

توسعه دهندگان باید با پیچیدگی اضافی ایجاد یک سیستم توزیع شده مقابله کنند:

توسعه دهندگان باید مکانیسم ارتباط بین سرویس را پیاده سازی کنند و با خرابی جزئی مقابله کنند

اجرای درخواست هایی که چندین سرویس را در بر می گیرند دشوارتر است

آزمایش تعامل بین سرویس ها دشوارتر است

اجرای درخواست هایی که چندین سرویس را در بر می گیرد نیازمند هماهنگی دقیق بین تیم ها است

ابزارهای توسعه‌دهنده/IDE بر روی ساخت برنامه‌های کاربردی یکپارچه متمرکز شده‌اند و پشتیبانی صریحی برای توسعه برنامه‌های کاربردی توزیع شده ارائه نمی‌کنند.

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

افزایش مصرف حافظه معماری میکروسرویس N نمونه‌های کاربردی یکپارچه را با نمونه‌های خدمات NxM جایگزین می‌کند. اگر هر سرویس در JVM (یا معادل) خود اجرا شود، که معمولاً برای جداسازی نمونه‌ها ضروری است، پس سربار M برابر تعداد زمان‌های اجرا JVM وجود دارد. علاوه بر این، اگر هر سرویس بر روی VM خود (به عنوان مثال EC2) اجرا شود، همانطور که در Netflix چنین است، سربار حتی بیشتر می شود.

مسائل زیادی وجود دارد که باید به آنها رسیدگی کنید.

چه زمانی از معماری میکروسرویس استفاده کنیم؟

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

چگونه اپلیکیشن را به سرویس ها تجزیه کنیم؟

چالش دیگر تصمیم گیری در مورد نحوه تقسیم سیستم به میکروسرویس ها است. این بسیار یک هنر است، اما تعدادی استراتژی وجود دارد که می تواند کمک کند:

تجزیه بر اساس قابلیت تجاری و تعریف خدمات مربوط به قابلیت های تجاری.

تجزیه بر اساس زیر دامنه طراحی دامنه محور.

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

با تعریف سرویسی که مسئول تمام عملیات موجودات/منابع از یک نوع معین است، توسط اسامی یا منابع تجزیه می شود. به عنوان مثال، یک سرویس حساب که مسئول مدیریت حساب های کاربری است.

در حالت ایده آل، هر سرویس باید تنها مجموعه کوچکی از مسئولیت ها را داشته باشد. (عمو) باب مارتین در مورد طراحی کلاس ها با استفاده از اصل مسئولیت واحد (SRP) صحبت می کند. SRP مسئولیت یک کلاس را به عنوان دلیلی برای تغییر تعریف می کند و بیان می کند که یک کلاس فقط باید یک دلیل برای تغییر داشته باشد. منطقی است که SRP را در طراحی سرویس نیز اعمال کنیم.

قیاس دیگری که به طراحی سرویس کمک می کند، طراحی ابزارهای یونیکس است. یونیکس تعداد زیادی ابزار کاربردی مانند grep، cat و find را ارائه می دهد. هر ابزار دقیقاً یک کار را انجام می دهد، اغلب به طور استثنایی، و در نظر گرفته شده است که با سایر ابزارها با استفاده از یک اسکریپت پوسته برای انجام کارهای پیچیده ترکیب شود.

چگونه یکپارچگی داده ها را حفظ کنیم؟

به منظور اطمینان از اتصال شل، هر سرویس پایگاه داده خاص خود را دارد. حفظ سازگاری داده‌ها بین سرویس‌ها یک چالش است، زیرا 2 مرحله تعهد / تراکنش‌های توزیع‌شده گزینه‌ای برای بسیاری از برنامه‌ها نیست. یک برنامه باید در عوض از الگوی Saga استفاده کند. یک سرویس زمانی یک رویداد را منتشر می کند که داده های آن تغییر کند. سایر سرویس ها آن رویداد را مصرف می کنند و داده های خود را به روز می کنند. راه‌های مختلفی برای به‌روزرسانی قابل اعتماد داده‌ها و انتشار رویدادها وجود دارد، از جمله منابع رویداد و فهرست تراکنش‌ها.

چگونه کوئری ها را پیاده سازی کنیم؟

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

ترکیب API و الگوهای تفکیک مسئولیت پرس و جوی فرمان (CQRS).

الگوهای مرتبط

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

الگوهای تجزیه

تجزیه بر اساس توانایی تجاری

تجزیه بر اساس زیر دامنه

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

الگوی API Gateway نحوه دسترسی مشتریان به خدمات در معماری میکروسرویس را تعریف می کند.

الگوهای کشف سمت مشتری و کشف سمت سرور برای هدایت درخواست‌های یک کلاینت به یک نمونه سرویس موجود در معماری میکروسرویس استفاده می‌شوند.

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

الگوهای Single Service per Host و Multiple Services Per Host دو استراتژی استقرار متفاوت هستند.

الگوهای نگرانی های متقابل: الگوی شاسی میکروسرویس و پیکربندی خارجی

الگوهای تست: تست مؤلفه خدمات و تست قرارداد یکپارچه سازی خدمات

مدار شکن

نشانه دسترسی

الگوهای مشاهده پذیری:

تجمیع گزارش

معیارهای کاربردی

ثبت حسابرسی

ردیابی توزیع شده

ردیابی استثنا

API بررسی سلامت

استقرار و تغییرات گزارش

الگوهای رابط کاربری:

ترکیب قطعه صفحه سمت سرور

ترکیب UI سمت مشتری

کاربردهای شناخته شده

اکثر وب سایت های مقیاس بزرگ از جمله نتفلیکس، آمازون و eBay از معماری یکپارچه به معماری میکروسرویس تکامل یافته اند.

نتفلیکس، که یک سرویس پخش ویدیوی بسیار محبوب است که تا 30 درصد از ترافیک اینترنت را بر عهده دارد، دارای معماری سرویس‌گرا در مقیاس بزرگ است. آنها روزانه بیش از یک میلیارد تماس با API پخش ویدیوی خود از بیش از 800 نوع دستگاه مختلف انجام می دهند. هر API هواداران را به طور متوسط ​​به شش تماس با سرویس های پشتیبان دعوت می کند.

Amazon.com در ابتدا یک معماری دو لایه داشت. به منظور مقیاس پذیری، آنها به معماری سرویس گرا متشکل از صدها سرویس پشتیبان مهاجرت کردند. چندین برنامه از جمله برنامه هایی که وب سایت Amazon.com و وب سرویس API را پیاده سازی می کنند، این خدمات را فراخوانی می کنند. برنامه وب سایت Amazon.com برای دریافت داده هایی که برای ساخت یک صفحه وب استفاده می شود، 100-150 سرویس را فراخوانی می کند.

سایت حراج ebay.com نیز از معماری یکپارچه به معماری سرویس گرا تبدیل شد. لایه برنامه از چندین برنامه مستقل تشکیل شده است. هر برنامه کاربردی منطق کسب و کار را برای یک حوزه عملکرد خاص مانند خرید یا فروش پیاده سازی می کند. هر برنامه از تقسیم محور X استفاده می کند و برخی از برنامه ها مانند جستجو از تقسیم محور Z استفاده می کنند. Ebay.com همچنین ترکیبی از مقیاس بندی X-، Y- و Z-style را در ردیف پایگاه داده اعمال می کند.

نمونه های متعدد دیگری از شرکت هایی وجود دارد که از معماری میکروسرویس استفاده می کنند.