Мікросервіси

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

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

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

Філософія

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

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

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

Критика

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

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

Примітки
  1. Microservices. martinfowler.com. Процитовано 2 лютого 2016.
  2. The Philosophy of Microservice Architecture | Microservices Book. microservicesbook.io. Архів оригіналу за 12 листопада 2016. Процитовано 2 лютого 2016.
  3. Microservices: Five Architectural Constraints - nirmata. nirmata (амер.). Процитовано 2 лютого 2016.
  4. Experiences from Failing with Microservices. InfoQ. Процитовано 2 лютого 2016.

Посилання


This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.