Микросервисы Java — это разбивка при написании огромного кода Java-приложения
на более мелкие самостоятельные компоненты. Вот эти самостоятельные
компоненты — это и есть микросервисы Java. Но нужно понимать, что эти
компоненты взаимосвязаны и представляют единое целое приложение, хотя
разрабатываться могут по отдельности друг от друга и разными разработчиками.
Микросервисы Java или Монолит Java
Приложения Java могут разрабатываться по 2-м сценариям:
- микросервисы Java;
- монолит Java.
Остановимся на обоих сценариях, чтобы понять разницу и преимущества одного
перед другим.
Монолит Java
Принцип монолитной архитектуры означает, что программное обеспечение
разрабатывается как единое целое. При такой архитектуре подразумевают всего 3
блока у ПО:
- Интерфейс пользователя;
- Данные и их хранилище;
- Сервер.
Все работает очень тесно и взаимосвязано. Как правило, при такой архитектуре
сервер отвечает за обработку запросов, выполнение бизнес-логики, наполнение
HTML- страниц, работу с базой данных и др. Поэтому, когда нужно внести какое-то
изменение в эту рабочую систему, приходится обновлять и серверную часть
приложения.
Хочется заметить, что при микросервисной архитектуре, такого не происходит.
Обновляется только та часть программы, где в этом есть необходимость.
Многие небольшие приложения или приложения «одного разработчика»
разрабатываются именно в такой архитектуре, в ней нет ничего критичного.
Проблемы при такой архитектуре возникают в следующих случаях:
- Когда начинается более масштабная работа;
- Когда в разработке задействованы несколько разработчиков или даже команд разработчиков, а многие работают удаленно и, даже, находятся в разных странах и часовых поясах;
- Если разработка ведется или рассчитана на несколько месяцев/лет.
- Когда приложение сложное и подразумевает большое количество разносторонних модулей.
То есть, когда есть вероятность, что код приложения превратиться в гигабайты веса,
и при этом его будут писать разные люди, то проблем при монолитной архитектуре
не избежать. Плюс дополнительно возникают трудности при обновлениях таких
продуктов или при желании его масштабировать.
Недостатки монолитной архитектуры Java
Поэтому можно выделить следующие недостатки монолитной архитектуры Java:
- Большое количество сборок приложения. Любое изменение в приложение можно будет внести только при развертывании новой сборки самого приложения.
- Нет масштабирования частей приложения. Если будет необходимо масштабировать или переделать компонент приложения, то придется изменять все приложение.
- Дорогой сбой. Если откажет один из компонентов, то может произойти отказ всего приложения.
- Сложность в организации рабочего процесса. Если приложение будет большим, то нужны будут отдельные специалисты по: интерфейсу, БД и бизнес-логике. Но главное, что каждый из этих специалистов должен будет знать особенности работы параллельных специфик. Потому что приложение функционирует как единый организм, а значит ошибка одного из специалистов, может отразиться на работе всей системы.
- Сложность с обновлением. Обновление любого из компонентов затрагивает обновление всего ПО. А обновлять все ПО затратно. Поэтому при монолитных архитектурах необходимые изменения «накапливают» и проводят масштабные работы над обновлением всей программы.
Тут на помощь может прийти микросервисная архитектура Java, которая способна
избавить от многих недостатков Монолита.
Микросервисы Java
Главное отличие от Монолита — это «разбивка» большого приложения на
отдельные компоненты разработки (микросервисы Java), между которыми потом
налаживается связь. Суть в том, что эти отдельные компоненты независимы друг от
друга, их возможно разработать, изменить, обновить, поддержать, удалить и т. д. по
отдельности.
При такой архитектуре каждый компонент отвечает за собственный функционал и
задачи и обладает собственным хранилищем данных. Между всеми
микросервисами налаживается коммуникация.
Коммуникация между микросервисами Javа может быть налажена 2-мя вариантами:
- Синхронный вариант. Этот вариант подразумевает использование HTTP и
REST API сервисы, которые работают с XML и JSON. Данный вариант
позволяет получать практически мгновенный ответ на запрос. - Асинхронный вариант. Этот вариант подразумевает использование обмена
сообщениями с помощью реализации JMS или других протоколов, а также по
SMTP, последнее используется реже. Данный вариант используется, когда не
нужен мгновенный ответ на запрос.
Начинающих разработчиков часто путает приставка «микро». В микросервисах Java
это не означает что сервис очень маленький. Это отдельный процесс в приложении,
который на самом деле может быть очень большим. Кстати, споры о том, где
«микросервис», а где нет, продолжается постоянно. Поэтому четкой границы в этом
нет.
Но есть общие принцип, что весь «микросервис Java» должен уместиться в голове
одного разработчика. У компании Амазон в этом был собственный подход — они
считают что микросервис должен быть таким, чтобы его разработчиков можно было
накормить досыта 2-мя пиццами.
На практике же получается всегда по-разному. Если приложения разрабатывается с
нуля, то ест возможность сделать микросвервисы действительно небольшими и
выделить на них по одному разработчику, а иногда даже по несколько
микросервисов на одного разработчика. Но когда монолитное приложение пытаются
«разбить» на микросервисы, то тут размер этих «микросервисов» иногда может быть
большим и им могут заниматься несколько разработчиков.
Микосервисная архитектура Java, тоже не совсем идеально, у нее есть свои
преимущества перед Монолитом, но также есть и свои недостатки.
Преимущества и недостатки микросервисов Java
Выделим несколько преимуществ микросервисов перед монолитами:
- Разработка проще. Работать, обновлять, разрабатывать проще один
компонент приложения, чем все приложение разом. - Удобное масштабирование. К примеру есть компонент приложения, который
работает не с той производительностью, как хотелось бы. Его нужно
масштабировать. И делается это только с этим компонентом, а не со всем
приложением в целом. При этом другие компоненты спокойно могут работать. - Сбои приложения проходят «мягче». То есть, когда нарушена работа одного из
сервисов приложения , есть возможность его «отключить» и исправлять сбой.
Но при этом, само приложение будет продолжать работать, даже без
отсутствия какого-либо сервиса. Но опять же это становится возможным, когда еще при этапе разработки ПО была налажена «независимость» между
отдельными его сервисами. - Нет ограничения в технологиях. При разработке разных сервисов, можно
использовать различные технологии, при монолитной архитектуре — одна
технология на все сервисы. - Не нужны большие команды разработчиков. Если преследовать принцип: один
сервис-один разработчик или команда, то нет необходимости объединять их
всех в одну команду и собирать за «общим» столом, так как их работа может
быть налажена независимо друг от друга. - Упрощена манипуляция с сервисами. Допустим вам нужно заменить
существующий микросервис Java на другой. Все что вам нужно сделать — это
разработать необходимый микросервис и подключить его вместо
существующего. При этом не нужно отключать, закрывать, обновлять само
приложение.
Это не все преимущества микросервисной архитектуры Java, на каждом проекте
можно выделить собственные. Но при всем обилии преимуществ у такой
архитектуры есть и свои недостатки.
Недостатки микросервисов Java
- Недостаток распределенной системы. Микросервисы Java, как правило
распределены. Из-за этого снижена скорость работы приложения при их
вызове. А если представить, что ваш микросервис взаимодействует с
десятками других, а те с десятками следующих, то скорость «отклика» сильно
падает. Плюс возрастает вероятность возникновения отказов и сбоев. - Сложность интеграции всех процессов. Независимые микросервисы Java —
это прекрасно. Но возрастает сложность их интеграции в единую систему.
Также после их интегрирования, будет необходим постоянный мониторинг их
работы. Поэтому нужно наладить качественное взаимодействие всех
разносторонних специалистов: разработчик, тестировщик, инженер
мониторинга и т. п.
Заключение
Использовать или не использовать микросервисы Java — это вопрос требует
индивидуального исследования для каждого приложения. Однозначного ответа тут
нет. Но если правильно рассчитать, какие преимущества и какие проблемы принесет
микросервисная архитектура в ваш проект, то ответ станет очевиден.
Возможно вам будет интересно почитать статью “UX тестирование, где используется и как проводится”
В любом случае, нужно брать во внимание еще и то, что вы создаете проект не на
один день. Потому что есть вероятность, что на данный момент будет актуальна
монолитная архитектура, но в перспективе вы планируете развиваться и
расширяться. Поэтому с ее применением могут возникнуть соответствующие
проблемы. А потом «разбивать» монолит на микросервисы Java будет сложнее и
дороже. При этом все недостатки микросервисов легко перекрываются их
достоинствами и возможностями.
