探求真正的 SOA

从第一次读到罗斯尼·安（J.H. Rosny Aine）的《求火（Quest for Fire）》开始，我就一直着迷于这种“探求”风格的作品。在我看来，一个探求类故事的精髓，就是一组形形色色的人，他们开始一段漫长而艰险的历程，试图寻找难以发现的目标，最终却找到了别的东西，而这个意外的收获通常比原来要找的东西更有价值、更重要。无论是《绿野仙踪》还是《指环王》，我总无法抗拒被这类故事深深感染。

我认为把我关于 SOA 的看法的演变过程比喻为“探求”是相当贴切的，而且“探求”也解释了我对治理的愿景与业界流行看法不同的原因。在 2004 年秋，我在一家主要的 EAI/SOA 平台厂商工作。那时 SOA 很热，于是依据市场需求，我们的产品被定位为 SOA。不用说，我们的竞争对手们也都声称自己的产品是 SOA。然而，随着我们完成越来越多的企业级实现，我们发现，很明显市场讯息不完全对。如果你采用我们的产品、采取我们的方法、按照我们的指导方针与最佳实践（即便采用我们的专业服务）去实施的话，最终得到的将不是 SOA，至少不是原本预料的 SOA。没错，它能完成一定的功能并满足最初的特定目标，但至于履行已展望多年的 SOA 最初承诺，它就不行了。SOA 承诺将提供多用途的、粗粒度的、松耦合的、可动态发现的、易于组合的、易于重用的服务，正是这种承诺使得 SOA 的概念如此受到业务与 IT 部门的青睐，从而令 SOA 成为 CIO 们的战略计划、RFI/RFP 及产品特性列表中不可或缺的一项。我不是在批评我们的产品——当时别的厂商能给自己的产品贴上 SOA 的标签，我们当然也能。问题出在 SOA 定义自身。当这个概念流行起来时，大家都在竞相“实现”它。于是，厂商和 IT 机构们开始按照它们自己所能支持的方案，悄悄地改动 SOA 的定义。结果，人人都实现了 SOA，但几乎没人能从中受益。

基于这一背景，我们团队提出了一个经验性的问题：如何才能构建一个大家都认为符合 SOA 特征的平台呢？我们写了一份长达 40 页的白皮书来回答这一问题，并阐述了我们对 SOA 的看法，我们认为企业级 SOA 服务应当具备以下核心特征与支撑设施：

1. 服务的自包含性与模块性：包括模块可分解性（modular decomposability）、模块可组合性（modular composability）、模块可理解性（modular understandability）、模块化连续性（modular continuity）以及模块保护性（modular protection）；
2. 服务、消费者、基础设施、工具及遗留应用间的互操作性；
3. 消费者与提供者间的松耦合性；
4. 支持编配（Orchestration）及服务的可组合性；
5. 服务的可发现性，以及消费者与提供者间的动态绑定；
6. 服务、消费者及基础设施组件的位置透明性；
7. 无处存在的安全性：通过解决认证、授权、完整性、保密性、可问责性、身份识别及策略等问题中的一些或全部，在设计上确保 SOA 环境（包括服务、消费者、代理、合成应用、基础设施等）中的信任；
8. 支持可续航性（Sustainability）和自恢复性（Self Healing），包括监测、预测和缓解不期而至的意外行为和状况的能力，以及按需获取与释放资源的能力；
9. 服务版本化：通过允许同时存在不同版本的服务实现和消费者，支持 SOA 环境的演化；
10. 服务租用：显式定义并维护服务消费者与提供者之间的关系，并消除可能存在不利的相互假设（mutual assumptions）；
11. 网络可寻址的服务接口：具有灵活的调用机制，支持多种传输、协议及同步选项，以营造一个有活力的、多用途的 SOA 环境；
12. 粗粒度的服务接口：可以利用它们轻松地支持许多种服务消费环境；
13. 服务使用计量（实时的和历史的）；
14. 服务及其实现的监控、管理与控制；
15. 支持相关性与根源分析的异常与警报处理；
16. 有效的服务虚拟化，确保服务接口与服务实现的彻底分离；
17. 公开的、可核实的和可实施的服务质量（QOS），包括性能、可靠性、可用率、制度性、可访问性、完整性及安全性等等；

