В этой статье описаны шаблоны и реализации, которыми воспользовалась команда разработки коммерческого ПО при осуществлении переноса банковской системы в облако в Azure.
Архитектура
Архитектура Saga
Скачайте файл Visio для этой архитектуры.
Поток данных
В банке Contoso локально реализован шаблон Saga на основе оркестрации. В этой реализации оркестратор является конечным автоматом. Команда разработки коммерческого ПО выявила следующие сложности в проектировании архитектуры:
Затраты на реализацию и сложность обработки оркестратора с отслеживанием состояния при работе с управлением состояниями, временем ожидания и перезагрузками во время сбоев.
Механизмы наблюдаемости для отслеживания состояний рабочего процесса Saga на запрос транзакции.
Предложенное ниже решение представляет собой реализацию шаблона Saga через оркестрацию с помощью бессерверной архитектуры в Azure. Она решает возникающие сложности с помощью следующих инструментов:
Функции Azure для реализации участников Saga.
Устойчивые функции Azure для оркестрации, предназначенные для обеспечения модели программирования рабочего процесса и управления состоянием.
Центры событий Azure в качестве платформы потоковой передачи данных.
Azure Cosmos DB в качестве службы базы данных для хранения моделей данных.
Дополнительные сведения см. в статье Шаблон Saga на сайте Microservices.io.
Шаблон Saga
Saga — это шаблон, предназначенный для управления распределенными транзакциями, который обычно используется с финансовыми службами. Существует сценарий, когда операции распределяются между приложениями и базами данных. Клиентам понадобится разработка новой архитектуры и реализации, чтобы обеспечить согласованность данных в финансовых транзакциях.
Традиционный подход неделимости, согласованности, изолированности и устойчивости (ACID) больше не применим. Это обусловлено тем, что данные операций теперь размещаются в изолированных базах данных. С помощью шаблона Saga можно решить эту проблему, направив рабочий процесс через последовательность локальных транзакций на основе сообщений, что обеспечивает согласованность данных.
Архитектура KEDA
Скачайте файл Visio для этой архитектуры.
Дополнительные сведения о средствах масштабирования KEDA см. в следующей документации по KEDA:
Триггер Центров событий Azure: совместимость для чтения URI хранилища BLOB-объектов Azure для приложений Java. Он использует пакет SDK узла обработчика событий, что позволяет масштабировать потребителей Java, которые читают сообщения расширенного протокола управления очередью сообщений (AMQP) из Центров событий. Ранее средства масштабирования Центров событий работали только с Функциями Azure.
Триггер раздела Apache Kafka: поддержка проверки подлинности SASL_SSL Plain, что позволяет масштабировать потребителей Java, которые читают сообщения протокола Kafka из Центров событий.
Рабочий процесс
Команда разработки коммерческого ПО развернула приложение в кластере службы Azure Kubernetes (AKS). Решению требовалось автоматически горизонтально увеличивать масштаб приложения на основе количества входящих сообщений. Команда разработки коммерческого ПО воспользовалась средством масштабирования Kafka для определения необходимости активации или деактивации развертывания приложения. Средство масштабирования Kafka также передает пользовательские метрики для конкретного источника события. Источник событий в этом примере — концентратор событий Azure.
Когда количество сообщений в концентраторе событий Azure превышает пороговое значение, KEDA активирует модули pod для горизонтального масштабирования, увеличив количество сообщений, обработанных приложением. Если количество сообщений в источнике события не превышает пороговое значение, происходит автоматическое вертикальное уменьшение масштаба подов.
Команда разработки коммерческого ПО воспользовалась триггером раздела Apache Kafka. Это позволяет решению масштабировать службу обработчика ЭПС, когда превышается максимальное количество поступающих сообщений за временной промежуток.
KEDA с поддержкой Java
Средство автомасштабирования Kubernetes на основе событий (KEDA) определяет масштабирование контейнеров в решении на Kubernetes. Это решение основано на количестве событий, которые необходимо обработать. KEDA, предоставляющее различные средства масштабирования, поддерживает несколько типов рабочих нагрузок, Функции Azure, а также не зависит от поставщика. Перейдите в раздел Автомасштабирование приложений Java с помощью KEDA в Центрах событий Azure, чтобы изучить рабочий пример.
Архитектура нагрузочного тестирования
Скачайте файл Visio для этой архитектуры.
Решение использует скрипты JMeter (JMX) для нагрузочного тестирования Azure. Нагрузочное тестирование Azure — это полностью управляемая служба нагрузочного тестирования, которая позволяет создавать высокомасштабную нагрузку. Служба имитирует трафик для приложений независимо от того, где они размещаются, и может использовать существующие скрипты JMeter.
Рабочий процесс
Нагрузочное тестирование Azure позволяет вручную создавать нагрузочные тесты с помощью портал Azure или Azure CLI. Кроме того, можно настроить конвейер CI/CD для интеграции с Azure Load Testing. Это позволяет автоматизировать нагрузочный тест для непрерывной проверки производительности и стабильности приложения в рамках рабочего процесса CI/CD.
- Узнайте, как работает нагрузочное тестирование Azure, создав и выполнив нагрузочный тест.
- Используйте новые или существующие скрипты JMeter и настройте рабочий процесс CI/CD для выполнения нагрузочных тестов.
Подробности сценария
Этот сценарий поможет лучше понять закономерности и реализации в банковской отрасли при переходе в облако.
Следующие шаги
Дополнительные сведения о технологиях компонентов:
- Общие сведения о Функциях Azure
- Что такое "Устойчивые функции"?
- Центры событий Azure — платформа потоковой передачи больших данных и служба приема событий
- Вас приветствует Azure Cosmos DB
Связанные ресурсы
Сведения о связанных архитектурах: