Архитектура, управляемая событиями - как она может быть более эффективной?

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

Представим себе это. У нас есть 2 микросервиса с пружинной загрузкой.

микросервис-A вызывает событие, а микросервис-B слушает событие и выполняет некоторые действия. При подходе EDA микросервис-B обрабатывает все эти события последовательно, одно за другим. Для масштабирования мне нужно запустить несколько экземпляров микросервиса B. Но если бы я использовал традиционный подход, несколько HTTP-запросов обрабатывались бы параллельно одним сервером. Итак, с подходом EDA однопоточная и последовательная обработка - не лучший способ использования ресурсов, верно?


microservices cloud event-sourcing saga event-driven-design
person RamPrakash    schedule 25.04.2020    source источник
comment
Почему вы говорите, что события обрабатываются одно за другим? Даже в однопоточном микросервисе для большинства операций требуется большое количество операций ввода-вывода, поэтому их можно сильно распараллелить.   -  person Francesc Castells    schedule 26.04.2020
comment
@FrancescCastells, я могу так понять? Это ожидаемо. Потребитель должен обрабатывать запросы неблокирующим способом. Чтобы увеличить скорость обработки сообщений / событий, масштабируйте по горизонтали вместе с асинхронным / неблокирующим режимом.   -  person RamPrakash    schedule 26.04.2020
comment
Он ничем не отличается от сценария API. И api, и обработчик сообщений могут обрабатывать множество одновременных операций благодаря многопоточности. Если также операции реализованы как асинхронные, вы можете значительно увеличить параллелизм, потому что они не блокируют потоки. В любом случае операции одинаковы и потребляют одни и те же ресурсы. Разница в том, что обмен сообщениями временно не связан (запрос и выполнение не обязательно должны происходить одновременно).   -  person Francesc Castells    schedule 26.04.2020

Ответы (1)


arrow_upward
0
arrow_downward

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

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

По сути, управление событиями - это обмен сообщениями. Это не ново, и все шаблоны обмена сообщениями должным образом описаны в книге Мартина Фаулера «Шаблоны архитектуры корпоративных приложений». В обмене сообщениями ничего не говорится ни слова о последовательной однопоточной обработке.

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

person Alexey Zimarev    schedule 16.05.2020
comment
competing consumer - это не что иное, как горизонтальное масштабирование микросервиса B в моем примере. В книге не может быть сказано об однопоточности / многопоточности. В основном обработка сообщений будет последовательной. То, что вы говорите, заключается в том, что потребитель должен обрабатывать сообщения с использованием нескольких потоков после их получения. - person RamPrakash; 16.05.2020
comment
Вы сравнили традиционный подход с балансировкой нагрузки HTTP, которая по определению не может выполнять упорядоченную обработку. Ничего в EDA по сравнению с этим не меняется. Аналогичным образом действуют конкурирующие потребители и балансировщики нагрузки. Что касается заказа, у Google есть очень хорошая статья cloud.google.com/pubsub/docs/ заказ # do_i_really_have_order - person Alexey Zimarev; 16.05.2020