弘康人寿基于 RocketMQ 构建微服务边界总线的实践

随着互联网+和平台化战略的兴起，各个行业的 IT 系统都在向互联网架构发展，涉及的主要技术包括微服务、消息和弹性计算等，采用微服务架构实现服务高内聚、低耦合，经过异步消息完成交易快速响应和高并发。因为微服务和消息是企业应用架构中用的比较多的，故但愿经过本文探讨如下问题：

• 企业服务总线（ESB）是否真的过期了？
• 为何 RocketMQ 是企业服务总线的最佳技术方案之一？
• 如何设计企业微服务架构演进路线图？

SOA 架构演变史

阶段 1：企业服务总线 ESB

当单体应用拆分红多个应用后，应用服务之间须要相互调用，而 ESB 恰好是用来解决服务调用方和服务提供者之间的点对点链接关系的，点对点链接不如你们都连到一个总线上，这样就会实现物理位置、传输协议等多个方面透明。ESB 核心技术就是 MQ 消息中间件，服务一旦接入总线，相互之间紧耦合调用变成了发消息和收消息，以下图所示：

这样作的好处以下：

一、服务之间的点对点变成了总线链接，服务提供方和调用方接入总线后指定相同的队列名便可完成单向通信。固然双向通信也是能够实现的，好比 IBM 的 MQ 产品在推 ESB 解决方案时就提供发消息和收消息自动配对功能，实现机制是经过消息相关标识 CorrelId 字段，将一个消息与另外一个消息相关，或将一个消息与应用程序正在执行的其余工做相关，使用这个机制能够完成消息发送和接收的 request-reply 模式，达到实时调用响应效果，从而使一些不适合异步消息调用的场景也可使用 ESB。

二、服务之间负载均衡转移到总线。服务调用方能够是多个，共同发送消息，服务提供方也能够是多个，共同接收消息,所以只要总线自己是负载均衡的，那么就不存在负载均衡问题。

三、总线是服务之间的缓冲器，确保请求消息积压不会冲垮被调用方，同时能保证服务调用方的体验。

综上，ESB 企业服务总线经过 MQ 消息中间件实现 SOA 架构的两点核心功能：服务注册发现和负载均衡，服务接入 ESB 就完成了“注册”，经过指定消息队列名实现“服务发现”，而负载均衡问题经过总线自己是否负载解决。因为 ESB 优点明显，故在金融业尤为是银行业获得普遍应用，但因为早期的 MQ 消息中间件架构比较重，在高可用和高并发方面表现通常，更多关注的是消息事务性，不能彻底知足 ESB 自己的职能要求，所以当 ESB 上到必定规模后就成了整个应用架构最大的性能和故障点。

阶段 2：微服务

微服务架构出现于 2014 年，采用注册中心实现了服务注册发现、负载均衡、容错、 监控等功能，同时服务拆分粒度能够更细，服务共享和 IT 组织协做也能够更加精细化，所以微服务架构也推动了 IT 团队的专业分工和高效协做。

微服务的特征：

• 经过服务实现组件化，服务拆分粒度更细，有利于服务共享和集成 ；
• 按业务能力来划分服务和开发团队，有利于 IT 组织高效协做 ；
• 去中心化，服务与服务之间直接点对点链接，没有任何代理或负载均衡器，服务节点与注册中心采用异步心跳通信。

缺点：

• 微服务架构技术边界明显，必须经过新建方式才能完成新旧系统替换，成本较大；
• 老系统和新系统之间的对接仍旧经过传统负载均衡或网关来实现高可用，存在单点问题；
• 注册中心是微服务架构边界，随着加入服务节点数增长，注册中心会成为最大的故障点。

三、服务网格 ServiceMesh

针对微服务架构边界和新旧技术对接问题，诞生了服务网络 ServiceMesh，也称为代理边车（Sidecar），这种架构的本质是将微服务架构中的注册中心、负载均衡、故障处理等功能提取出来，单独做为一个代理进程与应用服务部署在同一机器，同时在网络通信层进行干预，实现服务的自动代理和自动发现，实际是把代理作成了微服务架构，这样不用动原来的老系统，就能够用上微服务架构的核心功能，简单高效。

服务网：

缺点：

每一个服务部署的服务器或容器上都要安装一个代理，就单个服务而言，代理是单点，一旦代理挂了，则该服务不可用，这个问题对每一个服务都存在。

ServiceMesh 要实现全部服务的互通互连，要求全部服务代理链接到注册中心，那么注册中心又成为最大故障点。

