GK
Ещё круто работают projections, можно обновлять порционно (PATCH) объекты
Size: a a a
2017 May 29
GK
является
AS
Мы не используем HATEOAS и значит не mature? Не думаю... :)
GK
потому что HATEOAS поверх 2-го уровня, глаголы HTTP в HATEOS так же отображаюстя на CRUD
GK
Мы не используем HATEOAS и значит не mature? Не думаю... :)
Не стоит рефлексировать по этому поводу
E
#msa просто комментарий на тему - вопрос децентрализации управления данными это вопрос, очень пограничный к бизнесу (чтобы не понимали под этим 😊 (это слайд 26) . По-моемум, на уровне сугубо техническом - до определённого предела это может быть это разделение осуществлено. Ну это вообще к теме выделения сервисов - микро, макро или просто.
GK
есть и такое мнение: http://soapatterns.org/compound_patterns/enterprise_service_bus
KB
Хорошо ли, когда два микросервиса обращаются к одной БД?
GP
#whois Глеб Попов enterprise/solution architect ВТБ24
ДС
В понятии "микросервис" приставка "микро" несет какую-то смысловую нагрузку? Грубо говоря, мы "размер" как-то берем в рассчет или это просто чтобы отличать микросервисы от всего остального? #msa
KB
А как относиться, когда два экземпляра одного микросервиса обращаются к одной БД?
KB
В понятии "микросервис" приставка "микро" несет какую-то смысловую нагрузку? Грубо говоря, мы "размер" как-то берем в рассчет или это просто чтобы отличать микросервисы от всего остального? #msa
Есть разумная рекомендация относительно размера - это тот размер кода, который команда может полностью переписать за 1-2 спринта
AV
А как относиться, когда два экземпляра одного микросервиса обращаются к одной БД?
Может, лучше на стороне БД иметь прослойку, которая будет разгребать очередь запросов, заниматься их валидацией и разрешением конфликтов? А остальные сервисы чтоб через неё работали.
AV
Если уж есть необходимость разным сервисам работать с одной БД.
KB
Может, лучше на стороне БД иметь прослойку, которая будет разгребать очередь запросов, заниматься их валидацией и разрешением конфликтов? А остальные сервисы чтоб через неё работали.
получается сильная связка...но почему-то все с этого начинают
AV
А какие другие варианты разрешения конфликтов есть?
Если придут противоречивые запросы от разных сервисов — кто-то получит ошибку. Если повторный запрос от лишнего инстанса сервиса (или что там у нас по сценарию) — есть вероятность, что запрос выполнится, а ошибку получат оба, смотря как реализовать.
Если придут противоречивые запросы от разных сервисов — кто-то получит ошибку. Если повторный запрос от лишнего инстанса сервиса (или что там у нас по сценарию) — есть вероятность, что запрос выполнится, а ошибку получат оба, смотря как реализовать.
AV
И будет это зависеть от кучи внешних факторов, как то, чей запрос из двух одновременных быстрее дошёл.
GP
Омниканальность, если каждый канал - микросервис, как раз приведет к доступу нескольких мс к одной бд.
MS
Друзья, спасибо за интерес к вебинару. Присоединюсь к этому чату через 10 минут