Do we still need ESB with micro-service architecture
这个题目我估计很小众,因为读者即需要了解微服务架构,又需要了解ESB,并且还要对这样的话题感兴趣。
微服务是近几年技术社群讨论很多的一种软件架构方式,可以说是SOA的现代版本、时尚版本。不过这次浪潮不是由大公司倡导的,而是由工程师们引领的。比如,它采用工程师们熟悉的RESTful接口,而不是笨重的WebService,也不需要一大堆昂贵的中间件。
与此对比,SOA这几年叫得不是那么响亮了。为什么呢?我分析有几个原因:第一,这几年大家忙着做移动APP或微信公众号呢,哪有精力搞别的?第二,大家这几年忙着上云平台呢,要不也要折腾一下Hadoop吧,这才是紧跟潮流;第三,这几个传统大厂商都不吃香了,都裁员呢,他们那一套还能信?现在要讲互联网化呢,最时髦的是去IOE呀。
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
首先说位置透明。如果采用RESTful协议,每个服务都有一个URL,比如:http://api.company.com/crm/orders,或者:http://crm.company.com/orders。这个时候,我们通过域名就能解析到具体的物理地址。所以说,有了URL,就能访问到服务,为什么还要去接到一个总线上?而且大家通常都是http,也不需要做协议转换呀。互联网已经提供了DNS这种基础设施,把它用好就行了呀?
但实际上,具体的服务可能跑在很多服务器上,就像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。