معماری میکروسرویس یک روش متمایز برای توسعه سیستم‌های نرم‌افزاری است که سعی می‌کند بر ساخت ماژول‌های تک عملکردی با رابط‌ها و عملیات‌های کاملاً تعریف شده تمرکز کند.
این روند در سال های اخیر رشد کرده است زیرا شرکت ها به دنبال چابک تر شدن و حرکت به سمت DevOps و آزمایش مداوم هستند.
میکروسرویس‌ها مزایای زیادی برای تیم‌های Agile و DevOps دارند - همانطور که مارتین فاولر اشاره می‌کند، Netflix، eBay، Amazon، Twitter، PayPal و سایر ستاره‌های فناوری همگی از معماری یکپارچه به معماری میکروسرویس تکامل یافته‌اند.
تمایز
بر خلاف میکروسرویس ها، یک برنامه یکپارچه به عنوان یک واحد مستقل ساخته شده است. بنابراین هرگونه تغییر در برنامه کند است، زیرا کل سیستم را تحت تأثیر قرار می دهد. تغییری که در بخش کوچکی از کد ایجاد می شود ممکن است نیاز به ساخت و استقرار یک نسخه کاملاً جدید از نرم افزار داشته باشد. بنابراین برای مقیاس کردن یک تابع خاص از یک برنامه همچنین به این معنی است که باید کل برنامه را مقیاس کنید.
ماژولار بودن کلید است
میکروسرویس ها چالش های سیستم های یکپارچه را با ماژولار بودن تا حد امکان حل می کنند. در ساده‌ترین شکل، آنها به ساخت یک برنامه کاربردی به‌عنوان مجموعه‌ای از سرویس‌های کوچک کمک می‌کنند که هرکدام در فرآیند خاص خود اجرا می‌شوند و به‌طور مستقل قابل استقرار هستند. این سرویس ها ممکن است به زبان های برنامه نویسی مختلف نوشته شده باشند و حتی ممکن است از تکنیک های مختلف ذخیره سازی داده ها استفاده کنند.
در حالی که این کارها را مقیاس پذیرتر و انعطاف پذیرتر می کند، نیاز به تغییری پویا دارد. میکروسرویس ها اغلب از طریق API ها به هم متصل می شوند و می توانند از بسیاری از ابزارها و راه حل هایی استفاده کنند که در اکوسیستم RESTful و وب سرویس رشد کرده اند. آزمایش این APIها اکنون غیرقابل مذاکره برای اطمینان از استقرار نرم افزار با کیفیت است. با اعتبارسنجی مسیرهای ارتباطی و جریان داده ها در سراسر استقرار میکروسرویس شما کار می کند.
مزایای میکروسرویس ها
استقرار ساده تر
بدون تأثیرگذاری بر سایر خدمات، در قطعات تحت اللفظی مستقر شود.
درک ساده تر
دنبال کردن کد آسان تر است زیرا تابع ایزوله و کمتر وابسته است.
قابل استفاده مجدد در سراسر تجارت
خدمات کوچکی مانند سیستم های پرداخت یا ورود به سیستم را در سراسر کسب و کار به اشتراک بگذارید.
جداسازی سریع تر نقص
هنگامی که یک تست با شکست مواجه شد یا سرویس از کار افتاد، آن را به سرعت ایزوله کنید.
به حداقل رساندن ریسک ناشی از تغییر
از قفل شدن در فن آوری ها یا زبان ها اجتناب کنید - تغییر در پرواز با حداقل خطر.
آشنایی با معماری میکروسرویس
همانطور که هیچ تعریف رسمی از اصطلاح میکروسرویس وجود ندارد، هیچ مدل استانداردی وجود ندارد که در هر سیستمی بر اساس این سبک معماری نشان داده شود. اما اکثر سیستم های میکروسرویس دارای برخی ویژگی های مشترک هستند.
ببینید چگونه SwaggerHub به تیم ها کمک می کند تا با Microservices شروع کنند
شش ویژگی میکروسرویس ها
1.اجزای چندگانه
می توان آن را به چندین سرویس جزء تقسیم کرد. چرا؟ به طوری که هر سرویس را می توان به طور مستقل بدون به خطر انداختن یکپارچگی یک برنامه مستقر، بهینه سازی و باز استقرار کرد. به این ترتیب، ممکن است به جای استقرار مجدد کل برنامه ها، تنها نیاز به تغییر یک سرویس مجزا داشته باشید. اما این رویکرد دارای جنبه‌های منفی است، از جمله تماس‌های گران قیمت از راه دور (به‌جای تماس‌های در حین فرآیند)، APIهای راه دور با دانه درشت‌تر، و پیچیدگی بیشتر هنگام توزیع مجدد مسئولیت‌ها بین مؤلفه‌ها.
2.ساخته شده برای تجارت
سبک میکروسرویس ها معمولاً بر اساس قابلیت ها و اولویت های تجاری سازماندهی می شود. برخلاف رویکرد توسعه یکپارچه سنتی – که در آن تیم‌های مختلف هر کدام تمرکز خاصی بر مثلاً رابطهای کاربری، پایگاه‌های داده، لایه‌های فناوری یا منطق سمت سرور دارند – معماری میکروسرویس از تیم‌های چندکارهی استفاده می‌کند. هر تیم مسئول تولید محصولات خاص بر اساس خدمات فردی است که از طریق گذرگاه پیام ارتباط برقرار می کند. در ریزسرویس‌ها، یک تیم مالک محصول در طول عمر خود است، همانطور که در اصل آمازون که اغلب ذکر می‌شود، شما آن را می‌سازید، اجرا می‌کنید.
3.مسیریابی ساده
میکروسرویس‌ها تا حدودی مانند سیستم یونیکس کلاسیک عمل می‌کنند: درخواست‌ها را دریافت می‌کنند، آنها را پردازش می‌کنند و بر اساس آن پاسخ تولید می‌کنند. این برخلاف بسیاری از محصولات دیگر مانند ESB (اتوبوس های خدمات سازمانی) است. اینجاست که از سیستم‌های با فناوری پیشرفته برای مسیریابی پیام، طراحی رقص و اعمال قوانین تجاری استفاده می‌شود. می توان گفت که میکروسرویس ها دارای نقاط پایانی هوشمندی هستند که اطلاعات را پردازش می کنند و منطق را اعمال می کنند، و "لوله های گنگ" که اطلاعات از طریق آنها جریان می یابد.
4.غیر متمرکز
از آنجایی که ریزسرویس‌ها شامل فناوری‌های متنوعی می‌شوند، روش‌های قدیمی مدیریت متمرکز بهینه نیستند. جامعه میکروسرویس ها از حاکمیت غیرمتمرکز حمایت می کنند تا توسعه دهندگان آن بتوانند ابزارهایی تولید کنند که توسط دیگران برای حل مشکلات مشابه مورد استفاده قرار گیرد. درست مانند حاکمیت غیرمتمرکز، معماری میکروسرویس از مدیریت غیرمتمرکز داده حمایت می کند. سیستم های یکپارچه از یک پایگاه داده منطقی واحد در برنامه های مختلف استفاده می کنند. در یک برنامه میکروسرویس، هر سرویس معمولا پایگاه داده منحصر به فرد خود را مدیریت می کند.
5.مقاوم در برابر شکست
ریزسرویس‌ها مانند یک کودک خوب برای مقابله با شکست طراحی شده‌اند. از آنجایی که چندین سرویس مختلف با هم ارتباط برقرار می کنند، ممکن است یک سرویس با شکست مواجه شود (به عنوان مثال، زمانی که تامین کننده در دسترس نیست). در این موارد، مشتری باید به خدمات همسایه‌اش اجازه دهد تا در حالی که با ظرافت خم می‌شود، کار کنند. با این حال، نظارت بر میکروسرویس ها می تواند به جلوگیری از خطر خرابی کمک کند. به دلایل واضح، این نیاز در مقایسه با معماری سیستم‌های یکپارچه، پیچیدگی بیشتری به میکروسرویس‌ها می‌افزاید.
6.تکاملی
این یک طراحی تکاملی است و دوباره برای سیستم‌های تکاملی که نمی‌توانید به طور کامل پیش‌بینی کنید چه دستگاه‌هایی در آینده به برنامه شما دسترسی خواهند داشت، ایده‌آل است. بسیاری از برنامه‌ها بر اساس معماری یکپارچه شروع می‌شوند، اما با ظهور چندین مورد پیش‌بینی‌نشده، میتوان به آرامی به ریزسرویس‌هایی که بر روی یک معماری یکپارچه قدیمی‌تر از طریق APIها تعامل دارند، تغییر داد.
نمونه هایی از میکروسرویس ها
نتفلیکس معماری گسترده ای دارد که از یکپارچه به SOA تکامل یافته است. هر روز بیش از یک میلیارد تماس، از بیش از 800 نوع دستگاه مختلف، به API پخش ویدئو دریافت می کند. سپس هر تماس API حدود پنج تماس اضافی را به سرویس باطن درخواست می‌کند.
آمازون نیز به میکروسرویس ها مهاجرت کرده است. آنها تماس‌های بی‌شماری را از برنامه‌های مختلف دریافت می‌کنند - از جمله برنامه‌هایی که API سرویس وب و همچنین خود وب‌سایت را مدیریت می‌کنند - که مدیریت آن برای معماری قدیمی و دو لایه‌شان به سادگی غیرممکن بود.
مزایا و معایب میکروسرویس
مانند هر چیز دیگری، اینکه آیا یک معماری میکروسرویس برای شما مناسب است یا خیر به نیازهای شما بستگی دارد، زیرا همه آنها مزایا و معایب خود را دارند. در اینجا خلاصه ای از برخی از خوب و بدها آورده شده است:
طرفداران
- به توسعه دهندگان این آزادی را می دهد که به طور مستقل خدمات را توسعه و استقرار دهند
- می تواند توسط یک تیم نسبتا کوچک توسعه یابد
- کد برای خدمات مختلف می تواند به زبان های مختلف نوشته شود (اگرچه بسیاری از پزشکان آن را منع می کنند)
- ادغام آسان و استقرار خودکار (با استفاده از ابزارهای یکپارچه سازی پیوسته منبع باز مانند جنکینز، هادسون و غیره)
- درک و تغییر برای توسعه دهندگان آسان است، بنابراین می تواند به یک عضو جدید تیم کمک کند تا به سرعت سازنده شود
- توسعه دهندگان می توانند از آخرین فناوری ها استفاده کنند
- کد بر اساس قابلیت های تجاری سازماندهی شده است
- ظرف وب را سریعتر راه اندازی می کند، بنابراین استقرار نیز سریعتر است
- هنگامی که تغییر در بخش خاصی از برنامه مورد نیاز است، فقط سرویس مربوطه را می توان تغییر داد و مجدداً مستقر کرد - بدون نیاز به تغییر و استقرار مجدد کل برنامه
- ایزوله‌سازی بهتر خطا: اگر یک میکروسرویس از کار بیفتد، دیگری به کار خود ادامه می‌دهد (اگرچه یک ناحیه مشکل‌ساز از یک برنامه مونولیت می‌تواند کل سیستم را به خطر بیندازد)
- مقیاس بندی و ادغام با خدمات شخص ثالث آسان است
- عدم تعهد طولانی مدت به پشته فناوری
منفی
- به دلیل استقرار توزیع شده، آزمایش می تواند پیچیده و خسته کننده شود - و اغلب مانع از برخی از مزایای مقیاس پذیری میکروسرویس ها می شود.
- افزایش تعداد خدمات می تواند منجر به موانع اطلاعاتی شود
- پیچیدگی بیشتر به دلیل کاهش تحمل خطا، تأخیر شبکه و انواع فرمت های پیام و همچنین تعادل بار توسط توسعه دهندگان
- به عنوان یک سیستم توزیع شده، می تواند منجر به تکرار تلاش شود
- هنگامی که تعداد خدمات افزایش می یابد، یکپارچه سازی و مدیریت کل محصولات می تواند پیچیده شود
- توسعه دهندگان باید با پیچیدگی اضافی یک سیستم توزیع شده مقابله کنند
- توسعه دهندگان باید یک مکانیسم ارتباطی بین سرویس ها را پیاده سازی کنند
- رسیدگی به موارد استفاده که بیش از یک سرویس را بدون استفاده از تراکنش های توزیع شده در بر می گیرد، نه تنها دشوار است، بلکه نیازمند همکاری بین تیم های مختلف است.
فشار دادن سوزن به جلو
میکروسرویس ها یک گلوله نقره ای نیستند و با اجرای آنها ارتباطات، کار تیمی و سایر مشکلاتی را که ممکن است ضمنی بوده باشند اما اکنون به اجبار آشکار شده اند را آشکار می کنید. اما چند راه برای کاهش این افت وجود دارد:
- استفاده از API Gateways در Microservices می تواند زمان و تلاش ساخت و کیفیت کیفیت را تا حد زیادی کاهش دهد
- اجرای آزمایش قرارداد با Pactflow یک راه اثبات شده برای کاهش اتکا به تست پیچیده E2E است.
یکی از مسائل رایج شامل به اشتراک گذاری منطق طرحواره/ اعتبارسنجی در بین سرویس ها است. آنچه A برای در نظر گرفتن برخی داده ها معتبر نیاز دارد، همیشه در مورد B صدق نمی کند، اگر B نیازهای متفاوتی داشته باشد. بهترین توصیه اعمال نسخه سازی و توزیع طرحواره در کتابخانه های مشترک است.
سپس تغییرات در کتابخانه ها به بحث بین تیم ها تبدیل می شود. همچنین، با نسخه‌سازی قوی، وابستگی‌هایی به وجود می‌آید که می‌تواند باعث سربار بیشتر شود. بهترین روش برای غلبه بر این، برنامه ریزی در مورد سازگاری با عقب و پذیرش تست های رگرسیون از سرویس ها/تیم های خارجی است. اینها شما را وادار می‌کنند که قبل از ایجاد اختلال در روند کسب و کار دیگران، مکالمه داشته باشید، نه بعد از آن.
معماری میکروسرویس چگونه کار می کند
1) یکپارچه ها و قانون کانوی
قانون کانوی: "سازمان هایی که سیستم ها را طراحی می کنند ... مجبور به تولید طرح هایی هستند که کپی هایی از ساختارهای ارتباطی این سازمان ها هستند."
تصور کنید شرکت X با دو تیم: پشتیبانی و حسابداری. به طور غریزی، ما فعالیت های پرخطر را جدا می کنیم. تصمیم گیری در مورد مسئولیت هایی مانند بازپرداخت مشتری دشوار است. در نظر بگیرید که چگونه میتوانیم به سؤالاتی مانند «آیا تیم حسابداری افراد کافی برای پردازش بازپرداخت و اعتبار مشتری دارد؟» پاسخ دهیم؟ یا، "آیا بهتر است از افراد پشتیبان ما اعتبار استفاده کنیم و با مشتریان ناامید برخورد کنیم؟"
پاسخ‌ها با خط‌مشی جدید شرکت X حل می‌شوند: پشتیبانی می‌تواند اعتباری اعمال کند، اما برای پردازش بازپرداخت به حسابداری نیاز است. نقش ها و مسئولیت ها در این سیستم به هم پیوسته با موفقیت تقسیم شده است، در حالی که رضایت مشتری را به دست آورده و خطرات را به حداقل می رساند.
به همین ترتیب، در ابتدای هر طراحی نرم‌افزاری، شرکت‌ها معمولاً یک تیم جمع می‌کنند و یک پروژه ایجاد می‌کنند. با گذشت زمان، تیم رشد می‌کند و پروژه‌های متعددی در یک پایگاه کد تکمیل می‌شوند.
این اغلب منجر به پروژه‌های رقیب می‌شود: برای دو نفر کار کردن در اهداف متقابل در یک حوزه کد بدون ایجاد معاوضه دشوار است. و افزودن افراد بیشتر به معادله فقط مشکل را بدتر می کند. همانطور که فرد بروکس می گوید، 9 زن نمی توانند در یک ماه بچه دار شوند.
علاوه بر این، در شرکت X (یا هر تیم توسعه‌دهنده)، اولویت‌ها اغلب تغییر می‌کنند که منجر به مشکلات ارتباطی می‌شود. مورد با بالاترین اولویت ماه گذشته ممکن است باعث شده باشد که تیم به شدت برای ارسال کد فشار بیاورد - اما اکنون یک کاربر مشکلی را گزارش می‌کند و ما دیگر زمانی برای حل آن به دلیل اولویت این ماه نداریم. این قانع‌کننده‌ترین دلیل برای اتخاذ رویکردهای سرویس‌محور (SOA) از جمله انواع میکروسرویس‌ها است. SOA ها اصطکاک های موجود بین تغییرات مدیریت، دانش دامنه و اولویت های تجاری را تشخیص می دهند و به تیم های توسعه دهنده اجازه می دهند تا به آنها رسیدگی کنند. البته، این به خودی خود یک معامله است - این نیاز به هماهنگی دارد. اما به شما این امکان را می دهد که اصطکاک را متمرکز کنید و کارایی را معرفی کنید، برخلاف اینکه از تعداد زیادی ناکارآمدی کوچک رنج می برید.
از همه مهمتر، اجرای معماری SOA یا میکروسرویس شما را مجبور می کند که اصل جداسازی رابط را اعمال کنید. با توجه به ماهیت متصل سیستم های بالغ، هنگام جداسازی مسائل، رویکرد معمولی یافتن یک درز یا نقطه ارتباطی، سپس ترسیم یک خط نقطه چین بین دو نیمه سیستم است.
با این حال، بدون فکر دقیق، این می تواند منجر به ایجاد تصادفی دو تکه کوچکتر اما در حال رشد شود که اکنون با نوعی پل مرتبط هستند. پیامد این امر می تواند پنهان کردن کدهای مهم در سمت اشتباه یک مانع باشد: تیم A به خود زحمت نمی دهد از آن مراقبت کند، در حالی که تیم B به آن نیاز دارد، بنابراین آنها آن را دوباره اختراع می کنند.
2) میکرو سرویس ها: اجتناب از یکپارچه ها
ما برخی از مشکلات را نام برده ایم که معمولاً ظاهر می شوند. اکنون بیایید شروع به بررسی برخی از راه حل ها کنیم.
چگونه میتوانید خدمات نسبتاً مستقل و در عین حال یکپارچه را بدون ایجاد یکپارچه‌های تصادفی اجرا کنید؟
خوب، فرض کنید یک برنامه کاربردی بزرگ دارید، مانند نمونه شرکت X ما در زیر، و در حال تقسیم کد و تیم ها به مقیاس می باشید. به جای یافتن یک بخش کامل برای جدا کردن، می توانید به دنبال چیزی در لبه نمودار برنامه باشید. شما می توانید بگویید که اینها کدام بخش هستند زیرا هیچ چیز به آنها بستگی ندارد.
در مثال ما، فلش‌هایی که به Printer و Storage اشاره می‌کنند نشان می‌دهند که این دو چیز هستند که میتوان به راحتی از برنامه اصلی ما حذف و انتزاع کرد. چاپ یک شغل یا فاکتور بی ربط است. یک چاپگر فقط داده های قابل چاپ می خواهد. تبدیل این موارد - چاپگر و ذخیره‌سازی - به سرویس‌های خارجی از مشکل یکپارچه جلوگیری می‌کند. همچنین منطقی است، زیرا آنها چندین بار استفاده می شوند، و چیزهای کمی وجود دارد که بتوان دوباره اختراع کرد. موارد استفاده از تجربه به خوبی شناخته شده است، بنابراین می توانید از حذف تصادفی عملکرد کلید جلوگیری کنید.
3) اشیاء خدمات و داده های شناسایی
پس چگونه از یکپارچه به خدمات برویم؟ یک راه از طریق اشیاء سرویس است. بدون حذف کد از برنامه خود، به طور موثر شروع به ساختاردهی آن می کنید که انگار کاملاً خارجی است.
برای انجام این کار، ابتدا باید اقداماتی را که میتوان انجام داد و داده‌هایی که به‌عنوان ورودی و خروجی آن اقدامات وجود دارد، متمایز کرد. کد زیر را با مفهوم انجام کاری مفید و وضعیت آن کار در نظر بگیرید.
# A class to model a core transaction and execute it
class Job
def initialize
@status = 'Queued'
end
def do_useful_work
....
@status = 'Finished'
end
def finished?
return @status == 'Finished'
end
def ready?
return @status == 'Queued'
end
end
برای اینکه این کار شبیه یک میکروسرویس به نظر برسد، چه کاری انجام می‌دهید؟
# Service to do useful work and modify a status
class JobService
def do_useful_work(job_status)
....
job_status.finish!
return job_status
end
end
# A model of our Job's status
class JobStatus
def initialize
@status = 'Queued'
end
def finished?
return @status == 'Finished'
end
def ready?
return @status == 'Queued'
end
def finish!
@status = 'Finished'
end
اکنون ما دو کلاس مجزا را متمایز کرده ایم: یکی که داده ها را مدل می کند و دیگری که عملیات را انجام می دهد. نکته مهم، کلاس JobService ما وضعیت کمی دارد یا اصلاً وجود ندارد - میتوانید اقدامات مشابه را بارها و بارها فراخوانی کنید، فقط داده‌ها را تغییر دهید و انتظار داشته باشید که نتایج ثابتی دریافت کنید.
اگر JobService به نحوی از طریق شبکه شروع به کار کرد، برنامه یکپارچه ما اهمیتی نمی‌دهد. جابجایی این نوع کلاس ها به یک کتابخانه، و جایگزینی یک کلاینت شبکه برای پیاده سازی قبلی، به شما این امکان را می دهد که کد موجود را به یک سرویس خارجی مقیاس پذیر تبدیل کنید.
این معماری شش ضلعی است، که در آن هسته برنامه و هماهنگی شما در مرکز قرار دارد و اجزای خارجی برای دستیابی به اهداف شما در اطراف آن هماهنگ شده اند.
4) هماهنگی و لوله های "خنگ".
حال بیایید نگاهی دقیق‌تر به این بیندازیم که چه چیزی چیزی را در مقایسه با SOA سنتی یک میکروسرویس می‌کند.
شاید مهم ترین تمایز، عوارض جانبی باشد. میکروسرویس ها از آنها اجتناب می کنند. برای اینکه بفهمیم چرا، اجازه دهید به یک رویکرد قدیمی تر نگاه کنیم: لوله های یونیکس.
در بالا، دو برنامه به هم متصل شده‌اند: اولی همه فایل‌های یک فهرست را فهرست می‌کند، دومی تعداد خطوط یک جریان ورودی را می‌خواند. تصور کنید یک برنامه قابل مقایسه بنویسید، سپس باید آن را به شکل زیر تغییر دهید:
ایجاد قطعات کوچک عملکرد متکی بر نتایج قابل تکرار، یک مکانیسم استاندارد برای ورودی و خروجی، و یک کد خروجی برای یک برنامه برای نشان دادن موفقیت یا عدم موفقیت آن است.
ما می دانیم که این کار از روی شواهد مشاهده ای کار می کند، و همچنین می دانیم که یک لوله یونیکس یک رابط "گنگ" است زیرا هیچ دستور کنترلی ندارد. لوله SRP را با فشار دادن داده‌ها از A به B اعمال می‌کند، و این به اعضای خط لوله بستگی دارد که تصمیم بگیرند آیا ورودی غیرقابل قبول است.
بیایید به سیستم شغل و فاکتور شرکت X برگردیم. هر کدام یک تراکنش را کنترل می کنند و می توانند با هم یا جداگانه استفاده شوند: فاکتورها را می توان برای مشاغل ایجاد کرد، مشاغل را می توان بدون فاکتور ایجاد کرد و فاکتورها را می توان بدون کار ایجاد کرد.
برخلاف دستورات پوسته یونیکس، سیستم‌هایی که دارای مشاغل و فاکتورها هستند، کاربران خود را دارند که به طور مستقل کار می‌کنند. اما بدون بازگشت به یک سیاست، اجرای قوانین برای هر یک از سیستم ها در سطح جهانی غیرممکن است.
فرض کنید می‌خواهیم عملیات کلیدی را که به طور مکرر اجرا می‌شوند استخراج کنیم - خدمات ارسال فاکتور، تغییر وضعیت شغل و تغییر وضعیت فاکتور. اینها کاملاً جدا از وظیفه تداوم داده ها هستند.
این به ما امکان می دهد تا اجزای مجزا را به دو خط لوله متصل کنیم:
کاربر یک فاکتور دستی ایجاد می کند
داده ها را به فاکتور اضافه می کند، وضعیت ایجاد شده است
- BillingPolicyService را فراخوانی می کند تا مشخص کند که چه زمانی یک فاکتور برای یک مشتری خاص قابل پرداخت است
فاکتور برای مشتری صادر می شود
همچنان به سرویس داده فاکتور، وضعیت ارسال شده است
کاربر یک کار را تمام می کند و یک فاکتور ایجاد می کند
کار اعتبار سنجی تکمیل شدنی است
داده ها را به فاکتور اضافه می کند، وضعیت ایجاد شده است
- BillingPolicyService را فراخوانی می کند تا مشخص کند که چه زمانی یک فاکتور برای یک مشتری خاص قابل پرداخت است
فاکتور برای مشتری صادر می شود
همچنان به سرویس داده فاکتور، وضعیت ارسال شده است
مراحل مربوط به محاسبه صورتحساب غیرممکن است، و تهیه پیش‌نویس فاکتور یا پیش‌نمایش مبالغ قابل پرداخت توسط مشتری با استفاده از ریزسرویس‌های اختصاصی جدید، امری بی‌اهمیت است.
برخلاف SOA سنتی، تفاوت در اینجا این است که ما جزئیات سطح پایین را از طریق یک رابط ساده در معرض نمایش قرار می دهیم، در مقایسه با یک فراخوانی API سطح بالا که ممکن است کل یک عملیات تجاری را اجرا کند.
با یک API سطح بالا، در واقع، سیم‌کشی مجدد اجزای کوچک با هم دشوار می‌شود، زیرا طراح سرویس بسیاری از درزها یا انتخاب‌هایی را که میتوانیم با ارائه یک رابط یک‌شات انتخاب کنیم، حذف کرده است.
در این مرحله، تکرار منطق، سیاست و قوانین کسب‌وکار، بسیاری را به سمتی سوق می‌دهد که به‌طور سنتی این پیچیدگی را به یک گذرگاه خدمات یا ابزار هماهنگ‌سازی گردش کار متمرکز و منحصربه‌فرد سوق دهند.
با این حال، مزیت حیاتی معماری میکروسرویس این نیست که ما هرگز قوانین/فرآیندها/سیاست‌های تجاری را به اشتراک نمی‌گذاریم، بلکه این است که آنها را در بسته‌های مجزا و همسو با نیازهای تجاری قرار می‌دهیم. این نه تنها به این معنی است که سیاست توزیع شده است، بلکه به این معنی است که شما می توانید فرآیندهای کسب و کار خود را بدون ریسک تغییر دهید.
SOA در مقابل میکروسرویس ها
ممکن است بگویید «یک دقیقه صبر کن»، «آیا این فقط نام دیگری برای SOA نیست؟» معماری سرویس گرا در چند سال اول این قرن ظهور کرد و معماری میکروسرویس (که برخی به اختصار MSA نامیده می شوند) شباهت های زیادی دارد.
با این حال، SOA سنتی یک چارچوب گسترده‌تر است و می‌تواند به معنای چیزهای مختلفی باشد. برخی از طرفداران میکروسرویس ها تگ SOA را به طور کلی رد می کنند، در حالی که برخی دیگر میکروسرویس ها را یک شکل ایده آل و تصفیه شده SOA می دانند.
در هر صورت، ما فکر می‌کنیم که تفاوت‌های کافی برای توجیه مفهوم «سرویس میکرو» متمایز وجود دارد (حداقل به عنوان شکل خاصی از SOA، همانطور که بعداً نشان خواهیم داد).
به عنوان مثال، مدل SOA معمولی معمولاً دارای ESB های وابسته بیشتری است و میکروسرویس ها از مکانیسم های پیام رسانی سریع تری استفاده می کنند. SOA همچنین بر برنامه‌نویسی ضروری تمرکز دارد، در حالی که معماری میکروسرویس‌ها بر سبک برنامه‌نویسی واکنش‌گرا متمرکز است.
علاوه بر این، مدل‌های SOA تمایل به داشتن یک پایگاه داده رابطهای بزرگتر دارند، در حالی که میکروسرویس‌ها اغلب از پایگاه‌های داده NoSQL یا micro-SQL (که می‌توانند به پایگاه‌های داده معمولی متصل شوند) استفاده می‌کنند. اما تفاوت واقعی در وهله اول به روش های معماری مورد استفاده برای رسیدن به مجموعه یکپارچه از خدمات مربوط می شود.
از آنجایی که همه چیز در دنیای دیجیتال تغییر می‌کند، تکنیک‌های توسعه چابک که می‌توانند با خواسته‌های تکامل نرم‌افزار همگام شوند بسیار ارزشمند هستند. بیشتر شیوه‌های مورد استفاده در معماری میکروسرویس‌ها از توسعه‌دهندگانی است که برنامه‌های نرم‌افزاری را برای سازمان‌های سازمانی بزرگ ایجاد کرده‌اند و می‌دانند که کاربران نهایی امروزی انتظار تجربه‌های پویا و در عین حال سازگار در طیف وسیعی از دستگاه‌ها را دارند.
برنامه های کاربردی مبتنی بر ابر مقیاس پذیر، سازگار، ماژولار و سریع در دسترس تقاضای زیادی دارند. و این باعث شده است که بسیاری از توسعه دهندگان رویکرد خود را تغییر دهند.
آینده معماری میکروسرویس
چه معماری میکروسرویس به سبک مطلوب توسعه دهندگان در آینده تبدیل شود یا خیر، به وضوح یک ایده قدرتمند است که مزایای جدی برای طراحی و اجرای برنامه های کاربردی سازمانی ارائه می دهد. بسیاری از توسعه‌دهندگان و سازمان‌ها، بدون استفاده از نام یا حتی برچسب‌گذاری عمل خود به عنوان SOA، از رویکردی برای استفاده از APIهایی استفاده می‌کنند که می‌توانند به عنوان میکروسرویس طبقه‌بندی شوند.
ما همچنین شاهد تعدادی از فناوری‌های موجود بوده‌ایم که سعی می‌کنند بخش‌هایی از بخش‌بندی و مشکلات ارتباطی را که هدف میکروسرویس‌ها حل‌وفصل آنها است، برطرف کنند. SOAP در توصیف عملیات موجود در یک نقطه پایانی مشخص و مکان کشف آن از طریق WSDL ها به خوبی عمل می کند. UDDI از نظر تئوری گام خوبی به سوی تبلیغات است که یک سرویس چه کاری می تواند انجام دهد و کجا می توان آن را پیدا کرد.
اما این فناوری ها با اجرای نسبتاً پیچیده به خطر افتاده اند و تمایل دارند در پروژه های جدیدتر مورد استفاده قرار نگیرند. سرویس‌های مبتنی بر REST با مشکلات مشابهی روبرو هستند و اگرچه میتوانید از WSDL با REST استفاده کنید، اما این کار به طور گسترده انجام نمی‌شود.
با فرض اینکه کشف یک مشکل حل شده است، به اشتراک گذاری طرح و مفهوم در بین برنامه های کاربردی نامرتبط همچنان یک پیشنهاد دشوار برای هر چیزی غیر از میکروسرویس ها و سایر سیستم های SOA باقی مانده است. فن آوری هایی مانند RDFS، OWL و RIF وجود دارند و استاندارد شده اند، اما معمولا مورد استفاده قرار نمی گیرند. JSON-LD و Schema.org نگاهی اجمالی به یک کل وب باز که تعاریف را به اشتراک می گذارد، ارائه می دهند، اما این موارد هنوز در شرکت های خصوصی بزرگ به کار گرفته نشده اند.
با این حال، قدرت تعاریف مشترک و استاندارد شده در داخل دولت نفوذ می کند. نتایج از طریق data.gov و data.gov.uk قابل مشاهده است، و میتوانید تعداد زیادی از مجموعه داده‌های موجود به عنوان داده‌های مرتبط با توصیف خوب را در اینجا کاوش کنید.
اگر بتوان روی تعداد زیادی از تعاریف استاندارد توافق کرد، گام‌های بعدی به احتمال زیاد به سمت نمایندگان است: برنامه‌های کوچکی که ریزسرویس‌های تعداد زیادی از فروشندگان را برای دستیابی به اهداف معین هماهنگ می‌کنند.
وقتی پیچیدگی روزافزون و الزامات ارتباطی برنامه‌های SaaS، ابزارهای پوشیدنی و اینترنت اشیا را به تصویر کلی اضافه می‌کنید، واضح است که معماری میکروسرویس احتمالاً آینده بسیار روشنی خواهد داشت.