Другое

Микросервисы Java: определение и для чего используются

Lorem ipsum dolor

Микросервисы Java — это разбивка при написании огромного кода Java-приложения на более мелкие самостоятельные компоненты. Вот эти самостоятельные компоненты — это и есть микросервисы Java. Но нужно понимать, что эти компоненты взаимосвязаны и представляют единое целое приложение, хотя разрабатываться могут по отдельности друг от друга и разными разработчиками.

Микросервисы Java или Монолит Java

Приложения Java могут разрабатываться по 2-м сценариям:

  • микросервисы Java;

  • монолит Java.

Остановимся на обоих сценариях, чтобы понять разницу и преимущества одного перед другим.

Монолит Java

Принцип монолитной архитектуры означает, что программное обеспечение разрабатывается как единое целое. При такой архитектуре подразумевают всего 3 блока у ПО:

  1. Интерфейс пользователя;

  2. Данные и их хранилище;

  3. Сервер.

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

Хочется заметить, что при микросервисной архитектуре такого не происходит. Обновляется только та часть программы, где в этом есть необходимость.

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

  • Когда начинается более масштабная работа;

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

  • Когда разработка ведется или рассчитана на несколько месяцев/лет;

  • Когда приложение сложное и подразумевает большое количество разносторонних модулей.

 

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

Поэтому можно выделить следующие недостатки монолитной архитектуры Java:

  • Большое количество сборок приложения. Любое изменение в приложение можно будет внести только при развертывании новой сборки самого приложения.

  • Нет масштабирования частей приложения. Если будет необходимо масштабировать или переделать компонент приложения, то придется изменять все приложение.

  • Дорогой сбой. Если откажет один из компонентов, то может произойти отказ всего приложения.

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

  • Сложность с обновлением. Обновление любого из компонентов затрагивает обновление всего ПО. А обновлять все ПО затратно. Поэтому при монолитных архитектурах необходимые изменения «накапливают» и проводят масштабные работы над обновлением всей программы.

Тут на помощь может прийти микросервисная архитектура Java, которая способна избавить от многих недостатков Монолита.

Микросервисы Java

Главное отличие от Монолита — это «разбивка» большого приложения на отдельные компоненты разработки (микросервисы Java), между которыми потом налаживается связь. Суть в том, что эти отдельные компоненты независимы друг от друга, их возможно разработать, изменить, обновить, поддержать, удалить и т. д. по отдельности.

При такой архитектуре каждый компонент отвечает за собственный функционал и задачи и обладает своим хранилищем данных. Между всеми микросервисами налаживается коммуникация.

Коммуникация между микросервисами Java может быть налажена 2-мя вариантами:

  1. Синхронный вариант. Этот вариант подразумевает использование HTTP и REST API сервисов, которые работают с XML и JSON. Данный вариант позволяет получать практически мгновенный ответ на запрос.

  2. Асинхронный вариант. Этот вариант подразумевает использование обмена сообщениями с помощью реализации JMS или других протоколов, а также по SMTP, последнее используется реже. Данный вариант используется, когда не нужен мгновенный ответ на запрос.

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

Но есть общий принцип, что весь «микросервис Java» должен уместиться в голове одного разработчика. У компании Амазон в этом собственный подход — они считают, что микросервис должен быть таким, чтобы его разработчиков можно было накормить досыта 2-мя пиццами.

На практике же получается всегда по-разному. Если приложение разрабатывается с нуля, то есть возможность сделать микросервисы действительно небольшими и выделить на них по одному разработчику, а иногда даже по несколько микросервисов на одного разработчика. Но когда монолитное приложение пытаются «разбить» на микросервисы, то тут размер этих «микросервисов» иногда может быть большим и им могут заниматься несколько разработчиков.

Микросервисная архитектура Java тоже не совсем идеальна, у нее есть свои преимущества перед Монолитом, но также есть и свои недостатки.

Преимущества и недостатки микросервисов Java 

Выделим несколько преимуществ микросервисов перед монолитами:

  1. Разработка проще. Работать, обновлять, разрабатывать проще один компонент приложения, чем все приложение разом.

  2. Удобное масштабирование. К примеру, есть компонент приложения, который работает не с той производительностью, как хотелось бы. Его нужно масштабировать. И делается это только с этим компонентом, а не со всем приложением в целом. При этом другие компоненты спокойно могут работать.

  3. Сбои приложения проходят «мягче». То есть, когда нарушена работа одного из сервисов приложения, есть возможность его «отключить» и исправлять сбой. Но при этом само приложение будет продолжать работать даже без отсутствия какого-либо сервиса. Но, опять же, это становится возможным, когда еще на этапе разработки ПО была налажена «независимость» между отдельными его сервисами.

  4. Нет ограничения в технологиях. При разработке разных сервисов можно использовать различные технологии, при монолитной архитектуре — одна технология на все сервисы.

  5. Не нужны большие команды разработчиков. Если преследовать принцип: один сервис один разработчик или команда, то нет необходимости объединять их всех в одну команду и собирать за «общим» столом, так как их работа может быть налажена независимо друг от друга.

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

Это не все преимущества микросервисной архитектуры Java, на каждом проекте можно выделить собственные. Но при всем обилии преимуществ у такой архитектуры есть и свои недостатки:

  1. Недостаток распределенной системы. Микросервисы Java, как правило, распределены. Из-за этого снижена скорость работы приложения при их вызове. А если представить, что ваш микросервис взаимодействует с десятками других, а те с десятками следующих, то скорость «отклика» сильно падает. Плюс возрастает вероятность возникновения отказов и сбоев.

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

Использовать или не использовать микросервисы Java — этот вопрос требует индивидуального исследования для каждого приложения. Однозначного ответа тут нет. Но если правильно рассчитать, какие преимущества и какие проблемы принесет микросервисная архитектура в ваш проект, то ответ станет очевиден. 

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

 

Схожие статьи

Пароль: какие символы нельзя использовать в пароле, минимальная длина
Другое

Пароль: какие символы нельзя использовать в пароле, минимальная длина

Модификатор в языке С: определение, виды, инструкция по применению
Другое

Модификатор в языке С: определение, виды, инструкция по применению

Кто такой наставник на работе: для чего нужно наставничество
Другое

Кто такой наставник на работе: для чего нужно наставничество

Firefox Monitor: что это за программа и почему ее стоит скачать?
Другое

Firefox Monitor: что это за программа и почему ее стоит скачать?

×