Использование правильных инструментов и схем для архитектур, управляемых событиями

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

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

• Используйте архитектуры, управляемые событиями, для процессов, не требующих синхронных ответов на запросы. Шаблоны, описанные в данном руководстве, предназначены для обеспечения согласованности данных, масштабируемости и повторного использования, что помогает свести техническую задолженность к минимуму по мере развития прикладного потенциала организации. (Дополнительную информацию см. в разделе «Хорошо архитектура - пропускная способность».)

• Если MuleSoft или другое решение Enterprise Service Bus (ESB) является частью существующего ландшафта, используйте его при возможности. Эти решения специально созданы для поддержки схем архитектуры, управляемых событиями, и имеют эффективные возможности, позволяющие повторно использовать интеграции на предприятии.

• Используйте Public/Sub API для любых будущих схем публикации/подписки вместо создания собственных средств обработки событий посредством других API, включая Streaming API. Теперь, когда Public/Sub API общедоступен, используйте его для любых новых схем публикации/подписки. Запланируйте миграцию текущих сообщений о событиях посредством других API платформы, например, Streaming API или настраиваемых служб Apex, в Public/Sub API, если это возможно.

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

Salesforce Platform — это универсальная платформа на основе искусственного интеллекта, которая объединяет сотрудников, автономных агентов на основе искусственного интеллекта, данные компании и приложения в единую надежную систему для повышения производительности и качества обслуживания клиентов. Он позволяет создать "агентское предприятие", подключив приложения Customer 360, Data Cloud и Slack для комплексной автоматизации.

MuleSoft — это ведущая платформа интеграции Salesforce, позволяющая организациям объединять приложения, данные и устройства в локальной и облачной среде. MuleSoft — это платформа, предоставляющая IT-платформы для разблокировки данных в системах, разработки масштабируемых инфраструктур интеграции и автоматизации, а также быстрого создания дифференцированных подключенных взаимодействий.

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

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

Большинство крупных организаций используют сложные ИТ-ландшафты, содержащие сочетание систем с разными возможностями. Возможно, или, возможно, организация использует устаревшие системы, которые не поддерживают интеграции, управляемые событиями. Возможно также использование сценариев, когда интеграции, управляемые событиями, не имеют смысла, даже если системы их поддерживают (например, передачи файлов SFTP от сторонних компаний). Если вы сделаете шаг назад и посмотрите на ИТ-ландшафт вашей организации в целом, вы, как и в случае с другими архитектурными решениями, будете использовать сочетание схем для поддержки разных сценариев. Когда вы решите сделать управляемый событиями подход предпочтительным для интеграций, подумайте о нем как о другом инструменте в наборе инструментов. Его можно и нужно использовать в соответствующих сценариях, но этот метод не следует навязывать каждой системе. Разработка комплексной стратегии интеграции поможет вам определить, когда схемы, описанные в этом руководстве, могут быть подходящими или нет.

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

Существуют разные схемы архитектуры, управляемые событиями. Некоторые из них являются схемами общего назначения, которые могут применяться в сценариях использования, не требующих особых требований, кроме случаев, определяемых событиями. Например, см. раздел «Хорошо архитектура - совместимость». Другие схемы применимы к конкретным сценариям использования, рассмотренным здесь, например, интеграции с большими объемами данных или сценарии, требующие более длительного сохранения сообщений.

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

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

Когда критическая запись меняет состояние в базовом приложении (например, статус заказа переходит из «Обработка» в «Отправлено»), многим другим системам, вероятно, нужно уведомление в близком к реальному режиме времени для выполнения соответствующих задач. Конкретная бизнес-потребность возникает, когда объем этих изменений высок, а сообщения сложны, что делает традиционные интеграции между точками обременительными и сложными в обслуживании. Создание хрупких настраиваемых подключений для каждой отдельной зависимой программы приводит к технической задолженности и ограничивает возможности организации по быстрому масштабированию. Требуется надежный подход интеграции для управления такими частыми синхронизациями данных без подключения исходной системы напрямую к каждой системе-потребителю.

Диаграмма ниже отображает типичную схему публикации/подписки с несколькими публикаторами и подписчиками, предоставляющими общий доступ к данным посредством шины событий. Эта базовая схема является основой для более конкретных схем, которые можно найти в остальных разделах данного руководства. Ниже перечислены некоторые ключевые характеристики этой схемы:

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

• Одна система может быть и публикатором, и подписчиком.

• Системы могут публиковать или подписываться на события нескольких типов.

• Как и во всех схемах в этом руководстве, схема публикации / подписки относится к общей категории схемы интеграции, известной как вызов удаленной процедуры (RPI) или просто "выполнить и забыть".

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

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

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

Ниже перечислены некоторые примеры.

• Сезонные скачки объема: Возможны скачки объемов, с которыми сталкиваются онлайн-ритейлеры, когда выбор их продуктов находится «в сезон». Когда большое количество клиентов одновременно осуществляет покупки, количество созданных событий может временно превысить возможности процессов синхронизации и трансформации. Дополнительную информацию см. в разделе «Хорошо архитектура - Обработка данных».

• Управление обращениями или претензиями: Компании на основе обслуживания могут столкнуться с резким увеличением количества обращений или претензий во время сбоев.

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

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

Схема «Переданные сообщения» работает посредством сегментирования логики обработки сообщений на несколько компонентов:

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

• Отдельный набор компонентов обрабатывает разные уровни трансформации сообщений (например, соотнесения полей, взаимосвязи объектов и т. д.).

• Последний компонент записывает последнее измененное сообщение.

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

Рассмотрите события для музыкальной потоковой платформы. Они могут включать:

• Отслеживание начатых/приостановленных/пропущенных событий

