یک برنامه کاربردی میکروسرویس گرا طراحی کنید قسمت دوم

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

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

هر میکروسرویس نسبتاً کوچک است - مدیریت و تکامل آن آسان است. به طور مشخص:

• درک و شروع سریع با بهره وری خوب برای یک توسعه دهنده آسان است.

• کانتینرها سریع شروع می شوند، که باعث می شود توسعه دهندگان بهره وری بیشتری داشته باشند.

• یک IDE مانند ویژوال استودیو می تواند پروژه های کوچکتر را سریع بارگذاری کند و توسعه دهندگان را سازنده کند.

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

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

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

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

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

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

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

برنامه توزیع شده توزیع برنامه پیچیدگی را برای توسعه دهندگان در هنگام طراحی و ساخت سرویس ها اضافه می کند. به عنوان مثال، توسعه دهندگان باید ارتباطات بین سرویسی را با استفاده از پروتکل هایی مانند HTTP یا AMPQ پیاده سازی کنند، که پیچیدگی آزمایش و مدیریت استثنا را اضافه می کند. همچنین تاخیر را به سیستم اضافه می کند.

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

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

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

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

یکی دیگر از مشکلات ارتباط مستقیم مشتری به میکروسرویس این است که برخی از میکروسرویس ها ممکن است از پروتکل هایی استفاده کنند که وب پسند نیستند. یک سرویس ممکن است از یک پروتکل باینری استفاده کند، در حالی که سرویس دیگر ممکن است از پیام رسانی AMQP استفاده کند. این پروتکل ها فایروال پسند نیستند و بهتر است به صورت داخلی استفاده شوند. معمولاً یک برنامه باید از پروتکل هایی مانند HTTP و WebSockets برای ارتباط خارج از فایروال استفاده کند.

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

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

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

الگوهای معماری و طراحی خارجی در مقابل داخلی

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

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

یکی دیگر از دلایل تکنولوژی متفاوت در هر میکروسرویس ممکن است ماهیت هر میکروسرویس باشد. به عنوان مثال، بهتر است به جای زبان برنامه نویسی شی گرا مانند سی شارپ، از یک زبان برنامه نویسی کاربردی مانند F# یا حتی زبانی مانند R اگر حوزه های هوش مصنوعی و یادگیری ماشین را هدف قرار می دهید، استفاده کنید.

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

دنیای جدید: الگوهای معماری متعدد و ریزسرویس های چند زبانه

الگوهای معماری زیادی توسط معماران و توسعه دهندگان نرم افزار استفاده می شود. موارد زیر به چند مورد (ترکیب سبک های معماری و الگوهای معماری) اشاره شده است:

• CRUD ساده، تک لایه، تک لایه.

• سنتی N-Layered.

• طراحی دامنه محور N-layered.

• معماری پاک (همانطور که با eShopOnWeb استفاده می شود)

• تفکیک مسئولیت فرمان و پرس و جو (CQRS).

• معماری رویداد محور (EDA).

شما همچنین می‌توانید میکروسرویس‌ها را با فناوری‌ها و زبان‌های بسیاری مانند ASP.NET Core Web API، NancyFx، ASP.NET Core SignalR (در دسترس با .NET Core 2 یا جدیدتر)، F#، Node.js، Python، Java، C++، بسازید. GoLang، و بیشتر.

نکته مهم این است که هیچ الگو یا سبک معماری خاصی و نه فناوری خاصی برای همه شرایط مناسب نیست.

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

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

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

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