Бессерверная обработка событий

Cosmos DB
Функции
Azure Monitor
Pipelines
Служба хранилища

В этой эталонной архитектуре показана ориентированная на события архитектура, котораяпринимает поток данных, обрабатывает их и записывает результаты в базу данных серверной части.

Логотип GitHub . Эталонная реализация для этой архитектуры доступна на сайте GitHub.

Эталонная архитектура для бессерверной обработки событий с помощью Функций Azure

Architecture

Центры событий принимают поток данных. Служба Центры событий предназначена для сценариев потоковой передачи данных с высокой пропускной способностью.

Примечание

Для сценариев Интернета вещей мы рекомендуем использовать Центр Интернета вещей. Центр Интернета вещей содержит встроенную конечную точку, которая совместима с API Центров событий Azure, поэтому вы можете использовать любую службу в этой архитектуре без существенных изменений внутренней обработки. Дополнительные сведения см. в статье Подключение устройств Интернета вещей в Azure. Центр Интернета вещей и Центры событий.

Приложение-функция. Функции Azure — это независимая от сервера служба вычислений. Она использует управляемую событиями модель, где часть кода ("функция") вызывается триггером. В этой архитектуре, когда события поступают в Центры событий, они инициируют функцию, которая обрабатывает события и записывает результаты в хранилище.

Приложения-функции подходят для обработки отдельных записей из Центров событий. Для более сложных сценариев обработки потока рассмотрите Apache Spark с использованием Azure Databricks или Azure Stream Analytics.

Cosmos DB. Cosmos DB — это многомодельная служба базы данных, которая доступна в бессерверном режиме, основанном на потреблении. В этом сценарии функция обработки событий сохраняет записи JSON с помощью SQL API Cosmos DB.

Хранилище очередей. Хранилище очередей используется для недоставленных сообщений. Если при обработке события возникает ошибка, функция сохраняет данные события в очереди недоставленных сообщений для последующей обработки. Дополнительные сведения см. в разделе Рекомендации по обеспечению устойчивости.

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

Azure Pipelines. Pipelines — это служба непрерывной интеграции (CI) и непрерывной поставки (CD), которая выполняет сборку, тестирование и развертывание приложений.

Вопросы масштабируемости

Центры событий

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

Триггер концентратора событий в приложении-функции масштабируется в соответствии с числом секций в концентраторе событий. Каждой секции назначается один экземпляр функции за раз. Для увеличения пропускной способности получайте события в пакете, а не по одному за раз.

Cosmos DB

Cosmos DB доступен в двух разных режимах емкости:

Чтобы обеспечить масштабируемость рабочей нагрузки, при создании контейнеров Cosmos DB важно выбрать соответствующий ключ секции . Вот некоторые характеристики хорошего ключа секции:

  • Значение пространства ключа велико.
  • Будет существовать равномерное распределение операций чтения и записи на значение ключа, что позволит избежать горячих ключей.
  • Максимальное количество данных, сохраняемых для одного значения ключа, не превышает максимальный размер физической секции (20 ГБ).
  • Ключ секции для документа не изменится. Обновить ключ секции для существующего документа невозможно.

В сценарии для этой эталонной архитектуры функция хранит только один документ для устройства, отправляющего данные. Функция постоянно обновляет в документах последнее состояние устройства, используя операцию Upsert. Идентификатор устройства является подходящим ключом секции для этого сценария, так как записи будут равномерно распределены по ключам, а размер каждой секции будет строго ограничен, потому что для каждого значения ключа существует отдельный документ. Дополнительные сведения о ключах секций см. в статье Секционирование и масштабирование в Azure Cosmos DB.

Рекомендации по обеспечению устойчивости

При использовании триггера Центров событий с Функциями перехват исключений происходит в цикле обработки. Если возникает необработанное исключение, среда выполнения Функций не выполняет повторную попытку отправки сообщения. Если сообщение не может быть обработано, поместите его в очередь недоставленных сообщений. Используйте внешний процесс, чтобы изучить сообщения и определить корректирующее действие.

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

[FunctionName("RawTelemetryFunction")]
[StorageAccount("DeadLetterStorage")]
public static async Task RunAsync(
    [EventHubTrigger("%EventHubName%", Connection = "EventHubConnection", ConsumerGroup ="%EventHubConsumerGroup%")]EventData[] messages,
    [Queue("deadletterqueue")] IAsyncCollector<DeadLetterMessage> deadLetterMessages,
    ILogger logger)
{
    foreach (var message in messages)
    {
        DeviceState deviceState = null;

        try
        {
            deviceState = telemetryProcessor.Deserialize(message.Body.Array, logger);
        }
        catch (Exception ex)
        {
            logger.LogError(ex, "Error deserializing message", message.SystemProperties.PartitionKey, message.SystemProperties.SequenceNumber);
            await deadLetterMessages.AddAsync(new DeadLetterMessage { Issue = ex.Message, EventData = message });
        }

        try
        {
            await stateChangeProcessor.UpdateState(deviceState, logger);
        }
        catch (Exception ex)
        {
            logger.LogError(ex, "Error updating status document", deviceState);
            await deadLetterMessages.AddAsync(new DeadLetterMessage { Issue = ex.Message, EventData = message, DeviceState = deviceState });
        }
    }
}

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

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

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

