在文章的开端前，咱们首先要考虑一个问题：从“烟囱式”架构、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 网关的组合，完成新老体系的替换。而关于不同的企业来说，两种晋级方法终究选择哪一种便是便是见仁见智了。
