《谈谈企业应用架构的进化和服务集成》下篇
本文系作者本人原创，如需转载，请务必写明出处，谢谢！
承接上篇，今天我们继续谈谈面对大量异构系统，该如何集成业务功能。
六 ESB 和API Gateway，不同的历史使命
1．ESB
Gartner 在2006年发表的“Hype Cycle for Application Integration and Platform Middleware, 2006”一文中，对ESB的定义如下
An enterprise service bus (ESB) is a Web-services-capable middleware infrastructure that supports program-to-program communication and related mediation services, such as service virtualization, transformation, security, intelligent routing, monitoring and guaranteed delivery.
而在2011年该文档的新版本中又强调了ESB “combines support for service-oriented architectures (SOAs) , Web services and features from several earlier types of middleware.”并突出了 “supports interaction protocols ” 的功能。
由此可见，ESB（即企业服务总线）的功能，是随着SOA的发展而不断丰富完善起来的。IBM作为SOA的大力推动者，它的ESB产品的发展史，很好地验证这一点。
针对不同的业务场景，IBM在历史上推出了三款ESB产品（详细可参考马 国耀 和 吴 宇 2008 年 11 月 06 日发表的“IBM ESB 产品之间的比较及应用场景”一文）
•WebSphere ESB (WESB)，最新 7.5.1 2013年
•WebSphere Message Broker(WMB)，最新 8.0.0.7 2016年
•DataPower 最新 7.6 2017年
有意思的是，IBM的ESB产品虽然在不断更新，但一直没有大的变化。而最近，随着基于Rest的微服务应用的兴起，IBM的ESB产品来了一个大变更，出了一款叫IBM Integration Bus的产品，取代了原来的WESB和WMB，现在的版本号为10.0.0.16，产品说明中特别强调了对Rest的支持，刻意模糊了ESB和API Gateway的概念。
更有意思的是，随着API Gateway的兴起，作为ESB产品线的的DATA Power，现在已经号称是API Gateway产品了，不再定位于ESB产品线。
结合下图，我们可以发现，ESB是由Adapter、Integration Hub和Service Exposure Gateway 这三个功能模块组成的。
（图片来源: Integration architecture: Comparing web APIs with service-oriented architecture and enterprise application integration Kim J. Clark March 18, 2015）
（1）Adapter 用于接口适配，包括数据处理、交互框架、连接管理、不同level API管理，协议转换，传输通讯等
（2）Integration hub用于规范化集成，包括数据转换，路由分配，服务组合等
（3）Service exposure Gateway 用于服务暴露，包括对服务的虚拟化包装、可视化管理、流量管理和安全管理（如集中鉴权）等
由此可以看出，在RestAPI 尚未ready的时代，ESB正是用来解决上篇第四章中提出的“如何在已有的老系统上，增加一个服务集成组件，使系统间能互相调用？”这个问题的。这正是ESB的历史使命。
2. API Gateway
Chris Richardson 在Building Microservices: Using an API Gateway 一文中和Péter Márton 在 Building an API Gateway using Node.js 文章中都认为：API Gateway 是微服务应用的入口，它为客户端提供了一个API的共享层来与微服务应用的内部服务通信。API Gateway的具体功能包括：路由处理、服务组合、流量控制、安全管理、可用性管理等。它所管理的API接口，已经是Restful了。
当然，当API Gateway作为一个商用产品售卖的时候，那么它的功能就应该不止于运行时，还应包括开发者门户和API管理的功能，如下图所示:
（图片来源: Microservices and how they relate to ESB API and messaging - IBM InterConnect 2017）
3．服务调用中最重要的几个问题
由于ESB和API Gateway都是对服务调用的管理，所以，我们不妨先把服务调用中最重要的几个问题罗列出来 。
<以下（1）-（8）的内容和图片，请参阅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原则。
4. ESB vs API Gateway
ESB的特性：
对于ESB来说，它是在应用服务化的早期、伴随着EAI和SOA的理念而产生的。它产生之初，天地还在混沌之中，世间充斥着各种不同的协议，同时，ESB所处理的服务是企业级的服务，服务粒度比较粗，它践行的是“share-as-much-as-possible”的架构模式，所以（2）调解和路由、（3）消息增强、（4）消息转换和（5）协议转换这四个方面，是它必须具备的也是具有强大优势的地方，也因为要实现这四个方面的需求需要极大的资源消耗，所以导致作为中央节点的ESB产品会很重；为了保证其可靠运行，其架构也会比较复杂。
API Gateway的特性:
而对于API Gateway ,它是伴随着微服务应用的产生而产生的，此时已经天下一统，“书同文、车同轨、行同伦”， 其所管理的微服务都是基于Rest协议的。所以它除了必须具备（2）调解和路由的功能外，（3）消息增强、（4）消息转换和（5）协议转换就基本不需要考虑了，而且，其调解和路由功能也要比ESB简单得多。
ESB&API Gateway的共性：
而对于（1）服务可用性和服务响应能力处理、（6）服务合约管理、（7）安全、（8）事务一致性问题，ESB和API Gateway都是需要的。
ESB PK API Gateway
ESB是一种集中式的服务总线方式，可以以最小的代价把竖井式架构的应用改造成面向服务的架构。但由于通过ESB暴露出来的服务以紧耦合的方式固化在单体应用中，不宜频繁修改功能，导致其更改可能无法快速适应业务需求的变化。
PK
微服务应用的API Gateway则是随着微服务架构而来的。微服务应用的最初目的不是功能的重用，而是为了适合小团队自助开发，达到敏捷开发、敏捷发布的目的，以加快软件上市时间！因此它强调“share-as-little-as-possible”。所以从业务的角度来说，这些微服务应用也是一个个竖井应用。
当一个以微服务为架构模式的企业扩张（或者兼并其他同类企业）后，业务性质相似的微服务应用会越来越多（比如淘宝、天猫、聚划算），必然要想办法去整合不同的微服务应用中重复和冗余的功能，建立可提供共享服务的应用中台（共享业务层），并将共享服务暴露出来。这种需求的产生实际上与最初SOA（或者EAI）的产生是一样的，但不一样的是，由于微服务应用系统内的服务以Restful风格的分布式架构单独存在，可以直接暴露于API Gateway被跨系统调用，而且其与整个应用系统几乎完全解耦，比较容易快速修改功能，配合CICD和容器技术，其更改可以快速适应业务需求的变化。
七 异构系统的服务整合之我见
一个有历史包袱的企业，在它的成长过程中，必然会遗留许多历史系统。是通过新增投资的方法将遗留系统重建成支持Rest的系统，还是通过运维的方式将服务接口暴露到ESB中?我相信每个企业的行动都会不一样，但无论如何，系统的多样性和异构性在一个企业里总会存在。充分考虑遗留系统的服务提供方式，针对异构的环境，结合ESB和 API Gateway两种产品来整合企业架构或许是最好的选择。
我的观点是：对于复杂协议、遗留系统我们用ESB来整合服务；对于新的业务系统，如果采用微服务架构，那么通过API Gateway来整合服务，如果不采用微服务架构，那至少采用Restful 的Web Service来暴露服务，以方便接入API Gateway，然后通过ESB和API Gateway之间的互相调用，打通遗留系统和新业务系统间的服务连接。而对于数据的同步或者异步传输，我们还是需要借助于像MQ或者是kafka这样的消息处理软件来实现。如下图所示：
（图片来源: Microservices, SOA, and APIs: Friends or enemies? Kim Clark January 22, 2016）
八 发展趋势
未来的服务集成，将不只止局限于业务系统的集成，也不局限于企业内部的集成。服务集成的范围将为越来越广。Gartner提出了HIP（即Hybrid Intergration Platform）的概念。有关HIP的描述，在这里不再赘述，有条件的读者可以查看gartner的相关报告，IBM developer官网上也有相应的文章比如“Hybrid integration platform in the digital enterprise”可参考。其示意图如下。
（图片来源: Hybrid integration platform in the digital enterprise by Prabhakar Mynampati May 9, 2017）
九 总结
经过以上分析，我们可以看到，为了适应移动互联的需要，采用轻量级的服务协议是大势所趋，而企业应用的架构也迫切需要从单体的竖井式架构向面向服务的架构转型，而我们面临的最大挑战，正是不同应用架构的整合问题。
从技术来说，单体应用和ESB或许已经是旧日黄花，但是，在一个有历史的企业里，他们依旧存在，而且他们依旧有使用的场景和存在的价值。对于IT而言，所谓的自然法则，就是是否能给客户创造最大的价值，如何通过整合保护好现有系统的价值，同时又能直面技术进化的挑战，是IT决策的依据。
参考文献
- Microservices, SOA, and APIs: Friends or enemies?
- Integration architecture: Comparing web APIs with service-oriented architecture and enterprise application integration
- IBM ESB 产品之间的比较及应用场景
- Microservices vs. service-oriented architecture
- 微服务与SOA架构
- WebSphere ESB (WESB)，最新 7.5.1 2013年
- WebSphere Message Broker(WMB)，最新 8.0.0.7 2016年
- DataPower 最新 7.6 2017年
- ESB工作机制
- IBM Integration Bus, Version 10.0.0.16
备注
我文中提到的API Gateway 是指微服务应用的API Gateway。而对于企业级API Gateway的理解，我还是有些困惑的。我的一种理解是：它是用来解决企业内部复杂业务场景的，所以其功能上更像ESB和微服务应用的API Gateway的结合，这个像IBM Integration Bus的功能。另外一种理解是：它是企业对外开放API的一个网关，那么它的安全性和客户管理的要求就特别突出了，这个又有点像IBM Data Power的功能 。但是我觉得，最终ESB 和API gateway都会融合到所谓的HIP（Hybrid Integration Platform）上去。
本人原文：谈谈企业应用架构的进化和服务集成【下篇】