![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
"Асинхронный" http api
Вчера был на тусовке junolab, где их главные гуру рассказывали, как у них бекенд устроен.
В частности, на входе у них стоят гейтвеи с обычным http протоколом и минимальным набором фич - валидация, проверка авторизации по токенам и прочее такое, которые перекидывают запрос в MQ (nats.io).
При этом, насколько я понял, асинхронность там реализована поверх обычного http, без всяких http2, веб-сокетов и прочих не везде работающих протоколов - т.е. клиент api сначала делает запрос к гейтвею, ему сразу говорят - 200 ок, а потом он должен, по идее, дальше опрашивать гейтвей, пока для него из MQ придет ответ от микросервисов. Или у них там ответы от сервера бесконечно идут, я сходу не понял (т.е. ответ без content-length и соединение просто ждет пока придет что-нибудь, не помню, как эта техника называется).
В принципе, если keep-alive и соединение не обрывается - то реализация дуплексного протокола поверх синхронного http вроде приемлемая. Единственное, что в случае бесконечного ответа - если сервер и клиент долго ничего друг другу не говорят - промежуточные NAT и прочая сетевая муть могут соединение забыть, причем пока TCP keep-alive не проснется (а это два часа по умолчанию, вроде) - это обнаружено той стороной, которая молчит и ждет, не будет. Но теоретически это какие-то heart-beat слать можно со стороны сервера и запросы со стороны клиента.
В частности, на входе у них стоят гейтвеи с обычным http протоколом и минимальным набором фич - валидация, проверка авторизации по токенам и прочее такое, которые перекидывают запрос в MQ (nats.io).
При этом, насколько я понял, асинхронность там реализована поверх обычного http, без всяких http2, веб-сокетов и прочих не везде работающих протоколов - т.е. клиент api сначала делает запрос к гейтвею, ему сразу говорят - 200 ок, а потом он должен, по идее, дальше опрашивать гейтвей, пока для него из MQ придет ответ от микросервисов. Или у них там ответы от сервера бесконечно идут, я сходу не понял (т.е. ответ без content-length и соединение просто ждет пока придет что-нибудь, не помню, как эта техника называется).
В принципе, если keep-alive и соединение не обрывается - то реализация дуплексного протокола поверх синхронного http вроде приемлемая. Единственное, что в случае бесконечного ответа - если сервер и клиент долго ничего друг другу не говорят - промежуточные NAT и прочая сетевая муть могут соединение забыть, причем пока TCP keep-alive не проснется (а это два часа по умолчанию, вроде) - это обнаружено той стороной, которая молчит и ждет, не будет. Но теоретически это какие-то heart-beat слать можно со стороны сервера и запросы со стороны клиента.
no subject
no subject
по одному урлу получаем ответы, там клиент делает запрос "дай штонибудь, я такой-то!" и ждет до усрачки, у сервера тймаут минут в 15. если ничего нет -- он скажет через 15 минут "нет ничего", клиент переспросит.
кажется это называется long poll mode
по второму урлу клиент срет запросами, сервер сразу отдает queue id, по которому с первого урла будет получен результат.
тут все обычно.
даже кипалив нигде не нужен.
no subject
Если все ок - идет в MQ, а клиенту 200. То, что попавшее в MQ должно обязательно обработаться, вроде у них тестами покрыто (тестов у них там больше чем продакшен кода, по ходу).
no subject
не совсем так
в общем случае:
- между клиентом и сервером постоянно (до траблов в сети, обрыва, окончания авторизированной сессии) висит HTTP persistent connections (HTTP keep-alive) == stream
- клиент api сначала делает запрос к гейтвею, ему сразу (после минимальных телодвижений по обеспечению персистента если оно нужно) говорят - 200 ок
- через некоторое время в stream прилетает ответ по запросу (json c `\n` терминаторами)
по этому каналу у нас для надежности раз в секунду летает `\n` (сделано и на уровне gateway и на уровне клиента в зависимости от направления стрима)
в сумме - у нас и клиенты и сервер считают что работают по асинхронному дуплекс каналу. транспортные проблемы изолированы по коду до состояния что переход на любой другой вариант (http2, websockets, raw tcp socket, etc.) затронет до сотни строк в фреймворке на бэкенде и по такому же кусочку в клиентах
Re: не совсем так
Re: не ÑовÑем Ñак
запросы - в одном канале (или стрим клиент-сервер или http реквест-респонс)
ответы - в другом
no subject
Идейка так-то хороша, но ведь по жизни уже все так делают. Никто не ждет "списка всех юзеров".
no subject
no subject
- не тот encoding пейлоада - лесом на уровне гетвея
- отсутствует хидер с токеном - лесом на уровне гетвея
- токен не проходит валидацию (не раскодируется, истёк, etc.) - лесом на уровне гетвея
- секьюрити группа не подходит по пермишенам для этого эндпоинта - лесом на уровне гетвея
- не валидный payload (не валидный json) - лесом на уровне гетвея
- etc.
если это всё прошло - пейлоад дальше в недра backend согласно маппингу endpoint-microservice, и клиенту `200 OK`
если микросервис определяет что пейлоад не соответствует контракту - уже в стрим пойдёт бизнес-ошибка
no subject
no subject
RE: Re: не ÑовÑем Ñак
no subject
no subject
no subject
no subject
no subject
Но иногда, кто знает, мож важно получить сообщение от сервера с наименьшей задержкой?
Например, на пульте атомной станции! ;-)
no subject
no subject
Влад когда-то работал в гугле, я никогда там не работал.
Этот вопрос как-то связан с моим шутливым ответом? ;-)
no subject
no subject
no subject
а ответ...
ну так, конечно быстрее будет ответ получен.
но вовсе не в этом основной смысл у данной методики
no subject
Ну как же. Всего можно добится и вовсе тупым поллингом, но при этом ещё и больше сервер напрягать.
И вообще, сейчас это всё меньше имеет смысл.
Уже совсем мало используется браузеров, не умеющих веп-сокеты.
no subject
надо завязывать с чтением интернетов
no subject
2:5030/119 Vova Patryshev from SPb Russia 1993.12.10 - 1998.05.29
> Ну как же. Всего можно добится и вовсе тупым поллингом, но при этом ещё и больше сервер напрягать.
воот. нагрузка -- это основное
> Уже совсем мало используется браузеров, не умеющих веп-сокеты.
они не работают через прокси.
и вроде, через некоторых мобильных операторов
no subject
Потому что все-таки это лучше делать веб-сокетами.
no subject
;-) Прикольно!
no subject
И что-то мне говорили, что heart-beats в этих веб-сокетах тоже под вопросом, а без них - всякие блядские наты имеют свойство про коннект забывать.
И еще веб-сокеты непонятно кто из фреймворков умеет. Например, у нас http.sys и то что поверх него сделано - не умеет.
no subject
no subject
no subject
no subject
мне кажется в такой жопе жить не стоит.
ну или тогда делать таймаут сервера 2 минуты.
no subject
no subject
там и часть сайтов работать не будет и ssh и месанджеры...
в общем все будет очень плохо.
no subject
no subject
no subject
no subject
https://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-websocket-protocol-support
Но в API http.sys при этом никаких изменений нет, что странно.
no subject
no subject
no subject
no subject
no subject
no subject
no subject