Монолитная архитектура

• Если мы разрабатываем все функциональные возможности в одном проекте, то это называется приложением на основе архитектуры Monolith.

• Мы упакуем наше приложение в виде jar/war для развертывания на сервере.

• Поскольку монолитное приложение содержит все функции, оно превратится в толстую банку/войну.

Преимущества
1) Легко разрабатывать и управлять.
2) Все доступно в одном месте.
3) Конфигурация требуется только один раз.

Недостатки
1) Сложно поддерживать
2) Единая точка отказа
3) Если мы внесем какие-либо изменения, весь проект будет повторно развернут и протестирован.
4) Разработчик может не знать целых модулей, поэтому приступить к устранению проблемы сложнее.
5) если какой-то модуль сильно загружен, нам нужно создать несколько экземпляров всего приложения, чтобы это заняло много места, поскольку каждый модуль тесно связан друг с другом.

Чтобы преодолеть проблемы монолитной архитектуры, на рынок вышла микросервисная архитектура

Микросервисная архитектура

• Микросервисы — это не язык программирования, платформа или API. Микросервисы — это шаблон архитектурного проектирования.

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

• В архитектуре микросервисов мы не разрабатываем все функциональные возможности в одном проекте. Мы разделим функциональные возможности проекта на несколько REST API.

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

Микросервисы — это подход, при котором мы разрабатываем небольшие сервисы, каждый сервис запускается в своем собственном контейнере/процессе/сервере, сервисы должны быть легкими и независимо развертываемыми. Это позволяет ускорить разработку, развертывание и масштабируемость.

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

Преимущества

• Технологическая независимость (мы можем разрабатывать серверные API с использованием нескольких технологий, таких как Python, Go и т. д.)

• Независимость базы данных.

• Каждая служба независима друг от друга (слабая связь), поэтому мы можем развертывать каждую службу независимо.

• при внесении каких-либо изменений в любую службу нет необходимости развертывать всю службу, можно также развернуть только одну службу.

• Разработчикам, работающим над одним сервисом, не требуется знание всего приложения.

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

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

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

• Каждый сервис можно тестировать по-разному.

Недостатки

• если мы хотим внести изменения в одну конфигурацию службы, нам нужно внести изменения в каждую конфигурацию службы, например, есть общее свойство, которое существует в каждом файле application.properties во всех моих проектах.

company.name=tier3Hub

поэтому, если мы хотим изменить название компании, то во всех сервисах нам нужно изменить название.

• Тестирование приложения на основе микросервисов может оказаться более сложным из-за взаимозависимостей и взаимодействия между сервисами.

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

Почему Java для микросервисов

Java предоставляет платформу под названием Spring-Boot для разработки Rest API, а Spring-Boot предоставляет множество функций, таких как автоматическая настройка, встроенный сервер, если мы разрабатываем службу, поэтому необходимо развернуть службу sech на сервере. а Spring-Boot предоставляет сервер Tomcat, поэтому каждая служба работает на разных портах Tomcat. например, служба сотрудников работает на порту 8080, служба курсов работает на порту 8081, и каждая служба имеет свой собственный сервер.

с помощью Spring-Boot предоставляет функции для быстрой разработки, меньшего количества настроек, готового к производству приложения и проекта состояния

и в рамках Spring Framework есть проект под названием Spring Cloud, который предоставляет готовые микросервисы поддержки. Spring Cloud предоставляет некоторые общие инструменты и методы для быстрой разработки общего шаблона микросервисов.

Spring Cloud фокусируется на предоставлении хороших готовых возможностей для типичных сценариев использования и механизма расширения для охвата других.

• Распределенная/версированная конфигурация
• Регистрация и обнаружение служб
• Маршрутизация
• Межсервисные звонки
• Балансировка нагрузки
• Автоматические выключатели
• Распределенный обмен сообщениями
• Короткоживущие микросервисы (задачи)
• Контрактное тестирование, ориентированное на потребителя и производителя.

Микросервисная архитектура

У нас нет какой-либо фиксированной архитектуры для микросервисов. Разработчики настраивают архитектуру микросервисов в соответствии с требованиями своего проекта. В большинстве проектов будут использоваться указанные ниже компоненты в архитектуре микросервисов.

1) Реестр служб (сервер Eureka)

2) Сервисы (REST API)

3) Межсервисное взаимодействие (FeginClient)

4) API-шлюз

5) Сервер администрирования

6) Зипкин

Заключение

Микросервисы на Java изменили наш подход к разработке программного обеспечения, выведя на новый уровень гибкости, масштабируемости и устойчивости. Богатая экосистема Java в сочетании с такими платформами, как Spring Boot и Micronaut, делает ее отличным выбором для создания микросервисов, отвечающих требованиям современных приложений.

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

Для разработчиков Java, работающих с микросервисами, крайне важно быть в курсе последних достижений в инструментах и ​​практиках. Ландшафт постоянно меняется, и те, кто адаптируется, смогут лучше всего использовать весь потенциал этой архитектуры. Будущее микросервисов на Java выглядит многообещающим: фреймворки и инструменты постоянно совершенствуются при поддержке растущего сообщества разработчиков, желающих поделиться своими знаниями и опытом.

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