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

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

مشخصات اپلیکیشن

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

برنامه شامل این نوع اجزا خواهد بود:

اجزای ارائه این مؤلفه‌ها مسئول مدیریت رابط کاربری و مصرف سرویس‌های راه دور هستند.

منطق دامنه یا تجارت این جزء منطق دامنه برنامه است.

منطق دسترسی به پایگاه داده این مؤلفه شامل اجزای دسترسی به داده است که مسئول دسترسی به پایگاه های داده (SQL یا NoSQL) هستند.

منطق یکپارچه سازی برنامه این جزء شامل یک کانال پیام رسانی است که بر اساس کارگزاران پیام است.

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

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

زمینه تیم توسعه
ما همچنین موارد زیر را در مورد فرآیند توسعه برنامه فرض می کنیم:

چندین تیم توسعه دهنده دارید که بر روی حوزه های مختلف تجاری برنامه تمرکز می کنند.

اعضای تیم جدید باید به سرعت سازنده شوند و برنامه باید به راحتی قابل درک و اصلاح باشد.

این برنامه دارای یک تکامل طولانی مدت و قوانین تجاری دائما در حال تغییر خواهد بود.

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

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

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

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

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

میکروسرویس ها با استفاده از پروتکل هایی مانند HTTP (REST) ​​و همچنین به صورت ناهمزمان (مثلاً با استفاده از AMQP) در صورت امکان ارتباط برقرار می کنند، به خصوص هنگام انتشار به روز رسانی با رویدادهای یکپارچه سازی.

میکروسرویس ها به صورت کانتینر مستقل از یکدیگر توسعه یافته و مستقر می شوند. این رویکرد به این معنی است که یک تیم توسعه می‌تواند یک میکروسرویس خاص را بدون تأثیر بر سایر زیرسیستم‌ها توسعه و استقرار دهد.

هر میکروسرویس پایگاه داده مخصوص به خود را دارد که به آن اجازه می دهد تا به طور کامل از سایر میکروسرویس ها جدا شود. در صورت لزوم، سازگاری بین پایگاه‌های داده از میکروسرویس‌های مختلف با استفاده از رویدادهای یکپارچه‌سازی در سطح برنامه (از طریق یک گذرگاه رویداد منطقی)، همانطور که در Command and Query Responsibility Segregation (CQRS) انجام می‌شود، به دست می‌آید. به همین دلیل، محدودیت‌های تجاری باید سازگاری نهایی بین ریزسرویس‌های متعدد و پایگاه‌های داده مرتبط را در بر گیرند.

eShopOnContainers: یک برنامه مرجع برای دات نت و میکروسرویس هایی که با استفاده از کانتینرها مستقر شده اند.
برای اینکه بتوانید به جای فکر کردن در مورد یک دامنه تجاری فرضی که ممکن است ندانید، بر روی معماری و فناوری تمرکز کنید، ما یک دامنه تجاری شناخته شده را انتخاب کرده ایم - یعنی یک برنامه تجارت الکترونیکی ساده شده (فروشگاه الکترونیکی) که ارائه می کند کاتالوگ محصولات، سفارشات مشتریان را می گیرد، موجودی را تأیید می کند و سایر وظایف تجاری را انجام می دهد. این کد منبع برنامه مبتنی بر کانتینر در مخزن eShopOnContainers GitHub موجود است.

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

برنامه erence

نمودار برنامه های مشتری با استفاده از eShopOnContainers در یک میزبان Docker.

شکل 6-1. معماری برنامه eShopOnContainers برای محیط توسعه مرجع است

نمودار بالا نشان می‌دهد که کلاینت‌های موبایل و SPA با یک نقطه پایانی دروازه API و سپس با میکروسرویس‌ها ارتباط برقرار می‌کنند. کلاینت های وب سنتی با میکروسرویس MVC ارتباط برقرار می کنند که از طریق دروازه API با میکروسرویس ها ارتباط برقرار می کند.

