Комментарии 10
Event system architecture (EDA),
Как у вас из Event System Architecture получилось EDA?
Человек старается, хотя уже две первые части заминусовали. Настойчивость - самое главное качество. Плюс в карму и на заметку.
Спасибо, на этот раз мне помогала @Ethera с проверкой на ошибки. )
Присоединяюсь ко мнению! Материалы интересные, понятные и в перспективе получится полезный гайд для начинающих. Отдельный плюс автору за краткость.
И как в этом архитектурном варианте решается проблема "случайно не перезаписать" по американски это называется false positive конкуренция?
Пример всё как у вас: есть сервис БИЛИНГ и ЛОТ:
СРАЗУ УЧТЕМ ЧТО СЕРВИСЫ ВЫПОЛНЯЮТСЯ в 1м экземпляре, в 1 потоке.
1) 2е пользователей одновременно жмут кнопку "купить лот",
2) WEB API создает 2 сообщений в шину для сервиса ЛОТ
3) сервис ЛОТ делает базовые проверки, что лот существует , у него есть цена, и т.д. выплевывает 2 сообщений в шину для БИЛИНГА "списать 500$"
4) БИЛИНГ начинает очухивается и начинает обрабатывать и у 1го и у 2го пользователя удачно списываются деньги. Выплевываеет 2 сообщения обратно в сервис ЛОТ
5) И тут приходит 1е сообщение , мы перезаписываем допустим OWNER_ID=1 у лота, а потом приходит 2е сообщение и бац мы перезаписывает на OWNER_ID=2.
Сразу откину решение что на шаге "3" помечать что этот лот уже в процессе обработки , и 2е сообщение уже на этом этапе откидывать, сказав "брат всё, этот лот уже в процессе сорри". Т.К. когда сообщение 1го человека дойдет до БИЛИНГА, тупа у человека не хватит денег, а мы ВТОРОГО уже откинули, хотя он мог купить т.к. у него хватало денег. Вы хотите терять деньги? я нет.
Надеюсь понятно описал простую ситуацию.
Привет. Наверное уже в сотый раз повторю, что данная статья для чайников. У меня не было задачи описать каждый вариант архитектуры. Если бы я начал это делать, то книг 10 спокойно можно было бы написать) Тут просто намёки, куда можно посмотреть и краткое изложение что это такое.
Но что касаемо вашей ситуации, в чём проблема делать проверки в сервисе биллинга, который списывает деньги. Примерно так же мы должны делать проверки на фронтоне и на бекенде, так и тут тоже самое. Мы перед тем как списывать деньги и поменять владельца лота должны проверить что всё в итоге нормально и у пользователя есть деньги, а у владельца остался лот. Как мы написали "СРАЗУ УЧТЕМ ЧТО СЕРВИСЫ ВЫПОЛНЯЮТСЯ в 1м экземпляре, в 1 потоке.". если мы говорим про один поток, так это вообще не проблема.
false positive Конкретно в данном случае не проблема. Если мы имеем дело с деньгами, то это Нужно делать по сотне дополнительных проверок везде. Но если мы говорим о том, что поставился лайк под фоточкой или нет, то лучше забить и сэкономить ресурсы сервера и если в один из 1.000.000 случаев лайк не поставился, то это не страшно, за то сервера работают быстрее, пользователь увидел обновление сразу и доволен. Всё зависит от задачи.
Все слишком поверхностно, в каждом пункте плюсов\минусов крайне спорные утверждения, а от словосочетания "эвентная архитектура" испытываешь мини-оргазм. Боюсь, что эту статью я бы не рекомендовал "чайникам", только хуже себе сделают.
Что-то тут разные вещи смешаны, message bus да и вообще EDA подразумевает именно общение сервисов через события. Вот это "Вы также можете отследить любой момент времени и откатить продукт к состоянию на любую дату" совсем не обязательно подразумевается в EDA. Для этого всё-таки должен быть реализован event sourcing, обычно событие удаляется из шины после того как потребитель его обработал и передал acknowledgement о нем.
Разработка архитектуры для чайников. Часть 3