Привіт Хабр. Сьогодні я продовжую серію публікацій, яку написав спеціально до старту нового потоку курсу .
Запровадження
Вибір архітектурного стилю є одним із основних технічних рішень при побудові інформаційної системи. У цій серії статей я пропоную розібрати найпопулярніші архітектурні стилі побудови додатків і відповісти на питання коли який архітектурний стиль є найкращим. У процесі викладу я намагатимуся провести логічний ланцюжок, який пояснює розвиток архітектурних стилів від монолітів до мікросервісів.
Минулого разу ми поговорили про різні види монолітів і використання компонентів для їх побудови, причому як компонентів збірки, так і компонентів розгортання. Ми розібралися із сервіс-орієнтованою архітектурою.
Наразі ми нарешті визначимо основні характеристики мікросервісної архітектури.
Відношення архітектур
Необхідно розуміти, що, виходячи з даних у попередніх статтях визначень, будь-який сервіс є компонентом, але не будь-який сервіс є мікросервісом.
Характеристики мікросервісної архітектури
Основними характеристиками мікросервісної архітектури є:
- Організація відповідно до бізнес-можливостей (Organized around Business Capabilities)
- Продукти, а не проекти (Products not Projects)
- Розумні точки входу та дурні канали (Smart endpoints and dumb pipes)
- Децентралізоване управління (Decentralized Governance)
- Децентралізоване керування даними (Decentralized Data Management)
- Автоматизація інфраструктури (Infrastructure Automation)
- Страхування від збоїв (Design for failure)
- Архітектура з еволюційним розвитком (Evolutionary Design)
Перший пункт походить від сервіс-орієнтованої архітектури, оскільки мікросервіси є окремим випадком сервісів. Інші пункти заслуговують на окремий розгляд.
Організація відповідно до бізнес-можливостей (Organized around Business Capabilities)
Тепер слід згадати закон Конвею: організації, створюють системи, організують її архітектуру, копіюючу структуру взаємодії всередині цих організацій. Як приклад можна згадати випадок створення компілятора: команда із семи осіб розробила семипрохідний компілятор, а команда із п'яти — п'ятипрохідний.
Якщо ми говоримо про моноліти та мікросервіси, то в тому випадку, якщо розробка організована за функціональними відділами (бекенд, фронтенд, адміністратори баз даних), то виходить класичний моноліт.
Для отримання мікросервісів команди необхідно організовувати з бізнес-можливостей (команда замовлень, відвантажень, каталогу). Така організація дасть змогу командам зосередитись на створенні конкретних частин програми.
Продукти, а не проекти (Products not Projects)
Проектний підхід у якому команда передає розроблену функціональність іншим командам у разі мікросервісної архітектури не підходить. Команда повинна підтримувати систему протягом її життєвого циклу. Компанія Amazon, один із флагманів впровадження мікросервісів, заявляла: "ви створюєте продукт, і ви ж запускаєте його" ("you build, you run it"). Продуктовий підхід дозволяє команді відчути потреби бізнесу.
Розумні точки входу та дурні канали (Smart endpoints and dumb pipes)
SOA архітектура приділяла велику увагу каналам зв'язку, зокрема Enterprise Service Bus (сервісна шина підприємства). Що часто призводить до Erroneous Spaghetti Box, тобто складність моноліту перетворюється на складність зв'язків між сервісами. У мікросевісній архітектурі використовуються лише прості способи взаємодії.
Децентралізоване управління (Decentralized Governance)
Ключові рішення щодо мікросервісів повинні приймати люди, які справді розробляють мікросервіси. Тут під ключовими рішеннями мається на увазі вибір
мов програмування, методології розгортання, контрактів громадських інтерфейсів тощо.
Децентралізоване керування даними (Decentralized Data Management)
Стандартний підхід, у якому додаток спирається однією базу даних, неспроможна враховувати специфіки кожного конкретного сервісу. MSA передбачає децентралізоване керування даними, аж до застосування різних технологій.
Автоматизація інфраструктури (Infrastructure Automation)
MSA підтримує процеси безперервного розгортання та постачання. Здійснити це можна лише шляхом автоматизації процесів. При цьому розгортання великої кількості сервісів вже не виглядає чимось страшним. Процес розгортання має стати нудним. Другий аспект пов'язані з управлінням сервісами в продуктовому середовищі. Без автоматизації управління процесами, запущеними в різних операційних середовищах, стає неможливим.
Страхування від збоїв (Design for failure)
Численні сервіси MSA схильні до збоїв. При цьому обробка помилок у розподіленій системі — вельми не тривіальне завдання. Архітектура додатків має бути стійкою до таких збоїв. Ребека Парсонс вважає дуже важливим, що ми більше не використовуємо навіть внутрішньопроцесну взаємодію між сервісами, натомість для зв'язку ми вдається до HTTP, який і близько не буває настільки ж надійним.
Архітектура з еволюційним розвитком (Evolutionary Design)
Архітектура системи MSA повинна розвиватися еволюційно. Бажано обмежити необхідні зміни межами одного сервісу. Необхідно також враховувати вплив на інші послуги. Традиційний підхід полягає в тому, щоб спробувати вирішити цю проблему за допомогою керування версіями, але MSA передбачає використовувати керування версіями в
як крайній захід.
Висновок
Після всього сказаного можна сформулювати що таке мікросервіси. Мікросервісна архітектура - це підхід до розробки окремої програми у вигляді набору невеликих сервісів, кожен з яких працює у своєму власному процесі та взаємодіє за допомогою полегшених механізмів, часто API-інтерфейсом HTTP-ресурсів. Ці сервіси побудовані на бізнес-можливості і можуть бути розгорнуті незалежно за допомогою повністю
автоматизованого механізму розгортання. Існує мінімальний рівень централізованого управління цими сервісами, які можуть бути написані різними мовами програмування та використовувати різні технології зберігання даних.
Джерело: habr.com