几种不同的微服务数据库架构设计方案

总DB的架构设计

优点：  

在软件开发的初期，所有微服务的开发只需要进行一次数据库的开发，大幅提高开发速度。单一数据库的开发、维护都易于操作。

缺点：

开发时间耦合——例如，一个负责订单服务的开发者需要和其他服务的开发者协调模式发生的变化，因为其他服务也要访问同样的表。这种耦合和额外的协调工作会拖延开发工作的进展。

运行时间耦合——由于所有的服务访问同一数据库，他们便可能会互相干扰。例如，如果长时间运行的客户服务事务锁定了订单表，那么订单服务就会被阻塞。

系统容错性下降——由于只有一个数据库，整个系统的所有数据交互都要通过这个数据库进行，一旦某个微服务发生错误，数据库发生了阻塞，那么其他没有错误的微服务都将因为数据库阻塞从而无法正常运行。

单一数据库可能满足不了所有服务的数据存储和访问需求。

稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉。

扩展性不够：无法满足高并发情况下的业务需求。

分DB的架构设计

优点：  

数据库服务简单，每个专用数据库只关注一个业务功能。

每个微服务可由不同团队开发。每个微服务配套一个数据库，因此可由不同的开发团队进行开发，可大大提升开发效率。

数据库可根据不同的微服务类型进行选择，例如需要大型的数据管理时使用oracle数据库，若只管理少许数据时可使用Mysql数据库，甚至是SQLlite数据库，根据需求去选择数据库。

各个服务之间相互独立，若某一个或者几个服务发生阻塞时，不会对其他的服务造成影响，在一定程度上保证系统全局大部分功能的正常运行。

缺点：  

运维开销

更多的服务也就意味着更多的运维，产品团队需要保证所有的相关服务都有完善的监控等基础设施，传统的架构开发者只需要保证一个应用正常运行，而现在却需要保证几十甚至上百道工序高效运转，这是一个艰巨的任务。

DevOps要求

使用微服务架构后，开发团队需要保证一个Tomcat集群可用，保证一个数据库可用，这就意味着团队需要高品质的DevOps和自动化技术。而现在，这样的全栈式人才很少。对于一个完整的系统有若干个微服务对应的数据库，会大量需求这类人员。

隐式接口

服务和服务之间通过接口来“联系”，当某一个服务更改接口格式时，可能涉及到此接口的所有服务都需要做调整。

重复劳动

在很多服务中可能都会使用到同一个功能，而这一功能点没有足够大到提供一个服务的程度，这个时候可能不同的服务团队都会单独开发这一功能，重复的业务逻辑，这违背了良好的软件工程中的很多原则。

分布式系统的复杂性

微服务通过REST API或消息来将不同的服务联系起来，这在之前可能只是一个简单的远程过程调用。分布式系统也就意味着开发者需要考虑网络延迟、容错、消息序列化、不可靠的网络、异步、版本控制、负载等，而面对如此多的微服务都需要分布式时，整个产品需要有一整套完整的机制来保证各个服务可以正常运转。

事务、异步、测试面临挑战

跨进程之间的事务、大量的异步处理、多个微服务之间的整体测试都需要有一整套的解决方案，而现在看起来，这些技术并没有成熟。 

通用DB与分DB结合的结构设计

优点：  

这种结构将上文中提到的两种方法进行结合，对于比较基础和通用的数据将他们放入通用数据库中，可以减少使用这些基础数据时的重复开发，并且在后期的运维开销也会相应降低。

缺点：  

共用一个数据库的微服务之间会具备上文提到的单一DB架构设计的缺点。

分DB的微服务之间，会具有分DB架构设计的缺点。

总结： 单一DB与总DB的优缺点与微服务的属性和数量息息相关，因此不能简单地断定哪个方法是比较出色的，应该与实际开发相结合。

 

通用DB加上负载均衡与分DB结合的结构设计

优点：

这是对多个微服务共用一个数据库的改良，当某个服务发生错误引起DB阻塞时，其他的服务可以通过后备数据库进行正常运行。

缺点：

后备数据库与通用数据库之间的数据一致性需要保证，这将会消耗一定的硬件资源。