Декодирование синхронной и асинхронной связи в облачных приложениях

В этой статье разработчики компании DST Global расскажут про синхронные и асинхронные взаимодействия в облачных приложениях, изучайте варианты использования, проблемы и стратегические приложения при проектировании систем.

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

Эти детально детализированные сервисы участвуют во внутренних и внешних взаимодействиях, используя различные методы связи, синхронные или асинхронные. При синхронной связи служба вызывает другую службу с помощью HTTP или gRPC, ожидая ответа в течение определенного периода времени, прежде чем продолжить. И наоборот, асинхронная связь предполагает обмен сообщениями без ожидания немедленного ответа. Брокеры сообщений, такие как RabbitMQ или Kafka, служат посредниками, буферизуя сообщения для обеспечения надежной доставки. В облачных приложениях использование комбинации шаблонов связи часто является практическим подходом. Давайте сначала начнем с синхронной связи.

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

Синхронное общение похоже на разговор. Одна служба (назовем ее Службой А) инициирует запрос, а затем ожидает ответа от другой службы (Службы Б) или внешних API. Это похоже на вопрос и ожидание ответа. Служба А отправляет запрос по HTTP и ждет. Он либо ожидает ответа от службы B, либо истечет максимальное время ожидания. В течение этого периода ожидания Служба А временно блокируется, подобно тому, как человек приостанавливает свою деятельность, чтобы дождаться ответа. Этот шаблон, часто называемый шаблоном запрос-ответ, относительно прост в реализации. Однако его широкое использование может вызвать проблемы, требующие тщательного рассмотрения.

Проблемы синхронной связи

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

Временная связь

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

Зависимость доступности

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

Влияние на качество сети

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

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

Когда использовать синхронную связь

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

Доступ к данным в реальном времени или гарантированный результат

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

Организация последовательности зависимых задач

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

Поддержание целостности транзакций

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

Синхронная коммуникация является мощным инструментом и имеет свои проблемы. Хорошей новостью является то, что у нас также есть возможность асинхронной коммуникации — дополнительный стиль, который может работать вместе с синхронными методами. Давайте рассмотрим это подробнее в следующем разделе.

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

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

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

Общение один на один

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

Давайте рассмотрим пример розничного интернет-магазина, чтобы проиллюстрировать его использование. Интернет-бизнес во многом зависит от надежности своего веб-сайта. Шаблон обеспечивает отказоустойчивость и гарантии сообщений, гарантируя, что после того, как клиент разместит заказ на веб-сайте, серверные системы выполнения получат заказ для обработки. Брокер сообщений сохраняет сообщения, даже если серверная система не работает, и доставляет их, когда они могут быть обработаны. Например, в приложении электронной коммерции, когда клиент размещает заказ, детали заказа могут быть отправлены в виде сообщения от службы заказа (производителя) к службе выполнения (потребителю) с использованием брокера сообщений. Это пример индивидуального общения.

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

Связь «один ко многим»

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

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

Рассмотрим еще раз, что на платформе электронной коммерции есть служба, которая обновляет цены на продукты, и эта информация нужна множеству служб (например, служба подписки, служба рекомендаций и т. д.), обновление цен может быть отправлено в виде сообщения в тему в брокере сообщений. . Все заинтересованные сервисы (абоненты) могут прослушать эту тему и получить обновление цен. Это пример связи «один ко многим». Для реализации этого шаблона доступно несколько инструментов, среди которых Apache Kafka, Redis Pub/Sub, Amazon SNS и Azure Event Grid входят в число наиболее популярных вариантов.

Проблемы асинхронной связи

Хотя асинхронная коммуникация предлагает множество преимуществ, она также создает ряд проблем.

Отказоустойчивость

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

- Механизмы повтора: повтор неудачных сетевых вызовов при временных сбоях.

- Шаблон автоматического выключателя: предотвращение повторных вызовов неисправных служб во избежание узких мест в ресурсах.

Распределенная трассировка

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

Комплексная отладка и мониторинг

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

Управление ресурсами

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

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

Заключение

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

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

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

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

Декодирование синхронной и асинхронной связи в облачных приложениях
Получить консультацию у специалистов DST
Напишите нам прямо сейчас, наши специалисты расскажут об услугах и ответят на все ваши вопросы.
Комментарии
RSS
20:31
+1
Синхронное и асинхронное взаимодействие микросервисов являются двумя различными подходами к обмену данными и выполнению запросов между микросервисами. Оба подхода имеют свои плюсы и минусы, и выбор подхода зависит от конкретных требований и характеристик системы.
20:32
+1
В синхронном взаимодействии клиентский микросервис ожидает ответа от вызываемого микросервиса перед продолжением своей работы. Это означает, что клиентский микросервис блокируется и ожидает ответа, прежде чем перейти к следующему шагу.

Плюсы синхронного взаимодействия:

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

Минусы синхронного взаимодействия:

— Зависимость от доступности. Если вызываемый микросервис недоступен или работает медленно, это может привести к задержкам и блокировкам в клиентском микросервисе.
— Узкое место. Если синхронные вызовы выполняются последовательно, это может стать узким местом производительности.

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

Асинхронное взаимодействие

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

Плюсы асинхронного взаимодействия:

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

Минусы асинхронного взаимодействия:

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

Пример использования. Система обработки платежей может асинхронно отправлять запрос на обработку платежа, а затем получать ответ о статусе платежа через сообщения. Такой подход позволяет клиентскому микросервису продолжать работу без ожидания ответа платежного сервиса.
20:33
+1
Хорошо описали и чтоже по вашему тогда выбрать? Если также простым языком
Правильный выбор подхода зависит от следующих факторов:

— Время отклика. Если требуется мгновенный отклик и задержки недопустимы, синхронное взаимодействие может быть предпочтительным.
— Надежность. Если надежность и отказоустойчивость важны, асинхронное взаимодействие может быть предпочтительным, так как избегает блокировок и позволяет более гибко обрабатывать ошибки и отказы.
— Производительность. Если система требует высокой производительности и параллельной обработки запросов, асинхронное взаимодействие может быть более эффективным.

Иногда комбинация синхронного и асинхронного взаимодействия может быть наиболее эффективной. Например, клиентский микросервис может асинхронно отправлять запрос на выполнение длительной операции и получать уведомление о завершении через сообщения, в то время как продолжает синхронно выполнять другие операции.
Вам может быть интересно
Мы сталкиваемся с огромными объемами информации, высокой нагрузкой, и постоянно меняющимися требованиями. Все это требует от нас не только навыков программирования, но и грамотного проектирования архи...
Используя возможность компоновки, организации могут упростить управление и извле...
В этом статей разработчики компании DST Global исс...
Часть 1. Конфиденциальность и безопасность данных....
Kubernetes стал незаменимым для разработки совреме...
В этой статье разработчики компании DST Global рас...
В этой статье разработчики компании DST Global зна...

Новые комментарии

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

Заявка на услуги DST

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

Адрес

Ижевск, ул. Воткинское шоссе, д. 170 Е, Технопарк Нобель, офис 1117

8 495 1985800
Заказать звонок

Режим работы: Пн-Пт 10:00-19:00

info@dstglobal.ru

Задать вопрос по почте

Укажите ваше имя
Укажите ваше email
Укажите ваше телефон