本文系作者本人原创，如需转载，请务必写明出处，谢谢！
题目很长，想说的东西很多。
一 IT的进化论
达尔文的进化论同样适用于IT世界，能大行其道的IT技术，确实是优胜劣汰，自然的选择。 有人说J2EE想解决很多东西，可惜它不够人性，有人说，SOA多么美好，可惜它生不逢时。所以在经历多年的发展之后，J2EE也好，SOA也好，终于碰到了天花板，逐渐被其他IT技术所取代。
而最近炒得火热的中台概念，是不是因为手中握着被自然选择优胜劣汰下来的利剑？
首先让我们看看中台是个什么鬼？
二 从中台说起
以下两张图告诉我们中台要做些什么，又该怎么做。
（图片来源 Thoughtworks 王健在华为CBG IT技术合作峰会上的分享《中台战略到微服务架构》）
DDD已是旧闻，最近一些公司大谈中台建设，似乎就是想用手握的利剑，再次采用领域驱动设计的方法，帮助客户重建平台系统，从而大赚一笔？
比较下面这两张SOA的示意图，各位是不是就清楚了，原来中台要做的事情只是当初SOA 要做的事情的一部分（可以理解为Enterprise Service这部分）。
（图片来源 Microservices vs. service-oriented architecture By Mark Richards July 6, 2016
这些大公司们凭什么敢做曾经没有取得大成功的事情？他们手握的自然法则锻造出来的那把利剑究竟是什么？我们得先从webservice 说起。
* 有关中台的文章，网上这两篇可参考，从中台到平台(上) 从中台到平台(下)
另外，可参考《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》
三 两种最为流行的web service实现方式，后来者居上
按照进化论的角度来看，目前最主要的Web服务实现方案有两种：
SOAP：即简单对象存取协议(Simple Object Access Protocol)，是XML Web Service 的通信协议。当用户通过UDDI找到你的WSDL描述文档后，他通过可以SOAP调用你建立的Web服务中的一个或多个操作。SOAP是XML文档形式的调用方法的规范，它可以支持不同的底层接口，像HTTP(S)或者SMTP。
REST：表征状态转移（Representational State Transfer），采用Web 服务使用标准的 HTTP 方法 (GET/PUT/POST/DELETE) 将所有 Web 系统的服务抽象为资源，REST从资源的角度来观察整个网络，分布在各处的资源由URI确定，而客户端的应用通过URI来获取资源的表征。Http协议所抽象的get,post,put,delete就好比数据库中最基本的增删改查，而互联网上的各种资源就好比数据库中的记录（可能这么比喻不是很好），对于各种资源的操作最后总是能抽象成为这四种基本操作，在定义了定位资源的规则以后，对于资源的操作通过标准的Http协议就可以实现，开发者也会受益于这种轻量级的协议。REST是一种软件架构风格而非协议也非规范，是一种针对网络应用的开发方式，可以降低开发的复杂性，提高系统的可伸缩性。
如果你开始用Spring boot来编写web应用，你一定会发现用Rest风格来写web service实在是太方便了，用起来也方便，于是越来越多的web服务开始采用REST风格设计和实现。
那么我们为什么要用web service? 这要从企业应用的发展历史来谈
四 从巨石应用到微服务应用，我们一路走来
实际上，当计算机技术开始用于企业应用的时候，应用的结构是这样的(这里省略掉最初期刀耕火种的原始计算机时代，数据库技术发展），只要有个业务，我们就建一个业务系统。这个时代的应用，我们称之为monolethic application 、silo system、孤岛系统、竖井式结构。
企业应用越来越多，这时候，在新开发系统的时候，大家发现，许多数据和功能，在已有的系统里已经有了。我们将来能不能建立这样的新系统（或者改造老系统），在架构上能支持其他应用来调用一些特定功能？如何在已有的老系统上，增加一个服务集成组件，使能系统间能互相调用？SOA的理念由此提出。
针对第一个问题，我们将来能不能建立这样的新系统（或者改造老系统），在架构上能支持其他应用来调用一些特定功能？web service 的概念应运而生。如下图的J2EE架构。一个企业应用，它的用户，已经不再只是在客户端点击菜单和按钮的人，更是企业其他应用。所以，我们由 web service衍生出服务提供者，和服务消费者的概念。以SOAP协议为主的web service大行其道。
时代又开始进入了移动互联网时代，这个时代被称作VUCA的时代。企业应用开始直面最终用户，也就是2C了。谁能最快让应用上线，谁就能取得市场先机。在组件服务化的前提下，围绕着云原生技术的两条脉络清晰可见
1，前后端分离，使前段从后端分离出来，快速提高软件开发的效率。
对于原来由J2EE应用服务器提供的MVC的功能，将VC交给node.js来处理，应用服务器只处理业务包装
注意这里，后端如何才能真正和前端分离？关键就是采用了Rest的编程风格，后端是服务提供者，前端是服务消费者。
2，以康威定律为理论基础的微服务，伴随着容器技术和DevOps（以敏捷和CICD为基础）的发展，开始蓬勃发展。
请注意，微服务架构同样把 Rest编程风格推到了最前面。
这时候，我们就可以把两张图拼起来，形成一个以API Gateway为核心的前后端分离的新的应用架构
由此可见，webserive 转向 Rest风格，使得前后端分离和微服务架构成为可能，企业里新的应用已然是Rest API ready。
然而，放眼望去，一个诺大的企业，依旧存在大量的遗留应用（老的SoR System of Record,如无法取代的SAP），它们没有使用RestAPI，本章提到的第二个问题“如何在已有的老系统上，增加一个服务集成组件，使能系统间能互相调用？”该如何解决？
五 从 ESB，到API Gateway ,我们要理解这两个产品不同的历史的使命
在不是RestAPI ready的时代，ESB正是用来解决复杂协议转换，整合系统间服务调用的。
1,ESB 的架构
Gartner对ESB的定义如下
“A Web-services-capable infrastructure that supports intelligently directed communication and mediated relationships among loosely coupled and decoupled business components.”
其实，把下面两张图合起来看，把ESB理解为Adapter+Integration Hub+ Service Exposure Gateway ，那就是正解了。
2. IBM ESB产品
IBM作为SOA的大力推动者 ，针对不同的业务场景，推出了三款ESB产品
•WebSphere ESB (WESB)，最新 7.5.1 2013年
•WebSphere Message Broker(WMB)，最新 8.0.0.7 2016年
并且明确了ESB产品的功能特性：
以下内容参考：IBM ESB 产品之间的比较及应用场景
必备特性
1.连接性：ESB 必须提供一种支持服务交互的桥梁，它必须支持多协议 (protocol) 之间的连接。不仅要提供对消息和面向事件的中间件的支持，还要提供和现有 EAI 技术的连接。
2.服务交互 服务交互可以理解为 ESB 的一个目的之一，ESB 作为 SOA 架构的核心，必然要支持服务的交互，要在服务的请求者和提供者架起一个坚实的桥梁，让服务的请求者和提供者只需要关心各自的业务逻辑，而不需要在发布和消费服务的环节花很大力气。
3.集成 集成的概念是对于系统而言的，ESB 不仅要能集成那些很容易封装服务的系统，也要集成不能方便地封装服务的系统，例如 SAP, ERP, CRM, Siebel 等 EAI 系统、遗留系统。
4.消息处理 在集成的过程中，必须要面对的是消息处理，在不同的应用系统中，消息的描述格式是不一样的。在集成环境中，必须要提供一种统一的格式来处理系统间的交互，从 ASBO(Application Specific Business Object ) 到 GBO(Generic Business Object) 之间的互转
可选特性
•管理
对于一个具有 ESB 特征的产品，管理也是一个重要的方面。例如，当一个服务从一个地址切换到另一个地址，在结构等不发生任何改变的时候，ESB 产品应该提供一个方便的途径适应这种改变。
•QoS
对于服务交互来说，QoS 也是一个重要的特征，比如针对不同的服务请求者提供不同质量的服务响应。有些服务的请求需要在事务中完成，有些服务的交互需要保证其可靠性。一个 ESB 产品应该提供给开发者定义 QoS 的接口。
•安全
安全的必要性不言而喻，系统和系统之间的交互必然需要认证，授权，加密，签名等安全性。一个优秀的 ESB 产品应该提供可靠的，可灵活配置的安全支持。
拿IBM主打产品WMB来分析一下ESB的使用场景，可以帮助我们更深入了解ESB的作用
WMB场景描述：
•B 银行提供的服务由 Web Service 的方式实现，C 银行提供的服务由 FTP 方式实现，只要把消息放到 C 银行指定的 FTP Server 即可 , 数据格式由 C 银行指定
•对 B.C 服务性能要求较高，需要每秒钟能同时处理 1000 到 10，000 条消息
•B 银行和 C 银行都支持通过 MQ 的方式对其提供的服务进行访问
•利用 ESB 构建一个统一的查询客户存款服务的，该服务通过查询不同的客户来源，动态路由到不同的服务提供银行
有意思的事，IBM的ESB产品在随着技术的发展不断更新，而最近，来了一个大变更，出了一款叫IBM Integration Bus
的产品，取代了原来的WESB和WMB，现在的版本号为10.0.0.16，产品说明中特别强调对SOAP和Rest的支持。
（这里吐槽一下IBM，IBM的产品一直是很不错的，可惜价格太贵，为什么不能好好培养一些合作伙伴来认真推广你们的产品呢？有了质和量，才能算一个真正成功的产品）
3. API Gateway
API Gateway的正统定义我没来得及查。
API Gateway（API GW / API 网关），顾名思义，是企业 IT 在系统边界上提供给外部访问内部接口服务的统一入口。在微服务概念的流行之前，API网关的实体就已经诞生了，例如银行、证券等领域常见的前置机系统，它也是解决访问认证、报文转换、访问统计等问题的。
在微服务流行之后，API Gateway 已经成为了RestAPI的Gateway了，这一点一定要强调。另外，API Gateway因微服务应用而来，它的初始作用是协调单个微服务应用自己内部的服务，，而非其他应用暴露出的服务，粒度比较细。
它的功能主要有两个层面：
系统级别
•高可用性
•均衡负载: 容错,防止雪崩.
•并发控制 : 错峰流控
•动态路由制定和修改
应用级别
•监控统计
•版本控制
•认证 鉴权
•数据安全: 防篡改,参数脱敏…
作为一个产品，它的功能应该不止于runtime 时的作用，还应包括开发功能和管理功能，如下图所示
4. API Gateway和ESB的比较
由于API Gateway 和ESB 都是对分布式服务接口进行管理的产品，所以，我们不妨先把分布式服务接口管理中最重要的几个问题罗列出来 （参阅Microservices vs. service-oriented architecture）
（1）服务可用性和服务响应能力（Service availability and responsiveness）
服务可用性是指远程服务及时地接受请求的能力，服务是否可用，常规的解决办法，就是多试几次，或者用队列方法来解决。
服务响应能力是指客户及时地从服务接收响应的能力。常见的一种解决方案是使用断路器模式（circuit breaker pattern）
另一种方案是在代码中使用“智能超时值（smart timeout values）”，以便在负载变化情况下自行调整超时值
（2）调解和路由（mediation and routing）：指的是架构基于特定业务或者用户请求来对服务进行定位和调用的能力。
（3）消息增强（message enhancement）：指的是架构在请求的数据部分到达服务之前之前对其进行修改、删除或者增加的能力。例子包括改变日期格式、添加额外数值或者查询数据库进行数据转换。
（4）消息转换（message transformation）：指的是架构将一种数据格式转换为另外一种格式的能力。
（5）协议转换（protocol transformation）：指的是架构允许客户采用与服务端预期不匹配的协议来调用服务的能力。
（6）服务合约管理（service contract）：它是服务提供者（通常是远程的）和使用者（客户）之间使用合约语言（XML、JSON、Java Object等）约定数据输入和数据输出的一份协议。服务合约管理需要考虑变更管理和版本管理的问题
（7）安全：认证与授权（Authentication and authorization）是指特定服务的使用者被认证（authentication）和被授权（authorization）的问题。
（8）事务一致性问题：分布式应用依赖BASE事务来追求数据库中的最终一致性而不是每个中间事务的一致性。所以遵循的是BASE原则而非ACID原则。
对于ESB来说，它是在应用服务化的早期、伴随着EAI和SOA的理念而产生的。它产生之初，天地还在混沌之中，世间充斥着各种不同的协议，同时，ESB所处理的服务是企业级的服务，服务粒度比较粗，它践行的是“能共享则共享”的架构模式，所以服务的调解和路由、消息增强、消息转换和协议转换，这是它必须具备的也是具有强大优势的地方，而对于消息队列的处理，大数据量的传输，更是它的强项；
而对于API Gateway ,它是伴随着微服务应用的产生而产生的，此时已经天下一统，“书同文车同轨行同伦”，同时，API Gateway 是为了协调微服务应用自身内部的微服务而产生的，微服务架构是“能不共享则不共享”的架构模式，所以它除了必须有对内部微服务的服务路由的功能之外（比如灰度发布、流量控制），服务的调配orchestration（API网关无需调配各个微服务，微服务应用内部的微服务之间互相调用由它们自己进行编排choreography，无需API Gateway 来进行调配）、消息增强、消息转换和协议转换就不是Gateway要考虑的事情，而是内部微服务自行处理的事情了。而对于微服务应用下各个微服务之间的异步数据传输、依旧需要单独的消息处理软件用发布订阅机制来进行处理，比如Kafka\rabbitMQ 之类。对于安全性、事务一致性、合约问题以及服务的可用性和响应能力的处理，面对的问题是一样的。
六 异构环境解决方案
作为一个有历史包袱的企业，在它的成长过程中，必然遗留了许多有历史的系统，正如Garnter在2012年就提出的，企业应用分为以下如图三类，而system of record SOR 往往就是历史最悠久的系统了。
通过新增投资investment的方法重新建设这些系统，还是通过overhead运维的方式对这些系统进行改造?我相信每个企业的行动都会不一样，但无论如何，系统的多样性和异构性在一个企业里总会存在。
所以我们必须认清自己的现实，在系统建设中，特别是基于SOR 的上两层应用的建设中，一定要实事求是，充分考虑现有SOR系统的服务提供方式，针对异构的环境，结合ESB和 RestAPI Gateway两种产品来进行企业架构。如下图所示：
而对于那些冲动着想要进行中台建设的人们，也请沉住气掂量一下，
1，企业的组织架构是不是支持中台的建设？比如，
是不是每个业务领域都有领域架构师和技术架构师存在？业务流程的成熟度如何？业务和技术的融合度如何？IT能力是否已经足够前置？有没有一个中台组织在致力于将业务平台中的共享服务部分抽取出来？
中台前的组织架构
中台后的组织架构
2，企业的IT系统架构是否支持中台建设的成熟度如何？比如
烟囱或者竖井应用到底多不多？应用架构是传统的三层架构还是微服务架构？应用之间的交互是在原始阶段、SOA阶段、Rest阶段？IT部门已经提供了哪些平台能力？
然后再考虑到底要花掉多少银子？是否用渐进的方式还是革命的方式来完成中台建设？
七，总结
现在大家已经知道，“他们手握的自然法则锻造出来的那把利剑究竟是什么？”实际上就是Rest！
经过以上分析，大家可以看到，为了适应互联网、移动互联化的需要，企业应用的架构迫切需要从竖井式架构向面向服务的架构转型，无论单体应用还是微服务应用，都必须顺应服务化的需求，而ESB、API Gateway 则是SOA不同历史阶段的产品。
ESB是一种集中式的服务总线方式，可以以最小的代价把竖井式架构的应用改造成面向服务的架构。但由于通过ESB暴露出来的服务以紧耦合的方式固化在竖井应用中，其服务的柔性比较差，服务更改的代价会比较大，导致ESB暴露的服务可能无法快速适应业务需求的变化。
API Gateway则是随着微服务架构而来的。微服务应用的最初目的不是功能的重用，而是为了适合小团队自助开发，达到敏捷开发敏捷发布的目的，以加快软件上市时间！所以它强调独立，no share with other team，other application。
当一个以微服务为架构模式的企业成长（或者兼并其他同类企业）后，新开发的或者合并过来的不同部门但业务性质相似的微服务应用越来越多，必然要想办法去整合不同的微服务应用中重复和冗余的功能，建立可提供共享服务的应用中台（共享业务层），这种需求的产生实际上与最初SOA（或者EAI）的产生是一样的（比较SOA的图，ESB层相对Rest API层）。
由于微服务应用采用了RestFul的分布式架构，其服务的柔性就相当大，服务更改的代价很小，系统改造的风险极小。这种架构更适合于面对互联网、移动互联网的以快致胜的特点。所以新时代的SOA就是建立在API Gateway的Restful的微服务应用架构之上的企业面向服务架构。
作为IT的建设者，一方面，需要开放接纳新的IT技术，比如迎接微服务架构和RestAPI的到来，甚至向service mesh进军；另一方面，必须认真对待旧技术和旧的管理模式的存在。从IT技术来说，巨石应用和ESB或许已经是旧日黄花，但是，在一个有历史的企业里，他们依旧存在，而且他们依旧有使用的场景和存在的价值，所以要说九九归一，Rest一统天下，还有待时日，有待投入。
对于IT而言，所谓的自然法则，就是是否能给客户创造最大的价值，而最好的方法论，就是实事求是、脚踏实地、PDCA的方法论，在哲学上说就是扬弃。唯此IT才能真正前进。
参考文献
Microservices, SOA, and APIs: Friends or enemies?
Microservices vs. service-oriented architecture
WebSphere ESB (WESB)，最新 7.5.1 2013年
WebSphere Message Broker(WMB)，最新 8.0.0.7 2016年
IBM Integration Bus, Version 10.0.0.16
《企业IT架构转型之道——阿里巴巴中台战略思想与架构实战》
读书笔记: <企业IT架构转型之道(阿里巴巴中台战略思想与架构实战)>
等