共计 2329 个字符，预计需要花费 6 分钟才能阅读完成。
在文章的开始前，咱们首先要思考一个问题：从“烟囱式”架构、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 网关的组合，实现新老零碎的交替。而对于不同的企业来说，两种降级形式到底抉择哪一种便是就是见仁见智了。
