، تهران , (اخبار رسمی): بیایید در این مقاله نگاهی گذرا به میکروسرویس ها و الگوهای طراحی آنها بیندازیم. الگوهای طراحی که در زیر ذکر شده اند، مقدمه ای عالی برای الگوهای طراحی معماری میکروسرویس به شما ارائه می دهند.
میکروسرویس ها به عنوان روشی برای ساخت برنامه های کاربردی در بازار امروز ظهور کرده اند. اکثر شرکت ها معماری Microservices را در حین توسعه یک برنامه تجاری به جای طراحی یکپارچه ترجیح می دهند. در نتیجه، درک معماری میکروسرویس (MSA) و برخی از الگوهای طراحی ضروری است.
الگوها و اصول طراحی میکروسرویس ها: فهرست محتوا
1. میکروسرویس چیست؟
2. معماری مایکروسافت
3. اصول میکروسرویس
4. الگوهای طراحی میکروسرویس ها
میکروسرویس چیست؟
میکروسرویس ها که با نام معماری میکروسرویس نیز شناخته می شوند، یک رویکرد معماری است که یک برنامه کاربردی را به عنوان مجموعه ای از خدمات به هم پیوسته سازماندهی می کند. میکروسرویس ها به گونه ای طراحی شده اند که سرعت انتشار برنامه ها را با تقسیم آنها به سرویس های کوچک و مستقلی که می توانند به طور مستقل ارائه شوند، افزایش دهند.
- قابل نگهداری و آزمایش به درجه بالایی است
- پیوند ضعیف اصطلاحی است که به رابطه ای اشاره دارد که هست
- به راحتی قابل استقرار
- ساختار سازمانی با محوریت قابلیت های تجاری.
- گروه کوچکی از مردم مالک آن هستند.
معماری مایکروسافت
طراحی میکروسرویس اجازه می دهد تا برنامه های کاربردی عظیم و پیچیده به سرعت، اغلب و با اطمینان ارائه شوند. همچنین پشته فناوری یک شرکت را قادر می‌سازد تا سازگار شود.
معماری میکروسرویس مجموعه ای از خدمات کوچک مستقل است که در حول و حوش حوزه کسب و کار سازماندهی شده اند. همه اجزای یک معماری میکروسرویس مستقل هستند و در اطراف یک قابلیت تجاری واحد قرار می گیرند.
ارتباط طراحی میکروسرویس با معماری یکپارچه در چهار مفهوم اصلی ذکر شده در زیر توضیح داده شده است.
- دید بالا - MSA دید خدمات شما را بهبود می بخشد.
- انعطاف‌پذیری را افزایش می‌دهد - انعطاف‌پذیری شبکه خدمات ما افزایش یافته است.
- کاهش زمان تولید - زمان لازم برای تبدیل شدن یک ایده به محصول نهایی را کوتاه کنید.
- هزینه های کمتر - کل هزینه ایجاد، استقرار و نگهداری خدمات فناوری اطلاعات را کاهش دهید.
اصول اساسی میکروسرویس
در زیر ایده‌های کلیدی میکروسرویس و الگوهای طراحی وجود دارد که می‌توانید برای مقابله با مشکلات رایج معماری میکروسرویس استفاده کنید. بیایید نگاهی به ایده هایی بیندازیم که زیربنای معماری میکروسرویس هستند.
- خدمات مستقل و مستقل
- مقیاس پذیری
- عدم تمرکز
- خدمات انعطاف پذیر
- تعادل بار در زمان واقعی
- دسترسی
- تحویل مداوم از طریق یکپارچه سازی DevOps
- یکپارچه سازی API بدون درز و نظارت مستمر
- انزوا از شکست ها
- تامین خودکار
این عناصر ستون فقرات هر معماری میکروسرویس قابل اعتماد هستند و باید هنگام ایجاد یک طراحی مبتنی بر میکروسرویس در نظر گرفته شوند. این ویژگی ها از ماهیت مستقل و منزوی میکروسرویس صحبت می کند که برای اجرای آن حیاتی است.
الگوهای طراحی میکروسرویس ها چیست؟
الگوهای طراحی میکروسرویس ها برای مقابله با مشکلات مختلفی شناخته شده اند. در نتیجه، در این وبلاگ در مورد الگوهای طراحی میکروسرویس‌ها، مهم‌ترین الگوها را برای ساختن یک معماری موفق میکروسرویس بررسی خواهیم کرد و هر کدام را به طور عمیق بررسی خواهیم کرد.
- جمع کننده
- دروازه API
- Backend For Frontend (BFF)
- تفکیک مسئولیت پرس و جو فرمان (CQRS)
- منبع یابی رویداد
- مدار شکن
- پیکربندی خارجی
- ردیابی قرارداد مبتنی بر مصرف کننده
- خفه کننده
- حماسه
1. جمع کننده
الگوی جمع‌آوری یک روش اجرای میکروسرویس است که در آن همان صفحه UI سرویس‌های متعددی را برای انجام عملکردهای لازم فراخوانی می‌کند. این روش هنگام ترکیب داده ها از چندین میکروسرویس در یک خروجی مفید است.
یک جمع کننده یک قابلیت ترکیبی است که ریزسرویس های متعددی را ترکیب می کند. ممکن است یک UI باشد که به عملکرد سه میکروسرویس نیاز دارد، یا می‌تواند یک سرویس همراه با برخی API منطق تجاری باشد. از آنجایی که ریزسرویس تجمیع کننده بر اساس اصل DRY است، ممکن است منطق را در میکروسرویس های مرکب انتزاعی کنیم و آن دلیل را در یک میکروسرویس واحد جمع کنیم.
مزایای الگوی طراحی جمع کننده
برخی از مزایای استفاده از الگوی طراحی تجمیع کننده به شرح زیر است:
- میکروسرویس های تونل زنی در هر دو محور x و z مقیاس پذیر هستند.
- خدمات داخلی از انعطاف پذیری امضای میکروسرویس ها بهره می برند.
- ارائه خدمات میکرو با یک نقطه دسترسی واحد
معایب الگوی طراحی جمع کننده
برخی از معایب استفاده از الگوی طراحی جمع‌آوری به شرح زیر است:
- هماهنگ سازی داده ها پیچیده است.
- ضد الگوی تنگناها
- تأخیر ارتباط بین میکروسرویس ها
2. API Gateway
رابط کاربری به Microservice های مختلف در Microservice Architecture پیوند دارد. اگر میکروسرویس ها دانه بندی شده باشند، ممکن است مشتری نیاز به اتصال به بسیاری از میکروسرویس ها داشته باشد که می توانند نویز و پیچیده باشند. سرویس ها و همچنین API های آنها نیز می توانند تغییر کنند. کسب‌وکارهای بزرگ از سایر نگرانی‌های بین‌بخشی (خاتمه SSL، احراز هویت، مجوز، throttling، ورود به سیستم و غیره) استقبال می‌کنند.
یکی از راه حل های این مشکلات استفاده از API Gateway است. می تواند به عنوان یک پروکسی معکوس عمل کند و درخواست های مشتری را به Backend Microservice مناسب هدایت کند. همچنین می‌تواند درخواست مشتری را به چندین میکروسرویس ارسال کند و پاسخ‌های جمع‌آوری شده را به مشتری برگرداند. همچنین به حل مسائل مهم بین بخشی کمک می کند.
الگوی طراحی دروازه API در این نمودار نشان داده شده است. میکروسرویس ها از کشف سرویس برای تعیین بهترین مسیر ارتباطی بین آنها استفاده می کنند. میکروسرویس‌ها از طریق یک سرور بدون حالت، مانند گذرگاه درخواست/پیام HTTP متصل می‌شوند.
مزایای الگوی طراحی دروازه API
- میکروسرویس‌ها برای قسمت جلویی و باطن می‌توانند به‌طور آزادانه جفت شوند.
- تعداد تماس های رفت و برگشتی بین مشتری و میکروسرویس ها را کاهش دهید.
- خاتمه SSL، احراز هویت و مجوز امنیت بالایی را فراهم می کند.
- ثبت و نظارت، دریچه گاز، و متعادل سازی بار نمونه هایی از نگرانی های مقطعی هستند که به صورت متمرکز مدیریت می شوند.
معایب الگوی طراحی دروازه API
- در معماری Microservice، این ممکن است منجر به یک نقطه شکست شود.
- به دلیل تماس اضافی شبکه، تاخیر افزایش می یابد.
- اگر مقیاس‌پذیر نباشند، می‌توانند به سرعت به گلوگاهی برای کل شرکت تبدیل شوند.
- هزینه های توسعه و نگهداری اضافی.
3. Backend For Frontend (BFF)
برنامه‌های front-end و Backend خدمات جدا و مستقل در توسعه برنامه‌های کاربردی تجاری مدرن، به‌ویژه در معماری Microservice هستند. پارادایم Backends for Frontends را می توان در مواردی استفاده کرد که هر رابط کاربری باطن خود را متناسب با آن دارد. مزایای دیگر عبارتند از عمل به عنوان یک نما برای میکروسرویس های پایین دست، که تعاملات چت بین رابط کاربری و میکروسرویس های پایین دست را کاهش می دهد. BFF ها همچنین برای ایجاد امنیت بیشتر در سناریوی بسیار ایمن زمانی که میکروسرویس های پایین دستی در یک شبکه DMZ قرار می گیرند، استفاده می شود.
مزایای الگوی BFF
- نگرانی های BFF ها از هم جدا شده اند. ما می‌توانیم آنها را برای یک رابط کاربری خاص تنظیم کنیم.
- سطح امنیت را افزایش دهید.
- میزان گپ بین رابط‌های کاربری و میکروسرویس‌های پایین‌دست را کاهش دهید.
معایب الگوی BFF
- تکرار کدها در بین BFF ها.
- اگر UI های اضافی متعددی به کار گرفته شوند، BFF ها گسترش خواهند یافت (به عنوان مثال، تلویزیون هوشمند، وب، موبایل، دسکتاپ).
- BFF ها نباید حاوی هیچ منطق تجاری و فقط منطق و رفتار مشتری خاص باشد که نیاز به طراحی و اجرای دقیق دارد.
4. تفکیک مسئولیت پرس و جوی فرمان (CQRS)
الگوی طراحی CQRS می تواند برای اجرای یک پرس و جو پیچیده که بسیاری از پایگاه های داده خدمات را پوشش می دهد مفید باشد زیرا دسترسی به داده ها به یک پایگاه داده محدود می شود. برنامه در این الگو به دو بخش فرمان و پرس و جو تقسیم می شود. تمام درخواست‌های ایجاد، به‌روزرسانی توسط بخش فرمان رسیدگی می‌شود، در حالی که بخش پرس‌وجو، نماهای تحقق‌یافته را دریافت می‌کند. این بدان معناست که مولفه فرمان مسئول ایجاد، به روز رسانی و حذف عبارات خواهد بود، در حالی که بخش پرس و جو به ترتیب دستورات خواندن خواهد بود. نمودار زیر باید به شما در درک الگوی طراحی CQRS کمک کند.
مزایای CQRS
- خواندن داده ها در میکروسرویس های رویداد محور سریعتر است.
- داده هایی با سطح دسترسی بالا.
- هر دو سیستم خواندن و نوشتن می توانند به طور مستقل مقیاس شوند.
معایب CQRS
- ذخیره داده های خوانده شده ناسازگار است (ثبات نهایی)
- پیچیدگی کلی سیستم افزایش می یابد. کشت محموله CQRS این پتانسیل را دارد که کل شرکت را خراب کند.
5. رویداد منبع یابی
منبع رویداد مسئول ایجاد یک توالی جدید و متوالی از رویدادها است. وضعیت برنامه را می توان با پرس و جو از داده ها دوباره ایجاد کرد، اما برای انجام این کار باید هر تغییری را در شرایط برنامه دوباره تصویر کنیم. اصل پشت منبع رویداد این است که سیستم باید هر تغییری را در وضعیت یک موجودیت مشاهده کند.
تداوم یک کالای تجاری با ذخیره سازی متوالی رویدادهای تغییر وضعیت به دست می آید. هر بار که وضعیت یک شی تغییر می کند، یک رویداد جدید به دنباله رویدادها اضافه می شود. از آنجایی که این یک عملیات واحد است، عملاً اتمی است. وضعیت فعلی یک موجودیت را می توان با پخش مجدد رخدادهای آن بازسازی کرد.
مزایای رویداد منبع یابی
- به سیستم ها اتمی بسیار مقیاس پذیر بدهید.
- تاریخچه موجودیت به طور خودکار نگهداری می شود و سفر در زمان امکان پذیر است.
- ریزسرویس هایی که به طور ضعیف به هم متصل هستند و رویداد محور هستند.
معایب منبع یابی رویداد
- خواندن موجودیت ها از فروشگاه رویداد دشوار می شود و اغلب نیاز به استفاده از یک ذخیره داده جداگانه (الگوی CQRS) دارد.
- پیچیدگی کلی سیستم افزایش می‌یابد و طراحی دامنه محور را ضروری می‌کند.
- سیستم باید رویدادهای تکراری (idempotent) و رویدادهای گمشده را مدیریت کند.
- انتقال طرحواره رویداد چالش برانگیز می شود.
6. مدار شکن
الگوی Circuit Breaker هرگونه فعالیت کاری را با توقف فرآیند درخواست و پاسخ در صورت کار نکردن سرویس، قطع می کند. وقتی صحبت از مفاهیم سرویس گرا مانند Microservices می شود، این امر بسیار مهم است. تماس گیرنده بدون اینکه بداند نقطه پایانی سرویس فعال است یا خیر، درخواست میکروسرویس می کند. اگر پاسخی دریافت نشد، به طور مداوم تماس را دوباره امتحان می کند. وقتی مشتری با بسیاری از میکروسرویس ها تماس می گیرد، یا گردش کاری شامل چندین میکروسرویس وجود دارد و یکی از آنها پاسخ نمی دهد، مشکل حتی بدتر می شود.
یک الگوی قطع کننده مدار برای جلوگیری از چنین مواردی استفاده می شود که در آن مشتری به جای سرویس مستقیماً یک پروکسی را فرا می خواند. به عنوان یک مانع مدار، نماینده عمل خواهد کرد. هنگامی که تعداد خرابی ها به حد معینی می رسد، قطع کننده مدار برای مدت زمان مشخصی کار می کند.
مزایای مدار شکن
- تحمل خطا و انعطاف پذیری Microservice Architecture را بهبود ببخشید.
- از سرایت خرابی ها به سایر میکروسرویس ها جلوگیری می کند.
معایب مدار شکن
- استثناها باید به شیوه ای پیچیده رسیدگی شود.
- نظارت و ثبت
- بازنشانی دستی باید امکان پذیر باشد.
7. پیکربندی خارجی
هر برنامه تجاری دارای تنظیمات پیکربندی زیرساخت زیادی است. علاوه بر این، در یک تنظیمات سازمانی، برنامه معمولاً در زمان‌های اجرا متعدد (محلی، توسعه‌دهنده، تولیدی) مستقر می‌شود. این یک نگرانی امنیتی قابل توجه است زیرا اعتبار تولید به راحتی به خطر می افتد. علاوه بر این، هر تغییری در پارامتر پیکربندی نیاز به بازسازی برنامه دارد.
این در معماری Microservice بسیار مهم است زیرا ممکن است صدها سرویس وجود داشته باشد. بیرونی کردن تمام تنظیمات یک استراتژی برتر است. در نتیجه فرآیند ساخت و محیط زمان اجرا از هم جدا می شوند. همچنین خطرات امنیتی را تنها با استفاده از فایل پیکربندی Production در زمان اجرا یا از طریق متغیرهای محیطی کاهش می دهد.
مزایای پیکربندی خارجی
- تنظیمات تولید در Codebase گنجانده نشده است و خطرات امنیتی را کاهش می دهد.
- تغییرات در پارامترهای پیکربندی را می توان بدون نیاز به ساخت جدید انجام داد.
معایب پیکربندی خارجی
- ما باید چارچوبی را انتخاب کنیم که بتواند پیکربندی خارجی را مدیریت کند.
8. ردیابی قرارداد مبتنی بر مصرف کننده
تیم مالک Microservice مصرف کننده یک مجموعه آزمایشی برای یک Microservice ارائه دهنده خاص ایجاد می کند که شامل درخواست و پاسخ مورد انتظار (برای ارتباط همزمان) یا پیام های مورد انتظار (برای ارتباطات ناهمزمان) است. قراردادهای صریح نامی است که به این مجموعه های آزمایشی داده شده است. مجموعه تست های قرارداد مصرف کننده ارائه دهنده میکروسرویس در تست خودکار آن گنجانده شده است. هنگامی که یک آزمایش خودکار برای یک Microservice ارائه‌دهنده خاص انجام می‌شود، تست‌ها و قراردادها را اجرا می‌کند و آنها را تأیید می‌کند. در این روش، تست قرارداد می تواند به حفظ یکپارچگی Microservice Communication به صورت خودکار کمک کند.
مزایای ردیابی قرارداد مبتنی بر مصرف کننده
- اگر ارائه دهنده یک تغییر غیرمنتظره در API یا پیام ایجاد کند، به سرعت خود به خود کشف می شود.
- شگفتی کمتر و انعطاف پذیری بالاتر، به ویژه در برنامه های سازمانی با بسیاری از میکروسرویس ها.
- استقلال تیم بهبود یافته است.
معایب ردیابی قرارداد مبتنی بر مصرف کننده
- آزمایش قرارداد در Microservice ارائه دهنده زمان بیشتری برای ساخت و ادغام نیاز دارد زیرا ممکن است از چندین ابزار تست استفاده کنند.
- این امکان وجود دارد که اگر آزمایش قرارداد با استفاده از سرویس در دنیای واقعی مطابقت نداشته باشد، تولید با شکست مواجه شود.
9. خفه کننده
طرح Strangler بسیار شبیه درخت انگور است که درخت پیچیده شده را خفه می کند. هنگامی که یک مهاجرت منظم از یک سیستم کاربردی سنتی به معماری مدرن انجام می شود، سیستم به فرآیندهای گسترده بازنویسی کد نیاز دارد. در چنین شرایطی، الگوی Strangler می تواند به از بین بردن تدریجی یک سیستم قدیمی و به آرامی معرفی عملکردهای جدید به جای آفلاین کردن کل سیستم و انجام یک تعمیر اساسی کمک کند. این بدان معنی است که دو برنامه مستقل (اصلی و بازسازی شده) در مکان دقیق با هم وجود خواهند داشت. برنامه refactored به دور برنامه اصلی پیچیده یا خفه می شود تا زمانی که برنامه واقعی خاموش شود.
مزایای Strangler
- تبدیل ایمن از یکپارچه به برنامه های کاربردی میکروسرویس.
- مهاجرت و توسعه عملکرد اضافی هر دو می توانند به طور همزمان اتفاق بیفتند.
- روند مهاجرت می تواند با سرعت خود ادامه یابد.
معایب Strangler
- اشتراک گذاری داده ها بین Monolith موجود و Microservices جدید دشوار می شود.
- تأخیر سیستم با افزودن یک Facade (API Gateway) افزایش می یابد.
- تست انتها به انتها چالش برانگیزتر می شود.
10. حماسه
در معماری Microservice، الگوی Saga را می توان برای تراکنش های توزیع شده استفاده کرد. Saga الگویی است که در سال 1987 به عنوان یک جایگزین مفهومی برای تراکنش های طولانی مدت پایگاه داده SQL ایجاد شد. با این حال، یک تغییر اخیر از این طراحی برای تراکنش های پراکنده نیز معجزه می کند. الگوی Saga یک توالی تراکنش محلی است که در آن هر تراکنش داده ها را در فروشگاه داده تغییر می دهد و یک رویداد یا پیام را در یک Microservice پخش می کند. یک درخواست خارجی، تراکنش اولیه را در یک حماسه آغاز می کند. پیام/رویداد منتشر شده، تراکنش محلی بعدی در Saga را پس از تکمیل تراکنش محلی آغاز می کند.
مزایای Saga
- یک معماری میکروسرویس رویداد محور، بسیار مقیاس پذیر یا با پیوند ضعیف، یکپارچگی با استفاده از تراکنش ها را فراهم می کند.
- هنگام استفاده از پایگاه های داده NoSQL بدون پشتیبانی 2PC در معماری Microservice، سطح را از طریق تراکنش ها ارائه دهید.
معایب ساگا
- باید بتواند شکست های گذرا را مدیریت کند و ناتوانی ایجاد کند.
- اشکال زدایی پیچیده است و با افزایش تعداد Microservice ها، پیچیدگی آن افزایش می یابد.
نتیجه
در نتیجه، این وبلاگ در مورد الگوهای طراحی میکروسرویس به پایان می رسد. امیدواریم در مورد الگوهای طراحی میکروسرویس و نحوه موثر بودن آنها در الزامات طراحی تخصصی میکروسرویس چیزهای زیادی یاد گرفته باشید.
### پایان خبر رسمی