"> معماری Microservice و Design Patterns در Microservices ها | ام اس پی سافت |

معماری Microservice و Design Patterns در Microservice ها

معماری Microservice

در این مقاله قراره راجب معماری Microservice و Design Patterns در Microservice صحبت کنیم. تا پایان این مقاله همراه ما باشید.

Microservice ها می توانند تأثیر مثبتی بر شرکت شما بگذارند. بنابراین باید به این نکته توجه کرد که چگونه می توان معماری میکروسرویس (MSA) و برخی از Design Pattern برای Microservice را مدیریت کرد.

به اهداف یا اصول کلی برای معماری Microservice ها در این‌ مقاله پرداخته شده است. در اینجا چهار هدف در نظر گرفته شده برای عملکرد معماری Microservice ارائه شده است.

کاهش هزینه: MSA.

  1. هزینه کلی: طراحی ، پیاده سازی و نگهداری خدمات فناوری اطلاعات را کاهش می دهد.
  2. افزایش سرعت انتشار: MSA سرعت ایده را به استقرار خدمات افزایش می دهد
  3.  بهبود انعطاف پذیری: MSA باعث افزایش مقاومت در شبکه خدمات ما می شود.
  4.  فعال کردن قابلیت مشاهده: پشتیبانی از MSA برای دید بهتر در سرویس و شبکه شما.

باید بدانید که چه اصول معماری Microservice ساخته شده است:

  • مقیاس پذیری
  • دسترسی
  • انعطاف پذیری
  • مستقل ، خودمختار
  • حاکمیت غیر متمرکز
  •  انزوا شکست
  • تأمین خودکار
  •  تحویل مداوم از طریق DevOps

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

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

آنها می توانند با استفاده از Design Pattern صحیح و منطبق، بر آن غلبه کنند.

Design Pattern برای Microservice وجود دارد که می توانند به پنج الگو تقسیم شوند.

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

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

تجزیه توسط Business Capability

خدمات Microservice همه چیز در مورد ایجاد خدمات، به همراه یکپارچه سازی اصل مسئولیت واحد است.

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

توانایی کسب و کار مفهومی است از مدل سازی معماری تجارت [۲].

این کاری است که یک تجارت برای تولید ارزش انجام می دهد. توانایی کسب و کار اغلب با یک موضوع تجاری مطابقت دارد ، به عنوان مثال:

  •  مدیریت سفارش وظیفه سفارشات را بر عهده دارد.
  •  مدیریت مشتری مسئولیت مشتریان را بر عهده دارد.

تجزیه توسط Subdomain

تجزیه برنامه با استفاده از قابلیت های کسب و کار ممکن است شروع خوبی باشد ، اما شما با اصطلاح “God Classes” روبرو می شوید که تجزیه آن آسان نخواهد بود.

این classes در بین خدمات متعدد متداول خواهد بود.

خدمات مربوط به Subdomain طراحی دامنه (DDD) را تعریف میکند. DDD به فضای مشکل برنامه – تجارت – به عنوان دامنه اشاره دارد.

یک دامنه از چندین Subdomain تشکیل شده است. هر subdomain مربوط به بخش دیگری از تجارت است.

Subdomains می توانند به شرح زیر طبقه بندی شوند:

  •  تمایز دهنده اصلی برای تجارت و با ارزش ترین قسمت برنامه
  •  پشتیبانی – مربوط به کارهایی که تجارت انجام می دهد اما یک تمایز دهنده نیست. اینها می توانند بصورت داخلی یا برون سپاری اجرا شوند.
  •  عمومی – مخصوص تجارت نیست و به صورت ایده آل با استفاده از نرم افزار قفسه اجرا می شود.

subdomain های مدیریت سفارش شامل موارد زیر است:

  • خدمات فروش محصولات
  • خدمات مدیریت موجودی
  •  خدمات مدیریت سفارش

 

Design Patterns

مرحله آماده سازی – در این مرحله ، کلیه شرکت کنندگان برای انجام کار آماده می شوند و به هماهنگ کننده اطلاع می دهند که برای تکمیل کار آماده هستند.

تعهد یا مرحله برگشت – در این مرحله ، دستور متعهد یا برگشتی توسط هماهنگ کننده کار به همه شرکت کنندگان اطلاع رسانی می شود.
مشکل ۲PC این است که نسبت به زمان کار با یک Microservice منفرد کاملاً کند است.

هماهنگی معاملات بین Microservice ، حتی اگر در یک شبکه باشند ، واقعاً می توانند باعث کاهش سرعت سیستم شوند ، بنابراین معمولاً در چنین مواقعی این راه حل به هیچ عنوان در سناریو پر ترافیک استفاده نمیشود.

