سلام هابر ثبت نام برای جریان دوره جدید در حال حاضر در OTUS باز است . در آستانه شروع دوره، می خواهم مقاله اصلی خود را با شما به اشتراک بگذارم.
معرفی
انتخاب سبک معماری یکی از تصمیمات فنی اساسی در هنگام ساخت یک سیستم اطلاعاتی است. در این سری از مقالات، من پیشنهاد می کنم محبوب ترین سبک های معماری برای کاربردهای ساختمانی را تجزیه و تحلیل کنیم و به این سوال پاسخ دهیم که چه زمانی سبک معماری بیشتر ترجیح داده می شود. در روند ارائه، من سعی خواهم کرد یک زنجیره منطقی ترسیم کنم که توسعه سبک های معماری از یکپارچه تا میکروسرویس را توضیح می دهد.
کمی از تاریخ
اگر سعی کنید از توسعه دهندگان بپرسید: «چرا به میکروسرویس نیاز داریم؟»، پاسخ های مختلفی دریافت خواهید کرد. خواهید شنید که میکروسرویس ها مقیاس پذیری را بهبود می بخشند، درک کد را آسان تر می کنند، تحمل خطا را بهبود می بخشند، و گاهی اوقات می شنوید که به شما اجازه می دهند "کد خود را پاک کنید". بیایید به تاریخ نگاه کنیم تا هدف از ظهور میکروسرویس ها را درک کنیم.
به طور خلاصه، میکروسرویس ها در درک فعلی ما به شرح زیر ظهور کردند: در سال 2011، جیمز لوئیس، با تجزیه و تحلیل کار شرکت های مختلف، توجه را به ظهور یک الگوی جدید "micro-app" جلب کرد که SOA را از نظر تسریع استقرار بهینه سازی کرد. خدمات. کمی بعد، در سال 2012، در یک اجلاس معماری، این الگو به میکروسرویس تغییر نام داد. بنابراین، هدف اولیه از معرفی میکروسرویس ها، بهبود بدنام بود زمان به بازار.
میکروسرویس ها در سال 2015 در موج تبلیغاتی قرار گرفتند. بر اساس برخی مطالعات، حتی یک کنفرانس بدون گزارش در مورد موضوع میکروسرویس ها کامل نبود. علاوه بر این، برخی از کنفرانس ها به طور انحصاری به میکروسرویس ها اختصاص یافت. امروزه، بسیاری از پروژه‌ها شروع به استفاده از این سبک معماری کرده‌اند، و اگر پروژه حاوی هزاران کد قدیمی باشد، احتمالاً مهاجرت به میکروسرویس‌ها به طور فعال انجام می‌شود.
علیرغم تمام موارد فوق، تعداد نسبتاً کمی از توسعه دهندگان هنوز می توانند مفهوم "microservice" را تعریف کنند. اما در این مورد کمی بعد صحبت خواهیم کرد...
یکپارچه
سبک معماری که در تضاد با میکروسرویس ها است، یکپارچه (یا همه در یک) است. احتمالاً منطقی نیست که بگوییم یکپارچه چیست، بنابراین من فوراً معایب این سبک معماری را که آغازگر توسعه بیشتر سبک های معماری است، فهرست می کنم: اندازه، اتصال، استقرار، مقیاس پذیری، قابلیت اطمینان و استحکام. در زیر پیشنهاد می کنم به طور جداگانه به هر یک از کاستی ها نگاهی بیندازیم.
اندازه
یکپارچه بسیار بزرگ است. و معمولا با یک پایگاه داده بسیار بزرگ ارتباط برقرار می کند. برنامه برای یک توسعه دهنده بزرگتر از آن است که اصلاً آن را بفهمد. فقط کسانی که زمان زیادی را صرف کار روی این کد کرده‌اند می‌توانند به خوبی با monolith کار کنند، در حالی که مبتدیان زمان زیادی را صرف کشف یکپارچه می‌کنند و هیچ تضمینی وجود ندارد که آن را کشف کنند. معمولاً هنگام کار با یک مونولیت، همیشه یک نفر ارشد "شرطی" وجود دارد که کمابیش مونولیت را به خوبی می شناسد و در عرض یک سال و نیم دست دیگر توسعه دهندگان جدید را می زند. طبیعتاً چنین ارشد مشروط یک نقطه شکست است و خروج او می تواند منجر به مرگ یکپارچه شود.
اتصال
یکپارچه یک "توپ بزرگ از گل" است، تغییراتی که در آن می تواند منجر به عواقب غیر قابل پیش بینی شود. با ایجاد تغییرات در یک مکان، می توانید به یکپارچه در مکان دیگر آسیب بزنید (همان "گوش را خراشیدید، *@ افتاد"). این به این دلیل است که اجزای یکپارچه دارای روابط بسیار پیچیده و مهمتر از همه غیر آشکار هستند.
گسترش
استقرار یک مونولیت، به دلیل روابط پیچیده بین اجزای آن، فرآیندی طولانی با آیین خاص خود است. چنین آیینی معمولاً کاملاً استاندارد نیست و "به صورت شفاهی" منتقل می شود.
مقیاس پذیری
ماژول های Monolith ممکن است نیازهای منابع متناقضی داشته باشند، که نیاز به مصالحه از نظر سخت افزاری دارند. تصور کنید که یک مونولیت متشکل از سرویس های A و B دارید. سرویس A نسبت به اندازه هارد دیسک سخت است و سرویس B بر روی RAM تقاضا دارد. در این حالت، یا دستگاهی که مونولیت روی آن نصب شده است باید الزامات هر دو سرویس را پشتیبانی کند، یا باید به صورت دستی، یکی از سرویس ها را غیرفعال کنید.
مثال دیگر (کلاسیک تر): سرویس A بسیار محبوب تر از سرویس B است، بنابراین شما می خواهید 100 سرویس A و 10 سرویس B وجود داشته باشد. باز هم دو گزینه: یا ما 100 یکپارچه کامل را مستقر می کنیم، یا در برخی از آن ها خدمات B باید به صورت دستی غیرفعال شوند.
قابلیت اطمینان
از آنجایی که همه سرویس ها با هم قرار دارند، اگر یکپارچه سقوط کند، همه سرویس ها به یکباره سقوط می کنند. در واقع، این ممکن است چندان بد نباشد، حداقل در یک سیستم توزیع شده خرابی جزئی وجود نخواهد داشت، اما از طرف دیگر، به دلیل یک اشکال در عملکرد که توسط 0.001٪ از کاربران استفاده می شود، می توانید همه کاربران را از دست بدهید. از سیستم شما
اینرسی
با توجه به اندازه یکپارچه، تغییر به فن آوری های جدید دشوار است. در نتیجه، حفظ همان ارشد یک کار جداگانه است. پشته فناوری انتخاب شده در شروع یک پروژه می تواند به بلوکی تبدیل شود که مانع توسعه محصول شود.
نتیجه
دفعه بعد در مورد این صحبت خواهیم کرد که چگونه مردم سعی کرده اند این مشکلات را با حرکت به سمت اجزا و SOA حل کنند.
بیشتر بخوانید:
منبع: www.habr.com