Post #527

Часто возникает вопрос — какой выбрать режим интеграции — синхронный или асинхронный. Особенно если у вас в инфраструктуре есть и то, и то. То есть, вы приходите к владельцу/архитектору системы, с которой хотите интегрироваться, а он говорит: у нас и REST API есть, и к Кафке мы подключены, нам в принципе всё равно, что для тебя сделать, а тебе-то как удобнее? То есть, перекладывает выбор на аналитика. А как аналитику выбрать? Ну, провести анализ, а что анализировать-то? Тем более, что вариантов у вас три (да ещё с подвариантами): 1. Синхронная интеграция (запрос-ответ, выполняемый немедленно) — в пределе — постоянный двунаправленный канал (websockets) 2. Асинхронная (и запрос, и ответ асинхронные; по сути, двунаправленный паттерн "публикатор/подписчик", обычно это топик для запросов и топик для ответов) 3. Смешанная или гибридная (обычно синхронный запрос и асинхронный ответ), причем тут два варианта: — ответ через очередь сообщений; — ответ через прямое обращение (webhook, подписки в graphql / grpc) Итого, на что смотрим и что анализируем: 1. Требования бизнес-процесса: нужен ли нам по сути деятельности немедленный ответ? (скорость ответа — десятки и сотни миллисекунд). То есть, онлайн-игры, чаты, совместное редактирование документов, управление видеоконференциями — это вебсокеты или что-то похожее. Онлайн-платежи, переводы, запрос баланса, аренда самоката, открытие автомобиля каршеринга, перевод, заполнение форм и вообще действия в интерфейсе — это синхронный запрос-ответ, REST API и RPC в любых видах. 2. Если время выполнения запроса может превышать секунды (граница тут тонкая, как видите) — можно думать про асинхронное взаимодействие. Нужны уточняющие вопросы: — Нужно ли сохранять все запросы?Будем ли мы перепосылать каждый запрос, если его не смогли обработать? (насколько ценна информация и насколько быстро она меняется? Важен ли нам конкретный экземпляр запроса? Заказ в магазине, вызов такси и запрос на создание документа точно будем перепосылать. А вот запрос остатков товара, оповещение о текущем положении вызванной машины, подтверждающий код — можем и пропустить, сохранять его не нужно — ответ именно на этот запрос нам не актуален, мы другой отправим. То есть, если промежуточное хранение не нужно — выбираем синхронную связь с возможными потерями, если нужно сохранять сообщение или обеспечить точный порядок сообщений — асинхронную очередь. — Нагрузка, которую мы обеспечим взаимодействующей системе: сможет ли её API выдержать наши запросы? Какой у системы RPS и насколько часто мы к ней собираемся обращаться? Возможно, для разгрузки системы перед ней нужно поставить очередь. — Как долго обрабатывается наш запрос? Если смежная система будет обрабатывать секунды и минуты — это точно асинхрон или гибрид: мы можем отдать команду на старт процесса синхронно (через REST API), а получить ответ асинхронно: через webhook, если нам ответ не очень важен, или через очередь, если ответ для нас важен, или ответов может быть несколько и важна их очередность. — Мы обращаемся к одной системе, или ко многим сразу? Например, у нас много систем, в которых учитываются разные банковские или страховые продукты для одного клиента, и мы хотим опросить все системы. Можем на своей стороне делать по запросу к каждой системе, а можем кинуть один запрос в очередь запросов, и пусть все системы оттуда его считают и отвечают в своем темпе. Если число систем неизменно, а отвечают они быстро — это API Gateway. Если системы по-разному нагружены, и число их может расти — лучше очередь. — Может ли наш запрос выполниться в одной системе за один раз, или это транзакция, которая выполняется в нескольких системах? Скорее всего, распределенная транзакция, особенно если это хореографическая сага, потребует асинхронной интеграции. Ну и помним, что организация очередей и брокеров не дается бесплатно, это всегда, с одной стороны, вычислительные ресурсы, а, с другой — усложнение логики работы и тестирования. А если вы встречали хороший алгоритм для выбора режима интеграции — скиньте в комменты, всем будет полезно.