محیط میزبانی. در شکل 6-1، چندین کانتینر را می بینید که در یک میزبان Docker مستقر شده اند. این مورد در هنگام استقرار در یک میزبان Docker با دستور docker-compose up صدق می کند. با این حال، اگر از یک ارکستراتور یا کانتینر کلاستر استفاده می‌کنید، هر کانتینر می‌تواند در میزبان (گره) متفاوتی اجرا شود، و هر گره می‌تواند هر تعداد کانتینر را اجرا کند، همانطور که قبلا در بخش معماری توضیح دادیم.

معماری ارتباطات برنامه eShopOnContainers بسته به نوع عملکرد عملکردی (پرسش‌ها در مقابل به‌روزرسانی‌ها و تراکنش‌ها) از دو نوع ارتباط استفاده می‌کند:

ارتباط مشتری به میکروسرویس Http از طریق دروازه های API. این رویکرد برای پرس و جوها و هنگام پذیرش دستورات به روز رسانی یا تراکنش از برنامه های مشتری استفاده می شود. روش استفاده از API Gateways در بخش های بعدی به تفصیل توضیح داده شده است.

ارتباطات ناهمزمان مبتنی بر رویداد. این ارتباط از طریق یک گذرگاه رویداد برای انتشار به‌روزرسانی‌ها در میکروسرویس‌ها یا ادغام با برنامه‌های خارجی انجام می‌شود. گذرگاه رویداد را می توان با هر فناوری زیرساخت واسطه پیام رسانی مانند RabbitMQ یا با استفاده از اتوبوس های خدمات سطح بالاتر (سطح انتزاعی) مانند Azure Service Bus، NServiceBus، MassTransit یا Brighter پیاده سازی کرد.

این برنامه به عنوان مجموعه ای از میکروسرویس ها در قالب کانتینرها مستقر شده است. برنامه های سرویس گیرنده می توانند با آن میکروسرویس هایی که به صورت کانتینر اجرا می شوند از طریق URL های عمومی منتشر شده توسط API Gateways ارتباط برقرار کنند.

حاکمیت داده در هر میکروسرویس
در برنامه نمونه، هر میکروسرویس پایگاه داده یا منبع داده خود را دارد، اگرچه همه پایگاه‌های داده SQL Server به عنوان یک ظرف واحد مستقر شده‌اند. این تصمیم طراحی تنها به این دلیل گرفته شد که برنامه‌نویس به راحتی کد را از GitHub دریافت کند، آن را شبیه‌سازی کند و آن را در Visual Studio یا Visual Studio Code باز کند. یا متناوبا، کامپایل کردن تصاویر سفارشی Docker را با استفاده از NET CLI و Docker CLI، و سپس استقرار و اجرای آنها در یک محیط توسعه Docker را آسان می کند. در هر صورت، استفاده از کانتینرها برای منابع داده به توسعه دهندگان این امکان را می دهد که در عرض چند دقیقه بدون نیاز به ارائه یک پایگاه داده خارجی یا هر منبع داده دیگری با وابستگی سخت به زیرساخت (ابر یا درون محل) بسازند و مستقر کنند.

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

بنابراین، واحدهای استقرار میکروسرویس ها (و حتی برای پایگاه های داده در این برنامه) کانتینرهای Docker هستند و برنامه مرجع یک برنامه کاربردی چند کانتینری است که اصول میکروسرویس ها را در بر می گیرد.

منابع اضافی
eShopOnContainers مخزن GitHub. کد منبع برای برنامه مرجع
https://aka.ms/eShopOnContainers/
مزایای یک راه حل مبتنی بر میکروسرویس
راه حل مبتنی بر میکروسرویس مانند این مزایای بسیاری دارد:

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

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

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

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

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

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

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

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

می توانید از آخرین فناوری ها استفاده کنید. زیرا

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

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

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

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

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