Strangler Pattern

بیش از سه ، Design Pattern که می خواهید به آن ها بپیوندید برنامه های کاربردی برای Greenfield را تجزیه می کردند ، اما ۸۰٪ کارهایی که انجام می دهید مربوط به برنامه های Brownfield است که برنامه های بزرگ و یکپارچه ای هستند (پایه کد به منتقل رسیده). الگوی Strangler به نجات می رسد.

این دو برنامه ای جداگانه ایجاد می کنند که در یک فضای URI در کنار هم سر می کنند.

با گذشت زمان ، برنامه تازه بازسازی شده ” strangles” یا جایگزین برنامه اصلی می شود تا سرانجام ، می توانید برنامه یکپارچه را خاموش کنید.

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

  •  تبدیل – ایجاد یک سایت موازی جدید با رویکردهای مدرن.
  •  همزیستی – سایت موجود را برای مدت زمان مشخص ترک کنید. از سایت موجود به سایت جدید تغییر مسیر دهید تا عملکرد به صورت تدریجی اجرا شود.
  •  از بین بردن – عملکرد قدیمی را از سایت موجود حذف کنید.

Bulkhead Pattern

عناصر برنامه را درون database جدا کنید تا در صورت عدم موفقیت ، دیگران به عملکرد خود ادامه دهند.

این الگو Bulkhead نامگذاری شده است زیرا شباهت زیادی به تقسیم بندی های بخش بدنه کشتی دارد.

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

این طراحی به منزوی ساختن خرابی ها کمک می کند و به شما امکان می دهد تا عملکرد سرویس را برای برخی از مصرف کنندگان حتی در هنگام عدم موفقیت حفظ کنید.

الگوی جانبی

اجزای برنامه را در یک ظرف پردازنده جداگانه مستقر کنید تا جداسازی و محوطه سازی فراهم شود.

این الگو همچنین می تواند برنامه ها را از مؤلفه ها و فناوری های ناهمگن جدا سازد .

این الگوی Sidecar نامیده می شود زیرا شبیه یک ساید بای ساید متصل به یک موتور سیکلت است.

در این الگو ، حاشیه جانبی به یک برنامه مادر متصل شده و ویژگی های پشتیبانی از برنامه را ارائه می دهد.

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

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

الگوهای ادغام

API Gateway Pattern

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

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

API Gateway تنها نقطه ورود هر تماس Microservice است.

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

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

این راه حل می تواند برای هر نوع مشتری خاص یک API ریز دانه ایجاد کند.

علاوه بر این می تواند درخواست پروتکل را تبدیل کرده و پاسخ دهد.

و در آخر مسئولیت تأیید اعتبار / مجوز از خدمات خرد را بارگیری کند.

الگوی جمع کننده:

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

این مسئولیت را نمی توان بر عهده مصرف کننده گذاشت.

الگوی Aggregator برای رفع این مسئله کمک می کند.

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

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

  • یک Microservice کامپوزیت با همه خدمات مورد نیاز تماس برقرار می کند ، داده ها را تلفیق می کند و داده ها را قبل از ارسال دوباره تبدیل می کند.
  • یک API Gateway همچنین می تواند درخواست را برای چندین Microservice و بخشی از داده ها قبل از ارسال آن به مصرف کننده تقسیم کند.

Gateway Routing Pattern

دروازه API مسئول مسیریابی درخواست ها می باشد.

یک دروازه API برخی از عملیات API را با مسیریابی درخواست به سرویس مربوطه پیاده سازی می کند.

هنگامی که یک درخواست را دریافت می کند ، دروازه API با نقشه مسیریابی مشورت می کند که مشخص می کند کدام سرویس برای هدایت درخواست است.

برای مثال ، یک نقشه مسیریابی می تواند یک روش HTTP و مسیر دسترسی به آدرس HTTP سرویس را ترسیم کند.

این عملکرد با ویژگی های Proxy معکوس ارائه شده توسط سرورهای وب مانند NGINX یکسان است.

زنجیره ای از الگوهای Microservice

چندین سرویس یا Microservice فقط به چندین وابستگی وابسته هستند: به عنوان مثال Microservice فروش Microservice محصولات وابستگی دارد و میکرو خدمات ارائه می دهد.

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

درخواست دریافت شده توسط Microservice 1 ، که در ارتباط با Microservice 2 است و همینطور ممکن است با Microservice 3 ارتباط برقرار کند.

