Когда я говорю с инженерными лидерами о тестировании микросервисов, управляемых событиями, я слышу общую боль: «Наши асинхронные потоки практически невозможно проверить».
Ранее мы исследовали, как Opentelemetry и изоляция сообщений позволяют тестировать рабочие процессы на основе Kafka без дублирования инфраструктуры. Этот подход резонировал со многими командами, сталкивающимися с проблемой тестирования асинхронных потоков экономически эффективно, но я получил множество вопросов о расширении этого шаблона на другие брокеры сообщения.
- «Это работает с AWS SQS?»
- «Можем ли мы применить это к Rabbitmq?»
- «А как насчет Google Pub/Sub?»
Короткий ответ — да. Паттерн изоляции сообщений работает в большинстве популярных брокеров сообщений, но детали реализации варьируются в зависимости от архитектуры и терминологии каждой системы.
Универсальный шаблон: изоляция сообщения
Прежде чем погрузиться в конкретные платформы, давайте вспомним основную проблему и наш подход:
Проблема
Тестирование микросервисов, которые общаются через очереди сообщения, представляет несколько проблем:
- Настройка отдельных испытательных среда дорого и трудно поддерживать.
- Асинхронные рабочие процессы трудно проверить без полных тестов.
- Проблемы интеграции часто появляются только после объединения кода.
- Издевательства часто уходят от реальности, что приводит к ложным позитивам.
Решение
Наш подход изоляции сообщений решает эти проблемы с помощью этих ключевых принципов:
Цель проста: позволить нескольким разработчикам проверить свои изменения в изоляции без помех, избегая при этом стоимости и сложности дублирования всей вашей инфраструктуры обмена сообщениями.
Apache Kafka: справочная реализация
Kafka остается нашей справочной реализацией для тестирования изоляции сообщений из -за своей надежной модели группы потребителей. В Кафке несколько групп потребителей могут независимо обрабатывать те же сообщения из темы, создавая естественный шаблон для нашего подхода к тестированию.
С Kafka каждый производитель включает в себя ключ маршрутизации в заголовках сообщений, а потребительские группы обеспечивают механизм изоляции. Когда разработчик развертывает свою версию услуг для тестирования, он присоединяется к уникальной группе потребителей (например, My-Service-Group-Sandbox123), получая копию всех сообщений, в то время как базовая версия продолжает работать в своей оригинальной группе потребителей.
Rabbitmq: обмены и привязки
Архитектура Rabbitmq отличается от Kafka, потому что она использует обмены и привязки в качестве посредников между производителями и потребителями, что позволяет более гибким моделям маршрутизации.
В Rabbitmq обмены распространяют сообщения в очереди через привязки. Паттерн изоляции сообщений работает путем создания временных очередей для служб песочницы, которые связаны с теми же обменами, что и базовые очереди. Например, если ваш базовый сервис потребляет из очереди, связанной с обменом темы, ваша версия песочницы создаст новую временную очередь, связанную с тем же обменом с соответствующими ключами маршрутизации.
В то время как Rabbitmq предлагает фильтрацию на уровне брокеров с помощью шаблонов привязки, нам все еще нужна фильтрация на стороне потребителя, чтобы проверить ключ маршрутизации песочницы на направлении центрального картирования. Потребитель извлекает ключ маршрутизации из заголовков сообщений, вызовут службу отображения, чтобы определить, следует ли оно обработать сообщение, а затем продолжить соответствующим образом.
Google Cloud Pub/sub: подписки
Google Cloud Pub/Sub организует сообщения по темам и подпискам, что делает изоляцию сообщений. Тема может иметь несколько подписок, и каждая подписка получает копию каждого сообщения, опубликованного в эту тему — идеально соответствует нашей модели песочницы.
Для тестирования на песочницу создайте временные подписки на те же темы, которые используют ваши базовые сервисы. Абонент будет реализовать фильтрацию на стороне потребителя для извлечения ключа маршрутизации из атрибутов сообщения, соответствующим образом проверить службу отображения и обработки.
AWS SQS: Специальный случай
AWS SQS представляет собой уникальную проблему для изоляции сообщений, потому что он не поднимает модель раздувания, на которую мы полагаемся в других брокерах. На SQS сообщения используются одним потребителем; Для нескольких потребителей нет встроенного механизма, чтобы получить одно и то же сообщение, и сообщения автоматически удаляются после обработки.
Поэтому мы должны рассмотреть альтернативные подходы:
Вариант 1: SNS + Sqs Pattern
Используйте Amazon SNS (Simple Service Service) в качестве точки входа, чтобы раздувать сообщения в несколько очередей SQS. Издатели отправляют сообщения в тему SNS, которая доставляет копии в несколько подписанных очередей SQS — одно для базового уровня и отдельные для каждой среды песочницы. Этот подход не требует изменений для существующих потребителей, поскольку они продолжают читать из своих выделенных очередей.
Вариант 2: Выделенные очереди теста
Создайте временные очереди SQS для тестирования с производителями и потребителями на песочке. Разверните новый экземпляр вашего производителя, который отправляет сообщения во временную очередь тестов и настройте для чтения тестирования для чтения из этой новой очереди. Каждая песочница получает свою собственную изолированную очередь, производитель и потребитель.
Для большинства команд вариант 1 предоставляет самое чистое решение. Настройка темы SNS, которая публикует как в вашей базовой очереди SQS, так и в любых временных очередях тестирования, поддерживает отделенную архитектуру, одновременно обеспечивая изоляцию, необходимую для тестирования. Накладные расходы дублирования сообщений обычно незначительны по сравнению с стоимостью дублирования всей вашей инфраструктуры.
NATS: субъекты и группы очерков
NATS, с его легким и высокопроизводительным дизайном, предлагает функции, хорошо подходящие для тестирования на песочницу. Мы можем использовать группы очередей NATS, которые функционируют аналогично группа потребителя KAFKA.
Создавая специфические для песочниковых групп очередей, испытательные службы получают копии сообщений, не вмешиваясь в базовые услуги. Ваша служба тестирования присоединится к уникальной группе очереди (например, Service-Sandbox123), подпишится на те же предметы, что и ваш базовый сервис и реализовать фильтрацию на стороне потребителя на основе ключей маршрутизации.
Реализация команды платформы
Подход к изоляции сообщений становится гораздо более поддерживаемым, когда платформные команды строят многократные компоненты, которые обрабатывают логику, специфичную для песочницы.
Создание потребительских библиотек с учетом песочницы
Команды платформ могут создавать тонкие обертки вокруг стандартных клиентских библиотек, которые автоматически обрабатывают фильтрацию песочницы:
Общедоступный класс Sandboxawarekafkaconsumer
Разработчики приложений используют это точно так же, как и стандартный потребитель:
// Разработчики просто используют предоставленную платформой реализацию Sandboxawarekafkaconsumer
Этот подход делает фильтрацию песочницы полностью прозрачной для команд приложений.
Управление жизненным циклом песочницы
Команды платформ могут предоставить стандартизированные крючки вокруг жизненного цикла песочниц, которые автоматизируют управление ресурсами:
Когда разработчик создает новую песочницу для тестирования:
- Платформа автоматически регистрирует идентификатор песочницы в центральной службе картирования.
- Необходимые группы потребителей, очереди или подписки создаются с последовательным именованием (Service- {Sandbox-ID}).
- При завершении тестирования все ресурсы, специфичные для песочницы, автоматически удаляются.
Этот подход, основанный на крючке, делает изоляцию песочницы частью основных возможностей платформы, а не бременем для каждой команды разработчиков.
Заключение
Паттерны изоляции сообщений работают для всех основных брокеров сообщений, хотя детали реализации варьируются в зависимости от архитектуры каждой системы. Подход последовательно обеспечивает три ключевых преимущества:
В Signadot мы внедрили эти шаблоны в десятках среды клиентов, используя различные системы обмена сообщениями. Такие компании, как Brex, Earnest и ShareChat, использовали эти подходы для преобразования их тестирования микросервиса. Если вы заинтересованы в изучении того, как применить эти концепции в вашей конкретной среде, зарегистрируйтесь и присоединяйтесь к нашему каналу Slack Cannel.
По мере того, как архитектуры микросервиса продолжают развиваться, эффективное тестирование асинхронных рабочих процессов становится все более критичным. Паттерн изоляции сообщений обеспечивает практический, масштабируемый подход независимо от того, какой брокер сообщения вы выбрали.
Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Арджун Айер, генеральный директор Signadot, является опытным экспертом в облачной местной области с глубокой страстью к улучшению опыта разработчика. У Арджуна хвастается более чем 25-летним опытом работы в отрасли, есть богатая история разработки программного обеспечения для интернет-масштаба и … Подробнее от Arjun Iyer
