Микросервисы как архитектура разработки ПО

Довольно-таки модная и уважаемая архитектура - Микросервисы, в первоисточнике называется как MSA (MicroService Architecture) и впервые о ней я узнал вот на этом докладе:

Скажу, что у MSA есть старший брат - SOA (Service Oriented Architecture). Об этой архитектуре я пока ничего не упоминал, если когда-нибудь решу написать о ней, то вместо этого предложения здесь появится ссылка. Продолжу дальше об архитектуре микросервисов и их основных принципах:

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

Исходя из этих принципов мы имеем определенные плюсы...

• Высокая стабильность. При отказе одного из сервисов, например, из-за программной ошибки, есть возможность откатить неработающий сервис или установить новую, более стабильную версию, не останавливая все приложение.
• Разнообразие технологий. Микросервисы не ограничены только одной технологией, принятой для всего приложения.
• Независимое развертывание. Простые сервисы проще разворачивать, и меньше вероятность отказа системы.

... и определенные минусы

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

Из перечисленных минусов мы видим, что к архитектуре есть только одно требование, тогда как к проектированию и разработке - три. Правильным выходом из этой ситуации может быть разбиение кода по сервисам основываясь на бизнес логике (обработка запроса на вход в систему, составление отчета по продажам, построение графика по данным из базы), а не на функционале, как мы это обычно делаем в монолитном приложении (Users, Storage, Back-End, DB). Такие функционально-законченные модули становятся действительно независимыми и их применение становится очевидным. Кроме того, общий функционал приложения может быть легко и безболезненно расширен либо изменен.

При общении я слышал и читал в сети о распространенной проблеме микросервисов в плане тестирования. В тестировании монолитного приложения все понятно. Проводить мануальное тестирование для микросервисной архитектуры это, мягко говоря, кошмар. Зато открывается не паханное поле идей для автоматизированного тестирования. Если проектировщики и разработчики все сделают правильно, то у нас получается приложение, которое:

• Состоит из набора функционально законченных сервисов
• Имеет взаимодействие между своими сервисами через менеджер сообщений
• Имеет стандартный интерфейс сообщений у всех сервисов

Здесь ключевой точкой является менеджер сообщений, к которому нам нужно подключить логгер и вуаля! Мы получаем четкий и понятный лог работы каждого сервиса, при этом взаимодействие сервисов между собой так же становятся прозрачным. А значит мы можем быстро выявить проблемный сервис и при необходимости его исправить. В случае WEB-приложения можно реализовать мониторинг, который будет в режиме реального времени сообщать нам о возникших проблемах.

Так как интерфейс сообщений у нас стандартный, нам не надо подстраиваться под каждый сервис в отдельности, достаточно использовать набор известных пар "запрос-ответ", например, из той же БД. А это так всеми любимый DDT (Data Driven Testing), что приводит нас к потрясающей масштабируемости и производительности.