基于服务网格的分布式 ESB， 实现应用无关的传统 ESB 转型升级

在文章的开始前，我们首先要思考一个问题：从“烟囱式”架构、SOA 架构、微服务架构。服务架构为何一直在变化演进？

一、ESB 的由来

今天话题主要聚焦在金融行业中较常见的 SOA 架构实现的一种方式 —— 企业服务总线 ESB (全称 Enterprise Service Bus)。

在 SOA 架构下，随着业务越来越复杂，服务越来越多，他们的调用关系图会变成如下图所示的情况。

那么该怎么理清这一团错综复杂的内容呢？

这时 ESB 企业服务总线便应运而生。通过下图可以发现，所有服务皆和 ESB 连接，ESB 就像是人身体中的心脏，连接了各个服务节点。

例如，如果调用方和提供方需要通信时，服务的交互路线是：

服务调用方 (服务请求) --> ESB (请求接收) --> 服务提供方 (服务处理) --> ESB (服务提供返回结果) --> 服务调用方 (服务返回)

传统 ESB 发挥的核心功能在于，提供不同协议、报文服务之间通过 ESB 实现互联互通。ESB 提供协议转换、解释以及路由寻址等功能。在整个服务调用过程中起到至关重要的作用。

虽然 ESB 系统解决了 SOA 架构所带来的问题。但是随着互联网快速发展，人们对于互联网的日常依赖不仅越来越深，同时也对互联网应用要求越来越高。响应时间超过一两秒都可能直接降低用户的体验感，造成客户的流失。同时，随着业务发展，服务越来越多的情况下，ESB 内部调用关系在不梳理的情况下就会变成如下图所示的混乱情况。

所以不管什么架构定时整理都至关重要！

二、传统 ESB 的劣势

正如上文所描述的，传统的 ESB 模式已经无法适应越发复杂的环境和越来越多的需要，它目前面临的困境如下，

(1) 由于老旧 ESB 系统对于使用者来说是一个黑盒的存在，排查问题难。

(2) 服务和服务之间调用关系需要人工梳理记录，耗时费力且不好维护追溯。且传统 ESB 采用集中式架构，可扩展性、可观测性低、且不支持微服务框架。

(3) 对于服务之间调用由于不支持链路追踪、服务订阅、故障分析、统计、服务治理方面的功能尤为欠缺。

这时，再从整个架构体系中看，老旧 ESB 就显得较笨重且阻塞。随着服务越来越多老旧 ESB 系统的弊端也逐渐明显，系统改造、架构升级便被提上了日程。

那么，如何解决老旧 ESB 所带来的问题呢？

作为业务方来说最重要且核心关注点是：如何稳定、快速、改动小的情况下实现快速迁移优化替换？

解决该问题通常可通过两方面入手：一方面是采用 ESB 替换升级，追求一站式解决。另一方面则是，“曲线救国”进行横向扩展。

下边针对这两方面咱们分别聊聊。

三、传统 ESB 弊端的双重解决之道

A. ESB 替换升级、一站式解决

新型 ESB 替代升级解决方案核心技术：采用新一代 Servicemesh 微服务架构，无须考虑架构、开发语言、服务器是容器还是非容器等所有情况。服务治理相关的内容更是其强势的地方。随着网格技术越来越成熟，越来越多的企业引进 Servicemesh 服务网格技术。并且，随着容器的优势而快速扩展逐渐成为业界主流体系的同时，Servicemesh 自身的优势越来越凸显，成为业界主流微服务解决方案也不无可能。

Envoy 边车接入无须关注架构问题的同时，支持在容器/虚拟机/物理机上完美兼容使用，对原服务无须做任何修改，可以对老系统渐进式升级改造。并且可监控从虚拟机到容器、容器到虚拟机之间调用的整条链路信息，解决了应用容器化到非容器化监控断层问题。

新型替代 ESB 方案的优势如下，

(1) 不改变原有 ESB 的接入接出使用习惯
兼顾高性能高并发、可扩展、可观测、可治理等场景。同时无需关注架构、报文编码等。不管是单体应用还是微服务架构都能无缝兼容。

(2) 减少沟通壁垒
减少各个部门沟通协作，降低推进所需的沟通协调成本。由于新型 ESB 是在不改变原有老 ESB 的接入方式，所以对于业务方来说感知较小甚至可做到无感知。有效避免了推动新技术时需要的各个部门沟通协作推行难等问题。

(3) 不增加新组件的维护
在不增加新组件的情况下，完美的解决现有老旧 ESB 系统所带来的一切问题。减少运维人员负担和接收新架构时所需要的学习成本。

(4) 自主可控
基于开源框架、代码自主可控。支持链路追踪、故障定位分析。

B. “曲线救国” 横向扩展

针对老旧 ESB 系统的劣势，上述中采用新一代 Servicemesh 微服务架构是一种解决方案。第二种方案，则是被称为“曲线救国”的横向扩展，其思路是不管现有老旧 ESB 系统，采用最新的微服务框架+ API 网关的组合，来另辟蹊径。新的系统采用微服务框架和 API 网关的方式来互联互通。老旧服务则通过 API 网关转向老 ESB 系统，来共同实现新老架构的一个更替。

如下图所示，在企业内部开发新型业务系统通过微服务框架提供的解决方案可直接调用，如需要调用老存量业务数据则通过 API 网关 --> 老 ESB 系统，这就需要 API 网关需要兼顾一定的协议转换功能。

这里有一个需要注意的问题，在新型业务系统调用存量的单体应用或者老系统服务是没问题的，但由于 API 网关和老 ESB 实现问题，无法逆向寻址。所以老系统调用新型业务系统则是不通的。

同时，由于老旧系统逐步改造需要各方业务配合，所以老 ESB 系统到新架构过渡期较长，在过渡阶段中会遇到一些比较棘手需要暂时绕开的处理方法。且在过渡阶段老 ESB 系统所存在的种种问题由于没有解决所以依旧存在。

四、总结

综上，我们回顾了传统 ESB 诞生的背景，在不断的发展过程中，老 ESB 的弊端逐渐显现。针对于老 ESB 系统所存在的种种弊端，目前有两种可行的方式来实现系统改造和架构升级，一种是采用新一代 Servicemesh 微服务架构，另一种则是忽视老旧 ESB 系统，采用最新的微服务框架+ API 网关的组合，实现新老系统的交替。而对于不同的企业来说，两种升级方式究竟选择哪一种便是就是见仁见智了。