【微服务】工业互联网正确打开方式系列（三）：在IIOT的PAAS层，有了微服务还需要ESB吗？

2018 年 8 月 18 日 产业智能官

工业互联网正确打开方式系列（三）

先看“产业智能官”的结论（仅供参考）：工业互联网PAAS架构中，传统软件应用云化、集成，用ESB架构，包括CAX\MES\CRM\ERP；创新型应用APP采用微服务架构，并通过ESB与传统软件集成，包括工艺参数优化、质量检测、预测性维护。总之，工业互联网PAAS架构是:ESB+微服务。

2018年是工业互联网元年，微服务更是在工信部等部委发布的企业上工业互联网云平台相关文件中频频提到，“微服务”这一诞生于消费互联网的技术术语逐渐被传统工业人所熟知。

微服务为什么就火了

微服务是近几年技术社群讨论很多的一种软件架构方式，可以说是SOA的现代版本、时尚版本。微服务采用工程师们熟悉的RESTful接口，而不是笨重的WebService，也不需要一大堆昂贵的中间件。与此对比，ESB架构中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，以及最新的人工智能技术。

微服务架构的优点与缺点

1. 优点

每个服务足够内聚，足够小，代码容易理解、开发效率提高
服务之间可以独立部署，微服务架构让持续部署成为可能;
每个服务可以各自进行x扩展和z扩展，而且，每个服务可以根据自己的需要部署到合适的硬件服务器上;
容易扩大开发团队，可以针对每个服务(service)组件开发团队;
提高容错性(fault isolation)，一个服务的内存泄露并不会让整个系统瘫痪;
系统不会被长期限制在某个技术栈上。

2. 缺点

《人月神话》中讲到：没有银弹，意思是只靠一把锤子是盖不起摩天大楼的，要根据业务场景选择设计思路和实现工具。我们看下为了换回上面提到的好处，我们付出(trade)了什么?

开发人员要处理分布式系统的复杂性;开发人员要设计服务之间的通信机制，对于需要多个后端服务的user case，要在没有分布式事务的情况下实现代码非常困难;涉及多个服务直接的自动化测试也具备相当的挑战性;
服务管理的复杂性，在生产环境中要管理多个不同的服务的实例，这意味着开发团队需要全局统筹(PS：现在docker的出现适合解决这个问题)
应用微服务架构的时机如何把握?对于业务还没有理清楚、业务数据和处理能力还没有开始爆发式增长之前的创业公司，不需要考虑微服务架构模式，这时候最重要的是快速开发、快速部署、快速试错。

ESB 所解决的核心问题：

1. 系统集成：站在系统的角度，解决企业系统间的通信问题，把原先散乱、无规划的系统间的网状结构，梳理成规整、可治理的系统间星形结构，这一步往往需要引入一些产品，比如技术规范、服务管理规范；

这一步解决的核心问题是【有序】

2. 系统的服务化：站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生，目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用；这一步解决的核心问题是【复用】

3. 业务的服务化：站在企业的角度，把企业职能抽象成可复用、可组装的服务；把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力；“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。第三步，则是以业务驱动把一个业务单元封装成一项服务。

这一步解决的核心问题是【高效】

微服务+ESB的融合

原来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更容易满足。

应用微服务架构设计时可能遇到的关键问题(内部服务通信、分布式数据管理)通过ESB轻松解决。

服务的消费者和提供者之间，除了通过服务接口调用耦合以外，还有通过事件EVEN的方式更加高效。ESB中的事件机制对于做UI编程的人来说很熟悉，一个UI组件发出事件，对此事件感兴趣的其他方可以获取事件中的信息，并运行相应的逻辑。ESB的事件机制譬如，订单处理发出事件，物流管理可以接受事件并处理。这是一种很干净的系统耦合方法。

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

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

看一个ESB与微服务融合的做法：有了ESB消息，我们发现某些逻辑，如果从微服务里抽取出来，似乎更好。就如订单处理逻辑，可以由物流服务去监听订单服务，以便及时安排物流。也可以把它们之间解耦，让ESB中的一个BPEL逻辑去调度。物流微服务只是被动的接受调用就可以了。表面上看，这只是把一段逻辑从物流微服务中剥离出来了。但剥离的好处，是更加容易维护这些流程逻辑（甚至可以通过图形界面来维护）。

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

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

再看一个ESB与微服务融合的做法：数据同步。

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

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

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

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

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

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

最后总结一下

微服务的整合，仍然需要ESB\BPEL\WORKFLOW\MQ\EVEN\CEP中间件。我们仍然可以从过去ESB中汲取一些有用的营养。