SOA 网关：轻量级、廉价的 ESB 替代方案

Jaime Ryan， Layer 7 的合作伙伴解决方案架构师，在一篇名为“重新思考ESB：基于SOA 网关建设简单、安全、可扩展的服务总线”的文章中谈到，SOA 网关将成为ESB 的替代者。其核心依据来源于当代SOA 网关提供了ESB 的三个典型用例，同时还提供一系列非功能性方面的优势。这三个典型ESB 用例是被称为“传统ESB 的标志”的服务端点的标准化抽象、数据及传输仲裁和消息路由。

为更好地理解Jaime Ryan 提出的一系列建议背后的逻辑以及何时采用这些建议，InfoQ 采访了作者本人。

InfoQ：为什么要寻求替代方案，当前 ESB 的哪些痛点刺激了这一需求的产生？

一旦某个企业决定要走企业服务总线路线，他们通常会陷入几大厂商的巨型软件套件的复杂性（及成本）的深潭之中，这些厂商试图将 ESB 模式等同于某个特定产品。而这些套件，虽然它们往往是比较全面的适配器，但其功能却超出了一般企业的需要。当敏捷和客户需求的响应速度作为架构目标时，答案绝不会是需要花一个星期去安装的解决方案。它们是重量级的、适配器驱动的解决方案，通常需要数月才能建成具有一定价值的规模，而且协议映射和数据格式往往还需要许多编码。此外，它们主要关注联通性，而很少关心安全，这就是当初在 ESB 模式中引入 SOA 网关的原因。 当企业为了安全和治理已经在其网络边界成功部署 SOA 网关之后，那么基于相同的考虑将它转入内部网络就成了自然而然的事了。一旦在内网应用间部署了（SOA 网关）的安全薄层之后，用户就会意识到这些轻量级、方便易用、廉价的替代方案能够实现更多的传统 ESB 平台所提供的功能，而已经在实施的传统 ESB 并非都取得了成功。此时一个需求分析问题就出现了……这些网关能否满足我的需求？如果可以的话，为什么还要继续沿着原先那条更慢、更昂贵、更费劲的道路向相同的目标前进呢？SOA 网关更易于配置，可一致地扩展，而且从运维的角度看它更便于管理。它能为安全架构师、应用开发者、网络管理员和运维人员都带来价值；更重要的是，其敏捷性和灵活性能够提升业务底线。并且，任何痛苦都痛不过口袋里缺钱。

InfoQ：使用 SOA 网关实现特定的 ESB 模式有何新意呢？为何在此刻提出呢？难道过去十几年里我们没见这种用法的发展么？例如，IBM ESB 家族中的 DataPower 就是这样的例子啊。

当然，将 SOA 网关用作 ESB 的的概念已经存在一段时间了，因为几大厂商的产品已经在这一领域里售卖了十多年了。然而，就像 ESB 要连接的那些应用及服务一样，这些解决方案已经变得极其复杂。随着 SOA 网关能支持的协议和消息格式越来越多，它正在日益变得全面。十年前，这些解决方案仅限于 HTTP 和 HTTPS，而且几乎仅关注安全。然而，为提供端到端的解决方案，SOA 网关需连接的应用和接口的无限制的，所以网关只需解决大型企业的某些特定的问题即可。 所幸，事情的两端都有发展。一边是网关功能的发展，而另一边是其所连接的应用也不断增加新型接口，满足客户需求的能力也不断增加。我敢说，当前市场仅需少量客户化或产品增强，就能够满足 85-90% 的用户需求，对于大多数 SOA 网关厂商来说的确是这样的。而且，如果出现一种新数据格式或服务接口，它不遵循 SOA 网关所支持的标准，那么 Layer 7 网关可为用户提供一个客户化组件的 SDK，供他们将这一新数据格式或服务接口接入我们的策略语言，由网关完成后续处理。同样，对于新生的传输协议，我们也能很容易地扩展我们的网络层支持以支持客户需求。于此同时，套装应用厂商的接口也越来越顺应时代，这意味着昂贵的适配器就不再需要了。这一点适用于主要套装应用提供商（SAP，JD Edwards，PeopleSoft 等）以及许许多多的较小厂商。只要在 Google 上搜索“套装软件名 (如 SAP)+web service”，你就可能找到整合该套装软件的简易流程。

除了通用的整合支持之外，近期大多数寻找更轻量级、敏捷的传统 ESB 的替代方案的人们主要迫于业务环境和技术平台的变化。IT 部门要节省开支，却要完成更多的工作，更快地响应客户需求。过去那种 3 年期的服务项目正快速成为历史，周转时间不再以年为单位度量，而使用周或月。以配置为主导的网关能够以创新的方式展现现有数据。相反，长期项目的需求则不断变化以使之几乎无法完成，所以前者比后者能更快地产生收入。移动计算和云技术这样的新技术尤其如此，传统的 ESB 实现不能方便地移植到云计算环境中，它更关注于 30 年前的旧技术环境，而不是 3 年内的技术。Layer 7 网关可移植到云计算环境中，或者以公有云 / 私有云的 IaaS/PaaS 环境上的 VM 形式部署，或者 Amazon EC2 或 vSphere 环境中的公有实例部署。企业端网关可通过简单的模板连接云端 SaaS，我们还提供云计算和移动计算接口支持的新型身份与访问控制机制，如 OAuth，双重认证（two-factor authentication）等。

