AS
пробовал и бросил. так же как и play. пока склонился к чистой akka +http
akka это не Event Sourcing
Size: a a a
2019 December 06
MB
я понимаю.
MB
и как-то ограничения лагома в 3 ноды (емнип) мне не понравились. но это было несколько лет назад...
AS
(А то может я опять велосипед изобретаю...)
Да вот как раз поддержку основных паттернов (Service Discovery, Circuit breaker) ну и ES+CQRS, плюс observability. Судя по всему такие проблемы этот lagom и решает
MB
Меня скорее интересует, чем вообще вызван интерес к выбору платформы для микросервисов...
И на что они при этом смотрят вообще.
И на что они при этом смотрят вообще.
имхо, по той же причине, что и спрингбут - фсёизкаропки.
PD
Нее, вряд ли только ради этого внутри была бы система акторов, персистанс и прочие примеры кода, которые я видел )
PD
Я вот понимаю про распределенный акторный движок с удобным API и гарантиями доставки/обработки и хорошей производительностью. Но на akka persistance такое не сделать (
PD
Хотя это не про CQRS, конечно )
MB
Я вот понимаю про распределенный акторный движок с удобным API и гарантиями доставки/обработки и хорошей производительностью. Но на akka persistance такое не сделать (
могу ошибаться, но в лагоме это попытались закрыть как раз кафкой и кассандрой
AS
Ну еще Saga Engine нужен с поддержкой retry
PD
могу ошибаться, но в лагоме это попытались закрыть как раз кафкой и кассандрой
Кафка тут не очень поможет, там проблемы с количеством топиков.
Кассандра - не знаю, не смотрел, что там с гарантиями.
Но я боюсь, что опять разделили хранилище очередей и хранилище стейтов, а это гарантированно приводит к нецелостности
Кассандра - не знаю, не смотрел, что там с гарантиями.
Но я боюсь, что опять разделили хранилище очередей и хранилище стейтов, а это гарантированно приводит к нецелостности
PD
Ну еще Saga Engine нужен с поддержкой retry
Ну, Saga Engine слишком общее понятие (как мы тут уже выясняли), нужно что-то более конкретное.
PD
И тогда уж нужен и движок для оборачивания любых запросов в идемпотентные )
RT
имхо, по той же причине, что и спрингбут - фсёизкаропки.
При переходе от традиционных приложений в микросервисы, значительная часть сложности выпала из уровня приложения на уровень инфраструктуры.
оркестрация контейнеров, управление сетью, доступы, аутентификация, прочий devops.
Сооружать все это самому с нуля сродни самоубиству проекта, нужен фреймворк.
оркестрация контейнеров, управление сетью, доступы, аутентификация, прочий devops.
Сооружать все это самому с нуля сродни самоубиству проекта, нужен фреймворк.
PD
Ну, это фреймворк другого уровня (не лагом).
И для небольших проектов это все не так страшно, это когда сервисов больше пары сотен становится неуютно.
И для небольших проектов это все не так страшно, это когда сервисов больше пары сотен становится неуютно.
AS
И тогда уж нужен и движок для оборачивания любых запросов в идемпотентные )
Если у тебя ES, то нужно, чтобы был механизм публикации и обработки событий с возможностью повторить по выбранной стратегии. Идемпотентность это уже бизнес-логика
MB
При переходе от традиционных приложений в микросервисы, значительная часть сложности выпала из уровня приложения на уровень инфраструктуры.
оркестрация контейнеров, управление сетью, доступы, аутентификация, прочий devops.
Сооружать все это самому с нуля сродни самоубиству проекта, нужен фреймворк.
оркестрация контейнеров, управление сетью, доступы, аутентификация, прочий devops.
Сооружать все это самому с нуля сродни самоубиству проекта, нужен фреймворк.
вот для этого имхо точно не нужен лагом.
MB
хотя это все уже для другого чата)
PD
Если у тебя ES, то нужно, чтобы был механизм публикации и обработки событий с возможностью повторить по выбранной стратегии. Идемпотентность это уже бизнес-логика
Хм, а это про сагу? Это не просто про повторное помещение события с очередь?
PD
Ну и retry же всегда требует идемпотентности, иначе никак (