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

◼ Сокращения статьи

◼ Введение

◼ Экосистема микросервисов

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

◼ Проблемы микросервисов

◼ Когда использовать микросервисы

Сокращения

• 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) в отношении микросервисов. Предположим, что клиент отправляет запрос в микросервис поставщика, и пока приходит ответ, возникает проблема с подключением. Из-за этого клиент долго ждет ответа, и это может повлиять и на другие сервисы. Начиная с архитектуры автоматического выключателя проблемный канал отбрасывается, и решается предыдущая проблема ожидания. Кроме того, существует три различных состояния автоматического выключателя, называемых замкнутыми ., открытый и полуоткрытый.

Монолитная архитектура против микросервисной архитектуры

Цена

• Монолитный: выше при масштабировании проекта.
• Микросервис: Высшее на первом этапе разработки

• Монолитность: единая кодовая база и база данных для всего продукта.
• Микросервис: несколько файлов кода; каждый сервис обрабатывает базу и хранилище данных

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

• Монолитный: тот же стек кода
• Микросервис: различные стеки (язык, среда выполнения и т. д.)

При работе с микросервисами возникают следующие проблемы.

• Межпроцессное взаимодействие (через сеть)
• Распределенные транзакции
• Большое количество услуг
• Требовать большей автоматизации

Теперь у нас есть хорошее представление о микросервисах и их проблемах. Давайте посмотрим, какие сценарии подходят для использования микросервисов.

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