作者：人月神话，新浪博客同名
简介：多年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的，而消息中间件再异步方式分发消息给目标系统，同时支持重试。
消息中间件的采用
消息中间件（message oriented middleware）是指支持与保障分布式应用程序之间同步/异步收发消息的中间件。消息是分布式应用之间进行数据交换的基本信息单位，分布式应用程序之间的通信接口由消息中间件提供。其中，异步方式指消息发送方在发送消息时不必知道接收方的状态，更无需等待接收方的回复，而接收方在收到消息时也不必知道发送方的目前状态，更无需进行同步的消息处理，它们之间的连接完全是松耦合的，通信是非阻塞的，这种异步通信方式是由消息中间件中的消息队列及其服务机制保障的。
消息中间件实现了发布者和订阅者在时间、空间和流程三个方面的解耦：
- 时间解耦—－发布方和订阅方无需同时在线就能够进行消息传输，消息中间件通过存储转发提供了这种异步传输的能力；
- 空间解耦——发布方和订阅方都无需知道对方的物理地址、端口，甚至无需知道对方的逻辑名字和个数；
- 流程解耦——发布方和订阅方在发送和接收数据时并不阻塞各自的控制流程。
从消息中间件的基本功能来看，无论是点对点消息中间件还是消息代理，其体系结构都是非常清晰简单的。但由于分布式应用及其环境的多样性和复杂性，导致了消息中间件的复杂性。
当前的消息中间件仍然分为两类，一类是基于AMQP高级消息协议的，一类是基于JMS消息协议的。对于互联网使用较多的RabbitMQ，Kafka等基本都基于AMQP高级消息协议。而对于Weblogic JMS，IBM MQ则是基于JMS消息协议的消息中间件产品。
对于Weblogic而言是一个企业级的应用服务器中间件，同时Weblogic JMS也是企业级的消息中间件产品，该产品是一个企业级消息中间件产品，具备了高可靠，高可用，高扩展，高性能基础特性。支持主流的各种消息模型，消息发布订阅，消息持久化，事务处理，集群等核心特性。
消息中间件的使用场景，具体包括了如下几个方面：
- 1.消息通知：单据状态变化后的事件通知，数据传输完成后的事件通知
- 2.异步集成：服务消费方只需要将数据送到OSB即实时返回，通过异步集成实现彻底解耦
- 3.目标系统削峰：大并发数据导入而目标系统处理性能受限的场景
- 4.消息发布订阅：基础主数据通过JMS实现1对多的实时数据分发
- 5.高可靠性场景：确保在数据集成中不出现任何丢失的情况
对于采用Weblogic JMS来实现消息集成，具体过程如下图：
