PD
REST level 1 - это тоже RPC
Это REST level 2 - только для крудов
Это REST level 2 - только для крудов
Size: a a a
2021 April 16
KK
но кому-то нравится json обмениваться и не придумывать свой payload. + реализация json-rpc v2 рассчитана на асинхронный обмен уже в стандарте, там есть номера запросов и ответов.
AK
REST - это плохое решение для RPC. Хотя бы потому, что это адски размытая парадигма и возникает простой вопрос - а где спека реста? где какие-то rfc? где описаны эти самые level'ы?
у json-rpc есть спека, у grpc и ногих других. а у реста есть только холивары в чятиках и на форумах, как готовить рест.
у json-rpc есть спека, у grpc и ногих других. а у реста есть только холивары в чятиках и на форумах, как готовить рест.
PD
В JSON-RPC - два типа передачи параметров (нафиг?), жесткий формат ошибок (его не хватает)
Поэтому приходится все равно свое делать.
Поэтому приходится все равно свое делать.
PD
Вот это да. Но при этом самым популярным в публичных API стал наиболее ужасный Rest level 2, в котором вообще сплошные проблемы.
PD
(левелы, кстати, много где описаны, более-менее все одинаково понимают)
PD
По сути, конечно, обычно приходится делать свой RPC протокол поверх REST level 1
PD
Со своим описанием различных ошибок на бизнес-уровне и т.п.
p
Ну было 2(пусть будет A и B) и стало 3( пусть будет C). Клиенты ws-серверов A и B никуда не делись же. А новые уже будут попадать на C.
PD
Это ты про пункт 3?
На самом же деле новые будут и дальше равномерно раскидываться по a-b-c, пока их не перезагрузят )
На самом же деле новые будут и дальше равномерно раскидываться по a-b-c, пока их не перезагрузят )
PD
Но вообще если в качестве mq была бы кафка - я бы не парился и отправлял все сообщения на все воркеры, а те пусть сами разбирают.
И не думал про роутинг вообще
И не думал про роутинг вообще
PD
И основная беда - что хочется "положить событие в очередь в базе и в MQ" делать транзакционным, а это не просто...
Впрочем, можно всегда положить в MQ, лишний запрос не страшен
Впрочем, можно всегда положить в MQ, лишний запрос не страшен
p
Да, про 3. Почему будут раскидываться, если мы через балансер можем управлять весами? Можно вообще все новые соединения направить на C.
PD
Ну, динамическое управление весами на балансере с поддержкой websocket? Я в это не очень верю, если честно (но это может быть личными искажениями, я привык, что инфраструктуру на входящим трафике я не контролирую и нет смысла рассчитывать на что-то больше round-robin)
p
Балансер ничего не знает про ws. Он балансирует udp/tcp, а ковыряться в payload - не его дело.
Речь про katran, glb и unimog. Вот хорошая статья от CF: https://blog.cloudflare.com/unimog-cloudflares-edge-load-balancer/
Речь про katran, glb и unimog. Вот хорошая статья от CF: https://blog.cloudflare.com/unimog-cloudflares-edge-load-balancer/
PD
Хм, а ты много видел систем, где они стоят? Я все больше nginx вижу или железный F5 и там такая балансировка - не самое простое, насколько я помню.
И про ws (вернее про длинные соединения) балансер должен понимать (чуть-чуть)
И про ws (вернее про длинные соединения) балансер должен понимать (чуть-чуть)
p
Прилично. Но там у компаний и свои каналы, и BGP и несколько точек присутствия. Просто если tcp-соединение от клиента терминируется на балансере, то это ставит крест на всей схеме.
Прелесть же такого подхода в том, что мы ограничены лишь полосой. И чем больше шардов, тем менее заметно для клиентов выпадение 1 шарда.
Прелесть же такого подхода в том, что мы ограничены лишь полосой. И чем больше шардов, тем менее заметно для клиентов выпадение 1 шарда.
w
Можно же и в json закодировать enum как int?
VA
нинада пазязя
w
ну грубо говоря - кодируем строку значения enum перед отправкой в crc32, почему нет?