همه این خدمات تماس های همزمان هستند.

الگوهای بانک اطلاعاتی

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

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

معاملات تجاری ممکن است متغیرهایی باشد که چندین سرویس را شامل می شوند.

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

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

خدمات مختلف نیازهای مختلفی برای ذخیره داده دارند.

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

برای حل مشکلات فوق ، باید یک بانک اطلاعاتی در هر Microservice طراحی شود.

این بانک اطلاعاتی باید فقط برای آن سرویس خصوصی باشد. فقط باید توسط API Microservice قابل دسترسی باشد.

به سایر سرویس ها به طور مستقیم قابل دسترسی نباشد.

به عنوان مثال ، برای سایر بانک های اطلاعاتی رابطه ای ، می توانیم از جداول در  هر سرویس یا پایگاه داده-سرور در هر سرویس استفاده کرد.

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

ما در مورد یک بانک اطلاعاتی در هر سرویس ایده آل برای خدمات میکرو صحبت کرده ایم.

این همانند ضد الگو برای خدمات میکرو است. اما اگر برنامه یکپارچه است و سعی در ورود به خدمات Microservice دارد ، ایجاد تفاوت به این آسانی نیست.

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

اما این راه حل کار برای سناریوی فوق است. بیشتر افراد این را یک الگویی برای Microservice ها می دانند ، اما برای برنامه های Brownfield ، این شروع خوبی برای شکسته شدن برنامه به قطعات کوچکتر است.

به این نکته هم باید توجه کرد که نباید برای برنامه های Greenfield اعمال شود.

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

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

در حال حاظر این امکان وجود ندارد. حال چه کنیم؟ CQRS پیشنهاد می کند که برنامه را به دو قسمت تقسیم کنید:

  •  سمت فرمان
  • سمت پرس و جو

طرف فرمان، درخواست های ایجاد شده را بروزرسانی، حذف و کنترل می کند

طرف پرس و جو نیز با استفاده از نماهای مادی قسمت مربوط به پرس و جو را کنترل می کند.

یافتن منابع

اکثر برنامه های کاربردی با داده کار می کنند ، و رویکرد معمولی این است که برنامه برای حفظ وضعیت فعلی باشد.

به عنوان مثال ، در مدل سنتی Creati ، Read ، Update و Delete یک فرایند داده معمولی برای خواندن یک سری داده ها از فروشگاه است.

این شامل محدودیت هایی برای قفل کردن داده ها در اکثر معاملات است.

Event Sourcing Pattern [8]

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

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

هر رویداد مجموعه ای از تغییرات در داده ها را نشان می دهد (مانند AddItemToOrder).

این وقایع در یک عرضه رویداد که به عنوان سیستم ثبت فعالیت می کنند ادامه دارند.

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

به عنوان مثال ، یک سیستم می تواند یک نمای کلی از کلیه سفارشات مشتری را که برای جمع آوری قسمت هایی از UI استفاده می شود ، حفظ کند.

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

شکل یک نمای کلی از الگوی را نشان می دهد.

Design Patterns

Saga Pattern

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

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

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

هیچکدام از آنها هیچگونه کنترلی بر فرآیندهای طرف های دیگر و یا احتمالاً مشاهده آن فرآیندها ندارند – نمی توانند فعالیت ها و فرآیندهای خود را برای به اشتراک گذاری اطلاعات و ارزش ها هماهنگ کنند.

در هنگام هماهنگی در حوزه های کنترل / دید ، از choreography استفاده کنید. شما می توانید مثل یک پروتکل شبکه ، در یک سناریوی ساده به choreography فکر کنید.

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

 Design Patterns

Orchestration- یک Orchestration (شی) مسئولیت تصمیم گیری و توالی منطق کسب و کار حماسه را به عهده می گیرد.

این امر زمانی اتفاق می افتد که بر همه بازیگران یک روند کنترل داشته باشید و همینطور زمانی که همه در یک دامنه کنترل قرار داشته باشند و شما می توانید جریان فعالیت ها را کنترل کنید.

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

الگوهای قابل مشاهده

Log Aggregation

موارد کاربردی را در نظر بگیرید که یک برنامه شامل چندین سرویس است.

درخواست ها غالباً در چندین سرویس وجود دارد.

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

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

آنها می توانند هشدارهایی را که هنگام نمایش پیام های مشخص در گزارش ها ایجاد می شوند ، پیکربندی کنند.

به عنوان مثال ، PCF دارای یک جمع کننده Log (Log) است که از هر مؤلفه (Router ، Controller ، Diego و…) سکوی PCF به همراه برنامه ها جمع آوری می کند.