当然，SOA 网关不能也不应该无所不能，就像任何其他定位成 ESB 的产品不应该解决每个人的所有问题一样。当需要实现业务逻辑时，使用运行在应用服务器上的标准编程语言应该是正选——没有理由将复杂的业务逻辑放在 ESB 上；当需要实现业务规则时，应该使用规则引擎将这些规则呈现给业务用户；当碰到与人交互以及长运行的任务时，自然选择 BPM 解决方案。

InfoQ：你在文章中强调了三个用例：“服务端点的标准化抽象、广泛的数据和传输仲裁能力以及动态的、智能的消息路由”。有些人认为数据仲裁是功能性需求，所以应该封装在服务端点 (endpoint) 的某个转换组件中。你如何看待这一观点。

虽然服务请求或 API 调用的实际业务逻辑应该留给服务端点去完成。但是，若干强有力的理由却支持将数据转换从服务端点中剥离，并转移到更加集中的仲裁执行点。这些关键原因可归结为性能、成本及复杂性等方面。 当要为某后台应用暴露新的标准接口时，直接的选择通常是 SOAP 或 REST 服务的 XML 形式。在自描述和（理论上）人类可读的同时，XML 很冗余而且处理时需要消耗大量内存。因此，解析、格式校验、和转换往往变成了不擅长这些功能的软件解决方案的痛处；而让网关提供这些功能，特别以硬件携带 XML 加速硬件的形式，则减低了应用本身的负载，提高了解决方案的整体吞吐率。

在现实世界中，性能的影响等同于金钱。虽然大多数遗留平台已经开始进行自我改造并提供新型接口，但是这一进程仍然很慢而且往往事与愿违。譬如一款领先的主机交易型产品，其最新版本就增加了“Web Service”接口，并且开发了将应用映射成预定义的 Web Service 接口，并在主机上执行数据格式转换。所以，首先，你要确保你运行的是最新版本，这在类似银行这样的企业中并非小事；然后，你还要专门安排开发人员来编写、测试、并部署那些执行从主机格式到 XML 接口间映射的代码。即便是最成功的情况，当所有工作都部署到生产环境并且按预期执行时，你还不得不需要提高主机的处理负载。如果你将这一转换功能剥离出来并在一个分布式架构中运行时，为何还要增加主机的 MIPS 和更多成本呢？

再次，将所有转换丢给服务端点还会给 IT 人员增加更多负担。即便最简单的场景，假设某个应用已经提供了 REST 接口，而客户却更喜欢基于 SOAP 的 Web Service 接口，你的开发团队必须立刻为相同的底层应用提供多个接口。底层数据是相同的，但是他们不得不为该客户编写更多代码。更进一步，当新版本发布时，你还必须要同时支持新旧版本。这顿时导致了开发、部署和管理的噩梦，所有工作都内置在应用本身。SOA 网关中的转换能力可以暴露一个新的映射，完成 REST 到 SOAP 的转换，实现这一功能仅需使用简单的、标准的转换能力和相关的 HTTP 配置——无需编码。SOA 网关还支持多个版本的服务同时运行，并且可根据用户、名字空间、甚至消息内容进行动态路由，所有转换都连接到同一后台接口，这对终端用户完全透明。

最后，任何服务端点中完成的数据仲裁都很难达到 SOA 网关所提供的简单性、扩展性、高性能以及高投资回报率（ROI）。

InfoQ：除了开箱即用的对安全协议的支持之外，还有那些非功能性方面促使 SOA 网关代替 ESB 产品？

安全的确是 SOA 网关最初的立足点，但它仍然非常重要。传输层安全、消息级安全、入侵保护、身份认证和访问控制——安全的确是一等公民，而且网关中有证书来证实这一点。已经我谈到在某个专门设备上执行转换和协议仲裁带来的性能上的优势；而当性能达到饱和时，即往集群中再扔进一台新设备，这远比安装新软件要受欢迎得多。实际上，当你开始将几十台传统的应用服务器替换成一台专门设备时，还能得到很多切实的环境及成本控制上的优势，比如数据中心容量、电力消耗、管理负载等。 易用性和灵活性可能是最重要的优势。在 SOA 网关上可创建策略，策略可执行复杂操作，如数字签名的验证、入侵保护、转换、基于内容的路由等，无需编写代码。功能需求是主要原因，但是真正让 SOA 网关胜出的是非功能需求。

查看英文原文： SOA Gateway: A Lightweight, Low-Cost Alternative to the ESB