PD
Вообще бэк-2-бэк синхронные вызовы - тоже сомнительный паттерн где-то кроме оркестратора )
Size: a a a
2020 April 06
SE
event-driven FTW 🙂
PD
В истио реально крутая возможность - это определение роутинга для сервисов по заголовку. И, как следствие, возможность легко делать канарейку, dog-fooding и т.п. Но эта возможность дорого обходится (
PD
event-driven FTW 🙂
Ну, можно и не event-driven, но довольно мало сервисов должны вызывать другие, а те, что должны - обычно поддерживают retry...
SE
в моей предыдущей компании было около 30ти сервисов, и только 2 или 3 из них вызывали другие сервисы (там либо отдельно бегущий R скрипт с http endpoint-ом, либо мета-сервис который аггрегировал другие и должен в идеале был быть на клиенте)
все остальные слушали и писали в event log (не путать с message bus)
все остальные слушали и писали в event log (не путать с message bus)
A
Не везде так модно молодежно =)
SE
И если кто собирается сказать "ну, там наверное стартап был, вы могли себе позволить" - мы командой в 3 человека за 8 месяцев родили решение для Германии, которое потом выиграло тендер (против IBM/Cisco/T-Mobile и других), так что давления по срокам хватало ))
SE
от части благодаря такой архитектуре и успели, кстати 🙂 за счёт того, что сервисы не блокировали разработку друг друга и читали всегда из одного источника, а базы бызи кэшами, по сути дела
PD
Ну, да. Единственное. что чистый фронтенд на гетах так сложно сделать. Хотя websocket помогает, конечно.
DP
щас же уже даже разнообразие есть, кроме ws. Тут и grpc, и rsocket (хотя, я не уверен, что его используют, а не только на конференциях рекламируют)
SE
А все уже видели это эпичное голосование?
https://groups.google.com/forum/#!topic/microprofile/i6E_a5WOPSs
tl;dr: в Java Enterprise всё как обычно.
https://groups.google.com/forum/#!topic/microprofile/i6E_a5WOPSs
tl;dr: в Java Enterprise всё как обычно.
J🎩
А все уже видели это эпичное голосование?
https://groups.google.com/forum/#!topic/microprofile/i6E_a5WOPSs
tl;dr: в Java Enterprise всё как обычно.
https://groups.google.com/forum/#!topic/microprofile/i6E_a5WOPSs
tl;dr: в Java Enterprise всё как обычно.
куда там смотреть?
SE
второе сообщение описывающее разницу между pull и push голосом, и на тонну pull
J🎩
я не вижу второго сообщения, описывающего что бы то ни было. После первого только голоса за pull.
過
щас же уже даже разнообразие есть, кроме ws. Тут и grpc, и rsocket (хотя, я не уверен, что его используют, а не только на конференциях рекламируют)
Как я попытался притащить в спринг проект, thrift, меня попытались сожрать.
DP
Как я попытался притащить в спринг проект, thrift, меня попытались сожрать.
ну, может, они были за протобаф)
過
ну, может, они были за протобаф)
Нет, они были за rest
LI
что такого делает OT чего не может NR? Ну то есть концептуально же инструментация она и есть инструментация. Или типа в OT инструментация концептуально минимальна - мол, инструментируем только те методы которые являются интересными (где есть IO, или где байткода на пол мегабайта итд)?
OT process the data outside the app VM. So no fancy things in memory to maintain state, partial traces etc
PD
Как я попытался притащить в спринг проект, thrift, меня попытались сожрать.
А зачем ты пытался его притащить?
PD
щас же уже даже разнообразие есть, кроме ws. Тут и grpc, и rsocket (хотя, я не уверен, что его используют, а не только на конференциях рекламируют)
А как grpc поможет для асинхронного взаимодействия с сервером? Он же тоже на request-response подходе? А делать пулинг как-то дороговато обычно (вернее становится дороговато при любом нечаянном скачке задержек при пуллинге).