⚡ Kotobotov ⚡

как вариант - подключится к рабочему контейнеру через docker exec дополнительно указав команду export с необходимой переменной.

Насколько я понимаю, микросервис - это обычный сервис, который решает одну маленькую задачу. Микросервис может состоять как из одного контейнера, так и из нескольких контейнеров (если используются контейнеры).

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

2. дополнительная пропускная способность? - ну если только ДО БД, а дальше бд то одна, соответственно перфоманс всего приложения всё равно не изменится.

обычно микросервисы нарезают так чтоб они обслуживали отдельную "тематику", которую можно было бы отдельно маштабировать и отдельно дорабатывать, от всех остальных. Пример:
микросервис который обрабатывает работу каталога (и всё что связанно с ним), отдельно микросервис который будет работать с доставкой и отправкой заказов, микросервис который работает с партнёрской программой и начислением балов лояльности, и микросервис который занимается обработкой платежей. У каждого из этих микросервисов желательно иметь свою БД, тогда они могут независимо друг от друга работать и независимо маштабироваться, только отвечая потребностям свой нагрузки - очевидно нагрузка на каталог сильно выше чем на сервис обработки платежей (например каталог может обрабатывать 10 узлов, заказы обрабатывают 3 узла а платежи 1 узел)
При использовании монолита вы масштабируете сразу все сервисы на узлы, что не так эффективно.
-------
По поводу перфоманса - при такой нарезке как описал выше, у вас крайне редко будет ситуация когда для ответа на один запрос от пользователя, нужно будет опрашивать сразу несколько сервисов, НО даже в таких ситуациях не так важна задержка между вызовами, сколько возможность масштабировать обработку этих запросов.
-------
транзакционность обычно осуществляется через SAGA паттерн.
По поводу консистентности - если ты начинаешь масштабировать систему, значит состояние размазывается по множеству разных узлов/сервисов, вся суть что эти узлы/сервисы могут независимо друг от друга работать, значит консистентность будем мешать независимой работе (тоесть производительности), если сервисы зависимы то они не маштабируются (раз один узел ожидает что-то для работы от другого узла), поэтому там предъявляются "ослабленные требования" к консистентности состояния, как правило используют eventual consistency (согласованность в конечном счете), говорят что рано или поздно типа состояние в системе будет согласованно, если не будут поступать новые данные)
ну а пока данные поступают, то состояние может быть не согласованно между узлами.

ну есть такая команда docker commit - которая позволяет сохранить изменения в контейнере. но думаю всё равно стоит сохранять в докер фаил все шаги необходимые для новой сборки имиджа (просто не всегда его пересобирать).
а для того чтоб автоматизировать сборку, обычно выстраивают CI/CD пайплайны, завязывая их на изменениях в репозитории. Тоесть в своём репозитории описываются дополнительно шаги по сборке контейнера, которые срабатывают каждый раз когда происходят изменения в репозитории (ну например изменения докер файла или какие-то изменения в коде проекта).
П. С.
сборка разумеется идет с нуля, но за счет того что каждая инструкция в докер файле - это отдельный слой который кэшируется, то процесс может неплохо так ускоряться.

ну вроде как у вас на врокере, на котором идет сборка из гитлаба, не установлен какой-то модуль)

обычно используют облачную БД + виртуальные машины в разных регионах, ну и балансировщик запросов для сервиса.

контейнеры лучше шарить через репозиторий, тк за счет кэширования слоев получается очень быстрая и эффективная схема работы.

в контейнере не сохраняются изменения файлов (баз данных), после перезапуска контейнера вся ваша БД будет сброшена в изначальное состояние, что удобно например при тестировании, но не при работе.
для того чтоб сохранять изменения данных, требуется проводить определенные операции, и чтоб данные в бд были согласованными с вашим контейнером вам нужно будет постоянно отслеживать и обновлять контейнер сразу после внесения изменений в БД, такая процедура создает серьезную нагрузку и ненужный гиморой.