AWS Cloud Watch نیز همین کار را انجام می دهد.

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

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

یک سرویس متریک برای جمع آوری آمار مربوط به عملیات فردی مورد نیاز است.

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

دو مدل برای اندازه گیری متغیرها وجود دارد:

فشار دهید – این سرویس اندازه گیری ها را به سرویس اندازه گیری سوق می دهد ، به عنوان مثال. NewRelic، AppDynamics
بکشید – سرویس های اندازه گیری، اندازه گیری ها را از این سرویس به تصویر می کشند. مثل Prometheus

در یک معماری Microservice ، درخواست ها اغلب شامل چندین سرویس می شوند.

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

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

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

  • هر درخواست خارجی را به یک شناسه درخواست خارجی منحصر به فرد اختصاص می دهد.
  • شناسه درخواست خارجی را به کلیه خدمات منتقل می کند.
  • شامل شناسه درخواست خارجی در کلیه پیام های ورود به سیستم میشود.

Health Check

هنگامی که معماری Microservice ارائه شده است ، این احتمال وجود دارد که یک سرویس ارتقا یابد اما قادر به انجام معاملات نباشد.

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

این API باید وضعیت میزبان ، اتصال به سایر خدمات / زیرساخت ها و هرگونه منطق خاص را بررسی کند.

Cross-Cuting Concern Pattern

پیکربندی تنظیم کننده:

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

برای هر محیطی مانند URL ،Prod،UAT،QA،dev نقطه انتهایی با برخی ویژگی های پیکربندی اصلی ممکن است متفاوت باشد.

تغییر در هر یک از این ویژگی ها ممکن است نیاز به ایجاد و استقرار مجدد این سرویس داشته باشد.

برای جلوگیری از پیکربندی اصلاح کد می تواند مورد استفاده قرار گیرد.

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

برنامه باید آنها را در هنگام راه اندازی یا در حالت پرواز بارگیری کند.

این ها به وسیله برنامه در هنگام راه اندازی و یا بدون راه اندازی مجدد سرور، قابل تجدید است.

Service Discovery Pattern

هنگامی که Microservice ها به تصویر کشیده میشوند، ما باید از نظر فراخانی خدمات به چند موضوع بپردازیم.

با فناوری کانتینر،آدرس های IP به صورت پویا به نمونه های یک سرویس اختصاص می یابد.

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

هر URL سرویس توسط مصرف کننده باید بهم پیوسته شود.

باید یک ریجستر خدمات ایجاد شود که داده های هر سرویس تولید کننده و مشخصات مربوط به هر یک را حفظ کند.

یک نمونه سرویس باید هنگام شروع به ثبت در ریجستر بپردازد و هنگام خاموش شدن ثبت مجدد کند.

دو نوع سرویس یابنده وجود دارد:

  • Client-side : eg: Netflix Eureka
  •  Server-side: eg: AWS ALB.

 

معماری Microservice

الگوی مدار شکن

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

دو مشکل در این زمینه وجود دارد:

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

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

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

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

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

در غیر این صورت ، اگر یک خرابی وجود داشته باشد ، دوره پایان دوره دوباره شروع می شود.

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

معماری Microservice

Blue-Green Deployment Pattern

با استفاده از معماری Microservice ، یک برنامه میتواند Microservice های متعددی داشته باشد.

اگر همه خدمات را متوقف کنیم و سپس یک نسخه پیشرفته را مستقر کنیم خرابی بسیار زیادی ایجاد خواهد شد و می تواند بر کسب و کار تأثیر بگذارد.

همچنین ، بازگرداندن دوباره آن یک مشکل بسیار بزرگ خواهد بود.

الگوی استقرار آبی-سبز از این امر جلوگیری می کند.

استراتژی استقرار آبی-سبز می تواند برای کاهش یا حذف خرابی ها اجرا شود.

این امر با اجرای دو محیط تولید یکسان ، آبی و سبز به این هدف می رسد.

فرض کنیم Green نمونه زنده موجود است و Blue نسخه جدید برنامه است.

در هر زمان ، تنها یکی از محیط های زنده است که محیط زندگی در آن ، تمام ترافیک تولید را ارائه می دهد.

همه سیستم عامل های ابری گزینه هایی را برای اجرای استقرار آبی-سبز فراهم می کنند.

معماری Microservice

 

  • پسورد: www.mspsoft.com
زهره سلطانیان

نوشته‌های مرتبط

دیدگاه‌ها

*
*

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