Начал читать про микросервисы. Как я понял микросервис это нечто автономное, общающееся с внешним миром по сети. Например через 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.

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

Вообще мой вопрос связан с местом хранения состояния. База это не средство коммуникации, а средство хранения состояния. Может в таком случае два однородных сервера использовать одну и ту же БД ?

забыл никВот жеж развели тут

В каноническом понимании микросервисов, один микросервис = bounded context из терминологии DDD Почитать можно тут - https://martinfowler.com/bliki/BoundedContext.html

Один Bounded context = одно хранилище состояния. Если кто-то другой пишет в те же таблицы - значит хреновые у вас микросервисы.

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

Ну и отвечая на непонятный вопрос ТС - да, если микросервис должен масштабироваться и работать на нескольких нодах - то никто не мешает ему писать в одну и ту же базу, почему нет? Смысл всей этой свистопляски в том, чтобы можно было задеплоить микросервис не ожидая каких-либо других приложений\сервисов. А в случае с разделяемой базой такое случится наверняка

Ну хоть один человек ответил на мой вопрос.

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


А что будет?

Basil A. Sidorovredwhite90Ну хоть один человек ответил на мой вопрос.Только ответ неправильный - считать таблицу "единицей состояния" ... Ну, "это мы дадим в конце".

Откуда в Вас злости то столько? перед кем Вы пытаетесь самоутвердиться? я ж пришёл с посылом, что я этого не знаю, но хочу узнать. Пока что Ваши ответы слабо коррелируют с тем, что я спрашивал

забыл ник
Ну и отвечая на непонятный вопрос ТС - да, если микросервис должен масштабироваться и работать на нескольких нодах - то никто не мешает ему писать в одну и ту же базу, почему нет? Смысл всей этой свистопляски в том, чтобы можно было задеплоить микросервис не ожидая каких-либо других приложений\сервисов. А в случае с разделяемой базой такое случится наверняка

Вот что пишут(лучше пройти по ссылке, чтобы прочитать - тут совсем некрасиво отформатировалось):

https://stackoverflow.com/a/30742466/2674303 Multiple applications accessing the same database tables can be (and usually is) a concurrency nightmare. Just adding a version column to tables does not help because each application may use different concurrency management mechanisms. Common problems encountered when sharing a database across applications (assuming read-write access for all and in no particular order):

Concurrency mismatch: Imagine one application using optimistic locking throughout, another using pessimistic locking and a third using no locking at all (since all are maintained by different teams). Even if there is a central architecture group handing out good application architecture advice to everyone, developers can do whatever they like and end up causing concurrency hell.
Deadlocks: Imagine one application using SERIALIZABLE isolation level for all transactions and performing long-running operations on the database, causing queues, deadlocks and timeouts. Even if other applications do not corrupt data, they may end up seeing too many errors due to deadlocks and timeouts, reducing their usefulness.
Data validity: It is common for developers to use in-memory caches for storing fixed or slow-changing data to save repeated database roundtrips. In a JPA application backed by Hibernate, developers could use a second-level cache. However, if another application updates the database, the cache would be holding stale (and therefore inaccurate) data.
Data integrity: Different applications may use different parts of the data. If all are allowed to update the common data independently, how is referential integrity maintained? What about business rules? Will they have to be duplicated across the applications?
Team communication overhead: Each team has to keep the other teams informed about changes they need to make to the schema so that they do not step on to each others' toes. This may even reduce agility if other teams do not agree with changes required by a team or if priorities cannot be aligned.
Schema errors: What happens if someone deletes, renames, moves or archives tables or columns required by an application?
Access control: If the underlying data is sensitive and requires authentication and authorization, access control checks will have to be duplicated across the applications.
Ownership: Who owns the common tables becomes a challenge as each team may have its own stakeholders, roadmap, constraints and priorities.
Portability: If the underlying database (vendor and type) has to be changed some day, all applications will need to be changed.
Auditing and versioning: If common data needs to be audited and/or versioned (multiple versions of data rows), the code will either have to be duplicated across applications or built into the database (which may not be easy within the database, for example, knowing which application user changed a record). If done within the database, portability is affected again because the syntax may vary from one database vendor to another.
Database-specific optimizations: Some scenarios (for example, reporting) may require native queries or other optimizations that may not be possible or too hard to perform using an ORM technology like JPA. If multiple applications require access to optimized queries, such functionality will either have to be built into the database (stored procedures) or duplicated across the applications (in possibly different ways).
Archival and partitioning: Different applications may have different archival and partitioning requirements. Who makes sure that everyone's needs are met equally?
Standardization: If different teams are allowed to manage the common database objects on their own, how are things such as data dictionary, naming conventions, etc. managed? A table that is used by different teams may have differently (and mostly annoyingly) named columns, constraints, etc.
A better approach is to expose the common database tables using a service. The service can keep things consistent and controlled at all times. A common team handling changes to the service can ensure that unexpected changes are minimized and also communicated to all affected parties in a timely manner.

Мужик годно объясняет. Всё с нуля, по делу и , главное, понятно изъясняет мысли.
[youtube=

Андрей Панфиловredwhite90Мужик годно объясняет. Всё с нуля, по делу и , главное, понятно изъясняет мысли.И в каком месте это отвечает на ваш вопрос? Первые пять минут презентации уделены не то что неочевидному, а даже спорному утверждению, что если мы возьмем нормально работающее приложение, разрежем его на куски, которые между собой будут общаться теперь не через память, а через HTTP, то у нас, "внезапно", приложение начнет лучше масштабироваться (примерно как здесь: https://blog.risingstack.com/why-you-should-start-using-microservices/ ). А остальные 40 минут посвящены тому, как героически решать проблемы, возникшие после такого вот неочевидного подхода.

В целом по теме микросервисов я имел ввиду.

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

Андрей Панфиловмне так кажется что с обоими способами доказательства, что микросервисы - это всегда хорошо, у вас возникнут проблемы



Я согласен, что это далеко не серебряная пуля. Есть проблемы, много проблем, но бывают ситуации(во всяком случае я в это верю) когда микросервисы могут быть подходящим вариантом. И не знакомиться с ними только потому, что в них есть какие-то там проблемы на мой взгляд глупо