برنامه فرضی درخواست ها را با اجرای منطق تجاری، دسترسی به پایگاه های داده و سپس برگرداندن پاسخ های HTML، JSON یا XML انجام می دهد. می گوییم که برنامه باید از کلاینت های مختلفی پشتیبانی کند، از جمله مرورگرهای دسکتاپ که دارای برنامه های کاربردی یک صفحه (SPAs)، برنامه های وب سنتی، برنامه های وب تلفن همراه و برنامه های موبایل بومی هستند. این برنامه همچنین ممکن است یک API را در معرض مصرف اشخاص ثالث قرار دهد. همچنین باید بتواند میکروسرویس ها یا برنامه های کاربردی خارجی خود را به صورت ناهمزمان ادغام کند، به طوری که این رویکرد به انعطاف پذیری میکروسرویس ها در صورت خرابی های جزئی کمک می کند.
برنامه از این نوع اجزا تشکیل شده است:
این برنامه به مقیاس پذیری بالایی نیاز دارد، در حالی که به زیرسیستم های عمودی خود اجازه می دهد تا به طور مستقل مقیاس شوند، زیرا زیرسیستم های خاصی نسبت به سایرین به مقیاس پذیری بیشتری نیاز دارند.
برنامه باید بتواند در محیط‌های زیرساختی متعدد (چندین ابر عمومی و در محل) مستقر شود و در حالت ایده‌آل باید بین پلتفرمی باشد و بتواند به راحتی از لینوکس به ویندوز (یا بالعکس) حرکت کند.
ما همچنین موارد زیر را در مورد فرآیند توسعه برنامه فرض می کنیم:
معماری استقرار برنامه چگونه باید باشد؟ مشخصات برنامه، همراه با زمینه توسعه، قویاً نشان می‌دهد که باید برنامه را با تجزیه آن به زیرسیستم‌های مستقل در قالب میکروسرویس‌ها و کانتینرهای مشترک، طراحی کنید، جایی که میکروسرویس یک کانتینر است.
در این رویکرد، هر سرویس (کانتینر) مجموعه ای از توابع منسجم و مرتبط با هم را پیاده سازی می کند. به عنوان مثال، یک برنامه ممکن است از خدماتی مانند سرویس کاتالوگ، سرویس سفارش، خدمات سبد خرید، خدمات نمایه کاربر و غیره تشکیل شده باشد.
میکروسرویس ها با استفاده از پروتکل هایی مانند HTTP (REST) و همچنین به صورت ناهمزمان (مثلاً با استفاده از AMQP) در صورت امکان ارتباط برقرار می کنند، به خصوص هنگام انتشار به روز رسانی با رویدادهای یکپارچه سازی.
میکروسرویس ها به صورت کانتینر مستقل از یکدیگر توسعه یافته و مستقر می شوند. این رویکرد به این معنی است که یک تیم توسعه می‌تواند یک میکروسرویس خاص را بدون تأثیر بر سایر زیرسیستم‌ها توسعه و استقرار دهد.
هر میکروسرویس پایگاه داده مخصوص به خود را دارد که به آن امکان جداسازی کامل از سایر میکروسرویس ها را می دهد. در صورت لزوم، سازگاری بین پایگاه‌های داده از میکروسرویس‌های مختلف با استفاده از رویدادهای یکپارچه‌سازی در سطح برنامه (از طریق یک گذرگاه رویداد منطقی)، همانطور که در Command and Query Responsibility Segregation (CQRS) انجام می‌شود، به دست می‌آید. به همین دلیل، محدودیت‌های تجاری باید سازگاری نهایی بین ریزسرویس‌های متعدد و پایگاه‌های داده مرتبط را در بر گیرند.
برای اینکه بتوانید به جای فکر کردن در مورد یک دامنه تجاری فرضی که ممکن است ندانید، بر روی معماری و فناوری تمرکز کنید، ما یک دامنه تجاری شناخته شده را انتخاب کرده ایم - یعنی یک برنامه تجارت الکترونیکی ساده (فروشگاه الکترونیکی) که ارائه می کند. کاتالوگ محصولات، سفارشات مشتریان را می گیرد، موجودی را تأیید می کند و سایر وظایف تجاری را انجام می دهد. این کد منبع برنامه مبتنی بر کانتینر در مخزن eShopOnContainers GitHub موجود است.
این برنامه از چندین زیرسیستم، از جمله چندین بخش جلویی رابط کاربری فروشگاه (یک برنامه وب و یک برنامه تلفن همراه بومی)، به همراه ریزسرویس‌های پشتیبان و کانتینرها برای تمام عملیات مورد نیاز سمت سرور با چندین دروازه API به عنوان نقاط ورودی تلفیقی تشکیل شده است.
محیط میزبانی. در شکل 6-1، چندین کانتینر را می بینید که در یک میزبان Docker مستقر شده اند. این مورد در هنگام استقرار در یک میزبان Docker با دستور docker-compose up صدق می کند. با این حال، اگر از یک ارکستراتور یا کانتینر کلاستر استفاده می‌کنید، هر کانتینر می‌تواند در یک میزبان (گره) متفاوت اجرا شود، و هر گره می‌تواند هر تعداد کانتینر را اجرا کند، همانطور که قبلا در بخش معماری توضیح دادیم.
معماری ارتباطات برنامه eShopOnContainers بسته به نوع عملکرد عملکردی (پرسش‌ها در مقابل به‌روزرسانی‌ها و تراکنش‌ها) از دو نوع ارتباط استفاده می‌کند:
این برنامه به عنوان مجموعه ای از میکروسرویس ها در قالب کانتینرها مستقر شده است. برنامه های سرویس گیرنده می توانند با آن میکروسرویس هایی که به صورت کانتینر اجرا می شوند از طریق URL های عمومی منتشر شده توسط API Gateways ارتباط برقرار کنند.
در برنامه نمونه، هر میکروسرویس دارای پایگاه داده یا منبع داده خود است، اگرچه همه پایگاه های داده SQL Server به عنوان یک ظرف واحد مستقر شده اند. این تصمیم طراحی فقط به این دلیل گرفته شد که یک توسعه دهنده به راحتی کد را از GitHub دریافت کند، آن را شبیه سازی کند و آن را در Visual Studio یا Visual Studio Code باز کند. یا متناوبا، کامپایل کردن تصاویر Docker سفارشی را با استفاده از NET CLI و Docker CLI، و سپس استقرار و اجرای آنها در یک محیط توسعه Docker را آسان می کند. در هر صورت، استفاده از کانتینرها برای منابع داده به توسعه دهندگان این امکان را می دهد که در عرض چند دقیقه بدون نیاز به ارائه یک پایگاه داده خارجی یا هر منبع داده دیگری با وابستگی سخت به زیرساخت (ابر یا درون محل) بسازند و مستقر کنند.
در یک محیط تولید واقعی، برای دسترسی بالا و مقیاس‌پذیری، پایگاه‌های داده باید بر اساس سرورهای پایگاه داده در فضای ابری یا درون محل باشند، اما نه در کانتینرها.
بنابراین، واحدهای استقرار برای میکروسرویس ها (و حتی برای پایگاه های داده در این برنامه) کانتینرهای Docker هستند و برنامه مرجع یک برنامه کاربردی چند کانتینری است که اصول میکروسرویس ها را در بر می گیرد.
