从项目开发成本和维护成本角度来看，微服务里的每个模块应当尽可能地共用同一套数据库，同一套redis缓存，以及同一套中间件，甚至很多中小型项目都采用集中式部署，而不是用微服务部署的方式。不过本文先来讨论微服务是否要共享数据库的问题。

先说下本人之前做过的一个基于微服务结构的系统，一个网上商城系统，其中包含收单支付，招商引资和线上支付模块。

1 其中每个业务模块是由一个组来开发，每个组开发的成果物是jar包，部署的时候会把含自身业务（比如支付，线上商城）的jar部署到服务器上，每个业务之间的调用是用dubbo，服务治理是用zookeeper，每个业务模块部署在多个节点上，网关是用nginx，发来的请求会经过nginx分摊到多个节点，实现负载均衡。

顺带说一句，微服务更是体现在开发方式和部署方式层面，比如是多个团队开发各自的jar包，而集中式开发是多个团队开发一个jar包里的不同业务类。微服务的部署方式是，如果某业务模块有问题，修改代码后，部署该模块对应的jar包，其它业务的jar包不动。

至于是用nginx做网关还是用gateway，用zookeeper还是nacos，模块间的相互调用是用dubbo还是openfeign，这其实都是技术层面的问题。

当然如果某项目工期定好是半年，一共才几十万，模块不复杂，那么可以把所有的业务都打成一个jar包，然后把该jar包部署在多个节点，然后用nginx做高可用的负载均衡也行，这是最节省开发成本的，至于扩展和维护成本，等这个项目做大，拉到更多的钱以后再改微服务体系也行。

2 再说数据库，数据库用oracle，这里每个业务之间的数据是私密的，比如商户模块的代码不能直接访问风控模块对应的数据表，得通过风控模块对应的远程调用接口来访问数据，而不同业务的数据表可以放在不同的oracle库里，但多个业务的数据库是放在一台oracle服务器上的。

这里有多个概念，数据表，数据库和数据库实例。比如商户风控明细表，这是数据表，对应的放在风控库里，该风控库里还存在风控规则表等相关的表，而一台oracle服务器（也叫实例）是包含多个业务类型（比如风控库，商户库）等数据库。这里也能说是数据库独立，但绝不是服务器层面上的独立。

这样做的好处是数据维护方便，比如每天只需要备份该服务器的数据，如果部署在多个数据库服务器，那么备份的工作量会成倍增加。把相关数据放在一个服务器上会有风险，但对应的策略是监听外带告警，同时做主备切换，这个代价要比部署在多个oracle节点上小很多，毕竟整个oracle服务器宕机的可能性不高。

请注意，在高并发项目里确实会把不同的数据库放在不同的实例上，这是为了提升性能，比如A数据库服务器上放了3个业务数据库，然后发现对数据库的压力太大，引入缓存提升性能无效，那么可以在其它业务数据库放在B数据库服务器上，但这也绝不是每个微服务模块有自己独立的数据库。

3 这里再说数据卷，这所谓是用docker等容器部署，把mysql数据库映射成为数据卷。

如果是自己搭建部署环境，一般不用这种做法，比如我搭建一套docker和k8s等容器环境，再把mysql数据库映射成为卷，这里其实多了一层。如果docker容器宕机，那么整个数据库里的数据都没了，事实上容器宕机的概率虽然不高，但应该是高于数据库服务器宕机。

如果是用云服务，比如系统部署到某云，然后用云上的mysql等数据库，出于节省成本的考虑，也应该在一个实例上引入更多的数据库和数据表，而不是为每个微服务开个数据库。

4 再说Redis缓存，这一般是多个业务公用一个redis实例，顶多搭建redis集群来分摊压力，而不是创建多个redis实例，毕竟维护redis服务器也要成本。

总之，理想情况下，一个项目当然是拥有的服务器越多越好，这样的话性能和容错性能高，但做项目时首先得考虑成本，即能买或租多少台服务器，然后考虑维护的工作量，然后再考虑开发的难易性，这样一来的话，很多小公司其实真未必用微服务的开发模式，一般直接用集中版的开发模式，而一些能用微服务架构的公司，也绝不是能随心所欲地使用服务器。