BoCloud博云：ESB老旧力不能支，微服务独立自治强势替代

傷城~ 2022-08-31 04:40 29阅读 0赞

**在微服务化建设中，应该考虑到 ESB ，也必须考虑到 ESB 。**那么同样是面向服务的架构， ESB 与微服务相比差别在哪儿？微服务化的建设应该如何安置 ESB ？在新型架构终将取代腐化传统架构的背景下，如何迁移、替代，保证业务的可用性？接下来的内容里，将给大家做一个详细的分析。

**SOA与ESB**

技术架构的发展有其规律可循，从单体到垂直拆分、再到面向服务、最后到分布式微服务，从技术架构上来看是化整为零的，从服务管理角度来看是从单一的管理到集中式的管理。在服务化以后，也就是提出面向服务的架构以后，除了微服务以外，SOA 和 ESB 也是大家熟知的架构：

*  SOA架构：其实是一种设计理念，没有架构和技术的依赖，只是多个服务以独立的形式部署运行，服务间通过网络调用，最终提供一系列完整的功能。

![40c4ec154ae147048309bf024c62737c.png][]

*  ESB：企业服务总线，用来连接各个服务节点，服务间通信都通过 ESB 做路由和转发。最主要的是，不同应用可能有不同的协议和报文，ESB 最大的功能是解决不同的服务间互联互通。**所以，ESB 其实也算是 SOA 的一种实现形式**。

![6b3d51e054ceba395b9c3ecbad8cccf1.png][]

**微服务的特点**

看着上面 SOA 的描述，是不是感觉跟微服务架构也差不多？或者说微服务是 SOA 的升华。那么微服务与 SOA、ESB 有什么不同呢？

我们先来看看微服务优势介绍：

**1、 独立、专注、自治**

*  可以独立的部署、独立的运行，使用单独的数据库，甚至使用单独的前端。这样可以将故障影响面降低，不会出现牵一发动全身的事情。
 *  专注于自身的业务，比如报表服务，只关注于报表，也就能聚焦于报表业务，不需要考虑监控、告警和日志，只需要输入数据，生成报表。
 *  研发团队自治，可以拉起一个三五人的小团队，只做报表相关功能和业务，效率高、专业程度高、产生质量和价值高。

**2、 分布式，高可用，扩缩容，资源分配**

*  微服务框架，支持分布式的部署和运行方式，解决了服务的高可用问题。
 *  通过注册中心的服务发现，实现服务的动态扩缩容，可根据业务并发量，自动调整横向的扩缩容量。
 *  根据不同的业务模块，调整服务的资源配比。例如在财务系统中，用户管理模块（用户增删改）使用频率较低，可以部署一个资源少、单副本的用户服务；但是账务模块使用极其频繁，每天达到上百单，可能分配一个资源多、多副本的账务服务。但是如果非微服务架构的话，就需要做系统的整体扩容，以满足最大业务量的模块，会造成其他模块的资源浪费。

**3、 服务解耦、服务化**

*  拆分了微服务以后，服务间的依赖都会通过网络传输的方式提供。也就是说一个服务只需要提供所需的功能接口，就可以满足整体的业务实现。因此，微服务使用什么编程语言，如何实现业务逻辑都可以不用考虑，只需要提供该有的功能接口（只关注于结果）。这样服务在开发、管理、使用的时候，可以实现真正的解耦，不会受到开发框架、开发模式的制约。
 *  微服务化以后，服务的业务能力，不只是该系统可以使用，其他有需要的部门或者系统也可以通过接口调用该微服务，提供给其业务处理能力。

**ESB对比微服务**

1、 **独立而不自由。**相对于微服务，SOA架构可以独立部署业务服务，但是不够自由，不能像微服务那样自由互通，只能通过 ESB 做服务通信，所有服务通信都需要 ESB 转发，在 ESB 处集中管理，配置权限、配置策略。

2、 **非分布式解决方案**，服务的高可用无法通过框架整体解决，只能通过传统方式解决。所以，更无法实现横向动态的扩缩容。