ServiceMesh 实际是微服务版本的企业服务总线，用于服务解耦和负载均衡，而 SOA 架构除了具有这些功能，还须要经过服务拆分和共享知足业务需求开发、上线、运维的快速迭代，从这个角度讲 ServiceMesh 称不上微服务架构，仅仅完成其中一部分功能。所以，
ServiceMesh 只是一个微服务架构实施的临时方案。

启示:

从单体应用到 SOA 架构的3个阶段，每一个阶段都出现了不一样的架构解决方案，经过以上分析不难看出，经过单一架构解决企业应用架构的全部问题是不可行的，所以咱们要吸收各类架构的优势，采用多种架构融合的方式寻求最佳解决方案。

弘康人寿微服务架构建设

弘康人寿 IT 系统同国内大部分保险企业相似，都是从一个单体核心系统逐步拆分发展而来，服务与服务之间没有经过 ESB 总线，而是采用传统负载均衡方式进行通信，还处于 SOA 架构演变的初级阶段。去年公司陆续在官网和增值服务领域引入了微服务架构，新官网使用的 Dubbo，增值服务使用的是 SpringCloud，这里说明一下，公司内部开发统一使用的微服务架构是 SpringCloud，因为新官网是外采的成型产品，技术架构没法改变，故使用 Dubbo ,这样的状况在国内不少企业都存在。

因此，在微服务架构实施初期咱们就意识到统一技术架构对企业来讲是有很大困难的，不一样的业务线，不一样的团队对技术架构的需求和理解不同，因此技术架构方面必定要是开放的，求同存异，不能为了架构而架构。另外一方面咱们仔细分析了公司业务结构和特色，所有放入一个微服务架构边界（注册中心）里也是不合适的，那么也就意味着微服务架构也会分红几个不一样区域，每一个业务区域链接一个注册中心，架构规划图以下：

区域1直接面向互联网，属于前置应用，区域2到5在内网，属于中后台服务，架构设计到这一步，摆在咱们面前的问题是不一样的区域有的是微服务架构，有的是旧的分布式架构，不一样架构之间都存在注册中心、负载入口等边界问题，按照传统思路各个区域使用网关或软负载统一对外提供服务，架构图以下：

在各个区域增长一个负载均衡器，每一个区域内部使用微服务或老架构进行通讯，跨区域则经过负载均衡器，因为传统的负载均衡器（如 Nginx）都存在单点问题，一旦出现宕机或阻塞，将会影响整个系统运行，因此为了分摊风险，负载均衡器也采用分区设计。

另外一方面，你们能够看到各个应用区域之间的互连互通也是很是必要的，尤为是在大数据、AI 等新科技驱动下，企业的数据化转型一个最基本的要求是全部数据可否自由流通，因此从这个角度看，上图中的负载均衡器其实是一个数据总线的雏形，我认为能够参考企业服务总线 ESB 和 ServiceMesh 的设计思想，用高可用的消息中间件取代上图中各个区域的负载均衡器。

为何 RocketMQ 是企业服务总线的最佳技术方案之一

在 SOA 架构发展的三个阶段，咱们提到了 ESB 的优点和缺点，对于 ESB 当时采用的消息中间件太重、性能差等技术问题，随着开源技术的不断发展和进步，这些问题获得有效解决，目前开源技术中消息中间件大概有 RabbitMQ、RocketMQ 和 Kafka 三种选项，网上有不少纯技术指标对比，单就 ESB 级别的应用来讲 RocketMQ 是最均衡的，而且通过阿里巴巴"双11"压力考验，性能稳定，下边从如下几个方面说明：

一、微服务架构、高性能、高可用

RocketMQ 消息中间件架构上基于微服务设计，由 NameServer 注册中心、 broker 集群、Producer 集群、Consumer 集群四部分组成，每一个部分都支持多节点扩展，broker 支持主从模式，有同步双写、异步复制两种模式。NameServer 注册中心各节点互相独立，彼此没有通讯关系，单台 NameServer 挂掉，不影响其余 NameServer，这一点比 zookeeper 轻量不少。同时 RocketMQ 底层基于 Netty 异步事件驱动通信框架，采用长链接，具备高性能、高可靠性特色。

二、单机支持上万 Topic 主题，Topic 数量增长对性能影响很小

RocketMQ 是以 Topic 做为消息通道的划分单元，不一样的业务使用不一样的 Topic 发送和接收消息，这样能够达到物理上划分消息通道资源的目的，这一点对企业服务总线很重要。
而 RocketMQ 单机支持上万 Topic，Topic 的增长对性能影响很小，这一点是 Kafka 欠缺的。

如上图，不一样的业务能够划分不一样容量的总线通道，例如日志通道能够经过分配更多的 broker 主题方式提升通道传输能力效果。

