YZ
Ну все-таки в сервисном взаимодействии все на эмуляцию RPC на кафке переводить наверное смысла особого не имеет? Вряд ли полностью надо переводить взаимодействие на персистентные распределенные транзакции?
Про транзакции я не говорил
Size: a a a
2021 January 08
ВК
Ну, транзакций там не будет в любом случае.
Транзакций в смысле ACID - не будет. Но в смысле саг - еще как будут, ради этого обычно и делают RPC же.
AN
Транзакций в смысле ACID - не будет. Но в смысле саг - еще как будут, ради этого обычно и делают RPC же.
я бы не стал сагу распределенной транзакцией называть, а то некоторым может показаться, что это одно и то же )
YZ
Если у вас все взаимодействие сервисов на kafka-rpc, то вы наверное хотите делать и откаты - не всегда отказ сервиса нештатный из-за недоступности например.
Это уже не про kafka/rest/rpc, а про механизмы достижения консистентности
PD
Условная команда запоздала при обработке и была отказана - надо откатывать остальные действия транзакции.
Это уже саги и прочие workflows
ВК
А RPC у вас ради RPC или ради чего?
ВК
Ну то есть, один из сценариев - это например устойчивость к отказам сервиса, да?
PD
Транзакций в смысле ACID - не будет. Но в смысле саг - еще как будут, ради этого обычно и делают RPC же.
Классические саги с хореографией - сомнительный паттерн. Workflow в стиле cadencе лучше, но на кафке сложно реализовывать
YZ
Ну то есть, один из сценариев - это например устойчивость к отказам сервиса, да?
Не устойчивость (это достигается логикой обработки запросов в частности), а лёгкость достижения распределения нагрузки и прогнозируемый+надёжный механизм доставки
ВК
Не устойчивость (это достигается логикой обработки запросов в частности), а лёгкость достижения распределения нагрузки и прогнозируемый+надёжный механизм доставки
Окей. Какие сложности вы встречали в распределении нагрузки на http?
Надежный механизм доставки - его цель разве не повышение отказоустойчивости?
Надежный механизм доставки - его цель разве не повышение отказоустойчивости?
SS
Artem Nenashev
по поводу ресурсных затрат я точно знать не могу, но выглядит не очень оптимально. может кто-то с большим опытом прокомментирует.
а вот по поводу Stream'а у меня вопрос: я же правильно понимаю, что этот стрим кладет что-то в KTable по ключу correlationId?
а вот по поводу Stream'а у меня вопрос: я же правильно понимаю, что этот стрим кладет что-то в KTable по ключу correlationId?
Кафка топик изначально представляется в виде KStream ,если применить метод filter то получим KStream - это по прежнему ближе к топику, а KTable это для хранения состояния , данные с одним ключём перезаписывается. Но в нашем случае по моему достаточно KStream.
PD
А зачем вообще kstream?
PD
Насколько я понимаю, кафка вместо http спасает только в сценарии 'упал получатель, потом упал отправитель'. Но тут вполне спасает организация бизнес-логики через wokflow. Гарантий больше, реализовывать проще.
AN
Не совсем понимаю проблему, если честно
проблема в том, что добавив в свою модель сохранения состояния request'а (хотя, вы видимо все-таки имели ввиду состояние процесса/контекста в рамках которого он вызывается, он же не один может быть) вы лишаетесь главного преимущества RPC - вызывать его так, как будто это локальный вызов.
проблема в том, что это состояние надо не забывать сохранять перед каждым
проблема в том, что это состояние надо не забывать сохранять перед каждым
Request. и абстракции начнут течь в этом месте, когда пользователю библиотеки надо будет объяснять смысл этого сохранения перед каждым `Request`ом.SS
Клиент же реактивный, подозреваю? И тогда никакой синхронный http ему и не нужен, проще request получить через http (и там, конечно, просто rest level 1), а ответ получить через подписку на websockets, склейку и сам клиент может сделать.
Это будет гораздо масштабируемее и проще в реализации в конечном итоге.
Единственное - нужно будет как-то обеспечивать надежные очереди для websockets, но для этого есть вполне себе набор внешних решений
Это будет гораздо масштабируемее и проще в реализации в конечном итоге.
Единственное - нужно будет как-то обеспечивать надежные очереди для websockets, но для этого есть вполне себе набор внешних решений
Тут вопрос , как в определенную websocket сессию отправить только те события из топика, которые относятся именно к этой сессии. Потому что создание отдельного топика на сессию трудозатратно ( nats шина кстати так умеет). Вот и приходится читать один топик и перенаправлять события в нужные сессии.
PD
Sergey Sokolov
Тут вопрос , как в определенную websocket сессию отправить только те события из топика, которые относятся именно к этой сессии. Потому что создание отдельного топика на сессию трудозатратно ( nats шина кстати так умеет). Вот и приходится читать один топик и перенаправлять события в нужные сессии.
Это умеют делать внешние инструменты (
YZ
Artem Nenashev
проблема в том, что добавив в свою модель сохранения состояния request'а (хотя, вы видимо все-таки имели ввиду состояние процесса/контекста в рамках которого он вызывается, он же не один может быть) вы лишаетесь главного преимущества RPC - вызывать его так, как будто это локальный вызов.
проблема в том, что это состояние надо не забывать сохранять перед каждым
проблема в том, что это состояние надо не забывать сохранять перед каждым
Request. и абстракции начнут течь в этом месте, когда пользователю библиотеки надо будет объяснять смысл этого сохранения перед каждым `Request`ом.Предложенный выше механизм можно легко скрыть в либу, но разумеется нужно 100 раз подумать над тем, как это правильнее сделать под описанный вами сценарий
AN
Sergey Sokolov
Кафка топик изначально представляется в виде KStream ,если применить метод filter то получим KStream - это по прежнему ближе к топику, а KTable это для хранения состояния , данные с одним ключём перезаписывается. Но в нашем случае по моему достаточно KStream.
тогда как этот фильтр сработает? на каждый
correlationId будет создаваться свой KStream?AN
Предложенный выше механизм можно легко скрыть в либу, но разумеется нужно 100 раз подумать над тем, как это правильнее сделать под описанный вами сценарий
возможно. но вот я такого способа сокрытия этого механизма (тем более легкого) пока представить не могу.
SS
Nikolay
а сколько у вас будет таких клиентов в штуках?
Если по одновременным подключениям, то не думаю что больше 200, но потом появятся IoT. Но у нас есть уже задача реализовать что то наподобие совместного редактирования документа, отображением изменений онлайн, поэтому стали думать в сторону EventSourcing.