Event-Driven Architecture в контексте микросервисов: основные паттерны | Николай Голов, ManyChat

7 декабря в офисе Авито прошел пятый митап в серии Backend United, получивший название «Шаурма». Эта встреча ориентирована на архитекторов и на разработчиков.

О чем был доклад Николая:
« Допустим есть микросервисы, есть шина данных, дальше все должно быть очевидным — Event-Driven Architecture. Но не все так просто, поскольку Event-Driven Architecture — это несколько паттернов, с взаимоисключающими паттернами. Event Notification/Event-Carried State Transfer/Event-Sourcing/CQRS — 4 паттерна, 4 подхода, в чём-то схожие, а в чём-то взаимоисключающие. Я расскажу, чем отличаются эти паттерны, что мы пытались исплользовать, и что получили в итоге».

Подпишитесь на канал, соцсети и блоги AvitoTech, чтобы узнавать больше о технологиях Авито 👇🏻

[-dubok-]

Тоже пришёл к идее, что разработка делится на event-driven и command-driven, или, что равнозначно — асинхронный и синхронный подходы. В основном все программируют в синхронном виде. Но практика показывает, что асинхронные сервера гораздо быстрее и естественнее. Синхронный подход не нормален для распределённых архитектур и для серверов в целом. Синхронный подход всё соединяет единой лапшой связей, и получается спагетти-монстр, монолит, хоть и сшитый из сетевых соединений между модулями. А всё потому, что команды создают ПРЯМЫЕ связи между компонентами. Компоненты должны знать друг о друге, что и создаёт связность, от которой многие хотели бы избавиться при распределённой серверной архитектуре. Всё это в целом говорит о том, что сервера необходимо программировать асинхронными и событийно-ориентированными. А иначе вас ждут боль и страдания. Синхронное программирование годится только для программирования отдельных функций, но никак не серверного кода.

В чём коренное отличие команды и события? Команда (как и любое сообщение) имеет адресата, а событие адресата не имеет! Событие — это сообщение, не имеющее адресата. Это даёт возможность каждому модулю не думать о других модулях. Он просто отправляет события, и ему всё равно, как и кто его обработает. Это убирает прямые связи и зависимости между модулями, позволяя легко их добавлять или убирать без вреда для других модулей. Это ли не мечта программиста?

Уверен, event-driven подход — это будущее, к которому все рано или поздно придут при написании серверного кода. Сам пока не реализовал эту идею, но она мне кажется очень естественной и правильной. Нахожусь в стадии доработки архитектурной идеи своего node js мини-фреймворка на этом подходе.

[yabnku]

Коля, большое спасибо за то, что делишься знаниями и опытом. Очень важная теория изложена в докладе. Нашел много ответов на вопросы, возникшие в процессе обдумывания микросервисной архитектуры.

[evgeniichornyi]

Отличный доклад - автор молодец шарит!

[alexanderk]

При совмещении event notification & event carried state transfer можно changeset`ы кидать не с timestamps. а с version, при условии оптимистичной блокировки в базе "источнике" - нормально работает. Другой вопрос, что организация таких changeset`ов - затрагивает изменение и бэка, и фронта.

[qhjjdqk]

Когда у тебя полезной информации максимум на 2 минуты, просто бегай 40 минут туда-сюда по сцене.

[VoimiX]

По моему докладчик путает redis с rabbitmq
не?

или в редисе тоже теперь можно очереди делать?

[victorklimov]

В git не хранятся дельты изменений. Там хранятся содержимое самих файлов в сжатом виде - состояния. Так что git это НЕ пример event source-инга

[shurale]

хорошему докладчику не хватает относительной статики .

[kdenisinfo]

Были бы опытные люди проблем бы не было. У меня никогда не было единной базы данных в последние 10 лет как минимум. Ето ежу понятно! Если человек опытны.. Почему нельзя было нанять в компанию людей с 25 летним стажам?? почему неопытный молодняк решает все ?? Или компания боится опытных людей? Коррупция