آیا می خواهید یاد بگیرید که چگونه یک معماری میکروسرویس طراحی کنید؟

در کارگاه من، شما با استفاده از Assemblage برای طراحی معماری microsevice برای برنامه خود آشنا خواهید شد.

متن نوشته

شما در حال توسعه یک برنامه کاربردی سازمانی حیاتی برای کسب و کار هستید. شما باید تغییرات را به سرعت، مکرر و قابل اعتماد ارائه دهید - همانطور که با معیارهای DORA اندازه گیری می شود - تا کسب و کار شما در دنیای بی ثبات، نامطمئن، پیچیده و مبهم امروزی رونق بگیرد. در نتیجه، سازمان مهندسی شما در قالب تیم های کوچک، با هم پیوندی آزاد و متقابل سازماندهی شده است. هر تیم با استفاده از روش های DevOps همانطور که در کتاب راهنمای DevOps تعریف شده است، نرم افزار ارائه می کند. به ویژه، استقرار مداوم را تمرین می کند. این تیم جریانی از تغییرات کوچک و مکرر را ارائه می دهد که توسط یک خط لوله استقرار خودکار آزمایش می شوند و در تولید مستقر می شوند.

یک تیم مسئول یک یا چند زیر دامنه است. یک زیر دامنه یک مدل قابل پیاده سازی از برشی از عملکردهای تجاری است که به عنوان قابلیت تجاری شناخته می شود. این شامل منطق تجاری است که از نهادهای تجاری (با نام مستعار DDD) که قوانین تجاری را اجرا می کنند و آداپتورهایی که با دنیای خارج ارتباط برقرار می کنند، تشکیل شده است. به عنوان مثال، یک زیر دامنه مبتنی بر جاوا، شامل کلاس هایی است که در بسته هایی سازماندهی شده اند که در یک فایل JAR کامپایل شده اند.

زیر دامنه ها رفتار برنامه را پیاده سازی می کنند که شامل مجموعه ای از عملیات (سیستم) است. یک عملیات به یکی از سه روش فراخوانی می شود: درخواست های همزمان و ناهمزمان از مشتریان. رویدادهای منتشر شده توسط سایر برنامه ها و خدمات؛و گذر زمانجهش می یابد و نهادهای تجاری را در یک یا چند زیر دامنه جستجو می کند.

مسئله

چگونه می توان زیر دامنه ها را در یک یا چند جزء قابل استقرار/اجرا سازماندهی کرد؟

نیروها

• اجزای ساده - اجزای ساده متشکل از چند زیر دامنه نسبت به اجزای پیچیده راحت تر قابل درک و نگهداری هستند
• استقلال تیم - یک تیم باید بتواند نرم افزار خود را مستقل از سایر تیم ها توسعه، آزمایش و استقرار دهد
• خط لوله استقرار سریع - بازخورد سریع و فرکانس استقرار بالا ضروری است و توسط یک خط لوله استقرار سریع فعال می شود، که به نوبه خود به قطعاتی نیاز دارد که ساخت و آزمایش سریع داشته باشند.
• پشتیبانی از پشته های فناوری متعدد - زیر دامنه ها گاهی اوقات با استفاده از فناوری های مختلف پیاده سازی می شوند. و توسعه دهندگان باید پشته فناوری برنامه را توسعه دهند، به عنوان مثال. از نسخه های فعلی زبان ها و چارچوب ها استفاده کنید
• تفکیک بر اساس ویژگی ها - به عنوان مثال. الزامات منابع برای بهبود مقیاس پذیری، الزامات در دسترس بودن آنها برای بهبود در دسترس بودن، الزامات امنیتی آنها برای بهبود امنیت و غیره.

• فعل و انفعالات ساده - عملیاتی که محلی برای یک مؤلفه است یا شامل چند تعامل ساده بین مؤلفه ها است، درک و عیب یابی آسان تر از یک عملیات توزیع شده است، به ویژه عملیاتی که متشکل از تعاملات پیچیده است.
• تعاملات کارآمد - یک عملیات توزیع شده که شامل تعداد زیادی رفت و برگشت شبکه و انتقال داده های بزرگ است، می تواند بسیار ناکارآمد باشد.
• ترجیح دادن ACID به BASE - اجرای یک عملیات به عنوان یک تراکنش ACID آسان تر است تا به عنوان مثال، در نهایت حماسه های ثابت
• کوپلینگ زمان اجرا را به حداقل برسانید - برای به حداکثر رساندن در دسترس بودن و کاهش تأخیر یک عملیات
• کوپلینگ زمان طراحی را به حداقل برسانید - احتمال تغییر سرویس ها را کاهش دهید، که بهره وری را کاهش می دهد.

راه حل

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

برخی از عملیات ها محلی خواهند بود (که توسط یک سرویس پیاده سازی می شوند)، در حالی که برخی دیگر در چندین سرویس توزیع می شوند. یک عملیات توزیع شده با استفاده همزمان با استفاده از پروتکلی مانند HTTP/REST یا به صورت ناهمزمان با استفاده از یک واسطه پیام مانند آپاچی کافکا اجرا می شود.

مثال ها

برنامه تجارت الکترونیک ساختگی

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

