BonBonSlick
@BonBonSlick
Vanilla Web Architect

Когда действительно нужен Event Sourcing и микросервисы?

Немного поиграв с ES и создав вроде как определенный оверхед в пет проекте, возник вопрос а нужен ли он?
На сколько? Когда, как и зачем его реализовывать?
К пример Мартин Файлер говорил что разрабатывает большую часть приложений именно с ивентами. Наиболее распространенный примеры в интернете это магазин, где есть обьекты Корзина, Покупатель и Продукт, или TODO списки.
Однако ES оверхед или нет?
Если скажем проект типа Trello?
Нужен ли ему ES? А если маленький самописный в компании? Когда разбивать на микросервисы?
Скажем Twitter, нужен ли ему ES и SOA?
Почему?
Оплата на сайте доход до 10 000$ в месяц и нагрузка до 100 000 уников в сутки нужен ES? Ведь его поддержка и содержание в разы выше чем обычный стейт в БД.
Хотелось бы знать кто, когда, и зачем применял ES и микросервисы?

https://martinfowler.com/eaaDev/EventSourcing.html
  • Вопрос задан
  • 681 просмотр
Пригласить эксперта
Ответы на вопрос 2
angrySCV
@angrySCV
machine learning, programming, startuping
микросервисы это ответ на ту сложность с которой приходится сталкиваться при разработке больших сервисов.
В первую очередь ответ на вопрос как эффективно создавать отказоустойчивые, легко масштабируемые сервисы, которые постоянно изменяются и эволюционируют.
сложный и большой проект, легче разрабатывать небольшими независимыми частями (в которых даже запись или чтение "состояния" разнесено по разным сервисам), также такие независимые части легче масштабировать, внедрять, обновлять, тестировать.
Микросервисы вместе с CQRS, DDD, ES помогают решать эту задачу.
Если у вас такой задачи НЕТ, у вас типовой интернет магазин, который сделал один раз и забыл, то микросервисы вам не нужны, точнее большого выхлопа вам не дадут по сравнению с монолитами+модулями внутри монолитов (при этом разработка микросервисов действительно несет определенный оверхед, например необходимость в микросервисах разрабатывать АПИ и АнтиКорапшен слои)
Опять же по поводу нагрузки и масштабирования, в целом у вас небольшая нагрузка которая легко закрывается силами одного дешевенького сервера.
Однако с микросервисной архитектурой можно организовать динамическое масштабирование в облаке -> масштабировать как вверх так и вниз практически в режиме реального времени, что например позволит во время распродаж обрабатывать например 10х типовой нагрузки, при этом не переплачивать за инфраструктуру.
Во время низкой нагрузки использовать 1/10 типовой мощности (и оплачивать 1/10) а в условиях высокой нагрузки (100х от минимальной нагрузки -> с оплатой 10х от типовой но за очень короткий период времени).
При этом можно использовать типа гибридные облака, в которых в начале сервис масштабируется по вашей инфраструктуре, а при резких пиках (на обработку которых у вас нет мощности) дополнительно масштабироваться внутри стороннего облака.
Но это все не типовые решения, разработка которых на порядки сложнее и дороже.
Ответ написан
@Ambrosian
Однако ES оверхед или нет?

любая метода применима для чего-то конкретного.

для мелкого магазинчина - лишняя работа.
для Amazon и более навороченные методы - никакой не оверхед.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы