Введение в архитектуру микросервисов

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

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

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

◼ Введение

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

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

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

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

Сокращения

  • 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

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

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

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

Контейнеризация

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

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

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

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

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

Цена

  • Монолитный: выше при масштабировании проекта.
  • Микросервис: Высшее на первом этапе разработки
  • Монолитность: единая кодовая база и база данных для всего продукта.
  • Микросервис: несколько файлов кода; каждый сервис обрабатывает базу и хранилище данных
  • Монолитный: необходимо развернуть всю кодовую базу.
  • Микросервис: каждый микросервис развертывается отдельно.
  • Монолитный: тот же стек кода
  • Микросервис: различные стеки (язык, среда выполнения и т. д.)

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

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

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

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