设计微服务时应考虑一些分布式数据管理方面的问题

当单块系统转向微服务架构时，数据库将变得非常复杂，因为每个微服务所拥有的数据对当前微服务来说是私有的，只能通过提供的API进行访问，封住数据可确保微服务松耦合、独立演进。基于微服务的应用程序通常混合使用 SQL 和 NoSQL 数据库，即所谓的混合持久化方式，虽然混合持久化架构有很多优点，但在设计微服务时应考虑一些分布式数据管理方面的问题：

（1）如何维护多个服务之间的事务一致性：可以使用分布式事务，也称为两阶段提交（2PC）。然而，许多现代技术，如大多数 NoSQL 数据库，都不支持 2PC。另一中解决方案是使用消息队列来解决微服务数据一致性问题，将消息与业务解耦，但一次消息发送需要两次请求，业务处理服务需要实现消息状态回查接口。

（2）微服务的共享库如何管理：在实际的项目中，产品中的微服务无法避免的会对某些库产生依赖；共享某些库。可采用四种方案，管理微服务间的共享

①将多个微服务会共享的代码，置入在一共享的项目中。在编译的时候，共享的代码便与特定的微服务的代码编译在一起。

②各微服务间共享著编译，构建JAR包。

③将各微服务都会用到模块，复制到各个微服务中。此方案虽然违背了DRY，但却使得每个微服务维持了自身的边界上下文，而使得产品中的数百个或甚至数千个微服务间的依赖降低；产品中的数百个或甚至数千个微服务间的依赖越少，各微服务便得以更高效的方式进行开发、测试、发布。

④将共享库作为微服务发布。

（3）如何从多个服务中检索数据：当数据从多个微服务的数据拿取时，将带来复杂性，可采用四种方案，从多个服务中检索数据，可通过不同的业务常见选择不同的方式：

①直接到各微服务所拥有的数据库中获取数据，并写到负责生成报表的服务所拥有的数据库或数据仓储中。此设计方案主要的问题是：破坏了原微服务的边界上下文 (Bounded Context)，使得原微服务无法独立自主的修改自身所拥有的数据表结构；原微服务若有任何数据表结构上的修改，将会影响到生成报表的服务所拥有的数据库或数据仓储。

②负责从多个服务检索数据的服务，经由各微服务所提供的 REST API，取得所需的数据，并写至自身所拥有的数据库或数据仓储。此设计方案，藉由 REST API，维持了各微服务的边界上下文 (Bounded Context)，但，却存在著其他的问题：

性能上的问题：当负责生成报表的服务需同时向上百个微服务获取数据时，则就表示将会有上百个远程调用会发生。所以，有可能负责生成报表的服务的某一个数据请求，已经达到了 Time Out，但有的微服务所提供的数据，还尚未送至负责生成报表的服务。

数据量的问题：当负责生成报表的服务向微服务获取大量的数据时，大量的数据将造成大量流量，所以，也有可能对负责生成报表的服务的某一个数据请求，造成 Time Out。

③在夜间执行批处理至各微服务所拥有的数据库中获取数据，并写至负责生成报表的服务所拥有的数据库或数据仓储中。也存在著破坏了原微服务的边界上下文的问题；使得原微服务无法独立自主的修改自身所拥有的数据表结构。原微服务若有任何数据表结构上的修改，将会影响到生成报表的服务所拥有的数据库或数据仓储。数据的时效性也会是个问题，无法获得实时的各微服务所拥有的数据库中的数据。

④当各微服务所拥有的数据库发生变更时，便会产生一个事件。此事件便会使得生成报表的服务去处理此事件；至发生数据库变更的微服务获取所变更的数据，并写入其所拥有的数据库或数据仓储中。此设计方案不仅维持了各微服务的边界上下文，更使得需要从多个服务检索数据的服务所拥有的数据库或数据仓储，获得实时的各微服务所拥有的数据库中的数据；拥有数据的时效性。