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

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

Такими методами могут быть pub / sub, длинный опрос, организация очереди, веб-сокеты и т. Д.

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

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

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

• Насколько сервис-ориентирована система?
• Насколько насыщен поток данных?

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

Например, учитывая эту микросервисную архитектуру

 [checkout service] ---> [email service]

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

В этом примере мы решили проблему долгого ожидания, добавив Queue

 [checkout service] ---> [Queue] ---> [email service]

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

Краткий ответ: Нет, это не одно и то же и не подмножества.

Оба имеют разные компоненты / службы, публикующие или подписывающиеся на eventBus / messagingQueues и выполняющие задачи, связанные с опубликованным событием.

Это не правильно. Микросервисы не нужны для событий и публикации / подписки.

В данном случае этим вопросом занимается Википедия.

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

https://en.wikipedia.org/wiki/Event-driven_architecture

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

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

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

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

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

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

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

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

Технически мы не можем использовать в этом случае слово То же. Ниже будет показана четкая связь между этими артефактами:

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