blocks|key|2560568|text|这真的不重要。现代基础设施往往不关心运行同一服务的多个副本的开销。由于数据库I/O通常是一个关键的性能点，因此您可能会发现不共享数据库更易于管理，这样您就可以在专用和/或更大的硬件上使数据库承受更重的负载。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2560569|(还要考虑在专用硬件上运行数据库，而不是在Docker下运行:它们是您必须备份的东西，并且您将比应用程序堆栈的其余部分更新它们的频率低得多，因此它们的生命周期与一次性Docker容器有根本的不同。如果您使用的是提供托管数据库服务的公共云服务，并且愿意为此付费，那么这也是一个非常合理的选择。)|2560570|无论您决定什么，您几乎肯定需要使所有参数(主机、数据库、用户名、密码)都是可配置的，通常是通过环境变量。(我看到太多在源代码中硬编码了主机名的SO问题。)您应该能够在开发、测试和生产环境中使用不同的选项部署相同的映像，这些环境通常具有不同的主机名。|2560571|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

It doesn’t really matter. Modern infrastructures tend not to care about the overhead of running multiple copies of the same service. Since database I/O can often be a critical performance point, you might find it more manageable to not share a database, so that you can put databases under heavier load on dedicated and/or larger hardware.

(Also consider running your database(s) on dedicated hardware, not under Docker: they’re the one thing you must back up, and you’ll update them much less often than the rest of your application stack, so their lifecycle is fundamentally different from a disposable Docker container. If you’re using a public cloud service that offers a managed database service and are willing to pay for it, that can also be a very reasonable option.)

Whatever you decide, you almost definitely need to make all of the parameters (host, database, username, password) configurable, usually via environment variables. (I see too many SO questions that have host names hard-coded in source code.) You should be able to deploy the same image with different options in development, test, and production environments, which will generally have different host names.

blocks|key|2560606|text|是的，在同一台服务器上有多个服务是可以的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2560607|部署配置应根据您的运营需求(成本、性能监控等)进行指导只要服务是解耦的，您就可以根据操作需要自由地移动数据|2560608|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Yes it is ok to have multiple services on the same server.

The deployment configuration should be guided by your operational needs (cost, performance monitoring etc.) as long as the services are decoupled you'd have the freedom to move the data around based on your operational needs

blocks|key|2350076|text|好的，你可以考虑这些：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2350077|1)如果你的服务不关心你的数据库服务器，我的意思是，对于服务A，它必须是MongoDB，服务B必须是Ms.+server，等等。|offset|length|style|BOLD|2350078|然后，您可以使用此设置：|2350079|一个数据库服务器->，具有多个数据库->，每个服务一个数据库。|2350080|2)但是，如果你觉得这很重要，就像我下面描述的那样：|2350081|服务A+->+Postgres|2350082|服务B+->+Postgres|2350083|Service+C+->+Ms.+Server|2350084|服务D+->+MongoDB|2350085|然后，您将有3个数据库服务器，其中服务A和B将共享相同的Postgres数据库服务器(包含2个数据库，一个用于服务A，一个用于服务B)，并且服务C将具有1个Ms.服务器(包含1个数据库)以及服务D+MongoDB服务器(包含1个数据库)。|2350086|通常，当您与不同的团队(负责处理每个服务)一起工作时，您会发现这种情况，每个团队都决定自己的选择。|2350087|entityMap^0|0|8|1K|0|0|C|0|0|V|0|0|Q|0|0|F|0|0|F|0|0|N|0|0|E|0|0|3B|0|0|1D|0^^$0|@$1|2|3|4|5|6|7|11|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|12|8|@$D|13|E|14|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|15|8|@$D|16|E|17|F|G]]|9|@]|A|$]]|$1|J|3|K|5|6|7|18|8|@$D|19|E|1A|F|G]]|9|@]|A|$]]|$1|L|3|M|5|6|7|1B|8|@$D|1C|E|1D|F|G]]|9|@]|A|$]]|$1|N|3|O|5|6|7|1E|8|@$D|1F|E|1G|F|G]]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1H|8|@$D|1I|E|1J|F|G]]|9|@]|A|$]]|$1|R|3|S|5|6|7|1K|8|@$D|1L|E|1M|F|G]]|9|@]|A|$]]|$1|T|3|U|5|6|7|1N|8|@$D|1O|E|1P|F|G]]|9|@]|A|$]]|$1|V|3|W|5|6|7|1Q|8|@$D|1R|E|1S|F|G]]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1T|8|@$D|1U|E|1V|F|G]]|9|@]|A|$]]|$1|Z|3|-4|5|6|7|1W|8|@]|9|@]|A|$]]]|10|$]]

Well, you can consider these:

1) If your service doesn't care about your database server, I mean like, for Service A it must be MongoDB, Service B must be Ms. SQL Server, etc. 

Then you can go with this setup:

One Database Server -> with, Multiple Databases -> where, One Database for each Service.

2) But, if you find it does matter, as I describe below:

Service A -> Postgres

Service B -> Postgres

Service C -> Ms. SQL Server

Service D -> MongoDB

then you will have 3 database servers where Service A &amp; B will share the same Postgres database server (containing 2 databases, one for Service A, one for Service B) and Service C will have 1 Ms. SQL Server (containing, 1 database) also Service D MongoDB server (containing 1 database).

Usually, you will find this case while you are working with different teams (which handle each service) and each team decides on their own choices.

Is it good practice to have multiple services connect to the same database server but each having their own database. 
I guess having one Postgres instance is better than each service/container having their own instance. 

My question is that should each service:

<ol>
<li>run in their own container with db server instance in the same container</li>
<li>run in their own container and the db for that service run on a separate container just for the db (multiple db containers/one per service)</li>
<li>one db SERVER, multiple databases, one container for all databases and all services connect this container/db server</li>
</ol>

I understand that each service should have their own db, but does that also means they should be completely decoupled even server wise.

I guess the reason I want to have one db SERVER is so that resources are not "wasted" as multiple instance of db server running 

I also understand that having one server will mean that all services will coupled hardware wise

multiple micro services sharing same database SERVER (One container, multiple dabases)

数据库

服务器

MongoDB

容器

将多个服务连接到同一数据库服务器，但每个服务都有自己的数据库，这是一种好的做法吗？我想有一个Postgres实例比每个服务/容器有自己的实例要好。我的问题是，每个服务是否应该：在自己的容器中运行，数据库服务器实例在同一容器中运行在自己的容器中运行，该服务的数据库在单独的容器上运行(多个数据库容器/每个服务一个)一个数据...

问多个微服务共享同一个数据库服务器(一个容器，多个数据库)
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问多个微服务共享同一个数据库服务器(一个容器，多个数据库)EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问多个微服务共享同一个数据库服务器(一个容器，多个数据库)
EN