• События сеанса прослушивания с отметками времени

• События создания/изменения плей-листа

• События социального обмена

• Загрузка для автономного прослушивания

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

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

Сценарии использования очереди распространены повсеместно. Примеры:

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

• Буферизация сообщений: Если объем сообщений иногда превышает нагрузку подписчика на обработку, и увеличение задержки не создаст дополнительных проблем, очереди могут быть буфером для хранения избыточных сообщений и предотвращения потери данных.

• Управление транспортом: Логистические организации, которым нужно следить за своим автопарком, могут использовать эту схему для просмотра маршрутов, по которым движется каждое транспортное средство, практически в режиме реального времени и обеспечения максимальной эффективности водителей.

• Устройства IoT: Производители часто используют системы, генерирующие быстрые потоки данных, и эти потоки могут иметь последующие эффекты для дополнительных систем. Эту схему можно использовать для определения последовательности событий, требующих вмешательства человека до возникновения катастрофических сбоев в нескольких системах.

В схеме «Очередь» производители отправляют сообщения очередям, которые удерживают сообщения до их извлечения подписчиками. Большинство очередей сообщений используют порядок отображения и удаления всех сообщений после их извлечения. Каждому подписчику назначается уникальная очередь, которая требует дополнительных шагов настройки, но позволяет гарантировать доставку и определить, какие подписчики какие сообщения получили.

Из-за асинхронного характера схемы «Очередь» может произойти длительная задержка между добавлением сообщения в очередь и его извлечением. Очереди требуют памяти или места для хранения сообщений, поэтому они не могут расти бесконечно, что означает, что подписчик, находящийся в автономном режиме неопределенно долго, может привести к сбою, если в очереди накопится достаточно сообщений. Буферизация сообщений может иметь такой же эффект, если время обработки подписчика становится слишком большим, что приводит к образованию больших объемов сообщений в его очередях. Чтобы уменьшить эти риски, выполните тщательный анализ требований к хранилищу для всех очередей сообщений и, при необходимости, создайте процессы, которые очистят и отключат очереди, если сообщения не извлекаются в течение заданного периода времени или когда они достигают предопределенного объема.

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

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

• Общая стратегия интеграции: Независимо от инструментов и схем, которые вы решили использовать, важно начать с создания стратегии предоставления общего доступа к данным в разных системах организации. Эта стратегия должна содержать цели организации для ее данных, способ предоставления общего доступа к данным и используемые схемы, а также источники данных, цели, структуры и требования к ответственности и доступу.

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

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

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

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

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

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

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

• Публикация событий из триггеров Apex, связанных с одним объектом события: Это приведет к бесконечному циклу триггера.

• События публикации из Apex до завершения транзакции DML: Если транзакция не выполняется и откатывается, все опубликованные события с алгоритмом публикации «Опубликовать немедленно» не добавляются в алгоритм отката.

• Публикация событий в потоке для организации последующей автоматизации: Лучший способ координации логики в нескольких автоматизациях - использование подпотоков или оркестра потока.

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

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

• Неизбирательная обработка событий приложения: При наличии нескольких компонентов, прослушивающих событие приложения, разработчики должны обеспечить выполнение средства обработки событий только при его желании и пользе. Например, в консоли Lightning компоненты, содержащиеся на нефокусированных вкладках, могут по-прежнему прослушиваться, хотя и недоступны. Разработчик может использовать разные приемы, например, использование фонового элемента служебной программы в качестве единственного слушателя или вызов getEnclosingTabId(), чтобы определить, заключен ли этот экземпляр компонента в сфокусированную вкладку, чтобы обеспечить обработку каждого события только при его наличии.

• Использование событий платформы некорректно публикует алгоритм: События платформы используют два алгоритма публикации — «Опубликовать немедленно» и «Опубликовать после обязательства». События платформы в реальном времени могут быть полезны для сценариев использования, например, «Запись в журнал», где нужно опубликовать событие регистрации, вне зависимости от успеха и обязательства транзакции. Однако, используйте «Опубликовать немедленно» очень осторожно с событиями платформы в реальном времени. События могут использоваться подписчиками в одной транзакции и приводить к блокировкам строк или другим условиям гонки.

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

• Определите оптимальную структуру полезных данных события. Хотя меньшие размеры сообщений сокращают время обработки, бомбардировка подписчиков большими объемами сообщений может привести к преградам производительности. Возможно, вам понадобится повторение размеров и структур полезных данных, чтобы найти правильный баланс. MuleSoft и аналогичные инструменты ESB предоставляют возможность проектирования настраиваемых полезных данных в сообщениях, связанных с событиями, что может помочь вам визуализировать структуры данных для повышения производительности со стороны подписчика. (Дополнительную информацию см. в разделе «Хорошо архитектура - Управление API».)

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

  Этот тип антипаттерна можно исправить, добавив логику к обеим системам, гарантирующую, что изменения, внесенные в результате использования события, не приведут к публикации нового события. Также необходимо задокументировать все события, связанные с ними триггеры и системы, которые могут пострадать в дальнейшем. Используйте эту документацию в качестве ссылки во время сеансов проектирования, чтобы помочь как можно раньше обнаружить бесконечные циклы и похожие сценарии. (Дополнительную информацию см. в разделе «Хорошо архитектура - проектирование процесса».)

• Использовать распространенные правила наименования в системах. Согласованные правила наименования - это рекомендации по разработке программного обеспечения, включая архитектуры, управляемые событиями. Потратьте время на документирование набора стандартов для имен событий, структур, связанных объектов и процессов обработки ошибок, чтобы обеспечить согласованность в системах. (Дополнительную информацию см. в разделе «Хорошо построенные - стандарты проектирования».)