سلام هابر امروز من یک سری از انتشاراتی را که به طور خاص برای شروع یک جریان جدید از دوره نوشتم ادامه می دهم. .
معرفی
انتخاب سبک معماری یکی از تصمیمات فنی اساسی در هنگام ساخت یک سیستم اطلاعاتی است. در این سری از مقالات، من پیشنهاد می کنم محبوب ترین سبک های معماری برای کاربردهای ساختمانی را تجزیه و تحلیل کنیم و به این سوال پاسخ دهیم که چه زمانی سبک معماری بیشتر ترجیح داده می شود. در روند ارائه، من سعی خواهم کرد یک زنجیره منطقی ترسیم کنم که توسعه سبک های معماری از یکپارچه تا میکروسرویس را توضیح می دهد.
В ما به بررسی سیستم یکپارچه پرداختیم و دریافتیم که دارای چندین مشکل است: اندازه، اتصال، استقرار، مقیاسپذیری، قابلیت اطمینان و استحکام.
این بار پیشنهاد میکنم در مورد امکان سازماندهی یک سیستم به عنوان مجموعهای از ماژولها/کتابخانهها (معماری کامپوننتگرا) یا سرویسها (معماری سرویسگرا) صحبت کنیم.
معماری مبتنی بر مؤلفه
معماری مؤلفهگرا (CEA) فرض میکند که یک سیستم به صورت مجموعهای از مؤلفهها پیادهسازی میشود که میتوانند در پروژههای فعلی و آینده مورد استفاده قرار گیرند. هنگام تجزیه یک سیستم به مؤلفهها، ملاحظاتی در مورد قابلیت استفاده مجدد، قابلیت جایگزینی، استقلال از زمینه، توسعهپذیری، کپسولهسازی و استقلال آنها در نظر گرفته میشود.
استفاده صحیح از کامپوننتها، مشکل «توپ بزرگ گِل» (اندازه بزرگ + اتصال زیاد) را حل میکند و خود کامپوننتها میتوانند هم واحدهای مونتاژ (ماژولها، کتابخانهها) و هم واحدهای استقرار (سرویسها) را نشان دهند. واحدهای استقرار همیشه به فرآیند در حال اجرا نگاشت نمیشوند: برای مثال، یک برنامه وب و یک پایگاه داده با هم مستقر میشوند.
برنامههای تکتکه اغلب به صورت مجموعهای از ماژولها توسعه داده میشوند. این رویکرد، توسعه مستقل را تضمین میکند، اما چالشهای مقیاسپذیری و استقرار مستقل، تحمل خطا و استقلال از کل پشته فناوری همچنان پابرجاست. به همین دلیل است که یک ماژول یک جزء تا حدی مستقل است.
مشکل اصلی چنین سیستم یکپارچهای این است که تقسیمبندی به ماژولها کاملاً منطقی است و توسعهدهندگان میتوانند به راحتی آن را نقض کنند. یک ماژول اصلی میتواند ظاهر شود که به تدریج به زباله تبدیل شود، نمودار وابستگی بین ماژولها میتواند رشد کند و غیره. برای جلوگیری از چنین مشکلاتی، توسعه باید یا توسط یک تیم بسیار بالغ یا تحت هدایت یک "معمار" که تمام وقت بررسی کد را انجام میدهد و توسعهدهندگانی را که ساختار منطقی را نقض میکنند، تنبیه میکند، هدایت شود.
سیستم یکپارچه «ایدهآل» مجموعهای از ماژولهای منطقی جدا از هم است که هر کدام به پایگاه داده خود مراجعه میکنند.
معماری سرویسگرا
اگر قرار باشد سیستم به صورت مجموعهای از سرویسها سازماندهی شود، به آن معماری سرویسگرا میگویند. اصول آن شامل سازگاری برنامههای کاربردی کاربرپسند، استفاده مجدد از سرویسهای تجاری، استقلال از هر مجموعه فناوری خاص و خودمختاری (تکامل مستقل، مقیاسپذیری و قابلیت استقرار) است.
معماری سرویسگرا (SOA) تمام مشکلات شناساییشده با یک سیستم یکپارچه را حل میکند: وقتی تغییری رخ میدهد، فقط یک سرویس تحت تأثیر قرار میگیرد و یک API که به وضوح تعریف شده باشد، کپسولهسازی خوبی از اجزا را حفظ میکند.
اما همه چیز به این راحتی نیست: معماری سرویسگرا (SOA) مشکلات جدیدی را ایجاد میکند. تماسهای از راه دور گرانتر از تماسهای محلی هستند و توزیع مجدد مسئولیتها بین اجزا به طور قابل توجهی گرانتر شده است.
اتفاقاً، توانایی استقرار مستقل، یک ویژگی بسیار مهم یک سرویس است. اگر سرویسها باید با هم یا حتی در یک توالی خاص مستقر شوند، سیستم را نمیتوان سرویسگرا در نظر گرفت. در چنین حالتی، ما از یک سیستم یکپارچه توزیعشده صحبت میکنیم (که نه تنها از دیدگاه SOA، بلکه از دیدگاه معماری میکروسرویسها نیز یک ضد الگو محسوب میشود).
معماری سرویسگرا از حمایت قوی جامعه معماری و فروشندگان برخوردار است. این امر به دورهها و گواهینامههای متعدد و همچنین الگوهای توسعهیافته منجر میشود. مورد دوم، به عنوان مثال، شامل گذرگاه سرویس سازمانی (ESB) معروف است. با این حال، ESB یک ویژگی ارائه شده توسط فروشندگان است و لزوماً برای استفاده در SOA مورد نیاز نیست.
معماری سرویسگرا در حدود سال ۲۰۰۸ به اوج محبوبیت خود رسید، و پس از آن شروع به کاهش محبوبیت کرد، که پس از ظهور میکروسرویسها (حدود ۲۰۱۵) به طور قابل توجهی چشمگیرتر شد.
نتیجه
حالا که در مورد امکان سازماندهی سیستمهای اطلاعاتی به عنوان سرویسها و ماژولها بحث کردیم، پیشنهاد میکنم در نهایت به اصول معماری میکروسرویس بپردازیم و در بخش بعدی به تفاوت بین معماری میکروسرویس و معماری سرویسگرا توجه ویژهای داشته باشیم.
منبع: www.habr.com
