与单一架构相比，微服务架构具有许多优势，如个体服务更小、凝聚力更强、业务职责更清晰、可重用性更强、独立部署和发布等。从软件开发的角度来看，灵活性和效率将大大提高.

然而，微服务架构本质上是一种分布式系统架构。每个服务需要相互协作来完成产品需求。业务数据的分散性使得服务需要通过集成来完成协同工作。那么，问题来了，应该采用什么样的整合？应该遵循哪些原则？设计如何尽可能保证不同服务之间数据的一致性？

第一，混乱的现实

建议将REST作为微服务架构中服务间同步通信的一种方式。对于非实时需求，可以基于事件实现异步协作。这个原理很简单，也很容易实现。但是，仅仅遵循这个原则，我们很难走上微服务的道路。

在一些被称为微服务架构的系统中，服务拆分一开始并没有太大的问题，但是随着逻辑的不断扩展和跨服务数据交换场景的增加，这个简单的原则很难指导日常决策，甚至会引发一些新的问题。举几个例子。

1.1服务周期依赖性

在某些场景下，服务A依赖于服务B，会调用服务B的API，在另一些场景下，服务B也需要服务A的数据，会通过调用服务A的API来实现，从单个实现层面来说，按需获取数据非常方便，可以达到业务想要的效果。但长期来看，两个服务之间的耦合越来越紧，未来新需求的实现成本会越来越高，成为技术债。

1.2第三方系统集成到业务服务中

在一些业务场景中，当前产品所需的业务数据需要从几个第三方系统中获取，经过一些计算后整合甚至使用。之前的一些项目在前期实现的时候，都是从第三方系统获取数据，经过处理后直接写入业务数据库，然后集成的代码直接写入业务服务。看起来问题不大，只要代码隔离好就行。

但事实上，后期发生了一些棘手的问题，迫使我们做出改变：

一些定期触发的集成任务一次只能在一个服务实例上运行。在运行期间，可能会有大量的数据读取、计算、更新、插入等操作，会短时间占用当前服务实例的大量资源。在严重的情况下，当前服务实例甚至不能正常向外界提供服务。

类似的集成以同样的方式集成到业务服务中。比如不同品牌的产品库存会从多个第三方系统获取，业务服务会变得臃肿。

集成端的一些变化直接影响业务服务，比如API的升级，只能通过重新升级部署业务服务来完成。

1.3集成接口不是等幂的。

无论是在第三方系统集成还是内部服务调用过程中，不平等的接口都会造成数据不一致的问题。最典型的场景是服务A调用服务B的接口更新或写入数据，服务B处理成功。但是，由于网络原因，服务A没有收到服务B的响应，服务A重试调用接口。此时服务B无法继续业务流程，因为接口不相等返回异常响应。

理想很丰满，现实很骨感，大部分项目都是从一个干净热情的建筑的梦想开始的，开发工作也没有想象中的顺利。随着项目人员的流动，交付压力大，人员能力不足等等，架构逐渐朝着大家都没有预料到的方向发展，技术债台高筑。攻城狮在奋力追赶进度的同时，只能寄希望于欠债。

第二，整合原则

当问题发生时，建筑师可以站出来说这个设计太差了。怎么能这样呢？事后诸葛是我们积累经验的重要手段。从高昂的技术债，从疲于救火的线上问题，从新的需求，都找不到合理的解决方案.我们一直在总结经验。有哪些可以先走的建筑设计原则，避免再次落在同一个地方？

2.1单向依赖

微服务拆分之初，定义了每个服务的上下游关系。我们可以将上游和下游服务的依赖关系定义如下：

下游服务可以直接依赖上游服务，下游服务可以通过上游服务提供的API同步读写上游服务的数据。

上游服务不依赖于下游服务。如果上游服务数据的状态变化会对下游服务产生影响，下游系统可以通过发布域事件来监控事件，并采取相应的行动。

2.2服务之间只有冗余的参考信息

微服务的各种域实体之间存在各种关系。当域实体A依赖于域实体B的信息时，通常需要在域实体A中保存一些域实体B的副本信息，这个副本信息应该包含哪些信息？

例如，域实体A是订单，域实体B是客户。每次客户查询订单信息，都要求同时查到客户的姓名、性别、手机号码。在订单服务中冗余这三个关键信息就能轻松满足需求，一切听起来都那么美好。

但是，如果这三个关键信息都可以更改，那么问题就来了。如果域实体B中的信息被更新，域实体A中的信息是否应该被更新？如果不更新，数据会不一致。如果更新无缘无故增加复杂度，很可能会出现循环依赖。

因此，在无法确定数据变更的确切情况时，只保留副本中的引用信息是最安全的，需要完整信息时可以通过引用查询相关信息。

2.3为第三方系统构建外观服务

面对第三方系统集成，应该在系统集成的过程中给予更全面的考虑。一般我们控制不了第三方系统。一旦集成出现问题，

需要沟通解决方案，排期开发，联调测试等等，修复周期很长。

另一个问题是第三方系统通常采用的技术栈或集成方式可能和我们的系统完全不同。比如它可能是个非常老旧的系统，提供的接口是基于XML的SOAP;再比如它可能无法提供API，只能通过导出文件到某个SFTP或发送邮件的方式进行集成……

为了让第三方系统集成产生尽量小的影响，我们倾向于构建外观服务来隐藏第三方系统实现的细节，通过外观服务对第三方系统的功能进行包装，提供和当前系统更加一致的集成方式。我们可以把外观服务和第三方系统看做是一个整体，那么第三方系统的集成对于当前系统内的服务来说，服务间的集成就可以和内部服务一样处理。而对于第三方系统集成相关的细节内容被隔离在外观服务中，第三方系统集成的变化，只需要修改外观服务就可以了。

2.4 集成接口实现要考虑幂等性

这个原则非常简单，但实现过程中非常容易被忽略，如果不在设计好的测试用例中，测试过程中也很难发现问题;多数情况下是到了线上，用户使用的真实场景才会发现问题，这时已经产生了业务影响。

因此在涉及集成的接口中，要特别关注，业务上是否要求接口的幂等性，接口不幂等的情况下业务是否能够正常的流转。

2.5 契约测试

服务提供的接口通常不只有一个消费者，不同消费者关心的信息往往可能也不一样，随着服务数量的增加，在没有契约测试的情况下，很有可能发生因为一个需求修改了当前服务接口的实现，而影响其他已有功能。而往往这个问题直到全面回归的时候才能完全发现，甚至可能发生因改动范围很小，回归不够，在上线前也难以发现。

契约测试可以很好的解决这个问题，一方面测试前置，尽早提供反馈，另一方面也起到了架构守护的作用。

小结

系统集成是分布式系统中一定会谈及的问题，而且是个大问题，因为它直接影响到当前系统的架构，一个微不足道的改动很可能就破坏了整个系统架构的原则，久而久之原则便形同虚设。

微服务架构也不例外，在缺少架构约束的情况下，只图一时之快的实现往往会葬送了微服务的优势，一个个微小的不合理改动会逐渐将整个架构大厦摧毁，所谓千里之堤，溃于蚁穴就是这个道理。

因此，在微服务架构设计之初，我们就要在团队内建立一些原则，明确系统间集成需要遵守的一些规范，并且在实践过程中定期review，必要时可以采用一些架构守护的辅助工具，来保护架构的健康度。