Да, пытаюсь ее использовать, где возможно. В принципе зарекоммендовала себе не плохо. Одно но, нужно поддерживать разные версии одного и того же микросервиса, особенно если он уже где-то был использован.
Такой вопрос. По логике классический микросервис это изолированный проект который общается с внешним миром посредством какого-то API или очередей сообщений. Изолированный подразумевается что имеет свою изолированную базу данных тоже. Вот я сталкнулся с таким парадоксом. Как проектируется микросервисная архитектура в этом случае? Когда надо делать сложные запросы для получения данных из разных сервисов или менять данные в разных сервисах в одной транзакции (чтобы можно было откатить все). Не нашел какой-то золотой середины. Даже https://microservices.io/ говорит что общая база данных это антипатерн, но также говорит что такое возможно. Wilder, какие мысли по этому поводу?
Если рассматривать базу данных так же как микросервис, то тебе должно быть не важно, она там одна общая или несколько. Но для этого нужно иметь интервейс для общения с ней, а не делать запросы напрямую
Для меня микросервис - эта такая черная коробка с торчащими проводами. Мы точно знаем что можно подавать на вход и точно знаем что должны получить на выходе. Как и что черная коробка делает внутри с точки зрения предыдущего микросервиса не важно.
Что ты имеешь под интерфейс для общения с БД? Другой сервис?
Вот к примеру ситуация. Есть микросервис который отвечает за user management, то есть его "слой данных" (назовем абстрактно вместо "база данных"). И есть сервис который например управляет форумом и сохраняет сообщения от пользователей у него тоже свой слой данные - сообщения. Вот надо сохранить сообщения от определенного пользователя и пользователю записать счетчик его сообщений. Если у нас маналит, то все просто - две таблицы: User+Post и ссылка из Post на User. Все просто. Если у нас два микросервиса, то они в идеале ничего не должны знать про слои данных друг друга. То есть микросервис User не знает ни о каких Posts, а микросервис Posts ничего не знает о таблице Users.
Получается что: - либо мы делаем общую базу данных и два сервиса знают о таблицах друг друга и могут их менять. Тогда смысл микросервисной архитектуры теряется так как сервисы уже не изолированные единицы а зависят друг от друга. - у каждого серсиса своя база данных, но тогда как-то надо связывать Post + User.
а почему ты не пытаешься вызвать микросервисы по цепочке? Ты пишешь в одну таблицу, возвращаешь результат и вызываешь второй вебсервис с нужными параметрами
"- у каждого серсиса своя база данных, но тогда как-то надо связывать Post + User."
ты предлагаешь связывать через "параметры"
То есть получили UserID из первого микросервиса User (назовем UserService) и передали его как параметр во второй Post микросервис (PostService). И собственно Post сервис сохранил user ID как простое тектовое поле в записи post.
Теперь чтобы показать на сайт список Posts с именами авторов мне что надо?
- Послать один запрос в PostService чтобы получить список всех сообщений. - Затем выдераем из этого списка сообщений список UserIDs. - Далее отправляем этот список UserIds в UserService чтобы получить всех Users - объединяем posts и users.
