Мікросервіс

Мікросервіси — архітектурний стиль, за яким єдиний застосунок будується як сукупність невеличких сервісів, кожен з яких працює у своєму власному процесі та спілкується з рештою, використовуючи прості та швидкі^[] протоколи передачі даних, зазвичай HTTP. Ці сервіси будуються навколо бізнес-потреб і розгортаються незалежно один від одного з використанням зазвичай повністю автоматизованого середовища. Існує абсолютний мінімум централізованого керування цими сервісами. Самі по собі вони можуть бути написані з використанням різних мов програмування і технологій зберігання даних.

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

Основні властивості

• Високий рівень незалежності: незалежна розробка, незалежне розгортання
• Незалежне масштабування
• Невелика кодова база зменшує кількість конфліктів та дозволяє швидко залучати нових розробників
• Простота заміни однієї реалізації сервісу іншою
• Простота додавання нової функціональності в систему
• Ефективне використання ресурсів
• Еластичність: вихід з ладу одного сервісу зазвичай не призводить до виходу з ладу всієї системи
• Сервіси організовані відносно бізнес логіки яку вони виконують
• Кожен сервіс незалежно від інших може бути реалізований за допомогою будь-якої мови програмування, СУБД, та ін.
• Архітектурно побудовані за симетричним принципом (виробник-споживач)

Філософія

Філософія мікросервісного підходу схожа на філософію Unix «Роби одну річ і роби її якісно»:

• Сервіси невеликі, розбиті на виконання єдиної функції
• Організаційна культура повинна охоплювати автоматизацію розгортання та тестування
• Культура і принципи проектування повинні реалізувати перехоплення та опрацювання відмов і дефектів та перебоїв у середовищі виконання
• Кожен сервіс гнучкий, стійкий до відмов, легко^[] компонується з іншими сервісами, функціонально мінімальний та закінчений.

З точки зору якості існує методологія, яка описує основні риси, які мають бути притаманні застосунку з добре продуманою архітектурою: методологія застосунку дванадцяти факторів. Методологія добре підходить для розробки застосунків, зокрема мікросервісів, які призначені для розгортання в хмарному середовищі.

Критика

Мікросервісна архітектура в основному критикується через наступні проблеми:

• Мікросервіси успадковують усі проблеми розподілених систем (складність розподілених транзакцій, остаточна узгодженість, CAP теорема)
• Значні накладні витрати на інфраструктуру, моніторинг і операційні дії
• Ускладнене налагодження, зневадження помилок в робочому сервісі, трасування
• Відсутність згоди між розробниками: різні погляди на переваги мікросервісної архітектури проти традиційної монолітної можуть викликати масу дискусій що призводить до втрати часу і зниження продуктивності.
• Обмеження типу «одна команда — один сервіс» викликає бар'єри: коли одна команда для розробки свого сервісу заблокована відсутністю необхідного їм функціоналу сервісу що розробляється іншою командою
• Незалежність сервісів призводить до дублювання коду (утиліти, робота з БД, об'єкти транспортування даних, тощо)
• Проблеми зі стабільністю мережевого зв'язку між сервісами, мережеві затримки, маршалінг/демаршалінг даних
• Ускладнене тестування і розгортання
• Ускладнене забезпечення безпеки

Примітки

1. . martinfowler.com. Архів оригіналу за 14 лютого 2018. Процитовано 2 лютого 2016.
2. . microservicesbook.io. Архів оригіналу за 12 листопада 2016. Процитовано 2 лютого 2016.
3. . nirmata (амер.). Архів оригіналу за 3 березня 2016. Процитовано 2 лютого 2016.
4. . InfoQ. Архів оригіналу за 3 березня 2016. Процитовано 2 лютого 2016.

Посилання

• James Lewis, Martin Fowler (25 березня 2014). Microservices. a definition of this new architectural term.