微服务架构下如何考虑组件解耦(11.26)

最近几年对于微服务架构，企业中台构建，组件化和服务化，平台+应用构建模式，包括 Docker 容器化，DevOps等都越来越受到传统企业的关注，也可以看到很多企业传统架构也在朝这个目标进行演进和转型。对于微服务架构本身的优点和缺点，包括传统企业实施微服务架构的演进路线等，在我前面很多微服务架构相关的文章中都有所介绍，今天主要谈下在微服务架构下的解耦问题。

要明白，企业实施微服务架构后，原来所有内部的接口调用，内部的完整事务都会变成微服务模块间的跨域的接口服务调用，传统事务也变成了分布式事务，这些本身是增加了系统复杂度。原来一个系统就能够完成的事情，现在要依赖底层技术组件服务，其它业务微服务模块多个Http Rest API接口调用往往才能够完成。只要其中任何一个API接口出现问题，都会直接影响到前端的业务功能使用。

对于互联网企业实施微服务架构，其中有几个关键点，其一就是微服务架构可以更好的进行平台的性能扩展和高伸缩要求，其二就是互联网应用本身业务规则相对简单，模块间容易解耦；其三就是大的互联网企业IT技术积累更强，有更好的技术能够搭建高可用的技术平台，也有更好的技术能够实现微服务架构实施后的自动化运维和监控。而这些往往都是传统企业在实施微服务架构所欠缺的，比如有些企业一开始实施微服务架构没发现问题，结果最终上线后却发现后续的系统运维和性能监控，故障问题分析和排查等能力跟不上，无法及时响应客户需求并快速的定位和解决问题。

即前面经常说到的，传统企业的IT治理和团队技术能力跟不上，直接影响到微服务架构实施成败。

那么回到正题，今天希望讨论和分析下，企业实施微服务架构后，如何尽量减少微服务模块的耦合导致的单个微服务模块功能实现和运行故障，简单来说就是一个微服务模块中业务功能的运行，如何做到最小化的依赖外部微服务模块Http API服务接口的可用性。即使外部模块挂点，当前模块也能够正常使用，或者说能够不影响到当前模块核心功能的使用。

如何做到这点？

将同步调用转为异步调用： 一说到解耦，我们一定会首先想到消息中间件来实现异步，即将同步转为异步，通过异步来实现解耦。我们可以先想消息发送给消息中间件，只要消息中间件是高可用性的没有宕机，整个接口集成过程就是OK的，而消息中间件再异步方式分发消息给目标系统，同时支持重试。这是我们最场景的解耦方法。

将同步接口调用转为本地消息暂存： 这个类似消息中间件的功能，举例来说我们设计了一个同步发送订单到ERP系统的接口，如果在同步实时调用这个接口服务的时候出现异常，那么我们可以首先将消息存储到本地，然后设置定时任务和重试机制，通过重试方式将消息发送到目标系统。即对于业务功能来说不用关心实时是否发送成功，而由业务系统自身机制来完成消息发送的重试。

而要做到这点，在接口功能设计时候，最好要做到单据业务完整性校验接口和实际的数据发送接口分离，即先调用接口进行完整性校验，在校验没有问题后再进行消息发送。以确保最终发送的消息不会因为数据完整性的原因导致无法发送成功。

查询数据本地化缓存： 对于实时查询类接口，将查询的基础数据进行本地化缓存，即如果在实时查询出现异常的时候，我们可以直接查询本地缓存的数据，减少对业务功能使用的影响。比如查询供应商接口服务，如果主数据系统提供的接口出现异常，我们可以直接查询本地缓存的供应商数据。这种模式对于变更不频繁的数据基本都适应，同时本身也减少实时调用接口带来的性能损耗。

规则检查后移或补偿： 对于在集成过程中，也经常会出现需要实时调用其它系统提供的业务规则校验类服务的情况，比如在提交报账单的时候，需要实时的进行预算检查和扣减，如果预算系统提供的接口服务有问题，那么就会导致报账单无法正常提交或提交出现异常。对于这种情况，可以考虑的是规则检查后移，即仍然允许单据提交，在流程启动并流转在进行审批前进行规则检查，或在最终单据导入前进行规则检查。这种情况适合业务规则检查在通常情况下都能够大概率通过的场景。以提升业务用户提交单据的交互友好性。

适量考虑数据落地方式的数据集成： 在微服务架构实施模式下，实际上我们是不建议数据落地的，因为数据落地容易造成数据的不一致性，但是在企业IT能力不足够成熟的情况下，还是需要考虑在整体微服务架构实施过程中，对于变化不频繁的数据适度落地到微服务模块本地。这样本身可以减少实时的业务接口服务调用，增加单个微服务模块的可用性和可靠性。

在ESB服务总线上启用缓存： 对于实时接口服务调用，当然也可以考虑在ESB服务总线上启用缓存能力，即对于调用过的接口，在同样参数重复调用的时候能够走缓存，这样即使在源端业务系统不可用的情况下，也不好影响到当前接口服务的成功调用。