Сергей Горностаев

Кто то счетает это хорошей идеей, как возможность связать все сервисы

Тем временем центральная идея микросервисов в том, чтобы связанность максимально снизить.

СУБД докеризировать нежелательно, тем более не стоит размещать СУБД и микроскрвис в одном контейнере, а сами базы в контейнерах хранить категорически нельзя.

Один или два - зависит от факторов, характерных для вашей ситуации. Но если два, то логин и пароль разумнее хранить в сервисе аутентификации.

Вы задаётесь очень сложными вопросами, развёрнутый ответ на каждый из которых вряд ли влезет в лимит символов ресурса. Чтобы разобраться с первой проблемой, стоит прочитать "Предметно-ориентированное проектирование" Эванса. Грубо говоря, микросервис должен оперировать небольшим самостоятельным подмножеством данных. Для поиска ответов на вторую и третью проблему хорошим стартом может быть "Высоконагруженные приложения" Клепмана. Да, взаимодействие внутри микросервисной системы очевидно медленнее, чем вызовы внутри монолита, у всего есть цена. Но при правильно написанном коде, правильно выбранной архитектуре и правильно построенной инфраструктуре скорость всё ещё достаточно, чтобы отвечать на запросы за доли секунды. А для согласованности приходится применять подходы вроде паттерна "сага".

Используют распределённые файловые системы.

Но немаловажная суть микросервисов в том, что бы минимизировать зависимости, в том числе обеспечить каждый микросервис своей БД.

Именно.

Дублировать данные для каждого микросервиса нет никакого смысла.

В микросервисной архитектуре в дублировании как раз есть смысл.

Может быть вам просто не нужны микросервисы, какую проблему вашего проекта решает микросервисная архитектура? А может вы наоборот зря заморачиваетесь по поводу дублирования, какие проблемы у вас с ним?