RS
как ты гарантируешь что от клиента(например из браузера) до тебя сообщения долетит
т.е.
client <—broken—> microservice <—broken—> kafka ?Size: a a a
2020 January 16
IR
да
RS
никак. Такой гарантии нет. Просто клиенту придётся показать фигу в этот момент и попросить его попробовать заново позже.
Тут суть в том, чтобы в ситуации:
Тут суть в том, чтобы в ситуации:
client <—okay—> microservice <—broken—> kafka сервис не стоял а работал, не дожидаясь пока там кафка на связь выйдетIR
а ты уже сталкивался со всем тем что пишешь тут или просто пока придумал?
RS
а ты уже сталкивался со всем тем что пишешь тут или просто пока придумал?
скажем так: с распределёнными системами знаком не на вы. Проектирую микросервисную архитектуру (tech-demo) и пока ещё никогда не работал с event sourcing’ом и CQRS
RS
и не смотря на то что Event-Sourcing и CQRS идеи давние - только сейчас начинают наберать обороты. Я и сам довольно недавно с данными паттернами познакомился
IR
просто проблемы с сетью для меня это довольно выдуманная проблема так как мало когда у тебя будет разрыв между сервисов и кафкой, чаще у тебя накроется сразу все
IR
и еще чаще у тебя будет падать сервис чем кафка
IR
в том числе под нагрузкой
IR
т е ты должен скорее беспокоится о том чтобы сервис с бизнес логикой не упал чем кафка
IR
почему не очень?
IR
вся наша работа это трейдофф
IR
деньги/качество/время
IR
ну ок можно выдумать проблему и решить
RS
просто проблемы с сетью для меня это довольно выдуманная проблема так как мало когда у тебя будет разрыв между сервисов и кафкой, чаще у тебя накроется сразу все
мало когда != никогда // правда
а что если от потери данных мы можем создать бизнесу проблемы на пару лямов? или больше? А что если от редкого отказа могут погибнуть люди?!
а что если от потери данных мы можем создать бизнесу проблемы на пару лямов? или больше? А что если от редкого отказа могут погибнуть люди?!
IR
тогда почему тебя не парит что от клиента данные могут не дойти
IR
клиентом же может быть и телефон
IR
и датчик