میکروسرویس چیست؟

1. مقدمه

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

منبع:

https://www.ibm.com/cloud/learn/microservices

2. میکروسرویس چیست؟

میکروسرویس (یا معماری میکروسرویس) یک رویکرد معماری بومی ابری است که در آن یک برنامه واحد از بسیاری از اجزای کوچکتر یا خدمات کوچک به هم پیوسته و مستقل استفاده میکند. این خدمات به طور معمول دارای

• Stack خاص خود ، شامل پایگاه داده و مدل مدیریت داده است.
• با یکدیگر از طریق ترکیبی از API های REST ، event streaming و message brokers ارتباط برقرار میکنند.
• با قابلیت کسب و کاری سازماندهی میشوند.

در حالی که بسیاری از بحث ها در مورد میکروسرویس در مورد تعاریف و ویژگی های معماری بوده است، ارزش آنها را میتوان بیشتر از طریق مزایای نسبتاً ساده تجاری و سازمانی درک کرد:

• کد را می توان راحت تر به روز کرد. ویژگی ها یا قابلیت های جدید را می توان بدون تغییر کل برنامه اضافه کرد.
• تیم ها میتوانند از پشتههای مختلف و زبان های برنامه نویسی مختلف برای اجزای مختلف استفاده کنند.
• اجزاء را میتوان مستقل از یکدیگر مقیاس بندی کرد. اتلاف و هزینه مربوط به مقیاس بندی کل برنامهها را کاهش داد ، زیرا ممکن است یک ویژگی واحد با بار زیادی روبرو شود.

همچنین ممکن است میکروسرویس با آنچه نیستند بهتر توضیح داده شوند. دو مقایسه ای که بیشتر با معماری میکروسرویس انجام میشود معماری یکپارچه و معماری سرویس گرا (SOA) است.

• تفاوت بین میکروسرویس و معماری یکپارچه در این است که میکروسرویس یک برنامه کاربردی واحد از بسیاری از سرویس های کوچکتر و به هم پیوسته تشکیل میشود ، برخلاف رویکرد یکپارچه که یک برنامه بزرگ و محکم و درهم تنیده است. برای اطلاعات بیشتر در مورد تفاوت بین میکروسرویس ها و معماری یکپارچه، این ویدیو را تماشا کنید:
• تفاوت بین میکروسرویس ها و SOA می تواند کمی واضح تر باشد. در حالی که تضادهای فنی را میتوان بین میکروسرویس ها و SOA ترسیم کرد، به خصوص در مورد نقش گذرگاه خدمات سازمانی (ESB) ساده تر است که تفاوت را به عنوان یکی از دامنه ها در نظر بگیریم. SOA یک تلاش گسترده سازمانی برای استاندارد کردن روشی بود که تمام سرویس‌های وب در یک سازمان با یکدیگر صحبت می‌کنند و با یکدیگر ادغام می‌شوند، در حالی که معماری میکروسرویس‌ها مختص برنامه‌های کاربردی است.

مقاله "SOA در مقابل میکروسرویس ها: تفاوت چیست؟" وارد جزئیات بیشتر می شود.

3. چگونه میکروسرویس ها برای سازمان سودمند هستند

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

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

منبع:  'Microservices in the enterprise 2021: Real benefits, worth the challenges.'

در اینجا فقط چند مورد از مزایای سازمانی میکروسرویسها آورده شده است.

1. به طور مستقل قابل استقرار

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

میکروسرویس ها به سازمان ها قول میدهند که پادزهری برای ناامیدی های مرتبط با تغییرات کوچک که زمان زیادی را صرف میکند، داشته باشند. همچنین نیازی به دکترای علوم کامپیوتر برای دیدن یا درک ارزش رویکردی که سرعت و چابکی را بهتر تسهیل میکند، نداشته باشند.

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

میکروسرویس ها همچنین درجه خوبی از ایزوله سازی خطا و انعطاف پذیری بهتر را در برنامه ها ایجاد میکند. اندازه کوچک خدمات، همراه با مرزها و الگوهای ارتباطی واضح بین آنها، درک کدهای پایه و کمک سریع به آن را برای اعضای تیم جدید آسان‌تر می‌کند. (یک مزیت واضح از نظر سرعت و روحیه کارکنان)

2. ابزار مناسب برای کار

