AA
OT process the data outside the app VM. So no fancy things in memory to maintain state, partial traces etc
Разве NR не так же делает? Они же тоже сливают трейсы в сервис
Size: a a a
2020 April 06
DP
А как grpc поможет для асинхронного взаимодействия с сервером? Он же тоже на request-response подходе? А делать пулинг как-то дороговато обычно (вернее становится дороговато при любом нечаянном скачке задержек при пуллинге).
я про bidirectional streaming из gRPC. Я не уверен, есть ли их поддержка в grpc-web (поверх HTTP2), но по идее, должна
LI
Разве NR не так же делает? Они же тоже сливают трейсы в сервис
Not the original basic agent. If don’t do basic work on the agent you either have to downsample a lot or you loose fidelity at all. Especially when you have a lot of services
LI
Their agent also was built to be suitable to monolith where you do have to vary the level of instrumentation dynamically to balance fidelity of the trace with the load on the VM.
PD
я про bidirectional streaming из gRPC. Я не уверен, есть ли их поддержка в grpc-web (поверх HTTP2), но по идее, должна
А оно есть в качестве стабильной библиотеки для той же java и js (с разных сторон)?
PD
Но grpc вообще не очень понятно чем существенно лучше json over http. А проблем с ним на всяких балансировщиках и маршрутизаторах хватает еще, сильно ограничивает выбор.
DP
А оно есть в качестве стабильной библиотеки для той же java и js (с разных сторон)?
вот, к сожалению, не скажу, про стабильность в этом месте.
Чем лучше - понятной схемой, по которой можно генерировать юзабельный код. Хотя некоторые, например, твитч - https://github.com/twitchtv/twirp , поняли, что им HTTP2 не нужен (вроде бы, не захотели бороться с балансировкой), и сделали свою штуку
Чем лучше - понятной схемой, по которой можно генерировать юзабельный код. Хотя некоторые, например, твитч - https://github.com/twitchtv/twirp , поняли, что им HTTP2 не нужен (вроде бы, не захотели бороться с балансировкой), и сделали свою штуку
PD
вот, к сожалению, не скажу, про стабильность в этом месте.
Чем лучше - понятной схемой, по которой можно генерировать юзабельный код. Хотя некоторые, например, твитч - https://github.com/twitchtv/twirp , поняли, что им HTTP2 не нужен (вроде бы, не захотели бороться с балансировкой), и сделали свою штуку
Чем лучше - понятной схемой, по которой можно генерировать юзабельный код. Хотя некоторые, например, твитч - https://github.com/twitchtv/twirp , поняли, что им HTTP2 не нужен (вроде бы, не захотели бороться с балансировкой), и сделали свою штуку
Ну, мне вот схема в grpc скорее печалит. Да и swagger вполне решает эту проблему.
DP
вот, со сваггером (openapi) интересно. В случае протобафа мы используем действительно те структуры данных, что описаны. В случае сваггера многие не хотят использовать сгенерированный код. Получается, что это документация, которая не проверяется компилятором. То есть, если все следовать ей будут - круто. А вот если нет, то узнаем мы о проблемах только в рантайме
PD
Хм. Если есть клиент и сервер, то на сервере идет автогенерация описания (и ее не надо проверять), а на клиенте - генерация кода. Так что все вполне проверяется при работе.
Впрочем, все равно нужно писать тесты уровня сервиса - и там можно проверять соответствие openapi (есть куча подходов, включая генерацию).
Впрочем, все равно нужно писать тесты уровня сервиса - и там можно проверять соответствие openapi (есть куча подходов, включая генерацию).
DP
ну да, если мы генерируем сваггер по коду на сервере - тут проверки не надо. А если мы пишем руками yaml файл с описанием API, то уже хотелось бы иметь проверку от компилятора , что сервер корректен. Но да, тесты тут подскажут, и они всё равно нужны
PD
Ну, зависит от потребности в поддержке мультиязыковости. Если (как у меня обычно) на сервере одна платформа, то проще генерить сваггер по серверу для фронта, а остальное использовать через явные интерфейсы.
А если разные языки, то нужно уже кодогенерацией заниматься, увы.
А если разные языки, то нужно уже кодогенерацией заниматься, увы.
PD
Так что разницы между grpc и openapi особо и нет.
AW
AW
Ну а что там было в heptio - дела давно минувших дней.
SE
Ну а что там было в heptio - дела давно минувших дней.
весь Heptio сейчас в VMware, если что 🙂
SE
"Минувшими" я б их не назвал 🙂
AW
Ну а ваше все сомнения @bsideup очень даже валидны. Service mesh делает сервисы тупыми. И это вполне себе клауд-нейтив паттерн. Как и разнообразный серверлесс. Кстати ивент-дривен о том же в чем то
AW
Умные очереди сообщений
AW
Как я это вижу - сита помогают в первую очередь сделать сети прозрачней, а во вторую - позволяют делать умный роутинг и эксперименты без изменений кода. Прогрессивная доставка рулит. Большой добрый брат