Microservices

James Lewis, Martin Fowler, 25 March 2014

Оригинал: http://www.martinfowler.com/articles/microservices.html

«Microservice Architecture» - это подход, при котором единое приложение строится как набор небольших сервисов, каждый из которых работает в собственном процессе и коммуницирует с остальными, используя легковесные механизмы. Существует некоторый общий набор характеристик: организация сервисов вокруг потребностей, автоматическое развертывание, перенос логики от шины сообщений к приемникам (endpoints) и децентрализованный контроль над языками и данными.

• Разбиение на сервисы

Сервисы — это компоненты, выполняемые в отдельном процессе и коммуницирующие между собой через веб-запросы или remote procedure call. Главная причина использования сервисов вместо библиотек — это независимое развертывание. В отличие от библиотек, использование сервисов не требует переразвертки всего приложения при внесении изменений. Другое следствие использования сервисов как компонент — более явный интерфейс между ними.

• Организация вокруг потребностей

Микросервисный подход к разбиению подразумевает разбиение на сервисы в соответствии с потребностями клиентов. Такие сервисы включают в себя полный набор технологий, необходимых для этого варианта использования, в том числе пользовательский интерфейс, хранилище данных и любые внешние взаимодействия.

• Продукты, а не проекты

Большинство компаний по разработке ПО используют проектную модель, в которой целью является разработка некой части функциональности, которая после этого считается завершенной. После завершения эта часть передается команде поддержки и проектная команда распускается. Сторонники микросервисов считают, что команда должна владеть продуктом на протяжении всего срока его жизни. Продукт — это не просто набор функций, которые необходимо реализовать, это постоянные отношения, цель которых — помочь пользователям увеличить их возможности.

• Умные приёмники и глупые каналы передачи данных (Smart endpoints and dumb pipes)

При выстраивании сообщений между процессами обычно в механизмы передачи данных помещают существенную часть логики. Сторонники микросервисов предпочитает альтернативный подход. Приложения, построенные с использованием микросервисной архитектуры, как правило, содержат собственную доменную логику. Два наиболее часто используемых протокола связи — это HTTP запросы и легковесные шины сообщений.

• Децентрализованное управление

Одним из следствий централизованного управления является тенденция к стандартизации используемых платформ. Опыт показывает, что такой подход слишком сильно ограничивает выбор. Используя микросервисы, мы имеем выбор, как построить каждый из них, какие языки и стандарты использовать для их проектирования, чтобы они наилучшим образом подходили для данных вариантов использования.

• Децентрализованное управление данными

Микросервисы предпочитают давать возможность каждому сервису управлять собственной базой данных: как создавать отдельные инстансы общей для компании СУБД, так и использовать нестандартные виды баз данных. Этот подход называется Polyglot Persistence. Децентрализация ответственности за данные среди микросервисов оказывает влияние на то, как эти данные изменяются. В таких случаях используют распределенные транзакции, несмотря на их сложность реализации.

• Автоматизация инфраструктуры

Обычно применяется при тестировании (автоматическое развертывание системы в среде тестирования) и управлении микросервисами в продакшне. Одним из побочных эффектов автоматизации процесса развертывания является создание удобных инструментов для помощи разработчикам и администраторам.

• Проектирование под отказ

Следствием использования сервисов является необходимость проектирования приложений так, чтобы они могли работать при отказе отдельных сервисов. Команды разработчиков, как правило, создают изощренные системы мониторинга для каждого индивидуального сервиса, чтобы следить за состоянием системы и своевременно реагировать на отказ.

• Эволюционный дизайн

Те, кто практикует микросервисную архитектуру, обычно много работали с эволюционным дизайном и рассматривают декомпозицию сервисов как дальнейшую возможность дать разработчикам контроль над изменениями их приложения без замедления самого процесса разработки. Контроль над изменениями не означает уменьшение изменений: с правильным подходом и набором инструментов можно делать частые, быстрые, хорошо контролируемые изменения.

Цель данной статьи – ознакомление с основными принципами микросервисной архитектуры. Она обладает рядом несомненных преимуществ по сравнению с той же монолитной архитектурой. С другой стороны существуют некоторые сложности, которые не позволяют назвать данную архитектуру идеальной. К ним можно отнести сложность связи между компонентами и координации межсервисных изменений, заметно более сложный процесс тестирования. Однако данный стиль проектирования имеет своих поклонников и большие перспективы.