Навіщо потрібна сервіс-орієнтована архітектура

Навіщо потрібна сервіс-орієнтована архітектура

Як розбити програму на модулі.

Вартість розробки залежить кількості нового функціоналу. Чим більше фіч буде реалізовано в додатку, тим більше часу піде на їхнє впровадження. На вартість розробки впливають і технологічний стек продукту, і архітектурні підходи, які використовує команда.

Сервіс-орієнтована архітектура (SOA, service-oriented architecture) допомагає досягти балансу між вартістю та швидкістю. SOA базується на поділі програми на слабко пов’язані компоненти (сервіси).

Пояснюємо, як розбиття логіки на модулі полегшує розробку.

Сервіси як частини

Основна одиниця SOA — сервіс, що відповідає за конкретний бізнес-процес. Наприклад, у додатку можуть бути окремі сервіси для:

  • авторизації користувачів;
  • логування;
  • сповіщень.

Великі завдання поділяються між модулями. Для опису вмісту та функцій сервісу немає суворих правил. Команда сама визначає, що потрібне сервісу. При цьому самі сервіси дотримуються контрактів (чітких правил):

  • що саме може підключитися до сервісу;
  • за яким протоколом і через який інтерфейс йде передача даних;
  • з якими даними працює сервіс;
  • за які функції він відповідає;
  • що сервіс повертає у відповідь на звернення.

Модулі нижнього рівня нічого не знають про реалізацію верхніх, крім протоколу, за яким вони працюють із ресурсами. Сервіси лише передають та приймають дані, не маючи доступу до методів один одного. Крім того, усі події обробляються асинхронно. Не повинно бути ситуацій, коли сервіси не працюють через те, що очікують відповіді від інших систем.

Оскільки сервіси представляють окремі функції, їх можна перевикористовувати в різних додатках. Об’єднання сервісів у більші сутності називається оркеструванням. Розробник отримує конструктор, з якого може збирати програми.

Компоненти взаємодіють між собою за протоколами за допомогою черги подій. Вона постачається через Enterprise Service Bus (ESB) — програмне забезпечення, яке керує передачею повідомлень між компонентами системи.

Шарова архітектура

Додаток, наступний SOA, умовно поділяється на шари, кожен із яких відповідає за певну роботу:

  • Business Process Layer — шар для об’єднання сервісів та розв’язання завдань програми;
  • Service — шар із сервісами;
  • Components — шар із компонентами, які забезпечують роботу окремих сервісів. Наприклад, компонент не має своєї власної бази даних — він звертається до БД, якою користуються відразу кілька сервісів;
  • Integration Layer — шар, що зв’язує між собою компоненти окремого модуля.

Переваги та недоліки SOA

Плюси SOA:

  • Гнучкість — модулі запускаються окремо. У результаті архітектура виходить розподіленою й не залежить від платформи. Різні компоненти можна писати різними мовами програмування та фреймворками, а потім розміщувати на окремих серверах;
  • Легко інтегрувати нові фічі — достатньо написати новий сервіс і визначити, за якими протоколами він взаємодіятиме з іншими;
  • SOA забезпечує інкапсуляцію — бізнес-функції ізолюються одна від одної, що підвищує стійкість до відмов. Якщо змінюється один із сервісів, необхідно перезапустити ті частини, які з ним взаємодіють. Програма може працювати, нехай і з обмеженим функціоналом. Коли падає сервіс, відповідальний за розсилку листів, сервіс авторизації користувачів продовжує роботу;
  • Сервіс не прив’язаний до одного додатка та може використовуватися в іншому. Розробник може написати дві реалізації одного й того ж сервісу: один із них забезпечує основну бізнес-логіку, а другий використовується для тестування нових фіч.

Мінуси SOA:

  • Пов’язані модулі залежать один від одного;
  • Чим більше зв’язків між сервісами, тим більше змін слід відстежувати;
  • Коли над різними сервісами працює багато команд, їм складно кооперуватися для підтримки продукту та внесення змін, які стосуються кількох сервісів. У такому разі підтримувати високу швидкість гнучкої розробки неможливо;
  • Висока вартість товару зі збільшенням кількості сервісів;
  • Перехід до мікросервісної архітектури (наступна ітерація розвитку SOA) вирішує ці недоліки. Компоненти стають меншими, мають свої власні ресурси та сховища даних, а для комунікації використовують лише HTTP.
Ще статті
Як працювати з даними: фахівці діляться досвідом.
Розробники радять Telegram- та YouTube-канали, книги та блоги.