Реактивные микросервисы могут быть ответом!

Когда вам нужна высокая производительность, низкая задержка, надежность и масштабируемость, реактивные микросервисы - это ответ 21 века на вашу проблему. Почему бы не потратить несколько минут, чтобы понять, почему?

В течение многих лет мы создавали синхронные приложения с запросом-ответом, используя популярные технологии SOA, такие как Spring Boot и Jakarta RESTful Web Services (JAX-RS). Но сегодня, здесь и сейчас, в 21 веке, эти технологии 20 века исчерпываются, когда речь идет о высокой производительности, низкой задержке, надежности и масштабируемости. Нам нужно найти лучший способ.

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

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

Проблема с синхронным

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

Реактивные системы

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

Реактивные системы полагаются на асинхронную передачу сообщений, чтобы установить границу между компонентами, которая обеспечивает слабую связь, изоляцию и прозрачность местоположения. Асинхронный обмен сообщениями - ключевой и распространенный атрибут современных высокопроизводительных систем с высокой пропускной способностью.

Если вы хотите узнать больше о том, почему реактивные системы такие быстрые, это 17-минутное видео на YouTube Что такое реактивные системы? является отличным объяснением преимущества реактивных систем.

Реактивные микросервисы модели акторов

Форма реактивного субъекта микросервиса определяется его основным назначением. По сути, субъект микросервиса - это реактивный асинхронный процессор сообщений. Он сформирован и оптимизирован для использования одного потока для обработки одного сообщения за раз - настолько быстро и эффективно, насколько это возможно. Очень похоже на Node.js, это высокопроизводительный асинхронный процессор сообщений.

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

  1. Как асинхронное сообщение REST.
  2. Как событие перенос состояния с передачей событий (ECST).

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

Заключение

Асинхронные реактивные микросервисы на основе модели акторов - это технология 21 века, отвечающая требованиям 21 века. Традиционные API-интерфейсы SOA типа "запрос-ответ" не могут удовлетворить требования к производительности, масштабируемости и надежности современных приложений, развертываемых в облаке, без дополнительных уровней шлюзов API, балансировщиков нагрузки и других надстроек для перехвата циклов ЦП. Если эта идея вам понятна, рекомендуем прочитать: