微观 SOA：服务设计原则及其实践方式（上篇）

大量互联网公司都在拥抱 SOA 和服务化，但业界对 SOA 的很多讨论都比较偏向高大上。本文试图从稍微不同的角度，以相对接地气的方式来讨论 SOA，集中讨论 SOA 在微观实践层面中的缘起、本质和具体操作方式，另外也用相当篇幅介绍了当今互联网行业中各种流行的远程调用技术等等，比较适合从事实际工作的架构师和程序员来阅读。

为了方便阅读，本话题将分为两篇展现。本文是上篇，着眼于微观 SOA 的定义，并简单分析其核心原则。

亚马逊 CEO 杰夫•贝佐斯：鲜为人知的 SOA 大师

由于 SOA 有相当的难度和门槛，不妨先从一个小故事说起，从中可以管窥一点 SOA 的大意和作用。

按照亚马逊前著名员工 Steve Yegge 著名的“酒后吐槽”，2002 年左右，CEO 贝佐斯就在亚马逊强制推行了以下六个原则（摘自酷壳）：

1. 所有团队的程序模块都要以通过 Service Interface 方式将其数据与功能开放出来。
2. 团队间的程序模块的信息通信，都要通过这些接口。
3. 除此之外没有其它的通信方式。其他形式一概不允许：不能使用直接链结程序、不能直接读取其他团队的数据库、不能使用共享内存模式、不能使用别人模块的后门、等等，等等，唯一允许的通信方式只能是能过调用 Service Interface。
4. 任何技术都可以使用。比如：HTTP、Corba、Pubsub、自定义的网络协议、等等，都可以，贝佐斯不管这些。
5. 所有的 Service Interface，毫无例外，都必须从骨子里到表面上设计成能对外界开放的。也就是说，团队必须做好规划与设计，以便未来把接口开放给全世界的程序员，没有任何例外。
6. 不这样的做的人会被炒鱿鱼。

据说，亚马逊网站展示一个产品明细的页面，可能要调用 200-300 个 Service，以便生成高度个性化的内容。

Steve 还提到：

Amazon 已经把文化转变成了“一切以 Service 第一”为系统架构的公司，今天，这已经成为他们进行所有设计时的基础，包括那些绝不会被外界所知的仅在内部使用的功能。

那时，如果没有被解雇的的恐惧他们一定不会去做。我是说，他们今天仍然怕被解雇，因为这基本上是那儿每天的生活，为那恐怖的海盗头子贝佐斯工作。不过，他们这么做的确是因为他们已经相信 Service 这就是正确的方向。他们对于 SOA 的优点和缺点没有疑问，某些缺点还很大，也不疑问。但总的来说，这是正确的，因为，SOA 驱动出来的设计会产生出平台（Platform）。

今天，我们都知道亚马逊从世界上最大图书卖场进化为了世界上最成功的云平台……

贝佐斯的六原则展示出高度的远见和超强的信念，即使放到十几年后的今天，依然觉得振聋发聩……想起一句老话：“不谋万世者，不足以谋一时；不谋全局者，不足以谋一隅。”

当然，像贝佐斯这种将神性与魔性集于一身的专横人物，既可能创造划时代的进步，也可能制造前所未有的灾难。

SOA 漫谈：宏观与微观

SOA 即面向服务架构，是一个特别大的话题。

为了方便讨论，我在此先草率的将 SOA 分为两个层面（大概模仿宏观和微观经济学，但这里的划分没有绝对界限）：

• 宏观 SOA：面向高层次的部门级别、公司级别甚至行业级别；涉及商业、管理、技术等方面的综合的、全局的考虑；架构体系上包括服务治理（governance，如服务注册，服务监控），服务编排（orchestration，如 BPM，ESB)，服务协同（choreography，更多面向跨企业集成）等等。我认为 SOA 本身最主要是面向宏观层面的架构，其带来益处也最能在宏观高层次上体现出来，同时大部分 SOA 的业界讨论也集中在这方面。
• 微观 SOA：面向有限的、局部的团队和个人；涉及独立的、具体的服务在业务、架构、开发上的考虑。

