"Асинхронный" http api
Aug. 3rd, 2016 03:33 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassВчера был на тусовке 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 слать можно со стороны сервера и запросы со стороны клиента.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2016-08-03 05:58 pm (UTC)Влад когда-то работал в гугле, я никогда там не работал.
Этот вопрос как-то связан с моим шутливым ответом? ;-)
no subject
Date: 2016-08-03 06:01 pm (UTC)no subject
Date: 2016-08-03 06:09 pm (UTC)а ответ...
ну так, конечно быстрее будет ответ получен.
но вовсе не в этом основной смысл у данной методики
no subject
Date: 2016-08-03 06:14 pm (UTC)Ну как же. Всего можно добится и вовсе тупым поллингом, но при этом ещё и больше сервер напрягать.
И вообще, сейчас это всё меньше имеет смысл.
Уже совсем мало используется браузеров, не умеющих веп-сокеты.
no subject
Date: 2016-08-03 06:20 pm (UTC)надо завязывать с чтением интернетов
no subject
Date: 2016-08-03 06:58 pm (UTC);-) Прикольно!
no subject
Date: 2016-08-04 07:51 pm (UTC)no subject
Date: 2016-08-05 03:52 am (UTC)no subject
Date: 2016-08-03 06:21 pm (UTC)2:5030/119 Vova Patryshev from SPb Russia 1993.12.10 - 1998.05.29
> Ну как же. Всего можно добится и вовсе тупым поллингом, но при этом ещё и больше сервер напрягать.
воот. нагрузка -- это основное
> Уже совсем мало используется браузеров, не умеющих веп-сокеты.
они не работают через прокси.
и вроде, через некоторых мобильных операторов