Термін
Мікросервіси
Архітектура програмного забезпечення, за якої застосунок складається з багатьох невеликих самостійних сервісів, кожен з яких відповідає за одну галузь і спілкується через API. Полегшує незалежну розробку та масштабування, але ускладнює експлуатацію.
Оновлено
Що це означає
Мікросервіси - програмна архітектура, у якій застосунок складається з безлічі невеликих самостійних сервісів. Кожен відповідає за одну сферу, наприклад замовлення, платежі, склад чи рахунки, має власні дані й спілкується з іншими через API, найчастіше через REST API або повідомлення.
Протилежність - моноліт, тобто один великий застосунок, де всі частини пов'язані в одному коді й розгортаються одночасно. Моноліт простіший на початку, але зі зростанням його важче змінювати й масштабувати. Мікросервіси дають змогу різним командам розробляти і випускати свої частини незалежно.
Мікросервіси зазвичай працюють у контейнерах, які забезпечує контейнеризація, а керують ними оркестратори на кшталт Kubernetes. Тому кожен сервіс можна масштабувати окремо, наприклад додати потужності лише платіжному сервісу під час розпродажу.
Як це працює на практиці
Архітектура виправдана для великих і швидко зростаючих застосунків із кількома командами, де важливі незалежність і часті зміни. Випуск кожного сервісу відбувається автоматично через CI/CD, а експлуатацію забезпечує команда в культурі DevOps, що відповідає за сервіс від розроблення до роботи в продакшені.
Поділ застосунку на сервіси має відповідати бізнес-сферам, а не технічним шарам. Сервіс рахунків має містити все, що стосується виставлення рахунків, щоб у разі зміни правил, наприклад переходу на електронні рахунки, не довелося правити десять різних частин.
За безлічі сервісів потрібні централізований збір логів, метрик і трасування запитів через сервіси. Без нього пошук помилки, що виникла десь у ланцюжку з п'яти сервісів, дуже довгий. Важлива і документація інтерфейсів між сервісами.
На що звернути увагу
Мікросервіси помітно ускладнюють експлуатацію: більше випусків, мереж, моніторингу і варіантів збою зв'язку. Для невеликої команди чи простого продукту часто краще добре структурований моноліт, який можна поділити пізніше, коли для цього з'являться реальні причини.
Оскільки кожен сервіс має власні дані, складніше забезпечити узгодженість, наприклад щоб замовлення, платіж і складський рух завжди збігалися. Для фінансових і облікових процесів треба ретельно продумати обробку помилок і повторів, щоб не виникали подвійні платежі чи зниклі документи.
Потрібно пояснити термін на вашій конкретній ситуації? Консультації від 55 € / година без ПДВ, залежно від теми та складності.