微服务架构下如何解耦，对于已经紧耦合下如何重构？ _微服务架构

文章插图

作者：人月神话，新浪博客同名
简介：多年SOA规划建设，私有云PaaS平台架构设计经验，长期从事一线项目实践

今天准备谈下微服务架构下各个微服务间如何解耦，以及对于已经紧耦合的微服务如何进行重构。在谈这个内容前，可以先看下我前两天发布的微服务模块和粒度如何划分才更加合理的一篇文章，这篇文章对于微服务拆分有比较详细的描述。
可以参考：中台规划中微服务粒度究竟应该如何划分？你可以从以下几点考虑
要明白实际上微服务后续出现的诸多问题往往都是一开始微服务模块划分就不合理导致，对于具体的模块划分方法和原则，我在上面文章里面给出了以下几点。

原则1：划分为<10个微服务模块
原则2：强数据关联模块不要拆分
原则3：以数据聚合驱动业务功能聚合
原则4：从纵向功能划分思路到横向分层思路转变
原则5：高内聚，松耦合的基础原则

对于具体的内容在这篇文章不再重复给出。可以看到对于微服务模块拆分更多的是属于业务建模和系统分析方面的内容，而今天谈的微服务解耦重点是想从可用的技术手段入手来谈下可用的以下解耦方法和策略。
问题综述

文章插图

最近几年对于微服务架构，企业中台构建，组件化和服务化，平台+应用构建模式，包括Docker容器化，DevOps等都越来越受到传统企业的关注，也可以看到很多企业传统架构也在朝这个目标进行演进和转型。对于微服务架构本身的优点和缺点，包括传统企业实施微服务架构的演进路线等，在我前面很多微服务架构相关的文章中都有所介绍，今天主要谈下在微服务架构下的解耦问题。
要明白，企业实施微服务架构后，原来所有内部的接口调用，内部的完整事务都会变成微服务模块间的跨域的接口服务调用，传统事务也变成了分布式事务，这些本身是增加了系统复杂度。
原来一个系统就能够完成的事情，现在要依赖底层技术组件服务，其它业务微服务模块多个Http Rest API接口调用往往才能够完成。只要其中任何一个API接口出现问题，都会直接影响到前端的业务功能使用。

微服务间的雪崩效应：在采用微服务架构后，各个微服务间存在大量的API接口服务调用，相互之间还形成了服务调用链，比如A-》B-》C，那么如果C服务出现故障就将直接影响到B服务无法正常访问和服务阻塞，同时B的故障又将进一步传导到A服务的消费和使用。

对于互联网企业实施微服务架构，其中有几个关键点。

其一就是微服务架构可以更好的进行平台的性能扩展和高伸缩要求。
其二就是互联网应用本身业务规则相对简单，模块间容易解耦。
其三就是大的互联网企业IT技术积累更强，有更好的技术能够搭建高可用的技术平台，也有更好的技术能够实现微服务架构实施后的自动化运维和监控。

而这些往往都是传统企业在实施微服务架构所欠缺的，比如有些企业一开始实施微服务架构没发现问题，结果最终上线后却发现后续的系统运维和性能监控，故障问题分析和排查等能力跟不上，无法及时响应客户需求并快速的定位和解决问题。
即前面经常说到的，传统企业的IT治理和团队技术能力跟不上，直接影响到微服务架构实施成败。
那么回到正题，今天希望讨论和分析下，企业实施微服务架构后，如何尽量减少微服务模块的耦合导致的单个微服务模块功能实现和运行故障，简单来说就是一个微服务模块中业务功能的运行，如何做到最小化的依赖外部微服务模块Http API服务接口的可用性。即使外部模块挂点，当前模块也能够正常使用，或者说能够不影响到当前模块核心功能的使用。
对于该问题，我们可以分开从几个方面进行讨论。
同步调用转为异步调用一说到解耦，我们一定会首先想到消息中间件来实现异步，即将同步转为异步，通过异步来实现解耦。我们可以先想消息发送给消息中间件，只要消息中间件是高可用性的没有宕机，整个接口集成过程就是OK的，而消息中间件再异步方式分发消息给目标系统，同时支持重试。
消息中间件的采用