Архітектура ПЗ визначає проєкт задовго до першого рядка коду. Помилка у виборі дорого коштує пізніше; розуміння варіантів робить вибір усвідомленим.
Шість поширених архітектур: що кожна дає і чим за це платити.
1. Монолітна архітектура
Традиційна модель: інтерфейс, бізнес-логіка й доступ до даних живутьь в одному модулі, що розгортається.
- Плюси: просто розробляти, тестувати й розгортати; виклики всередині процесу швидкі.
- Мінуси: важко масштабувати окремі частини; супровід зростає разом із кодовою базою.
2. Мікросервісна архітектура
Застосунок ділиться на невеликі незалежні сервіси, що спілкуються через API. Кожен сервіс відповідає за свою функцію і розгортається та масштабується окремо.
- Плюси: незалежне масштабування, гнучкість технологій, ізоляція відмов.
- Мінуси: розподілена складність, узгодженість даних, мережеві накладні витрати.
3. Сервіс-орієнтована архітектура (SOA)
Схожа на мікросервіси, але сервіси більші й спілкуються через шину повідомлень або брокер, а також перевикористовуються між застосунками.
- Плюси: перевикористання між проєктами, стандартизована інтеграція.
- Мінуси: потрібна зріла інфраструктура; шина додає затримку.
4. Подієво-орієнтована архітектура
Компоненти породжують, виявляють, споживають і обробляють події - асинхронна обробка стає природною.
- Плюси: масштабується додаванням обробників; слабка зв’язаність.
- Мінуси: складність потоків подій, важче налагодження й узгодженість.
5. Шарова архітектура
Застосунок ділиться на шари - представлення, бізнес-логіка, доступ до даних, - кожен відповідає за своє.
- Плюси: чіткий розподіл відповідальності, шари розвиваються незалежно.
- Мінуси: накладні витрати між шарами; зміни можуть зачіпати кілька з них.
6. Мікроядерна архітектура
Невелике ядро дає мінімум функціональності, решта приходить плагінами й розширеннями.
- Плюси: розширюваність без правок ядра; маленький і керований центр.
- Мінуси: керування залежностями плагінів; накладні витрати шару розширень.
Як обирати на практиці
Почніть з модульного моноліту. Один деплой, явні межі модулів, власна схема в кожного модуля, жодних запитів у чужі таблиці в обхід. Більшість продуктів живуть так роками, а межі потім здешевлюють виділення сервісу.
Виділяйте сервіс, коли в модуля свій профіль навантаження, свій темп релізів або своя зона відмови. Генератор PDF, який з’їдає процесор на кожному завантаженні, підходить. Форма входу ні.
Події беріть, коли робота може йти після відповіді: листи, вивантаження, білінг, індексація пошуку. Не робіть події основним транспортом для запиту й відповіді, інакше рік розбиратимете потік, який не можна відтворити.
SOA потрібна, коли кілька продуктів уже є і мають ділити спільну шину. Мікроядро підходить, коли ядро стабільне, а варіації живуть у розширеннях: CMS, IDE, браузер.
Чим вибір обходиться після запуску
- Операційне навантаження. Кожному деплою потрібні логи, метрики, трейсинг, алерти й план відкату. П’ять сервісів означають п’ять комплектів.
- Узгодженість даних. Транзакція через кілька сервісів перетворюється на сагу або таблицю вихідних, і хтось має відповідати за шлях помилки.
- Форма команди. Один сервіс на команду працює. Один сервіс на розробника перетворює кожен реліз на узгодження.
- Найм і чергування. Розподілені системи потребують людей, які вміють їх експлуатувати о третій годині ночі, а не лише малювати на дошці.
Перехід це норма
Архітектура не вирішується один раз. Модульний моноліт, який переріс базу, спершу виділяє модуль із важким читанням. Парк мікросервісів, який тоне в узгодженні, укрупнюють назад. Корисне питання не в тому, який патерн сучасний, а в тому, яка зміна буде дешевшою наступного року.
Як обирати архітектуру ПЗ
Патерн мікросервісів докладно розібраний у Мартіна Фаулера. Найкращої архітектури не існує - є відповідна до вимог. Поставте три запитання: який масштаб потрібен, як швидко змінюватимуться команда й продукт, скільки операційної складності ви можете собі дозволити?
Моноліт - чудова відповідь для невеликого продукту з неясним майбутнім. Мікросервіси виправдані, коли незалежне масштабування й автономія команд переважують операційну ціну. Подієва архітектура окупається, коли асинхронні потоки - ядро бізнесу. Помилка не у виборі простої архітектури, а у виборі модної, яку ви не можете експлуатувати.
Розумійте компроміси, починайте з найпростішого робочого рішення й давайте архітектурі розвиватися разом із продуктом.
Як обрати архітектуру ПЗ під задачу
Архітектура ПЗ обирається за обмеженнями: навантаження, команда, швидкість змін, ціна помилки. Нотатки Мартіна Фаулера дають мову для такої розмови. Мода тут поганий порадник: архітектура ПЗ перевіряється навантаженням і ціною змін, а не слайдом. Архітектура ПЗ, яку не виходить пояснити колезі за п’ять хвилин, зазвичай не архітектура, а схема.
Ще за темою: Важливість правильного неймінгу в коді і Глибина SQL: один запит замість бекенд-сервісу.