Что такое синхронный и асинхронный обмен данными
Синхронный и асинхронный режимы передачи цифрового сигнала
В предыдущих постах я разобрал, что такое синхронизация при передаче цифрового сигнала и как на уровне логических элементов может происходить прием цифрового сигнала в получателе сигнала.
Какие бывают способы синхронизации? Первое, что приходит в голову — это передача тактового сигнала по отдельному дополнительному каналу передачи данных. Рассмотрим рисунок, который уже использовался в предыдущем посте:
Рисунок 1
На рисунке 1 верхний из двух сигналов может быть передан по одному каналу, а нижний (тактовый сигнал) — по другому, параллельному, каналу. Задний фронт (помечен зеленым цветом) импульса тактового сигнала командует источнику сигнала отправить очередной бит цифрового сигнала. Передний фронт (помечен красным цветом) импульса тактового сигнала командует получателю сигнала взять образец сигнала, приходящего от источника. Именно поэтому задний фронт каждого импульса тактового сигнала на рисунке 1 совпадает с началом каждого бита передаваемого от источника сигнала, а передний фронт каждого импульса тактового сигнала совпадает с серединой каждого бита передаваемого от источника сигнала.
Тут может быть два варианта: 1) тактовый импульс идет из источника сигнала. В этом случае получатель сигнала по полученному тактовому импульсу подстраивается под скорость работы источника сигнала. 2) Тактовый импульс идет из получателя сигнала к источнику сигнала. Источник сигнала начинает посылать цифровой сигнал с цифровыми данными при получении тактового сигнала от получателя сигнала. В этом случае источник сигнала подстраивается под скорость работы получателя сигнала.
Естественно, передача тактового сигнала по отдельному каналу по деньгам получается значительно дороже, ведь требуется дополнительный провод. Поэтому зачастую тактовый сигнал передают тем же сигналом, что и передаваемые цифровые данные. В этом случае дополнительный провод не требуется, но в получателе сигнала понадобится оборудование для обработки полученного цифрового сигнала, чтобы выделить из него тактовый сигнал и сигнал, несущий цифровые данные.
Существует еще так называемый «асинхронный режим» передачи цифрового сигнала или просто «асинхронная» передача цифрового сигнала. На самом деле, несмотря на то, что такая передача цифрового сигнала называется «асинхронной» (то есть «не синхронной»), при получении цифрового сигнала в получателе в этом случае всё равно требуется (и выполняется) синхронизация получателя и источника сигнала. Просто в случае асинхронной передачи цифровой сигнал с цифровыми данными идет кусками (пакетами, байтами и тому подобное), а между этими кусками есть промежутки, на которых канал остается пустым (без полезной нагрузки цифровыми данными). В итоге синхронизация нужна (и выполняется) только в момент приема получателем очередного куска цифрового сигнала с цифровыми данными, а в пустом промежутке между кусками сигнала с данными синхронизация не нужна (и не выполняется). То есть под словом «асинхронная» понимается не полное отсутствие синхронизации, а прерывистое выполнение синхронизации — она то выполняется, то не выполняется.
В википедии асинхронный режим передачи данных проиллюстрирован такой картинкой:
Из-за излишней компактности иллюстрации некоторые соседние надписи на этой иллюстрации сливаются и зритель с первого раза может воспринять некоторые соседние надписи на этой картинке за одну надпись, что может сильно затруднить понимание. На самом деле, на этой картинке только надпись «data bits» состоит из двух слов. Все остальные надписи — однословные.
Чтобы соседние надписи не сливались, я отделил их друг от друга цветом, кое-где добавил к линиям стрелки для понятности, и некоторые линии сделал пунктирными:
Понятия «mark» и «space», использующиеся в англоязычной литературе, посвященной передаче цифрового сигнала, по-русски означают «логическая единица» и «логический нуль» соответственно или для булевой алгебры — «true» («истина») и «false» («ложь»). В физическом смысле логическая единица может представляться, к примеру, высоким уровнем сигнала, а логический нуль — низким уровнем сигнала, или наоборот. В англоязычной википедии по этим понятиям есть статья «Mark and space». На рассматриваемом рисунке логическая единица («mark») показана высоким уровнем цифрового сигнала, а логический нуль («space») показан низким уровнем цифрового сигнала.
Как и описывалось выше при определении понятия «асинхронной» передачи цифрового сигнала, на рисунке есть промежутки, в течение которых канал заполнен данными, и промежутки, в течение которых канал не заполнен данными (последнее состояние на рисунке обозначено английским словом «idle», которое по-русски в данном случае значит «пустой» или «незанятый»). На рисунке таких незанятых промежутка два: перед стартовым битом первого байта и после стопового бита второго байта. Между двумя байтами, изображенными на рисунке, незанятого данными промежутка «idle» нет, но он может быть. Просто в данном случае байты переданы впритык друг к другу, но могли быть переданы и разделенными промежутком «idle».
На рисунке промежуток «idle» показан высоким уровнем сигнала, но в разных протоколах он может быть представлен как высоким уровнем сигнала, так и низким уровнем сигнала. Тут есть условие: стартовый бит всегда должен быть представлен уровнем сигнала, противоположным уровню промежутка «idle», а стоповый бит должен быть представлен уровнем сигнала, совпадающим с уровнем промежутка «idle». Очевидно, что стартовый и стоповый биты должны быть представлены противоположными уровнями сигнала.
Как работает асинхронный режим передачи цифрового сигнала? Каждый кусок (пакет, байт и тому подобное) данных может быть передан отдельно, отделяясь (или не отделяясь) друг от друга промежутками «idle» (канал не занят данными). При приеме очередного байта получателю сигнала нужно достичь синхронизма с источником сигнала, чтобы получить данные без ошибок. Для этого получателю сигнала необходимо знать момент начала входящего байта. Этот момент на обсуждаемом рисунке обозначен передним фронтом стартового бита («start»): в данном случае это переход из высокого уровня сигнала к низкому уровню сигнала. После передачи битов данных («data bits») обязательно нужно вернуть цифровой сигнал на уровень промежутка «idle», то есть в случае, показанном на обсуждаемом рисунке — на высокий уровень сигнала. Это нужно для того, чтобы было возможно отметить начало следующего байта передним фронтом стартового бита следующего байта. Возврат на уровень сигнала, соответствующий промежутку «idle», выполняется стоповым битом («stop»).
Для достижения синхронизма кроме начала участка цифрового сигнала, содержащего цифровые данные, получателю сигнала для правильного приема нужно знать длину одного бита цифрового сигнала. Как я понимаю, скорость передачи данных между стартовым и стоповым битом, определяющая длину одного бита сигнала, становится известна получателю сигнала перед началом передачи данных (настроена заранее), поэтому получателю сигнала в данном случае и требуется только информация о начале каждого байта.
Как видно из рисунка, к каждому байту данных при асинхронной передаче необходимо добавлять два дополнительных бита: стартовый и стоповый. Такую передачу цифрового сигнала часто называют «старт-стопной» передачей данных. Очевидно, что эти дополнительные биты уменьшают скорость передачи данных по сравнению с синхронным режимом передачи данных, при котором все байты передаются впритык друг к другу, без дополнительного обозначения начала и конца байта с помощью стартового и стопового битов.
Скорость передачи данных при асинхронном режиме передачи меньше еще и из-за того, что между байтами могут вставляться промежутки «idle» (канал не занят данными), а при синхронном режиме передачи между передаваемыми данными нет никаких лишних промежутков.
Оба эти режима передачи данных сегодня используются. В англоязычной википедии есть хорошая небольшая статья, сравнивающая эти режимы:
Проектирование взаимодействия между службами для микрослужб
Обмен данными между микрослужбами должен быть эффективным и надежным. Благодаря большому числу небольших служб, взаимодействующих с выполнением одной бизнес-деятельности, это может быть сложной задачей. В этой статье мы рассмотрим компромиссы между асинхронным обменом сообщениями и синхронными API. Затем мы рассмотрим некоторые трудности при проектировании устойчивой взаимосвязи между службами.
Сложности
Вот некоторые из основных проблем, возникающих при обмене данными между службами. Сети служб, описанные далее в этой статье, предназначены для решения многих из этих проблем.
Устойчивость. Могут существовать десятки и даже сотни экземпляров любой определенной микрослужбы. Экземпляр может завершиться ошибкой по ряду причин. Может произойти сбой на уровне узла, например сбой оборудования или перезагрузка виртуальной машины. Экземпляр может аварийно завершить работу либо быть перегружен запросами, не имея возможности обрабатывать новые запросы. Любое из этих событий может вызвать сбой сетевого вызова. Существует два конструктивных шаблона, которые могут повысить устойчивость сетевых вызовов между службами.
Повторите попытку. Сетевой вызов может завершиться сбоем из-за временной ошибки, которая исчезает сама по себе. Вместо завершения вызова вызывающий объект обычно повторяет операцию несколько раз или до тех пор, пока не истечет настроенный период времени ожидания. Тем не менее, если операция не является идемпотентной, повторные попытки могут вызвать непредвиденные побочные эффекты. Начальный вызов может быть выполнен успешно, но вызывающий объект никогда не получит ответ. Если вызывающий объект повторяет попытку, операция может вызываться дважды. Как правило, небезопасно повторять методы POST или PATCH, потому что они не обязательно будут идемпотентными.
Автоматическое выключение. Слишком много неудавшихся запросов могут вызвать узкое место, так как ожидающие запросы накапливаются в очереди. Эти заблокированные запросы могут содержать критические системные ресурсы, такие как память, потоки, подключения к базе данных и т. д., что может привести к каскадным сбоям. С помощью шаблона автоматического выключения (прерывателя) в службе можно предотвратить повторное выполнение операции, которая, вероятнее всего, завершится ошибкой.
Балансировка нагрузки. Когда служба «A» вызывает службу «B», запрос должен достичь работающего экземпляра службы «B». В Kubernetes тип ресурса Service обеспечивает стабильный IP-адрес для всех групп модулей pod. Сетевой трафик на IP-адрес службы отправляется в pod с помощью правил iptable. По умолчанию выбирается случайный модуль pod. Слой взаимодействия между службами (см. ниже) может обеспечить более интеллектуальные алгоритмы балансировки нагрузки на основе наблюдаемой задержки или других метрик.
Распределенная трассировка. Одна транзакция может охватывать несколько служб. Это может затруднить наблюдение за общей производительностью и работоспособностью системы. Даже если каждая служба создает журналы и метрики, при отсутствии определенного метода связать их вместе они имеют ограниченное использование. В статье ведение журнала и мониторинг рассматриваются дополнительные сведения о распределенной трассировке, но мы упомянули ее как проблему.
Управление версиями службы. Развертывая новую версию службы, команда должна предотвратить нарушение работы каких-либо других служб или внешних клиентов, которые зависят от нее. Кроме того, можно выполнять несколько версий службы параллельно и перенаправлять запросы к определенной версии. Дополнительные сведения см. в разделе Управление версиями API.
Шифрование TLS и взаимная проверка подлинности TLS. По соображениям безопасности можно зашифровать трафик между службами с помощью TLS и использовать взаимную проверку подлинности TLS для аутентификации вызывающих объектов.
Синхронный и асинхронный обмен сообщениями
Существует два основных шаблона обмена сообщениями, с помощью которых микрослужбы могут взаимодействовать.
Синхронный обмен данными. В этом шаблоне служба вызывает API, который предоставляет другая служба, используя протокол, такой как HTTP или gRPC. Это шаблон синхронного обмена сообщениями, потому что вызывающий объект ожидает ответа от получателя.
Асинхронная передача сообщений. В этом шаблоне служба отправляет сообщение, не дожидаясь ответа, поэтому одна или несколько служб обрабатывают сообщения асинхронно.
Важно различать асинхронный ввод-вывод и асинхронный протокол. Асинхронный ввод-вывод означает, что вызывающий поток не блокируется, пока не завершится операция ввода-вывода. Он важен для производительности и является элементом реализации с точки зрения архитектуры. Асинхронный протокол подразумевает, что отправитель не ждет ответа. Протокол HTTP — это синхронный протокол, хотя клиент HTTP может использовать асинхронный ввод-вывод при отправке запроса.
Каждый шаблон имеет свои недостатки. «Запрос — ответ» является вполне понятной парадигмой, поэтому разработка API может показаться более естественной, чем проектирование системы обмена сообщениями. Однако асинхронный обмен сообщениями имеет некоторые преимущества, которые могут быть полезны в архитектуре микрослужб:
Слабая взаимозависимость. Отправителю сообщения не нужно знать об объекте-получателе.
Несколько подписчиков. С помощью модели публикации и подписки несколько клиентов могут подписаться на получение событий. Дополнительные сведения см. в статье Стиль архитектуры, управляемой событиями.
Изоляция сбоев. Если объект-получатель вышел из строя, отправитель все равно может отправлять сообщения. Сообщения будут доставлены, когда объект-получатель восстановится. Эта возможность особенно полезна в архитектуре микрослужб, так как каждая служба имеет свой собственный жизненный цикл. В любой момент времени служба может стать недоступной или быть заменена более новой версией. Асинхронный обмен сообщениями может обрабатывать прерывистый простой. С другой стороны, в синхронных API нижестоящая служба должна быть доступна, иначе операция завершится ошибкой.
Скорость реагирования. Вышестоящая служба может отвечать быстрее, если она не ждет ответа от нижестоящих служб. Это особенно удобно использовать в архитектуре микрослужб. Если имеется цепочка зависимостей служб (служба «A» вызывает «B», которая вызывает «C» и т. д.), то ожидание синхронных вызовов может привести к неприемлемым задержкам.
Выравнивание нагрузки. Очередь может выступать в качестве буфера для выравнивания рабочей нагрузки, поэтому получатели могут обрабатывать сообщения с нужной им скоростью.
Рабочие процессы. Очереди можно использовать для управления рабочим процессом, устанавливая конечную точку для сообщения после каждого шага рабочего процесса.
Однако существуют некоторые проблемы с эффективностью использования асинхронного обмена сообщениями.
Взаимозависимость с инфраструктурой обмена сообщениями. Использование определенной инфраструктуры обмена сообщениями может вызвать тесную связь с этой инфраструктурой. Потом будет сложно переключиться на другую инфраструктуру обмена сообщениями.
Задержка. Если очереди сообщений заполняются, то совокупная задержка обработки операций может стать очень высокой.
Стоимость. При высокой пропускной способности инфраструктура обмена сообщениями может быть дорогостоящей.
Сложность. Обработка асинхронного обмена сообщениями является непростой задачей. Например, нужно обрабатывать дублирующиеся сообщения, удаляя дубликаты либо делая операции идемпотентными. При использовании асинхронного обмена сообщениями также трудно реализовать семантику «запрос — ответ». Для отправки ответа потребуется другая очередь, а также способ коррелировать запросы и ответные сообщения.
Пропускная способность. Если сообщения требуют семантику очереди, то очереди могут стать узким местом в системе. Каждое сообщение требует наличия хотя бы одной операции постановки в очередь и одной операции вывода из очереди. Более того, семантика очереди обычно требует некоторой блокировки внутри инфраструктуры обмена сообщениями. Если очередь выступает управляемой службой, может появиться дополнительная задержка, так как очередь является внешней по отношению к виртуальной сети кластера. Можно устранить эти проблемы, используя пакетные сообщения, но это усложнит код. Если сообщения не требуют семантики очереди, можно использовать поток событий вместо очереди. Дополнительные сведения см. в статье Стиль архитектуры, управляемой событиями.
Доставка с помощью дронов: выбор шаблонов обмена сообщениями
Учитывая приведенные выше соображения, команда разработчиков сделала следующие выборы в отношении проектирования приложения доставки с помощью дронов.
Служба приема предоставляет открытый интерфейс REST API, который клиентские приложения используют для планирования, обновления или отмены поставок.
Служба приема использует Центры событий для отправки асинхронных сообщений в службу планировщика. Асинхронные сообщения необходимы для реализации выравнивания нагрузки, которая необходима для приема данных.
Службы учетной записи, доставки, посылок, дронов и транспортных услуг третьих лиц предоставляют внутренние интерфейсы REST API. Служба планировщика вызывает эти API для выполнения запроса пользователя. Одной из причин использования синхронных API является то, что планировщику необходимо получить ответ от каждой из нижестоящих служб. Сбой в любой из нижестоящих служб означает, что вся операция завершилась неудачно. Тем не менее потенциальная проблема — это объем задержки, которая возникает при вызове серверных служб.
Если любая подчиненная служба имеет невременный сбой, вся транзакция должна быть помечена как неудачная. Для решения этой ситуации служба планировщика отправляет асинхронное сообщение супервизору, чтобы супервизор мог запланировать компенсирующие транзакции.
Служба доставки предоставляет открытый API, который клиенты могут использовать для получения состояния доставки. В шлюзе APIстатьи мы обсудим, как шлюз API может скрыть базовые службы от клиента, поэтому клиенту не нужно знать, какие службы предоставляют интерфейсы API.
Пока дрон находится в полете, служба дронов отправляет события, которые содержат сведения о текущем местоположении и состоянии дрона. Служба доставки принимает эти события для отслеживания состояния доставки.
Обратите внимание, что события состояния доставки являются производными от событий расположения дронов. Например, когда дрон достигает места доставки и выгружает груз, служба доставки преобразует это в событие DeliveryCompleted (доставка завершена). Это пример подхода с учетом модели предметной области. Как описано выше, управление дронами принадлежит к отдельному ограниченному контексту. События дронов передают их физическое расположение. С другой стороны, события доставки представляют собой изменения состояния доставки, что является другой бизнес-сущностью.
Использование слоя взаимодействия между службами
Слой взаимодействия между службами — это программный уровень, который обрабатывает обмен данными между службами. Слои взаимодействия между службами предназначены для решения многих проблем, перечисленных в предыдущем разделе. Они позволяют перенести ответственность за эти проблемы от самих микрослужб на общий уровень. Слой взаимодействия между службами выступает в качестве прокси-сервера, который перехватывает сетевой обмен данными между микрослужбами в кластере. В настоящее время концепция сетки служб применяется главным образом к оркестрации контейнеров, а не к бессерверным архитектурам.
Сетка службы — это пример шаблона посредник — вспомогательная служба, которая отправляет сетевые запросы от имени приложения.
Сейчас основными вариантами слоя взаимодействия между службами в Kubernetes являются linkerd и Istio. Обе эти технологии быстро развиваются. Тем не менее и linkerd, и Istio предоставляют следующие функции:
Балансировка нагрузки на уровне сеанса, основанная на наблюдаемых задержках или количестве ожидающих запросов. Это может повысить производительность по сравнению с балансировкой нагрузки уровня 4, предоставляемой Kubernetes.
Маршрутизация уровня 7 на основе URL-адреса, заголовка узла, версии API или других правил уровня приложения.
Повторение невыполненных запросов. Слой взаимодействия между службами распознает коды ошибок HTTP и может автоматически повторять невыполненные запросы. Можно настроить максимальное количество попыток, а также время ожидания, чтобы ограничить максимальную задержку.
Автоматическое выключение. Если экземпляр последовательно не выполняет запросы, слой взаимодействия между службами временно пометит его как отключенный. Через некоторое время он снова попробует связаться с экземпляром. Можно настроить автоматический выключатель на основе различных критериев, таких как количество последовательных сбоев.
Слой взаимодействия между службами фиксирует показатели вызовов между службами, такие как объем запроса, задержка, уровень ошибок и успешности, а также размеры ответов. Слой взаимодействия между службами также позволяет распределенную трассировку путем добавления информации о корреляции для каждого прыжка в запросе.
Взаимная проверка подлинности TLS для вызовов между службами.
Вам нужен слой взаимодействия между службами? Это зависит от нескольких условий. Без сетки служб необходимо учитывать каждую из проблем, упомянутых в начале этой статьи. Вы можете решать такие проблемы, как повторение запросов, автоматический выключатель и распределенная трассировка без слоя взаимодействия между службами, но она перемещает эти проблемы из отдельных служб на выделенный уровень. С другой стороны, в сети служб повышается сложность установки и настройки кластера. Так как запросы теперь маршрутизируются через прокси-сервер слоя взаимодействия между службами, а также потому, что на каждом узле кластера теперь выполняются дополнительные службы, возможны последствия для производительности. Следует выполнять тщательную проверку производительности и нагрузочное тестирование перед развертыванием слоя взаимодействия между службами в рабочей среде.
Распределенные транзакции
Распространенная сложность микрослужб — правильная обработка транзакций, охватывающих несколько служб. Часто в этом сценарии успешная транзакция полностью или нет — если одна из участвующих служб завершается сбоем, то вся транзакция должна завершиться ошибкой.
Здесь необходимо рассмотреть два случая:
Служба может столкнуться с временным сбоем, например со временем ожидания сети. Эти ошибки часто можно решить, просто повторив вызов. Если операция по-прежнему завершается ошибкой после определенного числа попыток, она считается невременной ошибкой.
Невременный сбой — это любой сбой, который вряд ли исчезает сам по себе. Невременные сбои включают обычные ошибки, например недопустимые входные данные. К ним также относятся необработанные исключения в коде приложения или сбой процесса. При возникновении такой ошибки вся бизнес-транзакция должна быть отмечена как сбой. Может потребоваться отменить другие шаги в той же транзакции, которые уже выполнены.
Если логика компенсирующих транзакций сложна, можно создать отдельную службу, которая отвечает за этот процесс. В приложении доставки с помощью дронов служба планировщика ставит неудачные операции в выделенную очередь. Отдельная микрослужба, называемая контролером, выполняет чтение из этой очереди и вызывает API отмены для служб, которые необходимо компенсировать. Это разновидность шаблона «планировщик, агент, контролер». Служба «Контролер» может выполнять и другие действия, такие как уведомление пользователя с помощью текстового сообщения или электронной почты или отправка предупреждения на панель управления операций.
Может произойти сбой самой службы планировщика (например, из-за сбоя узла). В этом случае новый экземпляр может быть создан и перенимать. Однако любые транзакции, которые уже начали выполняться, должны быть возобновлены.
Одним из подходов является сохранение контрольной точки в долговременном хранилище после завершения каждого шага в рабочем процессе. Если экземпляр службы планировщика аварийно завершает работу в ходе транзакции, новый экземпляр может использовать контрольную точку для возобновления, когда предыдущий экземпляр остался прежним. Однако создание контрольных точек может увеличить производительность.
Другой вариант — сконструировать все операции как идемпотентными. Операция является идемпотентной, если ее можно вызвать несколько раз, не создавая дополнительных побочных эффектов после первого вызова. По сути, подчиненная служба должна пропускать дублирующиеся вызовы, что означает, что служба должна иметь возможность обнаруживать дублирующиеся вызовы. Реализовать методы идемпотентными не всегда просто. Дополнительные сведения см. в разделе идемпотентными Operations.
Дальнейшие действия
Для микрослужб, напрямую взаимодействующих друг с другом, важно создать хорошо спроектированные API.