Слово «микросервисы» на слуху последние несколько лет. Технология активно развивается, на онлайн-конференциях о ней говорят, да и сами мы пишем их каждый день. Когда-то новый подход уже стал рутиной. Но мне как Java-архитектору интересно то, каким код был раньше, как он менялся, какие способы исполнения популярны сейчас и будут использоваться в 2021 году: асинхронность, контейнеры, FaaS. 

Так родился этот пост в двух частях, который я подготовил для Хабра на основе своих статей в блоге компании BellSoft и круглого стола Joker 2020, где мы обсуждали будущее джавы. Актуальное сегодня улучшение экосистемы для бэкендов не может существовать без понимания того, как создавать микросервисы: писать с нуля или вырезать скальпелем из монолитов? Предлагаю в первой части поговорить об их сущности, а во второй — разложить микросервисный контейнер на слои и посмотреть на вклад каждого слоя.

Главное преимущество — в структуре

Абсолютное большинство материалов о микросервисной архитектуре сравнивает её с монолитами с точки зрения строения. Того, каким образом работают компоненты, как единое целое или изолированно. Микросервисы не зависят друг от друга и могут обмениваться данными по сети через произвольные протоколы, например, REST API. Что это нам дает? Как минимум, свободу выбирать любые тулы, не оглядываясь на ESB, ограничения схем и тонкости совместимости. Виртуализация и контейнеризация тоже развиваются, и вот уже крошечные контейнеры с Alpine Linux позволяют запускать на прежде выделенном железе много компонент сразу.

Возьмём простой сервис, такой как бронирование билета или пополнение счёта. Ещё до появления микросервисов для управления жизненным циклом объекта данных в таких системах использовали подход CRUD. Но вся функциональность, которая обеспечивает CRUD операции для какой-то сущности, легко вычленяется. После чего можно отдельно заниматься масштабированием, управлением доступом и взаимодействием в целом, например, через REST.

Вроде, всё отлично, в чём подвох?

Проблемы и решения

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

• сложность в управлении сетевым трафиком и задержки;

• сбои запросов и другие ошибки;

• необходимость сериализовать данные и шифровать соединения.

Пожалуй, сегодня программист сервиса решит эти проблемы через готовые API Kafka/Redis/RabbitMQ и снимет с себя головную боль, отчасти забыв о сетевом уровне. А задача настройки Kafka уже пойдёт как активность DevOps.

Кроме того, управление микросервисами может стать проблемой, если их много. Поведение приложения становится сложно предсказать. Представьте сеть из сотен виртуальных хранилищ, каждое из которых обращается к другому, а иногда — одновременно. Где-то наверняка произойдёт сбой. 

Есть ряд очевидных подходов к решению этой проблемы:

1. Декомпозиция сервиса с помощью брокеров сообщений и систем управления потоковыми данными (Kafka, Kinesis);

2. Взаимодействие между сервисами с помощью сервисной сетки, или service mesh (Istio, OSM);

3. Перепроектирование системы. 

В идеале задача — избежать такой картины:

превратив её, скажем, в такую:

Видим, что современные системы стриминга сообщений предоставляют готовые коннекторы для баз данных и других хранилищ. Здесь streaming platform (допустим, Kafka) позволяет больше не думать, как связать базы со всем остальным приложением.

Если мы взглянем отдельно на первый уровень прямо под пользователем, то он тоже довольно сложный. Редкий сервис работает с одной копией приложения, их могут быть сотни. А значит, нужно понимать, куда полетят запросы.

Service mesh («cервисная сетка») как раз помогает наладить отправку и обработку запросов. При этом возникает задача построения архитектуры, в которой уже есть свои шаблоны проектирования, такие как Sidecar.

Рантаймы, такие как JVM, вместе с языками и фреймворками поддерживают всю эту конструкцию, вывозя на себе исполнение кода.

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

Выбор инструментов

При исполнении бизнес-логики, конечно же, задействовано само приложение и операционная система. Обратимся к недавней истории и посмотрим, что же ещё нужно для сборки контейнера.

Для начала уместно будет вспомнить о сервис-ориентированной архитектуре. На фоне монолитов это первая успешная попытка решить проблемы в работе всего приложения за счёт слабой связности его частей. Можно сказать, что микросервисы — это усовершенствованная интерпретация SOA. 

До поры до времени она справлялась с горизонтальным масштабированием сервисов. Но методы программирования не прекращали развиваться. Железо становилось лучше, сети — быстрее. Появлялись новые, легковесные способы коммуникации между приложениями, например REST.

Как обстояли дела с Java? Здесь всё началось с систем, основанных на наследовании и конфигах. Java EE еще лет 20 назад представила сервлеты. Далее история известна: конфигурация прямо в коде, когда XML и сам код генерировались из javadoc аннотаций; затем появились настоящие аннотации; следом и дженерики в Java 5. А вот сериализация уже была с самого начала. Появляющиеся фичи языка использовались в новых версиях Java EE.

Да, в спецификации Java EE прописаны протоколы (например, JNDI), но разработчикам реально помогло то, она описывает простые декларации того, что фактически контролируется сервером приложений. Когда мир перешел с Web 1.0 на Web 2.0, ответственность за представление перешла от бэкенда к фронтенду. И разница между внешними запросами и запросами от другой части системы исчезла.

Container dependency injection

Или «контейнерное внедрение зависимостей». Время идёт, за долгие годы индустрия освоила фичи языка и сформировала набор производственных практик. «Метапрограммирование при помощи аннотаций» — так теперь джависты могут описать свои будни. И в разработке фреймворков применяются те же подходы. Хотя стоит отметить, что другие языки предлагают достойные альтернативы: trailing lambdas в Kotlin для описания маршрутизации в Ktor; или же data-классы в разных языках, которые наконец догнала Java в 14 версии с её новыми record-ами (хотя и для старых версий давно есть Lombok).

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

Собственно такой шаблон построения компонентных моделей называется Contexts and Dependency Injection (CDI). CDI как спецификация Java EE была принята в JSR 299/365 и получила эталонную реализацию в Weld, которая до сих пор используется в контейнерах вроде WildFly. Основной принцип подобной архитектуры — инверсия управления (Inversion of Control, IoC).

Не все задачи предполагают строгие стандарты: например, модули, которые подключаются к базам данных (как Spring Data) или участвуют в создании интерактивного HTML. Но для них существуют фреймворки. В каждом — ограниченный набор таких модулей, что позволяет вести разработку продуктивно. Внедрение зависимостей и инверсия управления, наряду с еще одной полезной парадигмой Convention over Configuration (также известной как «кодирование по соглашению»), реализованы в IoC-контейнерах во фреймворках, например BeanFactory в Spring. Но о них поговорим в следующий раз.

Заключение

Как я и обещал во вступлении, этот пост стал небольшим экскурсом в историю микросервисной архитектуры — ведь без этого никуда. Мы работаем с отличными технологиями, которым уже 20 с лишним лет, но они по-прежнему ощущаются современными. Всё потому, что методы востребованные и живые, а не превращаются в legacy.

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