Декодирование синхронной и асинхронной связи в облачных приложениях
В этой статье разработчики компании DST Global расскажут про синхронные и асинхронные взаимодействия в облачных приложениях, изучайте варианты использования, проблемы и стратегические приложения при проектировании систем.
Представьте себе, что вы строите сложную машину с множеством независимых частей, каждая из которых выполняет свою функцию, но всем им необходимо эффективно взаимодействовать друг с другом для выполнения задачи. Это проблема, с которой мы сталкиваемся при разработке облачных приложений, которые состоят из взаимосвязанных микросервисов и бессерверных компонентов. В этой статье мы исследуем особенности проектирования надежных и отказоустойчивых систем связи, которые могут эффективно координировать эти независимые элементы как внутри, так и за пределами границ приложения.
Эти детально детализированные сервисы участвуют во внутренних и внешних взаимодействиях, используя различные методы связи, синхронные или асинхронные. При синхронной связи служба вызывает другую службу с помощью HTTP или gRPC, ожидая ответа в течение определенного периода времени, прежде чем продолжить. И наоборот, асинхронная связь предполагает обмен сообщениями без ожидания немедленного ответа. Брокеры сообщений, такие как RabbitMQ или Kafka, служат посредниками, буферизуя сообщения для обеспечения надежной доставки. В облачных приложениях использование комбинации шаблонов связи часто является практическим подходом. Давайте сначала начнем с синхронной связи.
Что такое синхронная связь?
Синхронное общение похоже на разговор. Одна служба (назовем ее Службой А) инициирует запрос, а затем ожидает ответа от другой службы (Службы Б) или внешних API. Это похоже на вопрос и ожидание ответа. Служба А отправляет запрос по HTTP и ждет. Он либо ожидает ответа от службы B, либо истечет максимальное время ожидания. В течение этого периода ожидания Служба А временно блокируется, подобно тому, как человек приостанавливает свою деятельность, чтобы дождаться ответа. Этот шаблон, часто называемый шаблоном запрос-ответ, относительно прост в реализации. Однако его широкое использование может вызвать проблемы, требующие тщательного рассмотрения.
Проблемы синхронной связи
Хотя синхронная связь является мощным инструментом в нашем облачном наборе инструментов, она сопряжена с собственным набором проблем, которые требуют тщательного рассмотрения.
Временная связь
Чрезмерная зависимость от синхронной связи во всем решении может привести к проблемам временной связи. Это происходит, когда многочисленные синхронные вызовы объединяются в цепочку, что приводит к увеличению времени ожидания получения ответов клиентскими приложениями.
Зависимость доступности
Синхронная связь требует одновременной доступности всех служб связи. Если серверные службы испытывают неожиданную нагрузку, клиентские приложения могут испытывать сбои из-за ошибок тайм-аута, что влияет на общую производительность.
Влияние на качество сети
Качество сети может напрямую влиять на производительность синхронной связи, включая доступную полосу пропускания и продолжительность, необходимую для прохождения ответов между обслуживающими серверными службами.
Несмотря на эти проблемы, синхронная коммуникация может оказаться неоценимой в конкретных сценариях. В следующем разделе мы рассмотрим некоторые варианты использования, где синхронная связь может быть лучшим выбором.
Когда использовать синхронную связь
Вот несколько ситуаций, в которых использование синхронной связи может оказаться лучшим выбором.
Доступ к данным в реальном времени или гарантированный результат
Когда необходима немедленная обратная связь или обратная связь в режиме реального времени, синхронная связь обеспечивает эффективность. Например, когда клиент размещает заказ на веб-сайте электронной коммерции, интерфейсу электронной коммерции необходимо проверить систему инвентаризации, чтобы убедиться в наличии товара на складе. Это синхронная операция, поскольку приложению необходимо дождаться ответа системы инвентаризации, прежде чем оно сможет приступить к выполнению заказа.
Организация последовательности зависимых задач
В тех случаях, когда служба должна выполнить последовательность задач, каждая из которых зависит от предыдущей, синхронная связь поддерживает порядок. Это особенно подходит для рабочих процессов, где порядок задач имеет решающее значение.
Поддержание целостности транзакций
Когда жизненно важно поддерживать согласованность данных между несколькими компонентами, синхронная связь может помочь поддерживать атомарные транзакции. Это актуально для таких сценариев, как финансовые транзакции, где целостность данных имеет первостепенное значение.
Синхронная коммуникация является мощным инструментом и имеет свои проблемы. Хорошей новостью является то, что у нас также есть возможность асинхронной коммуникации — дополнительный стиль, который может работать вместе с синхронными методами. Давайте рассмотрим это подробнее в следующем разделе.
Что такое асинхронная связь?
Шаблоны асинхронной связи предлагают динамичный и эффективный подход к межсервисному общению. В отличие от синхронной связи, асинхронная связь позволяет службе инициировать запрос, не ожидая немедленного ответа. В этой модели ответы могут не быть немедленными или поступать асинхронно по отдельному каналу, например, по очереди обратных вызовов. Этот режим связи основан на таких протоколах, как расширенный протокол очереди сообщений (AMQP) и промежуточном программном обеспечении обмена сообщениями, включая брокеры сообщений или брокеры событий.
Это промежуточное программное обеспечение для обмена сообщениями действует как посредник с минимальной бизнес-логикой. Он получает сообщения от службы-источника или производителя, а затем направляет их предполагаемой службе-потребителю. Интеграция промежуточного программного обеспечения для обработки сообщений может значительно повысить отказоустойчивость и отказоустойчивость этого отдельного подхода. Асинхронная связь включает в себя различные реализации. Давайте изучим их дальше.
Общение один на один
При передаче сообщений «один к одному» производитель отправляет сообщения исключительно получателю с помощью брокера обмена сообщениями. Обычно брокер сообщений полагается на очереди, чтобы обеспечить надежную связь и предложить гарантии доставки, например, хотя бы один раз. Реализация напоминает шаблон команд, в котором доставленные сообщения действуют как команды, используемые абонентской службой для запуска действий.
Давайте рассмотрим пример розничного интернет-магазина, чтобы проиллюстрировать его использование. Интернет-бизнес во многом зависит от надежности своего веб-сайта. Шаблон обеспечивает отказоустойчивость и гарантии сообщений, гарантируя, что после того, как клиент разместит заказ на веб-сайте, серверные системы выполнения получат заказ для обработки. Брокер сообщений сохраняет сообщения, даже если серверная система не работает, и доставляет их, когда они могут быть обработаны. Например, в приложении электронной коммерции, когда клиент размещает заказ, детали заказа могут быть отправлены в виде сообщения от службы заказа (производителя) к службе выполнения (потребителю) с использованием брокера сообщений. Это пример индивидуального общения.
Связь с одним потребителем оказывается полезной, когда две службы обмениваются данными «точка-точка». Однако возможны сценарии, когда издатель должен отправить определенное событие нескольким подписчикам, что приводит нас к следующей закономерности.
Связь «один ко многим»
Этот стиль общения полезен, когда одному компоненту (издателю) необходимо передать событие нескольким компонентам и службам (подписчикам). В общении «один ко многим» используется концепция темы, аналогичная онлайн-форуму.
Это похоже на онлайн-форум, где несколько пользователей могут публиковать статьи, а их подписчики могут читать их в удобное время, отвечая по мере необходимости. Аналогично, приложения могут иметь темы, в которые службы-производители записывают данные в эти темы, а службы-потребители могут читать данные из темы. Это один из самых популярных шаблонов в реальных приложениях.
Рассмотрим еще раз, что на платформе электронной коммерции есть служба, которая обновляет цены на продукты, и эта информация нужна множеству служб (например, служба подписки, служба рекомендаций и т. д.), обновление цен может быть отправлено в виде сообщения в тему в брокере сообщений. . Все заинтересованные сервисы (абоненты) могут прослушать эту тему и получить обновление цен. Это пример связи «один ко многим». Для реализации этого шаблона доступно несколько инструментов, среди которых Apache Kafka, Redis Pub/Sub, Amazon SNS и Azure Event Grid входят в число наиболее популярных вариантов.
Проблемы асинхронной связи
Хотя асинхронная коммуникация предлагает множество преимуществ, она также создает ряд проблем.
Отказоустойчивость
При наличии множества микросервисов и бессерверных компонентов, каждый из которых имеет несколько экземпляров, сбои неизбежны. Экземпляры могут выйти из строя, перегружаться или испытывать временные сбои. Более того, отправитель не ждет обработки сообщения, поэтому он может не сразу узнать об ошибке. Мы должны принять такие стратегии, как:
- Механизмы повтора: повтор неудачных сетевых вызовов при временных сбоях.
- Шаблон автоматического выключателя: предотвращение повторных вызовов неисправных служб во избежание узких мест в ресурсах.
Распределенная трассировка
Асинхронная связь может охватывать несколько служб, что затрудняет мониторинг общей производительности системы. Реализация распределенной трассировки помогает связать журналы и метрики вместе для понимания потока транзакций.
Комплексная отладка и мониторинг
Асинхронные коммуникации сложнее отлаживать и отслеживать, поскольку операции не следуют линейному потоку. Для эффективной отладки и мониторинга этих систем часто требуются специализированные инструменты и методы.
Управление ресурсами
Асинхронные системы часто включают долгоживущие соединения и фоновую обработку, что может привести к проблемам с управлением ресурсами. Необходимо позаботиться об эффективном управлении ресурсами, чтобы предотвратить утечки памяти или чрезмерную загрузку ЦП.
Понимание этих проблем может помочь разработать более надежные и отказоустойчивые асинхронные системы связи в облачных приложениях.
Заключение
Выбор между синхронными и асинхронными шаблонами связи не является бинарным, а скорее стратегическим решением, основанным на конкретных требованиях приложения.
Синхронную связь легко реализовать, она обеспечивает немедленную обратную связь, что делает ее подходящей для доступа к данным в реальном времени, координации зависимых задач и поддержания целостности транзакций. Однако он сопряжен с такими проблемами, как временная связь, зависимость доступности и влияние на качество сети.
С другой стороны, асинхронная связь позволяет службе инициировать запрос, не дожидаясь немедленного ответа, что повышает оперативность и масштабируемость системы. Он обеспечивает гибкость, что делает его идеальным для сценариев, где немедленная обратная связь не требуется. Однако это создает сложности в обеспечении отказоустойчивости, отказоустойчивости, распределенной трассировки, отладки, мониторинга и управления ресурсами.
В заключение, проектирование надежных и отказоустойчивых систем связи для облачных приложений как считают разработчики DST Global требует глубокого понимания как синхронных, так и асинхронных моделей связи. Тщательно рассмотрев сильные и слабые стороны каждого шаблона и согласовав их с требованиями, архитекторы могут проектировать системы, которые эффективно координируют независимые элементы как внутри, так и за пределами границ приложения, чтобы предоставлять высокопроизводительные, масштабируемые и надежные облачные приложения.
