软件架构设计 · SOA：定义、原则与关键技术

原文的立场是：迄今为止，对于面向服务的架构 SOA 还没有一个公认的定义，许多组织从不同角度进行了描述，较为典型的是三个。W3C 的定义：SOA 是一种应用程序架构，在这种架构中，所有功能都定义为独立的服务，这些服务带有定义明确的可调用接口，能够以定义好的顺序调用这些服务来形成业务流程。

Service-architecture.com 的定义：服务是精确定义、封装完善、独立于其他服务所处环境和状态的函数，SOA 本质上是服务的集合，服务之间彼此通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活动，服务之间需要某些方法进行连接。Gartner 的定义：SOA 是一种 C/S 架构的软件设计方法，应用由服务和服务使用者组成，与大多数通用的 C/S 架构模型不同之处，在于它着重强调构件的松散耦合，并使用独立的标准接口。

三个定义抓三个关键词：W3C 抓「独立的服务加可调用接口加形成业务流程」，Service-architecture.com 抓「服务的集合」，Gartner 抓「松散耦合加独立的标准接口」。问「哪个组织的定义强调松散耦合」，答 Gartner。

SOA 概述再记三句：SOA 是一种在计算环境中设计、开发、部署和管理离散逻辑单元即服务模型的方法；SOA 并不是一个新鲜事物，而只是面向对象模型的一种替代，虽然基于 SOA 的系统并不排除使用 OOD 来构建单个服务，但整体设计却是面向服务的；SOA 系统原型的一个典型例子是 CORBA。SOA 建立在 XML 等新技术的基础上，通过使用基于 XML 的语言来描述接口，CORBA 中的 IDL 无法与之相比。

SOA 的设计原则五条，逐条过。明确定义的接口：服务请求者依赖于服务规约来调用服务，因此服务定义必须长时间稳定，一旦公布不能随意更改，服务的定义应尽可能明确，减少请求者的不适当使用，不要让请求者看到服务内部的私有数据。自包含和模块化：服务封装了那些在业务上稳定、重复出现的活动和构件，实现服务的功能实体是完全独立自主的，独立进行部署、版本控制、自我管理和恢复。

粗粒度：服务数量不应该太多，依靠消息交互而不是远程过程调用，通常消息量比较大，但服务之间的交互频度较低。松耦合：服务请求者可见的是服务的接口，其位置、实现技术、当前状态和私有数据等，对服务请求者而言是不可见的。互操作性、兼容和策略声明：为了确保服务规约的全面和明确，策略成为一个越来越重要的方面，可以是技术相关的内容例如一个服务对安全性方面的要求，也可以是与业务有关的语义方面的内容例如需要满足的费用或者服务级别方面的要求。

是，粗粒度就怕你选成「细粒度、频繁调用」。接着服务构件。服务构件架构 SCA 是基于 SOA 的思想描述服务之间组合和协作的规范，它提供了构建粗粒度构件的机制，这些粗粒度构件由细粒度构件组装而成，还将传统中间件编程从业务逻辑分离出来。SCA 服务构件与传统构件的主要区别四条，逐条背：服务构件往往是粗粒度的，而传统构件以细粒度居多；服务构件的接口是标准的，主要是服务描述语言接口，而传统构件常以具体 API 形式出现；服务构件的实现与语言是无关的，而传统构件常绑定某种特定的语言；服务构件可以通过构件容器提供 QoS 的服务，而传统构件完全由程序代码直接控制。

现在进关键技术。与 SOA 紧密相关的技术主要有 UDDI、WSDL、SOAP 和 REST 等，而这些技术都是以 XML 为基础而发展起来的——这半句是总纲。先 UDDI：统一描述、发现和集成，提供了一种服务发布、查找和定位的方法，是服务的信息注册规范。

练习题第七题问「用于服务发布、查找和定位的规范」，答案就是 UDDI，干扰项 WSDL 是描述、SOAP 是传输、REST 是架构风格，各司其职别混。UDDI 规范主要包含三个部分：数据模型，是一个用于描述业务组织和服务的 XML Schema；API，是一组用于查找或发布 UDDI 数据的方法，UDDI API 基于 SOAP；注册服务，是 SOA 中的一种基础设施，对应着服务注册中心的角色。

再 WSDL：Web 服务描述语言，是对服务进行描述的语言，有一套基于 XML 的语法定义，描述的重点是服务，包含服务实现定义和服务接口定义。采用抽象接口定义对于提高系统的扩展性很有帮助：服务接口定义就是一种抽象的、可重用的定义，行业标准组织可以使用这种抽象的定义来规定一些标准的服务类型；服务实现定义描述了给定服务提供者如何实现特定的服务接口，其中包含服务和端口描述——一个服务往往会包含多个服务访问入口，每个访问入口都会使用一个端口元素来描述，端口描述的是一个服务访问入口的部署细节，例如通过哪个地址来访问、应当使用怎样的消息调用模式来访问等。

然后 SOAP：简单对象访问协议，定义了服务请求者和服务提供者之间的消息传输规范。SOAP 用 XML 来格式化消息，用 HTTP 来承载消息，通过 SOAP，应用程序可以在网络中进行数据交换和远程过程调用 RPC。SOAP 协议本身主要包括四个部分：封装，定义了一个整体框架，用来表示消息中包含什么内容、谁来处理这些内容以及这些内容是可选的还是必需的；编码规则，定义了一种序列化的机制，用于交换系统所定义的数据类型的实例；RPC 表示，定义了一个用来表示远程过程调用和应答的协议；绑定，定义了一个使用底层传输协议来完成在节点之间交换 SOAP 封装的约定。

对，仔细听，这题坑就在「必须」二字。SOAP 消息基本上是从发送端到接收端的单向传输，但常常结合起来执行类似于请求/应答的模式，所有 SOAP 消息都使用 XML 进行编码。消息包括三个部分：封装即信封，元素名是 Envelope，在表示消息的 XML 文档中是顶层元素，在 SOAP 消息中必须出现；SOAP 头，元素名是 Header，提供了向 SOAP 消息中添加关于这条消息的某些要素的机制，可能出现也可能不出现，如果出现必须是 SOAP 封装元素的第一个直接子元素；SOAP 体，元素名是 Body，是包含消息的最终接收者想要的信息的容器，必须出现且必须是 SOAP 封装元素的直接子元素。

没错，Body 里如果有错误信息会用到 Fault 元素，但它不是消息的组成部分名称，这个偷换要看穿。最后 REST：表述性状态转移，是一种只使用 HTTP 和 XML 进行基于 Web 通信的技术，可以降低开发的复杂性，提高系统的可伸缩性。它的简单性和缺少严格配置文件的特性，使它与 SOAP 很好地隔离开来，REST 从根本上来说只支持几个操作：POST、GET、PUT 和 DELETE，这些操作适用于所有的消息。

REST 的设计概念和准则五条，练习题第九题就从里面抽：网络上的所有事物都被抽象为资源；每个资源对应一个唯一的资源标识；通过通用的连接件接口对资源进行操作；对资源的各种操作不会改变资源标识；所有的操作都是无状态的。第九题问「不包括」，给的干扰是「必须使用 SOAP 协议进行消息传输」——REST 恰恰是摆脱 SOAP 的轻量方案，它只用 HTTP 和 XML，这一条错得明明白白。

信息量爆炸，但都是原题级考点，值得。下一集讲 SOA 的实现方法：Web Service 的三种角色和发布查找绑定三个操作、六层结构、服务注册表、企业服务总线 ESB 的功能与优势，最后压轴微服务——练习题第十一题在那里。