Начал читать про микросервисы. Как я понял микросервис это нечто автономное, общающееся с внешним миром по сети. Например через jms.

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

Могут ли в таком случае 2 инстанса сервера А исаользовать одну и ту же БД? если не могут, то почему именно и как решить эту проблему(репликация? consistency не будет?)?

Basil A. Sidorovredwhite90Начал читать про микросервисы. Как я понял Микросервис это попытка разменять сложность разработки многомодульного приложения на сложность развёртывания многосервисного облака.
Т.е. микросервис ~= модуль, превращённый в автономное приложение.
Точно также, как у вас может быть несколько экземпляров модуля в памяти монолитного приложения, точно также у вас может быть несколько экземпляров микросервиса.
Сколько экземпляров работают с базой - определяется логикой системы и здравым смыслом.

То есть микросервисы одного типа могут работать с одной базой, а микросервисы разного типа не могут?

Leonid Kudryavtsevredwhite90Соответственно микросервисы не должны общаться через базу.
Почему?
Чем Вам база не угодила?
Ну вот например

https://habr.com/post/249183/ Если коротко, то архитектурный стиль микросервисов — это подход, при котором единое приложение строится как набор небольших сервисов, каждый из которых работает в собственном процессе и коммуницирует с остальными используя легковесные механизмы, как правило HTTP . Эти сервисы построены вокруг бизнес-потребностей и развертываются независимо с использованием полностью автоматизированной среды. Существует абсолютный минимум централизованного управления этими сервисами. Сами по себе эти сервисы могут быть написаны на разных языках и использовать разные технологии хранения данных.


https://habr.com/company/mailru/blog/320962/#2 Микросервисная архитектура — это подход к созданию приложения, подразумевающий отказ от единой, монолитной структуры. То есть вместо того чтобы исполнять все ограниченные контексты приложения на сервере с помощью внутрипроцессных взаимодействий, мы используем несколько небольших приложений, каждое из которых соответствует какому-то ограниченному контексту. Причём эти приложения работают на разных серверах и взаимодействуют друг с другом по сети, например посредством HTTP.

Иными словами, мы инкапсулируем определённые контексты приложения в микросервисы, по одному на каждый, а сами микросервисы крутим на разных серверах.

Petro123redwhite90,
Почему у тебя теория одна?
В прошлой СВОЕЙ теме книжку прочитал?

Чтобы что-то начать делать нужна какая-то теоретическая основа и понимание нафига оно надо.

Вот ещё по теме:

https://habr.com/company/mailru/blog/320962/#2 При микросервисной архитектуре, когда каждый бизнес-компонент представляет собой микросервис, все компоненты обладают собственными базами данных, которые недоступны другим микросервисам. Данные компонента доступны (для чтения и записи) только через соответствующий интерфейс компонентов. Благодаря этому степень устойчивости данных варьируется в зависимости от компонента (Мартин Фаулер, Чед Фаулер).

Вот и возникает у меня вопрос:
Допустим я понял, что мы упёрлись в производительность Stock service и приходит понимание, что надо масштабироваться. Поднимаем рядом ещё одну машинку и получается, что 2 инстанса Stock service используют одну и ту же базу. Это нормально?

Basil A. Sidorovredwhite90Допустим я понял, что мы упёрлись в производительность Stock service и приходит понимание, что надо масштабироваться.
Поднимаем рядом ещё одну машинку и получается, что 2 инстанса Stock service используют одну и ту же базу.
Это нормально?Вы именно "поняли" или, всё-таки, спрофилировали ваше приложение и обнаружили дефицитный ресурс, который нельзя смасштабировать на имеющемся железе?
Это первое.

Второе.
Вы уже сделали оценку дополнительной нагрузки и можете обоснованно предположить, что СУБД не станет новым узким местом?
Или, опять-таки, "понимаете, что всё будет тип-топ"?

Ну и самое главное ...
Цель разработки приложения - решить поставленную задачу.
Если решение задачи требует использовать цать клиентов, работающих с базой вместо одного, то какие могут быть проблемы?
Вам деньги платят авторы материалов разной степени (бес)полезности или, всё-таки, (не)довольные клиенты?

Я пока на пути понимания концепции. Понятно, что в реальной ситуации иногда приходится отходить от канонов по той или иной причине. Я хочу понять противоречит это концепции или нет.

"Чтобы работало" часто можно написать по разному. Так что не считаю это достоверным показателем.

Basil A. Sidorovredwhite90Я хочу понять противоречит это концепции или нет.Концепция у микросервисов ровно одна - превращение модулей (групп модулей, подсистем) монолитного приложения в отдельные автономные приложения. Всё.

Ну то есть одну базу 2 разных микросервиса могут использовать вне зависимости занимаются они одним(являются братьями близнецами друг друга) и тем же или нет?

https://martinfowler.com/articles/microservices.html At a first approximation, we can observe that services map to runtime processes, but that is only a first approximation. A service may consist of multiple processes that will always be developed and deployed together, such as an application process and a database that's only used by that service.

Что на это скажете?