在微服务架构中，我们还需要ESB吗？:微服务架构可以理解为一种架构风格，将一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个

1

微服务架构可以理解为一种架构风格，将一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
对于微服务架构来说，他们更专注于对于系统应用和业务的解耦，可以达到快速开发，快速迭代的目的，而ESB则是专注将各个系统之间服务集成和转换，强调的是系统间的强强关联，看上去和微服务的理念是相冲突的，在同一环境下只能存在一个。但实际情况并不是这样的。
1. 微服务架构虽然优势很多，但是还处在一个发展过程，虽然目前很多的产品都在慢慢转型，但是还是需要时间，对于相对复杂的业务，并不能完全实现，而ESB能够做的，更多的是协助业务系统进行服务的转换，服务的开发，弥补业务系统当前环境下的不足，满足业务场景的快速对接和实现，相比理想化的结果，利用现有资源，更能进行快速的反应和实现。
2. 虽然微服务架构能够实现快速的开发和迭代，但是随着业务的复杂，系统的增多，对接难度也会变大，小改动可能变动一方改动，大改动双方都要改动，成本和周期都是需要衡量的，而ESB虽然前期投入很高，但是从长远来看，成本和开发周期都是最低的，对于客户来说，也是更容易接受的。
3. 让一个企业所有的业务系统都能支持微服务的开发是不可能的，相对于版本较低的产品，可能都不支持开发，有可能服务都没有，这种情况下，更多的是做好IT资产的复用和兼容，微服务和ESB相结合的方式，只有这样，才能获取更多的市场，满足更多业务场景的快速实现。

数通畅联专注于企业IT架构、SOA综合集成、数据治理分析领域，感谢您的阅读与关注

2

不需要，过去采用ESB（企业服务总线）经常会发现到最后系统变得异常臃肿，不利于治理。微服务架构相比ESB可以说是在正确的方向上前进了一大步，不过微服务架构也会面临复杂性问题，主要集中在服务之间的通信，这也就是为什么大家开始关注service mesh这种对服务透明的新型微服务架构，来解决服务发现、负载均衡、路由、流量控制、通信可靠性、弹性、安全、监控/日志方面的问题。

3

荣幸回答，我将知无不尽，尽无不言。

在微服务框架的选择中最重要的一点就是 ESB并不是被淘汰，而是从集中式转变为分布式，需求让ESB发生了改变。

集中式ESB演化为分布式

微服务框架的变化就是，从集中式ESB 到 分布式ESB Service Mesh这是我们必须明白的一点，对于具体有那么不同和改变我归结以下几点:

1. ESB的服务之间都通过ESB总线互相访问,微服务中内部服务之间可以直接访问,外部服务通过网关接入
2. ESB的总线的功能拆开来就相当于微服务中以下几个独立的微服务
3. 服务目录 和服务发现：都是解决服务注册和寻址问题
4. 路由/协议转换/聚合和网关：区别是ESB中外部访问和内部服务之间访问都需要路由
5. 消息传递和消息总线：区别是ESB同时提供异步和同步消息
6. 验证和授权和独立的微服务: 区别是对微服务来讲这视为一个业务功能
7. ESB总线是集中化的,而微服务的细颗粒度使得横向扩容非常容易
8. ESB对服务进行统一管理,而微服务的复杂网络需要配合服务网格来管理

微服务的工作原理图

不是ESB过时，而是你的集中式ESB过时了，分布式ESB

总之微服务框架对于开发中只会越来越简便。

4

ESB是soa架构里面的东西，如果按照微服务的说法，我觉得esb相当于微服务的网关+注册中心，对外部或者内部暴露服务的。