三、内存模式支持同步请求处理

通常消息中间件适合异步请求处理场景，RocketMQ 的内存模式支持消息不落盘，性能更高，这样也适用于“request-reply”同步请求处理场景。

四、延迟消息优点

RocketMQ 支持延迟消息，消息发送后可指定延迟被消费的时间，例如1小时后被消费，这一特性对于不一样系统间数据同步或对帐来讲很是实用，特别是一些老系统比较多的企业，大量的批处理都是为了这个目的，使用 RocketMQ 消息总线能够很好的治理这个问题，而不用大量使用定时任务。

五、流数据处理

对于日志流数据处理需求，RocketMQ 支持 log4j、logback 等日志异步 appender，对于其余非交易数据处理需求，也可采用异步发送+batch 模式提升数据传输效率。

六、客户端支持多语言，多 JDK 版本，兼容性好

RocketMQ Producer、Consumer 客户端支持 Java, C++, Go 语言，对于 java 语言，支持 JDK1.6 到 1.8，知足目前各企业主流使用需求，适用新旧系统。

经过以上六大特性分析，咱们认为 RocketMQ 是目前开源消息中间件中最适合企业服务总线 ESB 的技术方案，所以咱们选择使用 RocketMQ 做为链接各个系统区域的边界总线。

弘康人寿微服务边界总线架构图

咱们将应用系统的5个区域链接到 RocketMQ 边界总线，这样全部跨区域的数据传输经过总线完成，每一个区域（2-5）内部的服务与服务交互仍采用微服务架构。对于区域1属于前置层，直接面向互联网，采用微服务架构的意义不大，故在区域1的每一个应用程序上绑定一个 RocketMQ 客户端，负责收消息和发消息，这也得益于 RocketMQ 良好的 JDK 版本支持。

对于区域2-5，每一个区域会部署2个以上的 RocketMQ 代理微服务，对区域内部提供收消息和发消息服务，避免过多 MQ 客户端链接到总线，为总线 NameServer 减负。对于一些对于性能要求比较的业务场景，也容许区域内的系统直接客户端方式链接到总线，提升处理效率，但这种状况很少。总体架构达到的最终效果为：

• 除区域 1 采用传统负载负载均衡方式对终端用户提供服务外，区域 2-5 各个系统均无需使用传统负载均衡，消灭单点问题。
• RocketMQ 集群只是做为一种边界总线，不会与太多的系统链接，咱们初步估算一下须要链接到总线的客户端不会超过 100 个，这对 RocketMQ 集群 几乎没有什么压力，因此架构设计上保证了边界总线是轻量级的，同时也保证了其稳定性和处理性能，前面咱们讲到在 ESB 那个阶段大多数企业实施到最后阶段都会以为 ESB 太重，除技术自己问题外，认为 ESB 应该做为全部系统间调用的通道也是一种错误，这无形加剧了 ESB 的负担。
• 遵循“统一边界总线，差别化服务治理”的架构设计思想，各个区域的微服务架构能够不统一，好比区域2可使用 SpringCloud1.5.x 版本，区域3可使用 SpringCloud2.x 版本，区域4可使用 Dubbo，区域5可使用低成本的 ServiceMesh，只要各个区域内的版本统一便可。
• 有利于各个区域内的技术升级换代。全部的技术升级换代都是区域性的，随着业务的发展，咱们能够不断拆分各个业务区域，这样技术升级风险更小，也更平滑。

最后，回答一下刚开始提出的三个问题：

Q1. 企业服务总线（ESB）是否真的过期了？

A1. 企业服务总线（ESB）采用的核心技术是 MQ 消息中间件，对于点对点服务解耦有不可超越的优点，两个服务点对点须要处理负载均衡、容错、超时等问题，可是经过 ESB 消息管道后这些问题迎刃而解，这是 ESB 最大的魅力，因此我认为 ESB 没有过期，在技术不断进步的今天，各个企业能够尝试搭建本身的轻量级 ESB 边界总线。

Q2. 为何 RocketMQ 是企业服务总线的最佳技术方案之一？

A2. 结合本文中描述 RocketMQ 六大优点，符合这六点才能知足互联网时代的总线应用要求。

Q3. 如何设计企业微服务架构演进路线图？

• 首先进行应用架构分区和微服务边界总线规划。
• 搭建RocketMQ集群，创建统一ESB边界总线服务。
• 逐个区域实施微服务架构改造，经过消息代理或客户端接入RocketMQ边界总线。

本文做者：舒平，弘康人寿架构部负责人，长期从事保险行业IT服务化治理工做。

---

原文连接

本文为云栖社区原创内容，未经容许不得转载。