در الگوهای معماری سنتی n-tier، یک برنامه کاربردی معمولاً یک stack مشترک با یک پایگاه داده بزرگ و رابطه ای که از کل برنامه پشتیبانی می کند، به اشتراک میگذارد. این رویکرد چندین اشکال آشکار دارد که مهمترین آنها این است که هر جزء از یک برنامه کاربردی باید (حتی اگر ابزار واضح و بهتری برای کار برای مولفه خاص وجود داشته باشد) یک پشته، مدل داده و پایگاه داده مشترک داشته باشد،. این باعث ایجاد معماری بد میشود، و برای توسعه دهندگانی که دائماً از وجود راه حل بهتر و کارآمدتر برای ساخت این مؤلفه ها آگاه هستند، خسته کننده است.

در مقابل، در یک مدل میکروسرویس، مؤلفه‌ها به‌طور مستقل مستقر می‌شوند و از طریق ترکیبی از REST، جریان رویداد و واسطه‌های پیام ارتباط برقرار می‌کنند. بنابراین این امکان وجود دارد که stack هر سرویس جداگانه برای آن سرویس بهینه شود. فناوری دائماً تغییر می‌کند و برنامه‌ای که از چندین سرویس کوچکتر تشکیل شده باشد، با در دسترس شدن فناوری مطلوب‌تر، بسیار آسان‌تر و کم‌هزینه‌تر است.

3. مقیاس بندی دقیق

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

4. چالش هایی نیز وجود دارد

مزایای قابل توجه میکروسرویس ها با چالش های قابل توجهی همراه است. حرکت از مدل یکپارچه به مدل میکروسرویسها به معنای پیچیدگی مدیریتی بسیار بیشتری است. (خدمات بسیار بیشتری که توسط تیم های بسیار بیشتری ایجاد شده و در مکان های بسیار بیشتری مستقر شده اند.) مشکلات در یک سرویس می تواند باعث بروز مشکلاتی در سرویس های دیگر و یا ناشی از آن باشد. داده‌های ثبت‌نام (که برای نظارت و حل مشکل استفاده می‌شود) حجم بیشتری دارد و می‌تواند در بین سرویس‌ها ناسازگار باشد. نسخه های جدید می توانند مشکلات سازگاری با عقب را ایجاد کنند. برنامه‌ها شامل اتصالات شبکه بیشتری می‌شوند، که به معنای فرصت‌های بیشتر برای تأخیر و مشکلات اتصال است. رویکرد DevOps همانطور که در زیر خواهید خواند، می تواند بسیاری از این مسائل را برطرف کند، اما پذیرش DevOps چالش های خاص خود را دارد.

با این وجود، این چالش‌ها باعث نمی‌شود افراد غیرمتخصص از پذیرش میکروسرویس‌ها (یا پذیرندگان از تعمیق تعهدات میکروسرویس‌ها) جلوگیری کنند. داده‌های نظرسنجی جدید آی‌بی‌ام نشان می‌دهد که 56 درصد از غیرکاربران فعلی احتمالاً یا به احتمال زیاد در طی دو سال آینده از ریزسرویس‌ها استفاده می‌کنند و 78 درصد از کاربران فعلی میکروسرویس‌ها احتمالاً زمان، پول و تلاشی را که در میکروسرویس‌ها سرمایه‌گذاری کرده‌اند افزایش خواهند داد. شکل 1 را ببینید).

شکل 1: میکروسرویس ها اینجا هستند تا بمانند. در طی دو سال آینده، 56 درصد از غیرکاربران احتمالاً میکروسرویس ها را اتخاذ خواهند کرد، 78 درصد از کاربران سرمایه گذاری خود را در میکروسرویس ها افزایش خواهند داد و 59 درصد برنامه های کاربردی تخفیف با میکروسرویس ها ایجاد خواهند شد. (منبع: "سرویس های خرد در سازمان 2021: مزایای واقعی، ارزش چالش ها را دارد.")

4. میکروسرویس ها هم DevOps را فعال می کنند و هم به آن نیاز دارند

معماری میکروسرویس‌ها اغلب به‌عنوان بهینه‌سازی شده برای DevOps و یکپارچه‌سازی مداوم/تحویل پیوسته (CI/CD) توصیف می‌شود. همچنین درک دلیل آن در زمینه سرویس‌های کوچکی که می‌توانند مکرراً توسعه داده شوند، آسان است.

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

آندریا کرافورد در ویدیوی زیر به بررسی عمیق‌تر DevOps می‌پردازد:

5. فناوری‌ها و ابزارهای کلیدی توانمندساز

در حالی که تقریباً هر ابزار یا زبان مدرنی را می توان در معماری میکروسرویس استفاده کرد، تعداد انگشت شماری از ابزارهای اصلی وجود دارند که برای میکروسرویس ها ضروری و مرزی شده اند:

