Size: a a a

2017 November 13

NK

ID:57684913 in gcp_ru
а он разве не перестал уже быть модным?
источник

NK

ID:57684913 in gcp_ru
ну я к тому что хайп вроде стих… юзкейсы остались?
источник

ZO

Zon Orti in gcp_ru
да, у нас есть куски асинхронные, их удобно в такое выносить
источник

NK

ID:57684913 in gcp_ru
я неспешно размышляю за транспорт, а конкретно: условно есть две парадигмы - push когда сервисы сами посылают нужные данные в другие сервисы (http1/2, grpc и тп), и pull когда сервисы подписываются на события и обрабатывают логику в зависимости от изменений (amqp и прочие общие очереди)

в своих системах я нашел удобным миксовать оба подхода: push для прямых вопросов "сервис X, я сервис Y, дай мне эти данные ибо ко мне обратился клиент через REST и мне они нужны чтобы выполнить бизнес-логику и ответить клиенту", pull для бэграунда чтобы четко разделять доменную логику "всем привет, я сервис Z, я буду получать события от сервисов A и B потому что когда у них обновляются данные мне нужно у себя поставить соответсвующие флаги"

однако, я заметил что во всех решениях продвигается только одна модель - push (тот же istio в кубере, 99% фрейворков и тп)
у этой однобокой архитектуры есть свои плюсы (если все общение через http то проще написать сервис на другом языке не вкладываясь в доплибы), и свои минусы (логика оповещения всех зависимых сервисов висит на сервисе который изменяет состояние что усложняет бизнес-логику)

в связи с чем вопросы:
1) почему так - это тренд? у этого решения больше плюсов и поэтому выбирают? какие плюсы и минусы видите вы?
2) вы к чему пришли - используете один из подходов или тоже миксуете?
источник

E

Etki in gcp_ru
Хттп сранина и едва ли не самый дикий протокол за всю историю. Извините.
Конкретно у нас в большинстве случаев приходится сидеть на HTTP и поллить всякую сранину. В будущем планирую ближе к паб/саб перемещаться.
источник

NK

ID:57684913 in gcp_ru
ага, понятно, спасибо

конкретно сейчас я использую парадигму pattern matching (хз не нашел ее описания в интернете)
если вкратце то она описана тут: https://hemerajs.github.io/hemera/1_pattern_matching.html
по сути это паб/саб + допфичи

но минус в том что идет привязка к конкретному фреймворку (условно, я не могу создать сервис на golang не реализовав этот протокол)
источник

NK

ID:57684913 in gcp_ru
и моя основная задача - решить двигаться в этом направлении больше завязываясь на специфику но терять универсальность, или наоборот :)
источник

ZO

Zon Orti in gcp_ru
ID:57684913
я неспешно размышляю за транспорт, а конкретно: условно есть две парадигмы - push когда сервисы сами посылают нужные данные в другие сервисы (http1/2, grpc и тп), и pull когда сервисы подписываются на события и обрабатывают логику в зависимости от изменений (amqp и прочие общие очереди)

в своих системах я нашел удобным миксовать оба подхода: push для прямых вопросов "сервис X, я сервис Y, дай мне эти данные ибо ко мне обратился клиент через REST и мне они нужны чтобы выполнить бизнес-логику и ответить клиенту", pull для бэграунда чтобы четко разделять доменную логику "всем привет, я сервис Z, я буду получать события от сервисов A и B потому что когда у них обновляются данные мне нужно у себя поставить соответсвующие флаги"

однако, я заметил что во всех решениях продвигается только одна модель - push (тот же istio в кубере, 99% фрейворков и тп)
у этой однобокой архитектуры есть свои плюсы (если все общение через http то проще написать сервис на другом языке не вкладываясь в доплибы), и свои минусы (логика оповещения всех зависимых сервисов висит на сервисе который изменяет состояние что усложняет бизнес-логику)

в связи с чем вопросы:
1) почему так - это тренд? у этого решения больше плюсов и поэтому выбирают? какие плюсы и минусы видите вы?
2) вы к чему пришли - используете один из подходов или тоже миксуете?
Для быстрых запросов - http, для бекграунда/медленных - pubsub
источник

NK

ID:57684913 in gcp_ru
быстрые запросы и http? ) а как же circuit breaking и прочие шняги, это надо отдельно решать
источник

NK

ID:57684913 in gcp_ru
опять же ты по сути предлагаешь зоопарк транспортов что сложнее поддерживать (у меня щас так :)
источник

ZO

Zon Orti in gcp_ru
У нас специфика в том, что по пабсабу не только внутри, но и с внешними брокерами работаем. Но используем hosted решения
источник

ZO

Zon Orti in gcp_ru
ID:57684913
быстрые запросы и http? ) а как же circuit breaking и прочие шняги, это надо отдельно решать
Крутых штук пока нет:(
источник

NK

ID:57684913 in gcp_ru
а в пабсаб вы на что завязались?
источник

ZO

Zon Orti in gcp_ru
SQS, Google PubSub, у Азура что-то тоже есть. Для внутреннего - SQS исторически сложился, но на гугловый может смигрируем
источник

ZO

Zon Orti in gcp_ru
Но суть в том, что кастомерам мы евенты должны поставлять
источник

NK

ID:57684913 in gcp_ru
то есть у вас есть набор евентов которые вы емитите и это как бы контракт?

а например вашему сервису A нужно подписаться на определенные события сервиса Б: вы модифицируете сервис Б добавляя туда эмитинг соответсвующих событий?
источник

NK

ID:57684913 in gcp_ru
или у вас все события/действия под капотом эмитятся _на всякий случай_?
источник

ZO

Zon Orti in gcp_ru
ID:57684913
то есть у вас есть набор евентов которые вы емитите и это как бы контракт?

а например вашему сервису A нужно подписаться на определенные события сервиса Б: вы модифицируете сервис Б добавляя туда эмитинг соответсвующих событий?
Через апи клиент говорит - когда меняешь сущность X скинь мне сообщение в SQS
источник

NK

ID:57684913 in gcp_ru
по сути сервис меняет сущность и рассылает об этом оповещение подписчикам.. .ок понял
источник

ZO

Zon Orti in gcp_ru
один из юзкейсов
источник