KB
Спасибо, было интересно!
Size: a a a
2017 May 29
NT
А как относиться, когда два экземпляра одного микросервиса обращаются к одной БД?
Кирилл, по этому вопросу надо смотреть на принципы RESTful и идемпотентность операций. Ресурс должен быть изменен 1 раз, а второй запрос должен получить код 409, если операция идемпотентна. Для этого, при работе с ресурсами должна быть метка версии ресурса, которую необходимо проверять при работе с ресурсом
DM
Омниканальность, если каждый канал - микросервис, как раз приведет к доступу нескольких мс к одной бд.
В том то и дело, что каждый канал - микросервис, это не правильно, т.к. в каналах одинаковые bounded context
KB
Кирилл, по этому вопросу надо смотреть на принципы RESTful и идемпотентность операций. Ресурс должен быть изменен 1 раз, а второй запрос должен получить код 409, если операция идемпотентна. Для этого, при работе с ресурсами должна быть метка версии ресурса, которую необходимо проверять при работе с ресурсом
Спасибо!
KB
NT
Хороший ресурс по паттернам микросервисов microservices.io/patterns/index.html
БД и работа с данными в микросервисной архитектуре - это самый болезненный вопрос, который приходится решать. Чаще всего решение - это Event Sourcing
БД и работа с данными в микросервисной архитектуре - это самый болезненный вопрос, который приходится решать. Чаще всего решение - это Event Sourcing
KB
Да, изучаю два из них
AV
т.е. каждый микросервис должен в собственных транзакциях обеспечивать отсутствие конфликтов
GK
Попробую ответить: сервисы должны быть автотомны, для этого их данные должны быть инкапсулированы. В одной базе будут данные разных серисов или нет - зависит уже от ситуации. Важно - данные разных сервисов должны быть доступны строго посредством того сервиса, которому они принадлежат
KB
Да, это первый паттерн и он самый рекомендуемый
GK
То есть, данные должны монопольно принадлежать единственному сервису.
KB
Но как же уговорить людей, не далать второй паттерн (как они привыкли)?
GK
А дальше, если какой-нибудь сервис аффектит производительность базы, то есть всех других сервисов, то его данные нужно выносить
GK
Тут нет противоречий: Use a (single) database that is shared by multiple services. Each service freely accesses data owned by other services using local ACID transactions.
GK
вообще-то есть ))
GK
shared database - абсолютное зло
NT
Но как же уговорить людей, не далать второй паттерн (как они привыкли)?
Когда найдете простой способ работы с людьми в этом ключе, немедленно расскажите :) Мы больше года пытаемся внедрить разделение данных, разработчики данных упорно нормализуют и связывают их.