Интеграция Центров событий с бессерверными функциями в Azure

Решения, использующие Центры событий Azure вместе с Функции Azure использовать бессерверную архитектуру, которая является масштабируемой, экономичной и способной обрабатывать большие объемы данных практически в реальном времени. Насколько эти службы работают без проблем вместе, существует множество функций, параметров и тонкостей, которые усложняют их связь. В этой статье содержатся рекомендации по эффективному использованию этой интеграции, в котором рассматриваются ключевые аспекты и методы для обеспечения производительности, устойчивости, безопасности, наблюдаемости и масштабирования.

Основные понятия Центров событий

Центры событий Azure — это высокомасштабируемая служба обработки событий, которая может получать миллионы событий в секунду. Прежде чем углубляться в шаблоны и рекомендации по интеграции Функции Azure, лучше понять основные компоненты Центров событий.

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

События

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

Секции

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

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

Потребители и группы потребителей

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

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

Дополнительные сведения см. в разделе Подробное руководство по основным понятиям и функциям Центров событий.

Использование событий с помощью Функции Azure

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

Каждый экземпляр активированной функции Центров событий поддерживается одним экземпляром EventProcessorHost . Триггер (управляемый Центрами событий), гарантирует, что каждый определенный раздел может использоваться только одним экземпляром EventProcessorHost.

Например, рассмотрим концентратор событий со следующими характеристиками:

• 10 разделов;
• 1000 событий равномерно распределяют все секции с разным количеством сообщений в каждой секции.

Когда функция впервые включена, существует только один экземпляр функции. Первому экземпляру функции мы присвоим имя Function_1. Function_1 имеет один экземпляр EventProcessorHost , который содержит аренду для всех 10 секций. Этот экземпляр считывает события из секций 1–10. При этом возможно следующее:

• Новые экземпляры функций не требуются: Function_1 можно обработать все 1000 событий до того, как логика масштабирования функций вступит в силу. В нашем примере все 1000 сообщений обрабатываются экземпляром Function_1.

  

• Добавляется дополнительный экземпляр функции: масштабирование на основе событий или другая автоматическая или ручная логика может определить, что Function_1 имеет больше сообщений, чем может обработать, а затем создать новый экземпляр приложения-функции (Function_2). Эта новая функция также получает связанный экземпляр EventProcessorHost. Так как базовый концентратор событий обнаруживает, что новый экземпляр узла пытается прочитать сообщения, он балансирует нагрузку секций между экземплярами узла. Например, секции 1–5 могут быть назначены , Function_1 а секции 6–10 — .Function_2

  

• Добавлено не больше экземпляров функций: масштабирование на основе событий или другая автоматизированная или ручная логика определяет, что Function_1 и Function_2 имеют больше сообщений, чем они могут обработать, создаются новые экземпляры приложения-функции Function_N. Экземпляры создаются до точки, где N равно или больше числа секций концентратора событий. В нашем примере Центры событий снова распределяют нагрузку разделов, в этом случае — по экземплярам Function_1...Function_10.

  

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

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

Динамическое масштабирование на основе событий можно использовать в планах Azure "Потребление" и "Премиум". Приложения-функции, размещенные в Kubernetes, также могут воспользоваться преимуществами масштабировщика KEDA для Центров событий. Масштабирование на основе событий в настоящее время невозможно, если приложение-функция размещено в выделенном (Служба приложений) плане, который требует определения нужного количества экземпляров на основе рабочей нагрузки.

Дополнительные сведения см. в статье Центры событий Azure привязки для Функции Azure и триггер Центры событий Azure для Функции Azure.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально она была написана следующими участниками.

Основной автор:

• Давид Баркол | Главный специалист по решениям GBB

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

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

Связанные ресурсы

• Мониторинг бессерверной обработки событий предоставляет рекомендации по мониторингу бессерверных архитектур, управляемых событиями.
• Бессерверная обработка событий — это эталонная архитектура, описывающая типичную архитектуру этого типа, с примерами кода и обсуждением важных аспектов.
• Депакетирование и фильтрация при бессерверной обработке событий с помощью Центров событий более подробно описывает, как работают эти части эталонной архитектуры.