Size: a a a

Архитектура ИТ-решений

2020 September 04

С

Сергей in Архитектура ИТ-решений
В целом я рассматривал, в рамках данного примера, именно пакетный запрос или на экран/страницу, или на весь чат в момент его загрузки.

Но это лишь пример. Я его привёл для наглядности, но такого рода задачи встречаются и в других взаимодействиях микросервисов.

Я хотел понять, может есть какой-то общепринятый паттерн, который я упустил, но как вижу подход тут практически индивидуальный.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Да, bff - самое простое решение для начала.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Я в каком-то проекте просто написал документ про стандартные решения таких вопросов. Что делаем на bff, что на datamart, что через денормализацию и т.п.
источник

MS

Maxim Smirnov in Архитектура ИТ-решений
Сергей
Вот об этом и думаю. И не только об этом.
В контексте вопроса - это появление несогласованности данных.
А в чём несогласованность? Если собеседник поменял ФИО после отправки первого, но до отправки второго сообщения, то в сообщениях должны быть указаны разные ФИО, но, возможно, одна и та же гиперссылка на профиль собеседника с его текущим именем, полом и номером телефона
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Maxim Smirnov
А в чём несогласованность? Если собеседник поменял ФИО после отправки первого, но до отправки второго сообщения, то в сообщениях должны быть указаны разные ФИО, но, возможно, одна и та же гиперссылка на профиль собеседника с его текущим именем, полом и номером телефона
Ну, вот в телеграмме аватарка меняется и для старых сообщений, например.
источник

KG

Kirill Gorin in Архитектура ИТ-решений
а кто сказал что у каждого микросервиса своя бд?
источник

MS

Maxim Smirnov in Архитектура ИТ-решений
Phil Delgyado
Ну, вот в телеграмме аватарка меняется и для старых сообщений, например.
Ну и что? Может она отдельным HTTP GET-ом берется для каждого автора и 25 раз по дороге кэшируется
источник

MS

Maxim Smirnov in Архитектура ИТ-решений
Kirill Gorin
а кто сказал что у каждого микросервиса своя бд?
Думаю, это были Льюис с Фаулером https://martinfowler.com/articles/microservices.html#DecentralizedDataManagement
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Скорее всего. Имя, кстати, тоже кэшируется на клиенте, подозреваю. Тут клиент statefull
источник
2020 September 05

MS

Maxim Smirnov in Архитектура ИТ-решений
Сергей
В целом я рассматривал, в рамках данного примера, именно пакетный запрос или на экран/страницу, или на весь чат в момент его загрузки.

Но это лишь пример. Я его привёл для наглядности, но такого рода задачи встречаются и в других взаимодействиях микросервисов.

Я хотел понять, может есть какой-то общепринятый паттерн, который я упустил, но как вижу подход тут практически индивидуальный.
Такой паттерн - CQRS. Всё что мы хотим более-менее шустро читать синхронными запросами, предварительно должно быть асинхронно загружено в сервис для чтения. Всё что-то мы не можем (или не хотим) туда грузить оформляется отдельным ресурсом, на который передается гиперссылка
источник

KG

Kirill Gorin in Архитектура ИТ-решений
да да вот тут как раз
источник

MS

Maxim Smirnov in Архитектура ИТ-решений
Kirill Gorin
да да вот тут как раз
Вот ведь гады :-) Ладно, будем считать, что они так отобразили, что разные экземпляры сервиса ❤️ работают с общей базой, что, в принципе, тоже зло )
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Maxim Smirnov
Такой паттерн - CQRS. Всё что мы хотим более-менее шустро читать синхронными запросами, предварительно должно быть асинхронно загружено в сервис для чтения. Всё что-то мы не можем (или не хотим) туда грузить оформляется отдельным ресурсом, на который передается гиперссылка
Ну, cqrs обычно сложнее в эксплуатации, чем доменные объекты и bff.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, я делал несколько сервисов, смотрящих на одну БД. Если понимать 'зачем', то норм
источник

KG

Kirill Gorin in Архитектура ИТ-решений
Phil Delgyado
Ну, я делал несколько сервисов, смотрящих на одну БД. Если понимать 'зачем', то норм
"вот ведь гады"
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, просто что бы понимать "зачем нарушать правила", сначала надо научиться по ним жить )
источник

KG

Kirill Gorin in Архитектура ИТ-решений
а почему БД не может быть отдельным сервисом?
источник

KG

Kirill Gorin in Архитектура ИТ-решений
такой себе персистант сервис и все
источник

KG

Kirill Gorin in Архитектура ИТ-решений
я пока все эти вырожденные примеры где есть микросервис "заказов" и отдельно микросервис "клиентов" видел только в каких то конторах типа доставки пиццы... которые кхем... изобретают всю архитектуру компьютеров с нуля и этим со всеми делятся как ноу-хау
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Kirill Gorin
а почему БД не может быть отдельным сервисом?
Ну, если она хранит данные одного домена - то норм.
Если "все, что угодно", то это увеличивает связность.
А если через это "все, что угодно" связываются разные сервисы - то связность становится косвенной, что еще хуже.
источник