"> Design Pattern برای میکروسرویس ها | آموزش .NET Core | ام اس پی سافت

Design Pattern برای میکروسرویس ها

میکروسرویس ها

در این مقاله میخواهیم راجب Design Pattern برای میکروسرویس ها صحبت کنیم. معماری میکروسرویس به بهترین گزینه برای توسعه برنامه‌های کاربردی مدرن تبدیل شده‌است.

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

بنابراین ، Design Pattern برای میکروسرویس ها نیاز به بحث دارند.

قبل از اینکه به Design Pattern بپردازیم ، باید بدانیم که بر طبق چه اصول معماری میکروسرویس ها ساخته شده است :

  1. مقیاس پذیری
  2. دسترسی
  3. انعطاف پذیری
  4. مستقل بودن ، خودمختاری
  5. حاکمیت غیر متمرکز
  6. انزوا شکست
  7. تأمین خودکار
  8. تحویل مداوم از طریق توسعه عملیات (DevOps)

استفاده از همه این اصول چالش ها و مسائل مختلفی را به همراه دارد.

بیایید در مورد آن مشکلات و راه حل های آنها بحث کنیم.

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

یک: تجزیه توسط توانایی تجاری

مسئله:

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

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

چگونه می توانیم یک برنامه را به سرویس های کوچک تجزیه کنیم؟

راه حل:

یک استراتژی تجزیه توانایی شغلی است.

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

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

به عنوان مثال ، قابلیت های یک شرکت بیمه به طور معمول شامل فروش ، بازاریابی ، کارگشایی ، پردازش مطالبات ، صورت حساب ، انطباق و … است.

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

دو. تجزیه توسط Subdomain

مشکل :

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

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

به عنوان مثال در مدیریت سفارش ، سفارش گرفتن ، تحویل سفارش و …. استفاده خواهد شد.

چگونه می توانیم آنها را تجزیه کنیم؟

حل مسئله

برای “) (DDD) (Domain-Driven Design)  “God Classes )  به کمک می آید.

برای حل این مشکل از Subdomain و مفاهیم bounded context استفاده می شود.

DDD کل مدل دامنه ایجاد شده برای شرکت را به Subdomain می شکند. هر Subdomain دارای یک مدل خواهد بود ، و دامنه آن مدل به عنوان bounded context نامیده می شود.

هر میکروسرویس در اطراف bounded context توسعه خواهد یافت.

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

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

سه. الگوی کاهش رشد

مسئله:

تاکنون Design Pattern مورد بحث ما در حال تجزیه برنامه های کاربردی برای گرینفیلد بودند ، اما ۸۰٪ کارهایی که انجام می دهیم مربوط به برنامه های Brownfield است که کاربردهای بزرگ و یکپارچه ای دارند.

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

راه حل:

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

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

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

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

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

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

یک. الگوهای دروازه API

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

  1.  چگونه می توان چندین سرویس خرد کننده را توصیف کرد که اطلاعات تولید کننده را انتزاع می کنند.
  2. در کانال های مختلف (مانند دسک تاپ ، موبایل و تبلت ها) ، برنامه ها برای پاسخگویی به همان خدمات پس زمینه ، به داده های مختلفی نیاز دارند ، زیرا ممکن است UI متفاوت باشد.
  3. مصرف کنندگان مختلف ممکن است به قالب متفاوتی از پاسخ های ارائه شده از میکروسرویس های قابل استفاده مجدد نیاز داشته باشند. چه کسی تبدیل داده یا دستکاری درست را انجام خواهد داد؟
  4. نحوه اداره انواع مختلف پروتکل هایی که برخی از آنها ممکن است توسط میکروسرویس تولید کننده پشتیبانی نشوند.

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

  1.  یک ورودی و خروجی API نقطه ورود هر تماس میکروسرویس است.
  2.  این می تواند به عنوان یک proxy service برای انتقال درخواست به میکروسرویس مربوطه کار کند و جزئیات تولید کننده را انتصاب کند.
  3.  این می تواند درخواست چندین سرویس را اعلام کرده و نتایج را برای ارسال به مصرف کننده جمع کند.
  4.  همه API های یک اندازه نمی توانند تمام نیازهای مصرف کننده را حل کنند. این راه حل می تواند یک API ریز دانه برای هر نوع مشتری خاص ایجاد کند.
  5.  همچنین می تواند درخواست پروتکل (به عنوان مثال AMQP) را به پروتکل دیگری (به عنوان مثال HTTP) و برعکس تبدیل کند تا تولید کننده و مصرف کننده بتوانند از پس آن برآیند.
  6.  همچنین می تواند مسئولیت تأیید اعتبار / مجوز از خدمات خرد را بارگیری کند.

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

