在微服务化建设中，应该考虑到 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 的区别和优劣，敬请期待。