Асинхронного: Что такое асинхронное обучение – Блог Webinar

Синхронное и асинхронное программирование: в чем разница?

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

Что такое асинхронное программирование?
Асинхронное программирование основано на неблокирующем протоколе ввода-вывода (I/O). Это означает, что асинхронная программа не выполняет операции в иерархическом или последовательном порядке. Получающееся в результате распараллеливание означает, что асинхронная программа может обрабатывать несколько запросов одновременно и независимо.

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

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

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

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

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

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

Масштабируемость
Async/await — это хорошо известная синтаксическая структура многих языков программирования, которая позволяет асинхронным функциям удобно работать с промисами. Промисы — это объекты, которые инкапсулируют желаемое поведение асинхронной операции. Обе эти концепции являются неотъемлемой частью понятия масштабируемости. Масштабируемость может осуществляться двумя способами — горизонтально и вертикально.

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

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

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

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

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

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

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

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

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

Маркетинговый потенциал
Поисковым системам легче сканировать веб-страницы, использующие традиционную синхронную архитектуру. Для маркетологов, которые зависят от поисковой оптимизации (SEO) для создания своей репутации и узнаваемости бренда, это заметное преимущество. Чем больше людей просматривают ваш веб-сайт через Google или Bing, тем больше посетителей будет на вашей веб-странице. Естественно, это положительно скажется на вашем возврате инвестиций (ROI).

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

Скорость
Время загрузки может быть медленнее при синхронном программировании по сравнению с асинхронным программированием. Этого следовало ожидать, учитывая то, как синхронные программы обрабатывают несколько запросов. Когда поток блокируется, другие потоки в очереди также блокируются. Проще говоря, синхронное программирование похоже на посещение Disney World без VIP-пропуска .

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

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

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

Когда использовать синхронное программирование
Как известно, компьютеры работают быстро. Таким образом, синхронное программирование занимает не так много времени, как вы можете себе представить. Если вы просто хотите разработать внешнее приложение или выполнить базовую функцию центрального процессора (ЦП), то асинхронное программирование выходит за рамки допустимого. Рендеринг видео или математические вычисления, например, используют центральный процессор для максимальной функциональности. Использование асинхронного программирования для этих типов задач перегрузило бы ЦП и принесло бы больше вреда, чем пользы.

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

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

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

  • Статья
  • Чтение занимает 7 мин

Совет

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

Загрузить PDF-файл

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

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

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

Сообщение состоит из заголовка (метаданные, например, идентификатор или данные для обеспечения безопасности) и текста. Обычно сообщения отправляются с использованием асинхронного протокола, например AMQP.

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

Есть еще правило, которого следует придерживаться, насколько это возможно. Между внутренними службами следует использовать только асинхронный обмен сообщениями, а синхронное взаимодействие (например, HTTP) использовать только для клиентских приложений, работающих со службами интерфейса (шлюзами API и микрослужбами первого уровня).

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

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

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

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

Рис. 4-18. Одна микрослужба, получающая асинхронное сообщение

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

Взаимодействие на основе сообщений с несколькими получателями

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

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

Асинхронное взаимодействие, управляемое событиями

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

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

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

Важно то, что вы можете передать сообщение сразу нескольким микрослужбам, которые подписаны на это событие. Чтобы сделать это, вы можете использовать систему обмена сообщениями о публикациях и подписках на основе взаимодействия, управляемого событиями, как показано на рис. 4-19. Этот механизм публикаций и подписок используется не только в архитектуре микрослужб. Он похож на способ, которым взаимодействуют ограниченные контексты в DDD, или на способ распространения обновлений от баз данных записи к базам данных чтения в архитектурах типа разделение команд и запросов (CQRS). Цель — получить итоговую согласованность между различными источниками данных в распределенной системе.

Рис. 4-19. Асинхронное взаимодействие, управляемое сообщением о событиях

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

При использовании шины событий может возникнуть необходимость использования уровня абстракции (например, интерфейса шины событий) на основе соответствующей реализации в классах с кодом, использующим API из брокера сообщений, например RabbitMQ или служебной шины, такой как служебная шина Azure с разделами. Кроме того, вы можете использовать более высокий уровень служебной шины, например NServiceBus, MassTransit или Brighter , для формулировки шины событий и системы публикации и подписки.

Примечание о технологии обмена сообщениями для производственных систем

Технологии обмена сообщениями, с помощью которых можно реализовать абстрактную шину событий, находятся на разных уровнях. Например, такие продукты, как RabbitMQ (транспорт брокера обмена сообщениями) и Служебная шина Azure находиться на более низком уровне, чем другие продукты, такие как NServiceBus, MassTransit или Brighter, которые могут работать поверх RabbitMQ и Служебная шина Azure. Выбор зависит от того, насколько много сложных функций уровня приложения и готовых к использованию возможностей масштабирования необходимо для вашего приложения. Для реализации шины событий, предназначенной только для демонстрации принципа работы и используемой в среде разработки, как было показано на примере eShopOnContainers, будет достаточно простой реализации на основе системы RabbitMQ, работающей в контейнере Docker.

Для построения критически важных и производственных систем, требующих широких возможностей масштабирования, следует использовать служебную шину Azure. Для высокоуровневых абстракций и функций, упрощающих разработку распределенных приложений, рекомендуется оценить другие коммерческие и открытые служебные автобусы, такие как NServiceBus, MassTransit и Brighter. Кроме того, вы можете создавать свои собственные функции служебной шины на основе низкоуровневых технологий, таких как RabbitMQ и Docker. Однако эта черная работа может оказаться слишком дорогим занятием при разработке корпоративного приложения.

Гибкая публикация в шине событий

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

  • Использование очереди транзакций (на основе DTC), подобной MSMQ. (Этот способ применялся в системах более ранних версий.)

  • Интеллектуальный анализ данных журнала транзакций.

  • Использование полной модели источников событий.

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

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

При использовании асинхронного взаимодействия следует дополнительно рассмотреть вопросы идемпотентности и дедупликации сообщений. Эти вопросы рассматриваются в разделе Реализация взаимодействия между микрослужбами на основе событий (события интеграции) далее в этом руководстве.

Дополнительные ресурсы

  • Обмен сообщениями на основе событий
    https://patterns.arcitura.com/soa-patterns/design_patterns/event_driven_messaging

  • Канал публикации или подписки
    https://www.enterpriseintegrationpatterns.com/patterns/messaging/PublishSubscribeChannel.html

  • Уди Дахан (Udi Dahan). Пояснения к CQRS
    https://udidahan.com/2009/12/09/clarified-cqrs/

  • Разделение ответственности команды и запроса (CQRS)
    https://learn.microsoft.com/azure/architecture/patterns/cqrs

  • Взаимодействие между ограниченными контекстами
    https://learn.microsoft.com/previous-versions/msp-n-p/jj591572(v=pandp.10)

  • Итоговая согласованность
    https://en.wikipedia.org/wiki/Eventual_consistency

  • Джимми Богард (Jimmy Bogard). Рефакторинг для обеспечения отказоустойчивости: оценка взаимозависимости
    https://jimmybogard. com/refactoring-towards-resilience-evaluating-coupling/

НазадВперед

АСИНХРОННОЕ определение | Кембриджский словарь английского языка

Примеры асинхронных

асинхронных

Это действительно не работает как асинхронная игра ; Вы должны играть это вживую.

Из проводного