Event-Driven Architecture в контексте микросервисов: основные паттерны | Николай Голов, ManyChat
Вставка
- Опубліковано 11 вер 2024
- 7 декабря в офисе Авито прошел пятый митап в серии Backend United, получивший название «Шаурма». Эта встреча ориентирована на архитекторов и на разработчиков.
О чем был доклад Николая:
« Допустим есть микросервисы, есть шина данных, дальше все должно быть очевидным - Event-Driven Architecture. Но не все так просто, поскольку Event-Driven Architecture - это несколько паттернов, с взаимоисключающими паттернами. Event Notification/Event-Carried State Transfer/Event-Sourcing/CQRS - 4 паттерна, 4 подхода, в чём-то схожие, а в чём-то взаимоисключающие. Я расскажу, чем отличаются эти паттерны, что мы пытались исплользовать, и что получили в итоге».
Подпишитесь на канал, соцсети и блоги AvitoTech, чтобы узнавать больше о технологиях Авито 👇🏻
ВК: avitotech
Твиттер: / avitotech
Телеграм: t.me/avitotech
Хабр: habr.com/ru/co...
Медиум (eng): / avitotech
Гитхаб: github.com/avi...
Сайт: avito.tech/
Коля, большое спасибо за то, что делишься знаниями и опытом. Очень важная теория изложена в докладе. Нашел много ответов на вопросы, возникшие в процессе обдумывания микросервисной архитектуры.
Тоже пришёл к идее, что разработка делится на event-driven и command-driven, или, что равнозначно - асинхронный и синхронный подходы. В основном все программируют в синхронном виде. Но практика показывает, что асинхронные сервера гораздо быстрее и естественнее. Синхронный подход не нормален для распределённых архитектур и для серверов в целом. Синхронный подход всё соединяет единой лапшой связей, и получается спагетти-монстр, монолит, хоть и сшитый из сетевых соединений между модулями. А всё потому, что команды создают ПРЯМЫЕ связи между компонентами. Компоненты должны знать друг о друге, что и создаёт связность, от которой многие хотели бы избавиться при распределённой серверной архитектуре. Всё это в целом говорит о том, что сервера необходимо программировать асинхронными и событийно-ориентированными. А иначе вас ждут боль и страдания. Синхронное программирование годится только для программирования отдельных функций, но никак не серверного кода.
В чём коренное отличие команды и события? Команда (как и любое сообщение) имеет адресата, а событие адресата не имеет! Событие - это сообщение, не имеющее адресата. Это даёт возможность каждому модулю не думать о других модулях. Он просто отправляет события, и ему всё равно, как и кто его обработает. Это убирает прямые связи и зависимости между модулями, позволяя легко их добавлять или убирать без вреда для других модулей. Это ли не мечта программиста?
Уверен, event-driven подход - это будущее, к которому все рано или поздно придут при написании серверного кода. Сам пока не реализовал эту идею, но она мне кажется очень естественной и правильной. Нахожусь в стадии доработки архитектурной идеи своего node js мини-фреймворка на этом подходе.
Я кстати ,знаю откуда это все идет , с какой темы😂😂😂😂 просто это было давно придумано из другой схемы.
Отличный доклад. Николай - молодец!
Отличный доклад - автор молодец шарит!
бедный оператор
Прекрасный доклад , спасибо автору👍🏻
При совмещении event notification & event carried state transfer можно changeset`ы кидать не с timestamps. а с version, при условии оптимистичной блокировки в базе "источнике" - нормально работает. Другой вопрос, что организация таких changeset`ов - затрагивает изменение и бэка, и фронта.
Мужик с таким умным лицом говорит 😂
Когда у тебя полезной информации максимум на 2 минуты, просто бегай 40 минут туда-сюда по сцене.
Отдыхай через каждые две минуты и твой гипоталамус не будет перегружаться)
По моему докладчик путает redis с rabbitmq
не?
или в редисе тоже теперь можно очереди делать?
можно
редис умеет в паб\саб
В git не хранятся дельты изменений. Там хранятся содержимое самих файлов в сжатом виде - состояния. Так что git это НЕ пример event source-инга
Автор доклада в бувальном смысле пересказывал выступление Мартина Фаулера из далекого 2017 года, и там действительно упоминался гит. Только суть не в том, как гит фактически хранит изменения на диске - не это основа примера. Ивент сорсинг там в контексте того, что есть история коммитов, восприизведение/откат которых переводит систему в определенное состояние на тот или иной момент времени. Так что пример отличный, просто хреново пересказанный.
Нарамально
хорошему докладчику не хватает относительной статики .
на загнивающем западе докладчики только так по сцене перебегают
это видимо нужно для концентрации внимания слушателей, чтоб не было статики
20:25 но-но-но! нехороший пример.
Были бы опытные люди проблем бы не было. У меня никогда не было единной базы данных в последние 10 лет как минимум. Ето ежу понятно! Если человек опытны.. Почему нельзя было нанять в компанию людей с 25 летним стажам?? почему неопытный молодняк решает все ?? Или компания боится опытных людей? Коррупция
как-то очень скомканно