Введение в архитектуру микросервисов
Обратившись к этой статье, вы сможете получить лучшее представление об архитектуре микросервисов и о том, когда ее использовать. Кроме того, эта статья состоит из следующего содержания.
◼ Сокращения статьи
◼ Введение
◼ Экосистема микросервисов
◼ Монолитная архитектура и микросервисная архитектура
◼ Проблемы микросервисов
◼ Когда использовать микросервисы
Сокращения
- API: интерфейс прикладного программирования
- МС: микросервис
- NoSQL: не только SQL
- RTE: среда выполнения
Архитектура микросервисов — это подход к разработке приложений, при котором большое приложение строится как набор модульных сервисов (это означает, что он (микросервис) — это тип архитектуры приложения, в котором приложение разрабатывается как набор сервисов). Каждый модуль поддерживает определенную бизнес-цель и использует простой четко определенный интерфейс для связи с другими наборами сервисов. Кроме того, существует минимум централизованных служб управления, которые могут быть написаны на разных языках программирования, таких как java, python и т. д., и использовать различные технологии хранения данных, такие как реляционные и NoSQL, в архитектуре микросервисов.

Вот некоторые ключевые особенности/характеристики микросервисов.
- Высокая ремонтопригодность и возможность тестирования
- Слабосвязанный (связь через интерфейс)
- Независимо развертываемый
- Организовано вокруг бизнес-возможностей
- Принадлежит небольшой команде (кросс-функциональная команда)
Как правило, система Microservices содержит следующие перечисленные объекты. Некоторые из этих объектов являются этапами стандартной разработки программного обеспечения, а некоторые из них представляют собой процессы, специфичные для микросервисов, которые обеспечивают основу для эффективной системы микросервисов.
Балансировщик нагрузки
Основная обязанность балансировщика нагрузки — распределять входящую нагрузку между множеством экземпляров микросервисов. В основном существует 2 типа балансировщиков нагрузки, называемых обнаружением клиента (балансировщик нагрузки на стороне клиента) и обнаружением сервера (балансировщик нагрузки на стороне сервера). При обнаружении клиента клиент взаимодействует с реестром службы и выполняет балансировку нагрузки. Из-за этого клиенту необходимо знать о сервисном реестре. При обнаружении сервера клиент взаимодействует с балансировщиком нагрузки, а балансировщик нагрузки взаимодействует с реестром службы. Поэтому клиентской службе не нужно знать о реестре службы. Глядя на следующие диаграммы, вы можете лучше понять эти 2 типа балансировщика нагрузки.

Сервер обнаружения служб
Функция обнаружения служб позволяет микрослужбам самостоятельно регистрироваться при запуске вместо того, чтобы вручную отслеживать, какие микрослужбы развернуты в данный момент и какие хосты и порты нам нужны. Поэтому, если MS1 хочет поговорить с MS2, сначала MS1 получает подробности от службы реестра, которая принадлежит ландшафту, а затем общается с MS2. Более того, если в том же ландшафте есть другая MS под названием MS3, которая была включена или отключена, служба реестра будет обновляться автоматически.

Шлюз API
Шлюз API — это сервер. Это единая точка входа в систему. Шлюз API инкапсулирует внутреннюю архитектуру системы. Он предоставляет API, адаптированный для каждого клиента. У него также есть другие обязанности, такие как аутентификация, мониторинг, балансировка нагрузки, кэширование, формирование запросов и управление ими, а также обработка статических ответов. Шлюз API также отвечает за маршрутизацию запросов, композицию и преобразование протоколов. Все запросы, сделанные клиентом, проходят через шлюз API. После этого шлюз API направляет запросы в соответствующий микросервис.
Шлюз API обрабатывает запрос одним из двух способов:
- Он маршрутизировал или проксировал запросы к соответствующей службе.
- Разветвление (распространение) запроса на несколько сервисов.

Теперь мы знаем, что существует множество микросервисов, работающих на разных узлах в одной и той же экосистеме. Поэтому нам необходимо отслеживать их вместе в одной системе. Это несколько примеров инструментов мониторинга. Существует пять следующих принципов мониторинга микросервисов:
- Контролируйте контейнеры и то, что внутри них.
- Оповещение о работе службы.
- Мониторинг гибких сервисов с несколькими местоположениями.
- Мониторинг API.
- Следить за организационной структурой

Когда мы внедряем микросервисы, они работают на разных RTE, таких как JRE и Node.js, поскольку реализация микросервисов может выполняться с использованием разных технологий. Кроме того, вы знаете, что эти микросервисы развертываются многоязычным образом. Следовательно, узлы не знают RTE развернутой микрослужбы, и нам нужно установить его вручную на каждом узле. Но когда дело доходит до контейнеризации, мы упаковываем RTE вместе с микросервисом. Поэтому мы можем запускать микросервисы везде, не учитывая RTE, и мы можем легко управлять этими сервисами и обновлять их.

Автоматический выключатель

Это очень важная сущность в экосистеме микросервисов. В большинстве случаев это определяется как шаблон. Для понимания, это очень похоже на автоматический выключатель в вашем доме. Он защищает вас от катастрофы и останавливает распространение возникшей проблемы. Здесь происходит тот же сценарий (автоматический выключатель в MS) в отношении микросервисов. Предположим, что клиент отправляет запрос в микросервис поставщика, и пока приходит ответ, возникает проблема с подключением. Из-за этого клиент долго ждет ответа, и это может повлиять и на другие сервисы. Начиная с архитектуры автоматического выключателя проблемный канал отбрасывается, и решается предыдущая проблема ожидания. Кроме того, существует три различных состояния автоматического выключателя, называемых замкнутыми ., открытый и полуоткрытый.
Монолитная архитектура против микросервисной архитектуры

Цена
- Монолитный: выше при масштабировании проекта.
- Микросервис: Высшее на первом этапе разработки
- Монолитность: единая кодовая база и база данных для всего продукта.
- Микросервис: несколько файлов кода; каждый сервис обрабатывает базу и хранилище данных
- Монолитный: необходимо развернуть всю кодовую базу.
- Микросервис: каждый микросервис развертывается отдельно.
- Монолитный: тот же стек кода
- Микросервис: различные стеки (язык, среда выполнения и т. д.)
При работе с микросервисами возникают следующие проблемы.
- Межпроцессное взаимодействие (через сеть)
- Распределенные транзакции
- Большое количество услуг
- Требовать большей автоматизации
Теперь у нас есть хорошее представление о микросервисах и их проблемах. Давайте посмотрим, какие сценарии подходят для использования микросервисов.
- Компания хочет сразу же создавать чистый, читаемый код и избегать технического долга.
- В компании есть человеческие ресурсы для разработки микросервисов
- Компания отдает предпочтение долгосрочным выгодам, а не краткосрочным выгодам.
- Команда разработчиков использует разные технологические стеки и инструменты
- Платформа должна быть масштабируемой и расширяться на различные рынки.