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

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

SOA 与 ESB

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

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

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

微服务的特点

看着上面 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 的区别和优劣，敬请期待。