کد را به من نشان بده

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

زمینه حاصل

فواید

این راه حل دارای چندین مزیت است:

• خدمات ساده - هر سرویس از تعداد کمی زیر دامنه تشکیل شده است - احتمالاً فقط یک - و بنابراین درک و نگهداری آسان تر است.
• استقلال تیم - یک تیم می تواند خدمات خود را مستقل از سایر تیم ها توسعه، آزمایش و استقرار دهد
• خط لوله استقرار سریع - هر سرویس به سرعت آزمایش می شود زیرا نسبتاً کوچک است و می تواند به طور مستقل مستقر شود
• پشتیبانی از پشته های چند فناوری - خدمات مختلف می توانند از پشته های مختلف فناوری استفاده کنند و می توانند به طور مستقل به روز شوند
• زیر دامنه های جدا شده توسط ویژگی های آنها - زیر دامنه ها می توانند با ویژگی های آنها به خدمات جداگانه جدا شوند تا بتوانند مقیاس پذیری ، در دسترس بودن ، امنیت و غیره را بهبود بخشند

اشکالاتی

این راه حل دارای چندین اشکال (بالقوه) است:

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

مسائل

موضوعات بسیاری وجود دارد که باید به آنها بپردازید.

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

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

چگونه عملیات توزیع شده را اجرا کنیم؟

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

• حماسه ، که یک دستور توزیع شده را به عنوان یک سری معاملات محلی پیاده سازی می کند
• ماکت سمت فرمان ، که داده های فقط خواندنی را به سرویس ارائه می دهد که یک دستور را پیاده سازی می کند
• ترکیب API ، که یک پرس و جو توزیع شده را به عنوان یک سری نمایش داده شد
• CQRS ، که یک پرس و جو توزیع شده را به عنوان یک سری نمایش داده های محلی پیاده سازی می کند

الگوهای SAGA ، Commany-Replica و CQRS از پیام رسانی ناهمزمان استفاده می کنند. خدمات به طور معمول برای به روزرسانی اتمی نهادهای تجاری مداوم و ارسال پیام نیاز به استفاده از الگوی صندوق عقب معامله دارند.

الگوهای مرتبط

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

• الگوهای همکاری SService:
  • حماسه ، که یک دستور توزیع شده را به عنوان یک سری معاملات محلی پیاده سازی می کند
  • ماکت سمت فرمان ، که داده های فقط خواندنی را به سرویس ارائه می دهد که یک دستور را پیاده سازی می کند
  • ترکیب API ، که یک پرس و جو توزیع شده را به عنوان یک سری نمایش داده شد
  • CQRS ، که یک پرس و جو توزیع شده را به عنوان یک سری نمایش داده های محلی پیاده سازی می کند
  • تجمع ورود به سیستم
  • معیارهای کاربرد
  • ورود به سیستم حسابرسی
  • ردیابی توزیع شده
  • ردیابی استثناء
  • API بررسی سلامتی
  • استقرار و تغییرات را ثبت کنید
  • ترکیب قطعه صفحه سمت سرور
  • ترکیب UI طرف مشتری

  استفاده های شناخته شده

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

  Netflix ، که یک سرویس پخش ویدئویی بسیار محبوب است که مسئولیت حداکثر 30 ٪ از ترافیک اینترنت را بر عهده دارد ، دارای معماری مقیاس وسیع و خدمات محور است. آنها بیش از یک میلیارد تماس در روز به API پخش ویدیویی خود از بیش از 800 نوع دستگاه مختلف انجام می دهند. هر API طرفداران را به طور متوسط شش تماس برای خدمات باطن فراخوانی می کند.

  Amazon. com در ابتدا معماری دو لایه داشت. به منظور مقیاس ، آنها به یک معماری خدمات محور متشکل از صدها سرویس باطن مهاجرت کردند. چندین برنامه با این سرویس ها از جمله برنامه هایی که وب سایت Amazon. com و API سرویس وب را پیاده سازی می کنند تماس می گیرند. برنامه وب سایت Amazon. com برای دریافت داده هایی که برای ساخت یک صفحه وب استفاده می شود ، 100-150 سرویس را فراخوانی می کند.

  سایت حراج eBay. com همچنین از یک معماری یکپارچه به یک معماری خدمات گرا تبدیل شد. ردیف برنامه شامل چندین برنامه مستقل است. هر برنامه منطق کسب و کار را برای یک منطقه عملکرد خاص مانند خرید یا فروش پیاده سازی می کند. هر برنامه از تقسیمات محور X و برخی از برنامه ها مانند جستجو از شکاف محور z استفاده می کند. eBay. com همچنین ترکیبی از مقیاس بندی سبک X- ، Y- و Z را در ردیف پایگاه داده اعمال می کند.

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

  مثال ها

  کریس ریچاردسون نمونه هایی از برنامه های مبتنی بر میکروسرویس را دارد.

  همچنین ببینید

  • JFOKUS 2020 - مکعب ها ، شش ضلعی ، مثلث و بیشتر - درک میکروسرویس - مقدمه خوبی برای معماری میکروسرویس ارائه می دهد.
  • الگوهای میکروسرویس