在微服务架构中，我们还需要ESB吗?

Posted 2021-04-14 失控互联

Do we still need ESB with micro-service architecture

这个题目我估计很小众，因为读者即需要了解微服务架构，又需要了解ESB，并且还要对这样的话题感兴趣。

微服务是近几年技术社群讨论很多的一种软件架构方式，可以说是SOA的现代版本、时尚版本。不过这次浪潮不是由大公司倡导的，而是由工程师们引领的。比如，它采用工程师们熟悉的RESTful接口，而不是笨重的WebService，也不需要一大堆昂贵的中间件。

By Loïc Corbasson, created with en:OOo Draw (ODG source file available on request) - self-made, based on SOA Meta Model.jpg by David S. Linthicum, GFDL, https://commons.wikimedia.org/w/index.php?curid=3271972

总之，就是那一套不吃香了。就是在它吃香的时候，跟中小企业也没多大关系。一是贵，产品贵，实施贵；二是中小企业也没有那么复杂的应用呀，SOA的投入产出不划算；第三，推动SOA需要打破企业内部壁垒（我部门原来有套应用，满足自己的需求就行了。现在还要对你们提供服务接口？那接口出问题岂不是给自己找麻烦？），历史证明这样的事情都是吃力不讨好的。

那微服务为什么流行起来了呢？按理说它们都是让软件更加模块化，使相互之间保持松耦合，从而优化系统架构呀。是的，可以说，它们在核心理念上没有根本的不同。但为什么现在讲微服务，不讲SOA了呢？我自己分析了几个原因，跟大家分享：

第一，目前移动APP开发越来越重要。就算是html的客户端，也大量采用了html5技术。在这种情况下，工程师们都习惯通过RESTful接口与后端通讯，甚至他们把职位也简单的划分为前端工程师和后端工程师。这导致REST服务成了刚需。原来的软件可以拒绝提供Web Service接口，但现在的则不能不提供RESTful接口。人人都用，用量很大。这为微服务化提供了天然的契机。

第二，性能也越来越重要。为什么？只要服务一慢，APP的用户体验就差呀。原来的SOA体系不怎么提性能。一方面是故意不说，你想WebService各种打包解包就要消耗多少CPU周期和网络带宽，性能肯定不是优势。二是如果性能不好，正好买大厂商的昂贵的服务器和lincense呀。但工程师们不吃这一套。明明很简单就可以实现高性能，为什么要搞那么复杂？把微服务集群化、搞搞读写分离不就好了吗？

第三，替换比利旧重要。SOA很多的应用场景都是在对已有应用的打通，比如你买了SAP的软件，又买了另一家的软件，还有以前投资定制开发的软件。这些软件都很贵，要像祖宗一样供起来的，轻易不敢改动，改动成本很高。所以要尽量保留，要通过SOA的方式对接在一起。而搞微服务的那些人呢？他们的理念是“Design for replacement”，设计的每个微服务都要非常容易被抛弃、被替换。拥抱不断变化的业务，快读迭代开发。那些旧的包袱他们压根不想搭理，天天想的是怎么替掉它们算了。

所以，总结起来，就是企业IT技术的全盘互联网化。只要是大的互联网公司已经检验过的，就是好的，比如开源软件、分布式架构、云、hadoop，以及最新的人工智能技术。

没错，我也是这个方向的拥护者。但是一个问题来了，原来SOA架构中推行的那些东西：ESB、BPEL、CEP，这些还都有没有用？或者是不是有替代者？

比如，ESB是解决服务消费者和服务提供者之间的点对点连接关系的。点对点连接当然不如大家都连到一个“总线”上，这样就会实现物理位置、传输协议等多个方面对透明。这在微服务架构中有用吗？

By Silver Spoon - Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=8278078

但实际上，具体的服务可能跑在很多服务器上，就像api.company.com这个域名下，可能有crm、oa等很多个系统的服务接口，不可能都在一台物理服务器上。这个时候，就需要把实际的请求路由到真实的服务器上，起到这个作用的系统，我们把它叫做API网关，它跟基于http的负载均衡器工作起来差不多。

API网关大部分是对外的，也就是处于内部网络跟外部网络之间。比如，无数的APP客户端都要通过API网关访问内部的服务。因此，对它的安全性、健壮性也就有了很高的要求。此外，如果系统性能有问题，网关也需要知道是哪个服务慢了，这就需要性能监控、日志等功能。因此，凡是搞微服务架构，几乎肯定要用到API网关。