3、 ESB 尽管也是面向服务的框架，但是却无法真正的实现服务化。**服务化，应该是自消费的模式**，微服务的服务能力提供以后，使用者可以实现订阅使用。但是 ESB 中，服务能力提供出来只是给特定场景的某几个服务使用，其他服务如果想使用，需要通过定制化的增加。

4、 与自消费的道理相同，服务提供者不能实现自动化的服务提供，ESB中需要增加对应的接口以便于服务提供相应的业务能力。所以在ESB建设中，**会提前制定好需要暴露的指定接口**，如果有新增的需求，需要针对性的定制化。而微服务提供的则是一个微服务平台，只要遵循特定的协议，无论是服务的提供还是使用，都可以自由的上下线和增减。

5、 微服务架构是新型的服务化架构，而 ESB 架构很容易腐化，且维护困难，技术核心非开源，受厂商绑定。微服务基本上都是基于开源的新型的技术，**不存在腐化，且可以自主掌握核心技术**。

6、 ESB 是集中化的服务管理模式，**ESB 的性能将决定集团整体的通信性能**，且由于过于“集中”导致一旦总线出现问题，整个集团的信息化系统将面临“瘫痪”的风险。而微服务则不同，微服务采用去中心化方案，**任何一个组件出现问题都不会影响全局的业务**。

**ESB终将被替代**

业务持续增长，所以需要技术不断革新，促进技术框架也不断进步。一切变化的源头都在业务的变化，业务消费量成几何倍增长，所以要求服务可以自由的扩缩容；新型业务的不断增加，要求服务支持动态的运营和管理。而 **ESB 的架构过于死板，已经完全不适合云原生理念下的服务治理**。

**老旧的系统架构逐渐力不能支，新型的微服务架构应运而生**，在这个趋势的指引下，我们开始做微服务化的建设，但是在微服务化建设期间 ESB 如何安置，是一个比较大的问题。企业中多数系统的互联互通都依赖于 ESB 的服务总线，但同时改造所有 ESB 接入的系统，工程量会很巨大，容错率会很低，危险性也极高。因此 **ESB 的替代尽管势在必行，却也需要慎重的规划**。

通常 ESB 的改造需要采用逐步改造加逐步迁移的方式，根据不同的系统现状，做相应的方式处理：

*  **接受深度改造的系统**，通过拆分改造成微服务系统，那么之前的调用方式可以直接修改成微服务的调用方式，这部分在我们的微服务化建设当中，需根据实际情况做好相应的建设规划；
 *  **支持轻度改造的系统**，不做微服务化拆分，但是可以改造调用或访问的方式和地址。这部分系统可以将调用地址直接换成 API 网关的地址，通过 API 网关提供原 ESB 的如协议转换、路由转发、认证控制等功能，替换掉 ESB 的代理；
 *  **完全不接受改造的系统**，或者对 ESB 依赖极强的系统，在做深度改造之前，ESB 不能被取代，那么仍需要保留 ESB 。但是需要考虑新改造的，或者增量的微服务系统，与 ESB、与老旧系统之间的通信，因此需要对运行中的 ESB 做兼容和纳管。

**在微服务建设的初期，ESB 因在企业中起到的关键作用，并不能完全替换或取代，因此需要有个过渡期**：通过微服务管理台，兼容纳管 ESB 的服务；通过API 网关转换报文，路由转发 ESB 的接口，以保证存量的系统与增量或改造的系统兼容管理、互联互通。

其实 ESB 的功能，路由、转发，与 API 网关的功能极其相似。接下来，我们将会重点分析 API 网关在微服务中的作用与 ESB 的区别和优劣，敬请期待。

[40c4ec154ae147048309bf024c62737c.png]: /images/20220829/42b2edc4fd4a4d079b95ffb064e2e808.png
[6b3d51e054ceba395b9c3ecbad8cccf1.png]: /images/20220829/42a80c8b4c504a07ab7b026234bdb946.png