1. Containers, Docker, Kubernetes

یکی از عناصر کلیدی یک میکروسرویس این است که به طور کلی بسیار کوچک است. (هیچ مقدار دلخواه کدی وجود ندارد که تعیین کند چیزی یک میکروسرویس است یا نه، اما micro دقیقاً در نام آن وجود دارد.)

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

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

در ویدئوی Kubernetes Explained ، سای ونام نمای جامعی از همه چیزهای Kubernetes ارائه می دهد:

2. API Gateway

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

فناوری‌های متعددی وجود دارد که می‌توان از آنها برای پیاده‌سازی دروازه‌های API استفاده کرد، از جمله پلتفرم‌های مدیریت API، اما اگر معماری میکروسرویس‌ها با استفاده از کانتینرها و Kubernetes پیاده‌سازی شود، دروازه معمولاً با استفاده از Ingress یا اخیراً Istio پیاده‌سازی می‌شود.

3. پیام رسانی و جریان رویداد

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

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

4. بدون سرور (Serverless)

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

جایی که ساختارهای بدون سرور و پلتفرم‌های توابع به‌عنوان سرویس (FaaS) با میکروسرویس‌ها شباهت دارند، این است که هر دو علاقه‌مند به ایجاد واحدهای کوچک‌تر از استقرار و مقیاس‌بندی دقیق با تقاضا هستند.

6. میکروسرویس و خدمات ابری

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

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

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

7. الگوهای رایج

در معماری میکروسرویس‌ها، الگوهای طراحی، ارتباطات و یکپارچه‌سازی مشترک و مفید بسیاری وجود دارد که به رفع برخی از چالش‌ها و فرصت‌های رایج‌تر کمک می‌کند، از جمله موارد زیر:

1. الگوی Backend-for-frontend (BFF)

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

2. موجودیتها و الگوهای تجیعی

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

3. الگوهای کشف سرویس

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

4. الگوهای میکروسرویس آداپتور

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

5. الگوی کاربردی Strangler

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

می توانید در لینک «نحوه استفاده از الگوهای توسعه با میکروسرویس ها (قسمت 4)» درباره این الگوها بیشتر بدانید. اگر می خواهید در مورد سایر الگوهای کد میکروسرویس ها بیاموزید، برنامه نویس IBM نیز اطلاعات زیادی را ارائه می دهد.

8. ضد الگوها

در حالی که الگوهای زیادی برای انجام خوب ریزسرویس ها وجود دارد، تعداد قابل توجهی از الگوها وجود دارد که می تواند به سرعت هر تیم توسعه را با مشکل مواجه کند. برخی از این موارد - که به عنوان میکروسرویس‌ها «نمی‌شود» تعریف می‌شوند - به شرح زیر است:

1. اولین قانون میکروسرویس ها این است که میکروسرویس ها را ایجاد نکنید

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

2. ریزسرویس‌ها را بدون DevOps یا خدمات ابری انجام ندهید

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

3. ریزسرویس‌های را با کوچک‌کردن آن‌ها زیاد نکنید

اگر با «میکرو» در میکروسرویس‌ها زیاده روی کنید، به راحتی می‌توانید با سربار و پیچیدگی مواجه شوید که از دستاوردهای کلی معماری میکروسرویس بیشتر است. بهتر است به سمت سرویس‌های بزرگ‌تر متمایل شوید و تنها زمانی آنها را از هم جدا کنید که ویژگی‌هایی را ایجاد کنند که میکروسرویس‌ها آن‌ها را حل می‌کنند – یعنی اینکه اجرای تغییرات سخت و کند می‌شود، یک مدل داده مشترک بیش از حد پیچیده می‌شود، یا اینکه بخش‌های مختلف خدمات نیازهای بار/مقیاس متفاوتی دارند.

4. میکروسرویس‌ها را به SOA تبدیل نکنید

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

5. سعی نکنید نتفلیکس باشید

نتفلیکس یکی از پیشگامان اولیه معماری میکروسرویس ها هنگام ساخت و مدیریت برنامه ای بود که یک سوم کل ترافیک اینترنت را به خود اختصاص می داد - نوعی طوفان کامل که آنها را ملزم به ساخت تعداد زیادی کد سفارشی کرد. خدماتی که برای برنامه متوسط ​​غیر ضروری هستند. خیلی بهتر است با سرعتی که می توانید شروع کنید، از پیچیدگی اجتناب کنید و تا آنجا که ممکن است از ابزارهای آماده استفاده کنید.