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