public class DeadLetterMessage
{
    public string Issue { get; set; }
    public EventData EventData { get; set; }
    public DeviceState DeviceState { get; set; }
}

Используйте Azure Monitor для мониторинга концентратора событий. Если вы видите, что есть входные данные, но нет выходных, это означает, что сообщения не обрабатываются. В таком случае перейдите в Log Analytics и поищите исключения или другие ошибки.

Рекомендации по аварийному восстановлению

Представленное здесь развертывание расположено в одном регионе Azure. Для более гибкого подхода к аварийному восстановлению воспользуйтесь функциями геораспределения в различных службах:

  • Концентраторы событий. Создайте два пространства имен Центров событий: основное (активное) и дополнительное (пассивное). Сообщения автоматически перенаправляются в активное пространство имен, если вы не выполните отработку отказа в дополнительное пространство имен. Дополнительные сведения см. в статье Географическое аварийное восстановление в Центрах событий Azure.

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

  • Cosmos DB. Cosmos DB поддерживает несколько регионов записи, что позволяет выполнять запись в любой регион, добавляемый в учетную запись Cosmos DB. Если не включить множественную запись, вы по-прежнему можете выполнить отработку отказа основного региона записи. Клиентские пакеты SDK Cosmos DB и привязки функций Azure автоматически выполняют отработку отказа, поэтому нет необходимости обновлять параметры конфигурации приложения.

  • Хранилище Azure. Используйте хранилище RA-GRS для очереди недоставленных сообщений. В таком случае создается реплика только для чтения в другом регионе. Если основной регион становится недоступным, вы можете считывать элементы, находящиеся в очереди. Кроме того, можно подготовить другую учетную запись хранения в дополнительном регионе, в которую функция сможет записывать данные после отработки отказа.

Рекомендации по стоимости

Используйте Калькулятор цен Azure для оценки затрат. См. также раздел "затраты" в Microsoft Azure Well-Architected Framework. Ниже приведены некоторые другие рекомендации.

Функции Azure

Функции Azure поддерживают две модели размещения.

  • План потребления.

    Мощность вычислений автоматически выделяется при выполнении кода.

  • План службы приложений .

    Набор виртуальных машин выделяется для кода. План службы приложений определяет число и размер виртуальных машин.

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

Azure Cosmos DB

С Cosmos DB вы платите за операции, выполняемые с базой данных, и за хранилище, используемое данными.

  • Операции с базой данных. способ оплаты за операции с базой данных зависит от типа используемой учетной записи Azure Cosmos DB.

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

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

  • Хранилище. Вы оплачиваете по фиксированной ставке общий объем хранилища (в ГБ), потребляемый данными и индексами за указанный час.

В этой эталонной архитектуре функция хранит только один документ для каждого устройства, отправляющего данные. Функция постоянно обновляет документы с последним состоянием устройства, используя операцию Upsert, которая является экономичной с точки зрения используемого хранилища. Дополнительные сведения см. в разделе модель ценообразования Cosmos DB.

Используйте Калькулятор емкости Cosmos DB , чтобы быстро оценить стоимость рабочей нагрузки.

Рекомендации для DevOps

По возможности используйте инфраструктуру как код (IaC). IaC управляет ресурсами инфраструктуры, приложения и хранилища с помощью декларативного подхода, такого как Azure Resource Manager. Это поможет автоматизировать развертывание с помощью DevOps в качестве решения непрерывной интеграции и непрерывной поставки (CI/CD). Шаблоны должны иметь версию и входить в состав конвейера выпуска.

При создании шаблонов ресурсы группируются как способ организации и изоляции для каждой рабочей нагрузки. Типичный способ подумать о рабочей нагрузке — это отдельное Необслуживаемое приложение или виртуальная сеть. Целью изоляции рабочей нагрузки является связывание ресурсов с группой, чтобы группа DevOps могла независимо управлять всеми аспектами этих ресурсов и выполнять CI/CD.

Эта архитектура включает в себя действия по настройке состояния помощью Дронов приложение-функция помощью Azure Pipelines с YAML и слотами функций Azure.

При развертывании служб необходимо отслеживать их. Используйте Application Insights , чтобы позволить разработчикам отслеживать производительность и обнаруживать проблемы.

Дополнительные сведения см. в подразделе DevOps статьи Microsoft Azure Well-Architected Framework.

Развертывание решения

Чтобы развернуть эту эталонную архитектуру, просмотрите файл сведений на GitHub.

Дальнейшие действия

Дополнительные сведения о реализации эталонного кода см. в разделе Пошаговое руководство по использованию приложений с помощью функций Azure.