很多业界专家都认为 SOA 概念过于抽象，不接地气，我认为主要是宏观 SOA 涉及面太广，经常需要做通盘考虑，而其中很多方面距离一般人又比较远。而在微观层面的 SOA 更容易达到涛哥过去提出的“三贴近”：贴近实际、贴近生活、贴近群众。

同时，宏观 SOA 要取得成功，通常的前提也是 SOA 在微观层面的落地与落实，正如宏观经济学一般要有坚实的微观基础（比如大名鼎鼎的凯恩斯主义曾广受诟病的一点就是缺乏微观基础）

因此，我们着眼于 SOA 落地的目的，着重来分析微观 SOA，也算是对业界主流探讨的一个小小的补充。

SOA 定义

按照英文维基百科定义：SOA 是一种“软件”和“软件架构”的设计模式（或者叫设计原则）。它是基于相互独立的软件片段要将自身的功能通过“服务”提供给其他应用。

什么是“服务”？按照 OASIS 的定义：Service 是一种按照既定“接口“来访问一个或多个软件功能的机制（另外这种访问要符合“服务描述”中策略和限制）

Service 示例（代码通常以 java 示例）

 
public interface Echo {
   String echo(String text);
}
 
public class EchoImpl implements Echo {
   public String echo(String text) {
       return text;
   }
}

可能每个开发人员每天都在写类似的面向对象的 Service，难道这就是在实施 SOA 吗？

SOA 设计原则

既然 SOA 是设计原则（模式），那么它包含哪些内容呢？事实上，这方面并没有最标准的答案，多数是遵从著名 SOA 专家 Thomas Erl 的归纳：

标准化的服务契约 Standardized service contract 服务的松耦合 Service loose coupling 服务的抽象 Service abstraction 服务的可重用性 Service reusability 服务的自治性 Service autonomy 服务的无状态性 Service statelessness 服务的可发现性 Service discoverability 服务的可组合性 Service composability …

这些原则总的来说要达到的目的是：提高软件的重用性，减少开发和维护的成本，最终增加一个公司业务的敏捷度。

但是，业界著名专家如 Don Box，David Orchard 等人对 SOA 又有各自不同的总结和侧重。

SOA 不但没有绝对统一的原则，而且很多原则本身的内容也具备相当模糊性和宽泛性：例如，所谓松耦合原则需要松散到什么程度才算是符合标准的呢？这就好比一个人要帅到什么程度才算是帅哥呢？一栋楼要高到多少米才算是高楼呢？可能不同人心中都有自己的一杆秤……部分由于这些理论上的不确定因素，不同的人理解或者实施的 SOA 事实上也可能有比较大的差别。

浅析松耦合原则

SOA 原则比较多，真正的理解往往需要逐步的积累和体会，所以在此不详细展开。这里仅以服务的松耦合为例，从不同维度来简单剖析一下这个原则，以说明 SOA 原则内涵的丰富性：

• 实现的松耦合：这是最基本的松耦合，即服务消费端不需要依赖服务契约的某个特定实现，这样服务提供端的内部变更就不会影响到消费端，而且消费端未来还可以自由切换到该契约的其他提供方。
• 时间的松耦合：典型就是异步消息队列系统，由于有中介者（broker），所以生产者和消费者不必在同一时间都保持可用性以及相同的吞吐量，而且生产者也不需要马上等到回复。
• 位置的松耦合：典型就是服务注册中心和企业服务总线（ESB），消费端完全不需要直接知道提供端的具体位置，而都通过注册中心来查找或者服务总线来路由。
• 版本的松耦合：消费端不需要依赖服务契约的某个特定版本来工作，这就要求服务的契约在升级时要尽可能的提供向下兼容性。

SOA 与传统软件设计

我们可以认为：SOA ≈ 模块化开发 + 分布式计算