مسئله:

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

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

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

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

راه حل:

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

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

  1. یک خدمات میکروسرویس کامپوزیت با کلیه خدمات میکروسرویس مورد نیاز تماس برقرار می کند ، داده ها را تلفیق می کند و داده ها را قبل از ارسال دوباره تبدیل می کند.
  2. یک ورودی و خروجی API همچنین می تواند درخواست را برای چندین سرویس میکروسرویس داده تقسیم کند و داده ها را قبل از ارسال به مصرف کننده جمع کند.

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

سه.الگوی ترکیبی مشتری-جانبی UI

مسئله:

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

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

ما باید درک کنیم که چگونه این کار را انجام دهیم

راه حل:

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

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

چارچوب هایی مانند AngularJS وReactJS به انجام این کار به راحتی کمک می کنند.

این صفحات به عنوان Single Page Applications شناخته می شوند(SPA ). این برنامه را قادر می سازد تا به جای کل صفحه ، منطقه خاصی از صفحه را تازه کند.

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

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

مسئله:

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

  1.  خدمات باید با هم جفت شوند. آنها می توانند به طور مستقل توسعه یافته ، مستقر و مقیاس شوند.
  2.  معاملات تجاری ممکن است متغیرهایی باشد که چندین سرویس را شامل می شوند.
  3.  بعضی از معاملات تجاری باید داده هایی را که متعلق به چندین سرویس است جستجو کنند.
  4. برای مقیاس کردن ، پایگاه داده ها گاهی باید تکثیر و تقسیم شوند.
  5. خدمات مختلف نیازهای مختلفی برای ذخیره داده دارند.

راه حل:

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

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

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

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

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

مسئله:

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

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

راه حل:

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

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

این نباید برای برنامه های Greenfield اعمال شود. در این الگوی ، می توان یک پایگاه داده را با بیش از یک ریز سرویس تنظیم کرد ، اما باید حداکثر ۲-۳ آن را محدود کرد ، در غیر این صورت مقیاس بندی ، خودگردانی و استقلال برای اجرای چالش برانگیز است.

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

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

راه حل:

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

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

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

سه. الگوی حماسه

مسئله:

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

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

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

راه حل:

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

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

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

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

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

مسئله

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

درخواست ها غالباً در چندین سرویس وجود دارد. هر نمونه سرویس ، یک پرونده ورود را با فرمت استاندارد تولید می کند.

چگونه می توانیم از طریق سیاهههای مربوط به یک درخواست خاص ، رفتار برنامه را درک کنیم؟

راه حل:

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

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

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

به عنوان مثال ، PCF دارای Loggeregator است که از هر مؤلفه (روتر ، کنترل کننده ، دیگو و …) سکوی PCF به همراه برنامه ها جمع آوری می کند. AWS Cloud Watch نیز همین کار را انجام می دهد.

سه. ردیابی توزیع شده

مسئله:

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

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

سپس ، چگونه می توانیم درخواستی را برای پایان دادن به مشکل ردیابی کنیم؟

راه حل:

ما به خدماتی احتیاج داریم

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

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

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

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

یک zipkin به همراه سرور Spring cloud Sleuth اجرای مشترک است.

چهار. بررسی سلامت

مسئله:

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

راه حل:

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

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

Spring Boot Actuator

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

۵. الگوی مرتبط متقاطع

یک. پیکربندی خارجی

مسئله:

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

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

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

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

سرور پیکربندی Spring Cloud گزینه ای برای خارج کردن خصوصیات GitHub و بارگذاری آنها به عنوان ویژگی های محیطی فراهم می کند.

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

دو. الگوی کشف خدمات

مسئله:

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

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

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

بنابراین چگونه مصرف کننده یا روتر تمام موارد و مکان های خدمات موجود را می شناسند؟

راه حل:

باید یک رجیستری سرویس ایجاد شود که فوق داده های هر سرویس تولید کننده را حفظ کند.

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

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

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

دو نوع کشف خدمات وجود دارد: سمت مشتری و سمت سرور. نمونه ای از سمت مشتری Netflix Eureka و نمونه ای از سمت سرور AWS ALB است.

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

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

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

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

راه حل:

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

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

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

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

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

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

چهار. Deployment Pattern آبی-سبز

مسئله:

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

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

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

راه حل:

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

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

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

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

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

  • sidecar، Chained Microservice،
  • Event Sourcing Pattern
  • Branch Microservice.

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

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

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

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

دیدگاه‌ها

*
*

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