以上列出的这些，为我们评估 SOA 产品及实现的成熟度与完整性提供了一个很好的尺度。当我们用它来评价我们的旗舰产品时，得分仅为 40±5%（具体得分取决于你想给予自己的代码多少宽容）。于是，不用说，我们开始为争取“剩下那 60%”而努力。直到 2005 年秋 1.0 版发布之前，我们都是如此称呼我们所做的工作的。

正当我们要开始努力时，我们发现上述特征列表里漏了几项。不过，“SOA 的 19 项核心特征”听起来不如“17 项核心特征”好听，于是我们称之为“17+ 项核心特征”——我们正是这样偶然得到基于方面的 SOA（Aspect-Based SOA）基础设施这个想法的。此想法是基于这样一个前提，即我们无法列举出 SOA 服务——作为适当的企业计算平台——所应具备的全部特征，是有其根本原因。这个原因就是：这些特征是基于实际的业务、制度等需求的，而这些需求是因行业、地理、时间及各个客户的具体情况而变的。市场所需要的，是一个可以实现和支持任意项服务特征的平台，而且要允许用户根据当前的业务需要（或甚至自由地）对这些服务特征进行增加、修改和删除。

这个相当荒唐的想法居然得到了我们第一个客户的首肯。这个来自部队的客户，即使按照军方标准衡量也算相当偏执的了，他们拿出了一份很长的关于安全性需求的列表，其中大部分我们都能做到（要么直接支持，要么可以推给他们自己的安全基础设施）。但是有一项需求让我相当吃惊：该客户想防止一个写得很差的服务意外地把机密信息泄露给合法的、通过正确认证且经过适当授权的、但还尚未得到充分批准的用户。我的原始反应是：雇用优秀的开发人员，开展严格的质量保证（QA）活动，那么就没问题了！然后我意识到，在这个客户看来，解决意外泄露，跟受到别的行业重视的其他服务特征同样重要。于是，我在一小时之内设计好了一个审查方面（Censorship Aspect），它检查所有发给客户的服务响应，判断消息或各个片断的分类级别，将之与客户概要（在来访认证的过程中创建起来）中的许可级别进行对比，然后进行必要的纠正活动：或者隐藏部分信息，或者完全拦截。

其间，随着 1.0 版的发布，市场部需要一个名称来称呼它（由于某些莫名其妙的原因，他们不再热衷于围绕“剩下那 60%”而努力了）。他们先是想到了 SOAi 和 SOAf（分别代表基础设施与基础），之后又有人提出了治理（Governance）（也许是因为当时这个词正逐渐时髦起来）。当时我还不熟悉这个词，所以在 Google 里搜索了一下，但怎么也无法理解它跟我们所开发的技术有什么关系。那时我的主要忧虑是：明确的定义没几个，含糊的定义却一大堆。

大部分厂商只是按照自己的能力范围来定义 SOA 治理。Systinet 公司当时推行这样的观点，即 SOA 治理是一个用于 WSDL 的记录系统，它们提供了支持分类层次、发布工作流及订阅 / 通知机制的制品（artifacts）。AmberPoint 将 SOA 治理看成一种自动发现依赖关系及“流氓服务”的机制，以及一种轻量级安全、监控和端到端错误分析的机制。设备厂商们（appliance vendors）将治理看成 Web 服务安全以及他们所拥有的媒介功能。所谓的专家们不断地提出朦胧而模糊的定义，比如下面这个令 Pythia 引以为豪的 OASIS SOA 参考模型里的定义：

SOA 治理：通过结构化的关系、适合本机构的步骤与策略、以及分布式能力（可能处于不同控制域之下）的运用，来确保结果符合可测量的前提与预期的技术与原则。

经过一番思索之后，我觉得我们对 SOA 的理解就像是盲人摸象，都不够全面，于是我开始试图探求一个全面的定义。在本文剩余部分，我将给出 SOA 的定义，然后将 SOA 治理的愿景描述为该 SOA 的标志特征，另外我们也会通过一个例子来举例说明。

既然整个 SOA 问题域都充斥着模糊的术语，那么我们就先提出一些关键定义吧。首先，我们要看要治理的是什么。答案是显而易见的：当然是服务！然而，这一术语已被用于描述太多不同事物了，其中许多都跟 SOA 关系不大，所以我觉得有必要澄清这个概念——我通常的做法是给它增添一些限定。

一个企业服务就是一个自包含的组件，它提供业务功能，并具有一组可扩展的非功能性的、基于策略的特性（比如安全性、行业 / 客户定义的服务策略、管理、监控，生命周期管理等），它通过一个良好定义的、标准的、公开的接口来响应请求。