将两者传统上的最佳实践结合在一起，基本上可以推导出 SOA 的多数设计原则。SOA 从软件设计（暂不考虑业务架构之类）上来讲，自身的新东西其实不算很多。

SOA 原则的应用

基于 SOA 的原则，也许我们很难说什么应用是绝对符合 SOA 的，但是却能剔除明显不符合 SOA 的应用。

用上述标准化契约，松耦合和可重用这几个原则来尝试分析一下上面 Echo 示例：

• Echo 的服务契约是用 Java 接口定义，而不是一种与平台和语言无关的标准化协议，如 WSDL，CORBA IDL。当然可以抬杠，Java 也是行业标准，甚至全国牙防组一致认定的东西也是行业标准。
• Java 接口大大加重了与 Service 客户端的耦合度，即要求客户端必须也是 Java，或者 JVM 上的动态语言（如 Groovy、Jython）等等……
• 同时，Echo 是一个 Java 的本地接口，就要求调用者最好在同一个 JVM 进程之内……
• Echo 的业务逻辑虽然简单独立，但以上技术方面的局限就导致它无法以后在其他场合被轻易重用，比如分布式环境，异构平台等等。

因此，我们可以认为 Echo 并不太符合 SOA 的基本设计原则。

透明化的转向 SOA？

修改一下上面的 Echo，添加 Java EE 的 @WebServices 注解（annotation）

 
@WebServices
public class EchoImpl implements Echo {
   public String echo(String text) {
       return text;
   }
}

现在将 Echo 发布为 Java WebServices，并由底层框架自动生成 WSDL 来作为标准化的服务契约，这样就能与远程的各种语言和平台互操作了，较好的解决了上面提到的松耦合和可重用的问题。按照一般的理解，Echo 似乎就成为比较理想的 SOA service 了。

但是……即使这个极端简化的例子，也会引出不少很关键的问题，它们决定 SOA 设计开发的某些难度：

• 将一个普通的 Java 对象通过添加注解“透明的”变成 WebServices 就完成了从面向对象到面向服务的跨越？
• 通过 Java 接口生成 WSDL 服务契约是好的方式吗？
• WebServices 是最合适远程访问技术吗？

面向对象和面向服务的对比

面向对象（OO）和面向服务（SO）在基础理念上有大量共通之处，比如都尽可能追求抽象、封装和低耦合。

但 SO 相对于 OO，又有非常不同的典型应用场景，比如：

• 多数 OO 接口（interface）都只被有限的人使用（比如团队和部门内），而 SO 接口（或者叫契约）一般来说都不应该对使用者的范围作出太多的限定和假设（可以是不同部门，不同企业，不同国家）。还记得贝佐斯原则吗？“团队必须做好规划与设计，以便未来把接口开放给全世界的程序员，没有任何例外”。
• 多数 OO 接口都只在进程内被访问，而 SO 接口通常都是被远程调用。

简单讲，就是 SO 接口使用范围比一般 OO 接口可能广泛得多。我们用网站打个比方：一个大型网站的 web 界面就是它整个系统入口点和边界，可能要面对全世界的访问者（所以经常会做国际化之类的工作），而系统内部传统的 OO 接口和程序则被隐藏在 web 界面之后，只被内部较小范围使用。而理想的 SO 接口和 web 界面一样，也是变成系统入口和边界，可能要对全世界开发者开放，因此 SO 在设计开发之中与 OO 相比其实会有很多不同。

小结

在前述比较抽象的 SOA 大原则的基础上，我们可尝试推导一些较细化和可操作的原则，在具体实践中体现 SO 的独特之处。请关注本系列文章的下篇！

作者简介

沈理，当当网架构师和技术委员会成员，主要负责当当网的 SOA 实施（即服务化）以及分布式服务框架的开发。以前也有在 BEA、Oracle、Redhat 等外企的长期工作经历，从事过多个不同 SOA 相关框架和容器的开发。他的邮箱： shenli@dangdang.com

感谢马国耀对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。