Введение в обмен сообщениями в современных облачных архитектурах

Оригинал статьи: ссылка (Sam Dengler, Principal Serverless Solutions Architect)

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

Введение

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

Синхронная коммуникация

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

Паттерны синхронной коммуникации проще внедрить, но они создают сильную связанность (tight coupling) между отправителем и получателем. Сильная связанность может вызывать проблемы при всплесках трафика или проходящих через все приложение отказах. Например, в трёхуровневой архитектуре, когда происходит всплеск в клиентском трафике, веб-уровень увеличивает нагрузку на нижестоящие ресурсы (уровень логики и уровень данных), которые не успевают масштабироваться в соответствии с возросшей нагрузкой. Аналогично, отказы на уровне логики или уровне данных могут напрямую влиять на веб-уровень, отвечающий на запросы клиентов. Приложения могут имитировать синхронную коммуникацию с помощью отображения индикатора ожидания ответа, при этом используя асинхронную коммуникацию с помощью polling, либо push-уведомлений.

Асинхронная коммуникация

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

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

Замечания и следующие шаги

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

Amazon MQ, Amazon Kinesis, Amazon Simple Queue Service (SQS), Amazon Simple Notification Service (SNS) и Amazon EventBridge являются высокодоступными, масштабируемыми и отказоустойчивыми управляемыми сервисами (managed service), которые могут использоваться для внедрения паттернов асинхронного обмена сообщениями. Вы можете узнать больше об этих сервисах на странице Сервисы AWS для обмена сообщениями, а также об их интеграции в serverless-архитектуры в новом бесплатном онлайн-курсе Architecting Serverless Solutions. Вы также можете посетить страницу AWS Event-Driven Architecture, чтобы узнать, как применять паттерны обмена сообщениями для построения event-driven приложений. В следующих постах серии будут рассмотрены эти сервисы AWS, чтобы показать, как обмен сообщениями может применяться в соответствии с лучшими практиками в современных облачных архитектурах.