Что означает понятие "управляемые событиями" и насколько быстрым является режим реального времени?
Если мы ее рассмотрим, то сможем определить множество управляемых событиями сценариев. Большинству из них необходима реакция в режиме реального времени.
Что означает "реальное время"?
Реакцию в режиме реального времени можно рассматривать как мгновенный ответ. Рассмотрим такую ситуацию: кассир в кофейне спрашивает, что вы хотите выпить.
Ему необходимо дать ответ мгновенно или хотя бы очень быстро. В противном случае кассир может изменить вопрос или заподозрить вас в грубости. Быстрый ответ не только запрашивается, но и целесообразен. Время ответа может немного отличаться, но по-прежнему отображается как «в реальном времени». Таким образом, приветствие должно отображаться быстро, но у вас есть время подумать о своем заказе, чтобы ответить на вопрос кассира.
Если перенести эту ситуацию на программные системы, то тут также важно время: отклика, выполнения, доступа, запуска и т. д. Пользователь или приложение, обращающееся к приложению, определяет эти сроки.
Примечание.
В системах, работающих в режиме реального времени, задачи выполняют свои функции в рамках предписанных крайних сроков.
Необходимо всегда следить за тем, что происходит в вашей системе. Поэтому убедитесь, что вы не забыли очевидные вещи, а именно: ведение журнала, мониторинг и измерение времени.
Важно!
Убедитесь, что вы заранее задали крайние сроки и время, а для проверки настроили решение для мониторинга без блокировки.
Таким образом, мы соглашаемся, что понятие "реальное время" означает сверхбыстро, в одно мгновение. Точная скорость определяется в заданном сценарии.
Приложения, управляемые событиями
Если вы сразу представляете событие Click, то вы думаете немного не в том направлении. В управляемых событиями приложениях используется принцип отправить и забыть. Событие запускается или отправляется в следующую систему, которой может быть другая служба, концентратор событий, поток или брокер сообщений, например Kafka. Нам необязательно ждать от нее ответа. Слабая связь достигается за счет цены итоговой согласованности, которую необходимо принимать во внимание на другом уровне.
Чтобы понять природу управляемых событиями приложений, давайте рассмотрим основные шаблоны архитектуры на примере клиента по имени Алексей, который покупает кофе и капучино.
Уведомление о событии
Уведомление о событии — это уведомление о чем-то произошедшем, каком-то случае. Каждое событие отображается отдельно. Пример с клиентом по имени Алексей, который покупает кофе и капучино, может выглядеть следующим образом.
1. Событие: Алекс покупает кофе.
2. Событие: Алекс покупает капучино.
Один бариста должен был бы внимательно выслушать все события, чтобы получить весь заказ Алексея. Но двое барист также могли бы приготовить и подать напитки независимо друг от друга.
Передача состояния выполненного события
При передаче состояния выполненного события вся необходимая информация хранится в одном событии. Это может пригодиться, если событие потеряно или служба не ожидает передачи всех событий. В нашем примере события будут выглядеть следующим образом:
1. Событие: Алекс покупает кофе.
2. Событие: Алекс покупает, помимо кофе, капучино.
Для одного баристы выслушивания только второго события могло бы быть достаточно. Если же их двое, второму пришлось бы смотреть на первого. Заказ можно было бы обслужить вместе, но на это может потребоваться больше времени, чем при выполнении по отдельности.
Источник событий
При использовании источника событий в центре внимания находится хранилище событий. Как видите, события одинаковы, как в первом примере. Но бариста важно для этой концепции в данный момент, когда бариста получает событие, а затем думает обо всех соответствующих событиях, чтобы получить текущее состояние для всех заказов, сделанных Алексом.
После второго заказа бариста знает, что полный заказ Алексея состоит из кофе (он помнит это из первого заказа) и капучино, которое было заказано только что. Работать параллельно со вторым баристой не так просто.
При добавлении кассира для получения заказов и обслуживания напитков бариста могут работать независимо, чтобы подготовить напитки. Они не должны знать ничего о клиентах. Кассир в этом случае выступает в роли хранилища событий. Источник событий вводит еще один уровень сложности, но также обеспечивает разделение.
1. Событие: Алекс покупает кофе.
Кассир: (первый) заказ (для Алекса): Кофе
2. Событие: Алекс покупает капучино.
Кассир: (второй) заказ (для Алекса): Cappuccino
Данные телеметрии — это события в реальном времени
Существуют и другие примеры, которые мы можем рассмотреть. Представьте работу холодильной системы, например на пищевом или фармакологическом производстве. Вам нужен постоянный контроль температуры и других соответствующих данных в системе. Для успешной работы крайне важно учитывать данные телеметрии и контролировать их автоматически. Измерение данных телеметрии каждые две секунды с последующей их отправкой в систему управления, в которой данные анализируются и обрабатываются, — это и есть управляемая событиями система. Кроме того, данные должны обрабатываться в режиме реального времени, так как крайне важно быстро реагировать, чтобы избежать нежелательных последствий для бизнеса.