انتخاب سبک معماری (قسمت سوم)

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

معرفی

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

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

این بار پیشنهاد می‌کنم در مورد امکانات سازمان‌دهی یک سیستم به‌عنوان مجموعه‌ای از ماژول‌ها/کتابخانه‌ها (معماری مؤلفه‌گرا) یا خدمات (معماری سرویس‌گرا) صحبت کنیم.

معماری کامپوننت محور

معماری کامپوننت گرا شامل اجرای یک سیستم به عنوان مجموعه ای از اجزا است که می تواند در پروژه های فعلی و آینده استفاده شود. هنگام تقسیم یک سیستم به اجزاء، موارد زیر در نظر گرفته می شود: قابلیت استفاده مجدد، قابلیت جایگزینی، استقلال زمینه، توسعه پذیری، کپسوله سازی و استقلال.

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

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

بزرگترین مشکل چنین یکپارچه این است که تقسیم به ماژول ها کاملاً منطقی است و می تواند به راحتی توسط توسعه دهندگان نقض شود. ممکن است یک ماژول هسته ظاهر شود که به تدریج به زباله دانی تبدیل می شود، نمودار وابستگی بین ماژول ها ممکن است رشد کند و غیره. برای جلوگیری از چنین مشکلاتی، توسعه باید یا توسط یک تیم بسیار بالغ، یا تحت هدایت یک "معمار" انجام شود که درگیر بررسی تمام وقت کد است و دست توسعه دهندگانی را که ساختار منطقی را نقض می کنند، می زند.

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

معماری سرویس گرا

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

معماری سرویس گرا (SOA = معماری سرویس گرا) تمام مشکلات شناسایی شده یکپارچه را حل می کند: زمانی که تغییری رخ می دهد تنها یک سرویس تحت تأثیر قرار می گیرد و یک API به خوبی تعریف شده از کپسوله سازی خوب اجزا پشتیبانی می کند.

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

به هر حال، امکان استقرار مستقل از ویژگی های بسیار مهم این سرویس است. اگر سرویس ها باید با هم یا، علاوه بر این، در یک توالی خاص مستقر شوند، آنگاه نمی توان سیستم را سرویس گرا در نظر گرفت. در این مورد، آنها در مورد یکپارچه توزیع شده صحبت می کنند (که نه تنها از نقطه نظر SOA، بلکه از نقطه نظر معماری میکروسرویس نیز یک ضد الگو در نظر گرفته می شود).

معماری سرویس گرا به خوبی توسط جامعه معماری و فروشندگان پشتیبانی می شود. این به معنای وجود بسیاری از دوره ها و گواهینامه ها، الگوهای توسعه یافته است. مورد دوم شامل، برای مثال، اتوبوس خدمات سازمانی شناخته شده (ESB = اتوبوس خدمات سازمانی) است. در عین حال، ESB یک توشه از سوی فروشندگان است؛ لزوماً نباید در SOA استفاده شود.

محبوبیت معماری سرویس گرا در حدود سال 2008 به اوج خود رسید، پس از آن شروع به کاهش کرد، که پس از ظهور میکروسرویس ها (~2015) به طور قابل توجهی چشمگیرتر شد.

نتیجه

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

منبع: www.habr.com