另一种描述企业服务的方式是：一个名称为 CEO 或业务总管所熟悉、而且其具体功能受到后者关注的服务。按照这一定义， invoiceCustomer、dischargePatient 和 launchICBM 等都是企业服务，而 invokeBAPI、 saveLogRecord 和 generateToken 等则不是。参照该定义，SOA 本身可被描述为：

一种提供并促使企业 IT 朝着企业服务环境的方向演化的架构风格。

最后，SOA 治理就成为：

通过流程、实践与工具相结合，推动企业服务的生命周期，并提供方法来创建、传达、贯彻和管理目前对公司很重要的、关于非功能性服务特征的公司策略。

按照以上定义，SOA 治理就是通过实现跨 SOA 参与者控制域边界的合理重用、把企业服务（Enterprise Services）从数字制品转变为现实业务制品的活动。为便于理解，我们举一个例子。

设想有一家名为热狗有限公司的跨国公司，它们有面包研究部和香肠开发部两个业务部门。这两个业务部门都有独立的管理团队、盈亏责任、IT 部门及预算，只是在同一公司实体下运作。

某个时候，面包研究部的领导层决定实现一个新的应用来执行他们的核心业务功能。他们为实现这一任务花费了一百万美元。为了整个公司的利益，他们另外花了五万美元，以可重用服务的形式将新开发的功能包装并发布出来。

次年，香肠开发部的管理团队觉得他们需要构建一个新的应用来执行他们的核心业务，而面包研发部六个月前开发、包装、部署并发布的功能刚好可以满足他们的需要。[跟书本里的 SOA 业务案例颇为相似，是吧？] 香肠开发部的 IT 部门现在有两个选择，要么重用面包研发部的服务，要么自己重新花一百万美元开发一套。我敢保证，如果下层技术采用的是 CORBA 或无治理的（按照前面的定义）SOA，那么对香肠开发部来说，唯一合理的做法是花钱实现处于自己控制域下的功能。这样做的理由是：原来的服务是由面包研究部实现并发布的，所以尽管那些服务在功能上 100% 符合需求，但对于以下这些决定“那些服务能否为香肠开发部业务环境所用”至关重要的因素，香肠开发部无法得知：

• 预期的可用率、可靠性、平均故障间隔时间（MTBF）及修复时间怎样？
• 现有的安全性和可问责性是什么样的？
• 那些服务实现已经通过审核并经证实符合相关条例（如美国的 SOX，欧洲关于隐私的规定以及健康方面的 HIPAA 等）了吗？
• 支持什么样的性能水平？能够接受什么样的负载水平？
• 那些服务是永久性的吗？会不会随日期、星期或季节等有所变化？
• 对服务使用是如何进行计量和记账的？

即便香肠开发部的管理团队从面包研究部的同事那里得到了所有这些信息，仍存在一个至关重要的问题：我们怎么知道这些信息会不会在下周（也许是下个月或下一年）发生改变呢？

当我们的思考过程结束，并最终形成以上对 SOA 治理的看法时，有几件事变得明了了（至少对我们是这样）：

1. 与爱因斯坦相对论扩展牛顿经典力学、并形成后者所不适用的范围相似，这个对 SOA 治理的统一观点并非否定前面提到的、以及我在《SOA governance – the perspectives》这篇文章里详细描述过的那些零碎的定义与方法，相反，它而是构筑在后者基础之上的。
2. 若正确实现的话，这种 SOA 治理观点将为你带来一个能够符合前面提到的全部“17+ 项企业 SOA 核心特征”的方案。
3. 这样一种方案，能够把有缺陷的 SOA 平台与实现改造为真正的面向服务的架构（SOA），从而实现 SOA 的最初设想，并兑现所有承诺的优点。

最后，这一治理平台的构建其实比我们想象的要简单。而且，正如“探求”风格的特点，我们在这一过程中发现了许多预料外的、有价值的东西，比如委托治理（Delegated Governance）、分析时治理（Analysis-time Governance）、改建项目友好的治理（Brownfield-friendly Governance）和统一治理信息模型（unified Governance Information Model）等，这些为我们后续的文章提供了不错的主题。

查看英文原文： Quest for True SOA 。

志愿参与 InfoQ 中文站内容建设，请邮件至 editors@cn.infoq.com 。也欢迎大家到 InfoQ 中文站用户讨论组参与我们的线上讨论。