API网关与ESB有相似之处，但又有很大不同。基于DNS，API网关的存在几乎是透明的，应用不需要明确的知道一个中间件的存在，并跟它对接（实际在网络传输层面，还是要做一些配置和优化的，比如，在服务侧要允许来自API网关的大量访问）。这就体现出了REST的优势，因为它充分利用了互联网已有的基础设施。

所以，看上去我们不需要ESB了。ThoughtWorks的首席科学家Matin Fowler也不赞同在微服务架构中继续用ESB。他的考虑是说没有必要把一些逻辑集中在像ESB这样的中介结构中，这样与系统尽量解耦的初衷是背离的。

然而，事情似乎没有那么简单。我们在实践中发现，还是有一些需求，如果用类似ESB的机制，可能更容易满足。

服务的消费者和提供者之间，除了通过服务接口调用耦合以外，还有通过事件的方式。事件机制对于做UI编程的人来说很熟悉，一个UI组件发出事件，对此事件感兴趣的其他方可以获取事件中的信息，并运行相应的逻辑。

事件机制在DDD方法论里也讨论得很多。某领域（如订单处理）发出事件，其他领域（如物流管理）可以接受事件并处理。这是一种很干净的系统耦合方法。

这种耦合机制当然也可以用服务调用的等价方式来实现，比如物流微服务每隔一定的时间就去轮询一订单微服务。这仍然没有改变模块间的依赖关系，但效率上降低了。事件通讯的处理效率更高。这也是在系统架构中采用消息中间件（MOM）的一个重要场景。

那么，需要发出事件的微服务，就需要跟一个消息中间件对接，发送消息进去；而其他的消费者，就从消息中间件中不断地取信息。这个中间件的存在对于双方都是知道的，这就有点像一个ESB了。

有了消息，我们发现某些逻辑，如果从微服务里抽取出来，似乎更好。就如订单处理逻辑，可以由物流服务去监听订单服务，以便及时安排物流。也可以把它们之间解耦，让一个BPEL逻辑去调度。物流微服务只是被动的接受调用就可以了。

表面上看，这只是把一段逻辑从物流微服务中剥离出来了。但剥离的好处，是更加容易维护这些流程逻辑（甚至可以通过图形界面来维护）。

担心ESB中的逻辑太集中，又成了大块的软件？由统一的部门维护导致协作成本太高？

我觉得这是个权衡利弊取舍的问题。把很多公共的、全局的功能放在ESB层面上去实现，会大大简化微服务的实现，让它们更加专注于处理好自己的事情。

一个很重要的场景，就是微服务之间的数据复制。微服务之间是不共享数据库的，实现最大程度的低耦合。但在实际中，一个微服务可能要访问另一个微服务的部分数据的只读版本，这样可以大大提高性能。在这种情况下，微服务之间的数据复制就是一个必须要解决的问题，而且最好统一解决，不是由每个微服务各自去解决。借助ESB的数据自动同步，就是其中一个解决方案。

我们理解，在自由主义者心中，我们不想要任何的“枢纽”，我们希望整个世界是分布式，自由连接的，没有一个中央机构能够控制所有的事情。

在实际情况下，我们还没有办法做到完全的分布式，还必须依赖一些公共的基础设施，比如如果几个DNS的根服务器出了问题，全球的互联网都会出问题。

公有云也把很多企业的IT设施都集中到了一些大型的机房，从而导致了成本的大幅度降低。

所以，集中是有它的好处的。基于ESB，可以更好的做服务的治理以及一些高级应用，比如可以做CEP（复杂事件处理）、可以支持Event Sourcing，可以做全局的安全设计等。分布固然有分布的好处，但类似路由器这样的枢纽，在架构中还是有其必要性的。

按照《失控》的理论，我们还有一个“涌现”和分层的理解角度。所有的微服务是基础，而微服务之间的互动是涌现出来的特征。就如大脑的意识是神经元的连接涌现出来的，以及网络协议中TCP层的能力是由IP层的支持的。在上一个层次中，我们通常有能力做一些在下一层次做不到的事情，比如宏观的流程，比如微服务的治理。

最后总结一下：微服务的整合，仍然需要中间件。我们仍然可以从过去ESB的理念中汲取一些有用的营养。

By Axelangeli - Own work, CC BY 3.0, https://commons.wikimedia.org/w/index.php?curid=15958179

不过，我还是不喜欢ESB这个词。所以我们内部叫做MSB，micro-service bus。