Что такое микросервисы в java
Микросервисы Java: определение и для чего используются
Микросервисы Java — это разбивка при написании огромного кода Java-приложения на более мелкие самостоятельные компоненты. Вот эти самостоятельные компоненты — это и есть микросервисы Java. Но нужно понимать, что эти компоненты взаимосвязаны и представляют единое целое приложение, хотя разрабатываться могут по отдельности друг от друга и разными разработчиками.
Микросервисы Java или Монолит Java
Приложения Java могут разрабатываться по 2-м сценариям:
Остановимся на обоих сценариях, чтобы понять разницу и преимущества одного перед другим.
Монолит Java
Принцип монолитной архитектуры означает, что программное обеспечение разрабатывается как единое целое. При такой архитектуре подразумевают всего 3 блока у ПО:
Данные и их хранилище;
Все работает очень тесно и взаимосвязано. Как правило, при такой архитектуре сервер отвечает за обработку запросов, выполнение бизнес-логики, наполнение HTML-страниц, работу с базой данных и др. Поэтому, когда нужно внести какое-то изменение в эту рабочую систему, приходится обновлять и серверную часть приложения.
Хочется заметить, что при микросервисной архитектуре такого не происходит. Обновляется только та часть программы, где в этом есть необходимость.
Многие небольшие приложения или приложения «одного разработчика» разрабатываются именно в такой архитектуре, в ней нет ничего критичного. Проблемы при такой архитектуре возникают в следующих случаях:
Когда начинается более масштабная работа;
Когда в разработке задействованы несколько разработчиков или даже команд разработчиков, а многие работают удаленно и ли вообще находятся в разных странах и часовых поясах;
Когда разработка ведется или рассчитана на несколько месяцев/лет ;
Когда приложение сложное и подразумевает большое количество разносторонних модулей.
То есть, когда есть вероятность, что код приложения преврати тся в гигабайты веса и при этом его будут писать разные люди, то проблем при монолитной архитектуре не избежать. Плюс дополнительно возникают трудности при обновлениях таких продуктов или при желании его масштабировать.
Поэтому можно выделить следующие недостатки монолитной архитектуры Java:
Большое количество сборок приложения. Любое изменение в приложение можно будет внести только при развертывании новой сборки самого приложения.
Нет масштабирования частей приложения. Если будет необходимо масштабировать или переделать компонент приложения, то придется изменять все приложение.
Дорогой сбой. Если откажет один из компонентов, то может произойти отказ всего приложения.
Сложность с обновлением. Обновление любого из компонентов затрагивает обновление всего ПО. А обновлять все ПО затратно. Поэтому при монолитных архитектурах необходимые изменения «накапливают» и проводят масштабные работы над обновлением всей программы.
Тут на помощь может прийти микросервисная архитектура Java, которая способна избавить от многих недостатков Монолита.
Микросервисы Java
Главное отличие от Монолита — это «разбивка» большого приложения на отдельные компоненты разработки (микросервисы Java), между которыми потом налаживается связь. Суть в том, что эти отдельные компоненты независимы друг от друга, их возможно разработать, изменить, обновить, поддержать, удалить и т. д. по отдельности.
При такой архитектуре каждый компонент отвечает за собственный функционал и задачи и обладает своим хранилищем данных. Между всеми микросервисами налаживается коммуникация.
Коммуникация между микросервисами Java может быть налажена 2-мя вариантами:
Асинхронный вариант. Этот вариант подразумевает использование обмена сообщениями с помощью реализации JMS или других протоколов, а также по SMTP, последнее используется реже. Данный вариант используется, когда не нужен мгновенный ответ на запрос.
На практике же получается всегда по-разному. Если приложени е разрабатывается с нуля, то ест ь возможность сделать микрос е рвисы действительно небольшими и выделить на них по одному разработчику, а иногда даже по несколько микросервисов на одного разработчика. Но когда монолитное приложение пытаются «разбить» на микросервисы, то тут размер этих «микросервисов» иногда может быть большим и им могут заниматься несколько разработчиков.
Преимущества и недостатки микросервисов Java
Выделим несколько преимуществ микросервисов перед монолитами:
Разработка проще. Работать, обновлять, разрабатывать проще один компонент приложения, чем все приложение разом.
Нет ограничения в технологиях. При разработке разных сервисов можно использовать различные технологии, при монолитной архитектуре — одна технология на все сервисы.
Не нужны большие команды разработчиков. Если преследовать принцип: один сервис — один разработчик или команда, то нет необходимости объединять их всех в одну команду и собирать за «общим» столом, так как их работа может быть налажена независимо друг от друга.
Это не все преимущества микросервисной архитектуры Java, на каждом проекте можно выделить собственные. Но при всем обилии преимуществ у такой архитектуры есть и свои недостатки:
Сложность интеграции всех процессов. Независимые микросервисы Java — это прекрасно. Но возрастает сложность их интеграции в единую систему. Также после их интегрирования будет необходим постоянный мониторинг их работы. Поэтому нужно наладить качественное взаимодействие всех разносторонних специалистов: разработчик, тестировщик, инженер мониторинга и т. п.
Использовать или не использовать микросервисы Java — это т вопрос требует индивидуального исследования для каждого приложения. Однозначного ответа тут нет. Но если правильно рассчитать, какие преимущества и какие проблемы принесет микросервисная архитектура в ваш проект, то ответ станет очевиден.
В любом случае нужно брать во внимание еще и то, что вы создаете проект не на один день. Потому что есть вероятность, что на данный момент будет актуальна монолитная архитектура, но в перспективе вы планируете развиваться и расширяться. Поэтому с ее применением могут возникнуть соответствующие проблемы. А потом «разбивать» монолит на микросервисы Java будет сложнее и дороже. При этом все недостатки микросервисов легко перекрываются их достоинствами и возможностями.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Микросервисы: от CRUD до Native Image. Часть первая
Слово «микросервисы» на слуху последние несколько лет. Технология активно развивается, на онлайн-конференциях о ней говорят, да и сами мы пишем их каждый день. Когда-то новый подход уже стал рутиной. Но мне как Java-архитектору интересно то, каким код был раньше, как он менялся, какие способы исполнения популярны сейчас и будут использоваться в 2021 году: асинхронность, контейнеры, FaaS.
Так родился этот пост в двух частях, который я подготовил для Хабра на основе своих статей в блоге компании BellSoft и круглого стола Joker 2020, где мы обсуждали будущее джавы. Актуальное сегодня улучшение экосистемы для бэкендов не может существовать без понимания того, как создавать микросервисы: писать с нуля или вырезать скальпелем из монолитов? Предлагаю в первой части поговорить об их сущности, а во второй — разложить микросервисный контейнер на слои и посмотреть на вклад каждого слоя.
Главное преимущество — в структуре
Абсолютное большинство материалов о микросервисной архитектуре сравнивает её с монолитами с точки зрения строения. Того, каким образом работают компоненты, как единое целое или изолированно. Микросервисы не зависят друг от друга и могут обмениваться данными по сети через произвольные протоколы, например, REST API. Что это нам дает? Как минимум, свободу выбирать любые тулы, не оглядываясь на ESB, ограничения схем и тонкости совместимости. Виртуализация и контейнеризация тоже развиваются, и вот уже крошечные контейнеры с Alpine Linux позволяют запускать на прежде выделенном железе много компонент сразу.
Возьмём простой сервис, такой как бронирование билета или пополнение счёта. Ещё до появления микросервисов для управления жизненным циклом объекта данных в таких системах использовали подход CRUD. Но вся функциональность, которая обеспечивает CRUD операции для какой-то сущности, легко вычленяется. После чего можно отдельно заниматься масштабированием, управлением доступом и взаимодействием в целом, например, через REST.
Вроде, всё отлично, в чём подвох?
Проблемы и решения
Разные части монолитного приложения работают в общей памяти, а все запросы отправляются на один и тот же физический сервер. Микросервисы же связываются между собой через протоколы, а это порождает, например:
сложность в управлении сетевым трафиком и задержки;
сбои запросов и другие ошибки;
необходимость сериализовать данные и шифровать соединения.
Пожалуй, сегодня программист сервиса решит эти проблемы через готовые API Kafka/Redis/RabbitMQ и снимет с себя головную боль, отчасти забыв о сетевом уровне. А задача настройки Kafka уже пойдёт как активность DevOps.
Кроме того, управление микросервисами может стать проблемой, если их много. Поведение приложения становится сложно предсказать. Представьте сеть из сотен виртуальных хранилищ, каждое из которых обращается к другому, а иногда — одновременно. Где-то наверняка произойдёт сбой.
Есть ряд очевидных подходов к решению этой проблемы:
Декомпозиция сервиса с помощью брокеров сообщений и систем управления потоковыми данными (Kafka, Kinesis);
Взаимодействие между сервисами с помощью сервисной сетки, или service mesh (Istio, OSM);
В идеале задача — избежать такой картины:
превратив её, скажем, в такую:
Видим, что современные системы стриминга сообщений предоставляют готовые коннекторы для баз данных и других хранилищ. Здесь 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.
Во второй части я подробно разберу слои микросервисного контейнера, объясню, на что влияет правильный выбор рантайма, и расскажу, как снизить потребление ресурсов до минимума.
Руководство по микросервисам Java. Часть 1: основы микросервисов и их архитектура
Из этого руководства вы узнаете что такое микросервисы Java, как их проектировать и создавать. Также здесь затронуты вопросы о библиотеках микросервисов Java и целесообразности применения микросервисов.
Микросервисы Java: основы
Чтобы понять микросервисы, нужно сначала определить, что ими не является. А не является ими “монолит” — Java monolith: что это такое и каковы его преимущества или недостатки?
Что такое Java-монолит?
Представьте, что вы работаете в банке или финтех-стартапе. Вы предоставляете пользователям мобильное приложение, которое можно использовать для открытия нового банковского счета.
В Java-коде это приведет к наличию класса-контроллера. Упрощенно он выглядит следующим образом:
Вам нужно, чтобы контроллер:
В чем проблема с Java-монолитами?
По своей сути, в Java-монолитах нет ничего плохого. Однако опыт показал, что если у вас в проекте:
… то в таком случае ваш маленький файлик bank.jar превращается в необозримый гигабайт одного только кода, к которому даже подступиться страшно, не говоря уже о развёртывании.
Как уменьшить размер монолита Java?
Возникает естественный вопрос: как сделать монолит меньше? Сейчас ваш bank.jar работает на одной JVM, один процесс на одном сервере. Ни больше, ни меньше.
И вот именно сейчас в голову может прийти логичная мысль: «А ведь служба проверки рисков может использоваться и другими отделами в моей компании! Она не имеет непосредственного отношения к моему монолитному банковскому приложению! Возможно, стоит вырезать её из монолита и развернуть, как отдельный продукт? То есть, если говорить технически, запустить его как отдельный процесс Java”.
Что такое микросервис Java?
На практике такое словосочетание означает, что теперь вызов метода riskCheck() будет производиться не из BankController: этот метод или bean-компонент со всеми его вспомогательными классами будет перемещён в собственный Maven- или Gradle-проект. Также он будет развёрнут и помещён под систему контроля версий независимо от банковского монолита.
Однако весь этот процесс извлечения не превращает ваш новый модуль RiskCheck в микросервис как таковой, поскольку определение микросервиса открыто для интерпретации. Это приводит к частым дискуссиям внутри команд и компаний.
Давайте оставим теоретические рассуждения, а вместо них будем придерживаться прагматических соображений и сделаем вот что:
Итак, подведем итоги: раньше у вас был один JVM-процесс, цельный монолит для работы банка. Теперь у вас есть JVM-процесс банковского монолита и отдельный микросервис RiskCheck, который работает в рамках собственного JVM-процесса. И теперь для проверки рисков ваш монолит должен вызывать этот микросервис. Каким образом это сделать?
Как наладить коммуникацию между микросервисами Java?
В целом и общем есть два варианта — синхронная и асинхронная коммуникация.
Синхронная коммуникация: (HTTP)/REST
Обычно синхронизированная коммуникация между микросервисами осуществляется через HTTP и REST-подобные сервисы, которые возвращают XML или JSON. Разумеется, могут быть и другие варианты — взять хотя бы Google Protocol Buffers.
Если вам нужен немедленный ответ, лучше использовать REST-коммуникацию. В нашем примере именно так и нужно делать, поскольку проверка рисков обязательна перед открытием счета. Если нет проверки рисков, нет и счёта.
Инструменты обсудим ниже, в разделе “Какие библиотеки лучше всего подходят для синхронных вызовов Java REST”.
Обмен сообщениями — асинхронная коммуникация
Асинхронная микросервисная связь обычно осуществляется посредством обмена сообщениями с реализацией JMS и/или с помощью протокола, например, AMQP. Мы здесь написали “обычно” не просто так: скажем, количество интеграций по электронной почте/SMTP нельзя недооценивать.
Используйте его тогда, когда вам не нужен незамедлительный ответ. Например, пользователь нажимает кнопку «купить сейчас», а вы в свою очередь хотите сгенерировать счет-фактуру. Этот процесс, безусловно, не должен происходить в рамках цикла запроса-ответа пользователя на покупку.
Ниже мы опишем, какие инструменты лучше всего подходят для асинхронного обмена сообщениями Java.
Пример: вызов REST API в Java
Предположим, мы избрали синхронную микросервисную коммуникацию. В таком случае наш Java-код (тот, что мы приводили выше) на низком уровне будет выглядеть примерно так. (под низким уровнем здесь мы понимаем тот факт, что для микросервисной коммуникации обычно создаются клиентские библиотеки, которые абстрагируют вас от реальных HTTP-вызовов).
Исходя из кода, становится ясно, что теперь нам нужно развернуть два Java-(микро) сервиса, Bank и RiskCheck. В итоге у нас будет запущено два JVM-процесса.
Архитектура Java Microservices
На практике компании разрабатывают микросервисные проекты по-разному. Подход зависит от того, пытаетесь ли вы преобразовать существующий монолит в проект с микросервисами или же начинаете проект с нуля.
От монолита к микросервисам
Одна из самых логичных идей — извлечь микросервисы из существующего монолита. Обратите внимание, что приставка «микро» здесь на самом деле не означает, что извлеченные сервисы будут действительно небольшими, это совершенно не обязательно. Давайте рассмотрим теоретические основы.
Идея: разбить монолит на микросервисы
К легаси-проектам можно применить микросервисный подход. И вот почему:
Возвращаясь к нашему примеру, это означает, что вы можете взглянуть на свой банковский Java-монолит и попытаться разбить его по границам домена.
Воплощение идеи: пусть это сделает кто-то другой
Описанный выше подход отлично смотрится на бумаге и UML-подобных диаграммах. Однако всё не так просто. Для его практической реализации нужна серьезная техническая подготовка: пропасть между понимаем того, что было бы неплохо извлечь из монолита и самим процессом извлечения — огромна.
Большинство корпоративных проектов доходят до стадии, когда разработчики опасаются, скажем, обновить 7-летнюю версию Hibernate до более новой. Вместе с ней обновятся библиотеки, однако существует неиллюзорная опасность что-нибудь поломать.
И вот, те же разработчики теперь должны копаться в древнем легаси-коде с неясными границами транзакций базы данных и извлекать четко определенные микросервисы? Чаще всего эта задача очень сложна, её не получится “решить” на доске или на совещаниях по архитектуре.
Процитирую Twitter разработчика @simonbrown:
Проект “с нуля” на базе микросервисной архитектуры
В случае новых Java-проектов три нумерованных пункта из предыдущей части выглядят несколько иначе:
Это приводит к тому, что компании пытаются использовать новые проекты с микросервисами Java.
Техническая микросервисная архитектура
Первый пункт кажется наиболее очевидным для разработчиков, однако находятся и те, кто крайне не рекомендует его. Хади Харири рекомендует рефакторинг «Extract Microservice» в IntelliJ.
И хотя следующий пример очень упрощён, реализации, наблюдаемые в реальных проектах, к сожалению, не слишком далеко от него ушли.
До микросервисов
С substring-микросервисом Java
Таким образом, вы, по сути, включаете вызов метода Java в вызов HTTP, без очевидных причин для этого. Одна из причин, однако, заключается в следующем: отсутствие опыта и попытка форсировать подход на основе микросервисов Java.
Рекомендация: не делайте этого.
Workflow-ориентированная микросервисная архитектура
Следующим распространенным подходом является разделение микросервисов Java на модули на базе workflow.
Пример из реальной жизни: в Германии, когда вы обращаетесь к (общедоступному) врачу, он должен записать ваше посещение в своей медицинской CRM-системе.
Чтобы получить оплату от страховки, он отправит данные о вашем лечении (и лечении других пациентов) посреднику через XML. Посредник рассмотрит этот XML-файл и (упрощенно):
Примечание. В этом примере коммуникация между микросервисами не играет роли, но вполне может быть выполнена асинхронно брокером сообщений (например, RabbitMQ), поскольку врач все равно не получает немедленной обратной связи.
Снова таки, это отлично выглядит на бумаге, но возникают закономерные вопросы:
Интересно, что приведенная выше диаграмма выглядит проще, потому что у каждого сервиса теперь есть свое точное, четко определенное назначение. Раньше это выглядело примерно как этот страшный монолит:
Несмотря на то, что можно спорить о простоте этих диаграмм, теперь вам определенно нужно решить эти дополнительные операционные задачи.
Так что рекомендация будет следующей:
А теперь менее гиперболизировано.
Попытка моделировать микросервисы после доменных границ кажется вполне разумной. Но это не означает, что нужно взять один рабочий процесс и разделить его на крошечные отдельные части (получить XML, проверить XML, переслать XML).
Следовательно, всякий раз, когда вы начинаете новый проект с микросервисам Java, и границы домена все еще очень расплывчаты, старайтесь поддерживать размер ваших микросервисов на нижнем уровне. Позднее вы всегда сможете добавить больше модулей.
И убедитесь, что у вас найдётся продвинутый DevOps в команде/компании/подразделении для поддержки вашей новой инфраструктуры.
Полиглот или командно-ориентированная микросервисная архитектура
Существует третий, почти либертарианский, подход к разработке микросервисов: предоставление командам или даже отдельным лицам возможности реализовывать пользовательские истории с применением любого количества языков или микросервисов (маркетологи называют такой подход “полиглотским программированием”).
Так, описанная выше служба проверки XML может быть написана на Java, а микросервис валидации в то же самое время — на языке Haskell (чтобы сделать его математически обоснованным). Для микросервиса пересылки страховки можно применить язык Erlang (потому что он действительно должен масштабироваться;)).
То, что может показаться забавным с точки зрения разработчика (разработка идеальной системы с вашим идеальным языком в изолированной среде), в сущности, никогда не является тем, чего хочет организация: гомогенизация и стандартизация.
Это означает относительно стандартизированный набор языков, библиотек и инструментов, чтобы другие разработчики могли продолжать поддерживать ваш микросервис Haskell в будущем, когда вы перейдете на более экологичные пастбища.
История показывает, что обычно стандартизация укореняется слишком глубоко. Скажем, разработчикам больших компаний из списка Fortune 500 иногда даже не позволяли использовать Spring, поскольку это «не входит в план компании по технологиям». Впрочем, полный переход на подход полиглота — это почти то же самое, другая сторона той же монеты.
Рекомендация: если вы собираетесь использовать полиглот-программирование, попробуйте меньшее разнообразие в одной и той же экосистеме языка программирования. Так, лучше применять вместе Kotlin и Java (оба языка основаны на JVM и 100% совместимы друг с другом), а не Java и, скажем, Haskell.
В следующей части вы узнаете о развертывании и тестировании микросервисов Java.