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

Вот некоторые из более ранних блогов серии Cloud:

Балансировка нагрузки 101 Кэширование 101 Базы данных 101

Что такое асинхронная связь?

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

В отличие от традиционного шаблона синхронизации, построенного с использованием REST API, где ответ API end-2-end является фактором доступности всех компонентов в распределенной архитектуре, асинхронные системы могут независимо масштабироваться для удовлетворения высоких требований TPS (количество транзакций в секунду) . Однако в то же время его основным недостатком является надежность доставки сообщения и необходимость повторного воспроизведения данных. Следовательно, современная архитектура имеет тенденцию следовать гибридной модели использования как асинхронных, так и синхронных шаблонов для удовлетворения нефункциональных требований end-2-end к масштабируемой архитектуре.

Асинхронный и синхронный поток связи

Последовательность операций

1. Клиент вызывает MicroService 1 как HTTPS-запрос GET/POST в зависимости от бизнес-потока.
2. MicroService 1 внутренне вызывает MicroService 2 , чтобы получить информацию о бизнес-функциях либо в виде HTTPS-запроса GET/POST .
3. MicroService 2 внутренне вызывает MicroService 3 для получения информации о бизнес-функциях либо в виде HTTPS-запроса GET/POST .
4. После того , как MicroService 3 отправляет ответ обратно, то же самое в цепочке последовательно передается MicroService 2 и MicroService 1 обратно клиенту.

Последовательность операций

1. Клиент вызывает MicroService 1 как HTTPS-запрос GET/POST в зависимости от бизнес-потока.
2. MicroService 1 публикует событие 1 в шине сообщений для доставки полезной нагрузки клиента.
3. MicroService 2 считывает событие 1 и публикует событие 2 в шине сообщений, чтобы доставить измененную полезную нагрузку.
4. MicroService 3 считывает событие 2 и публикует событие 3 в шине сообщений для доставки подтверждения обратно в MicroService 1 .

Глоссарий асинхронных коммуникаций

Продюсер/Издатель

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

Потребитель/Подписчик

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

Темы

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

Очередь

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

Примеры

Чтобы поиграть с образцом приложения Docker, которое запускает упрощенную систему Message Broker с использованием Docker в локальной системе.

Резюме

Асинхронная связь стала важным строительным блоком в распределенных и масштабируемых развертываниях как в общедоступном, так и в частном облаке. В зависимости от потребностей пользовательского приложения в функциональной архитектуре end-2-end можно использовать платформы обмена сообщениями на основе очередей или тем. Вот некоторые из самых популярных: AWS Messaging , Azure Messaging и GCP Messaging.

Чтобы оставить отзыв, отправьте сообщение на адрес amit[dot]894[at]gmail[dot]com или воспользуйтесь любой из ссылок на странице https://about.me/amit_raj .