篇首语    Editor’s letter 

寻找内在的力量 
习武之人讲究内功的修炼，招式的“强”不一定是真正的“强”，有时候稳定的内在力量才是更
为持久的力量。恰巧最近读过的几本杂志、书籍都或多或少地强调了“内省”和“思考”，窃以
为他们便是两种强大的内在力量。 

世界的联通让知识的传播越来越容易、也越来越迅速，面对日新月异的科技变革，如何驾驭
自己、令自己能如磐石般坚毅呢？随大流，貌似简单而安全。但当我们习惯了从众，很多思
维和行为也会慢慢变为惯性，这让我们觉得放心和舒服，却阻碍我们去思考、提出质疑，我
们也就难以形成自己的价值观、难以专心地在自己的行业前进了。 

试着往“里”看看吧，勇敢并实事求是地了解、审视、反省一下自己。对自己有正确的认识，
才能更好地自我调节和进步——反求诸己就是这么重要和有用。 

当然，更为重要的是，我们还要用自己的头脑思考，对周围形形色色的信息进行甄别，有所
为、有所不为。思考能让我们提出质疑，能让我们更为全面和正确地认识这个世界、理解各
种问题，也能让我们以自省的精神和开放的态度去审视自己。 

本期主编：王丽娟

i 
  

目      录 
[篇首语] 

寻找内在的力量.............................................................................................................................. I 

[人物专访] 
PHILIPPE KRUCHTEN谈论架构和技术债务.......................................................................... 1 

[热点新闻] 

RUBYGEMS.ORG取代RUBYFORGE成为GEM托管站点 ....................................................... 7

PYTHON有望成为金融语言 ....................................................................................................... 9

IPHONE开发者许可变更：反响强烈、结果难料................................................................10

独立的BPMS当真已逝？ ...........................................................................................................14

与JOSH BLOCH探讨JAVA未来..................................................................................................16

讨论：当前运维团队在软件开发中的角色 ...........................................................................20 

[推荐文章] 

你是个软件架构师吗？..............................................................................................................31

DSL的演进.....................................................................................................................................38

SCOUT ­  可扩展的服务器和应用监控服务 ..........................................................................45

基于上下文图的策略性领域驱动开发....................................................................................51

MYSOA：敏捷的、治理的并且可持续的 ..............................................................................68 

[新品推荐] 

FAI：LINUX的自动安装、管理和自定义工具 .....................................................................96

ii 
 
  

MONGODB不断发展：发布 1.4 版本，10GEN提供商业支持.........................................96

MAVEN、ANT、RAKE：JRUBY 1.5 加强配置管理 ...........................................................96

IRONRUBY 1.0 发布 ...................................................................................................................97

INTERNET EXPLORER 9 预览：新特性与分析 ..................................................................97

与JIM MARINO谈FABRIC3 1.5 版的发布 .............................................................................97

W3C发布XML新标准：XPROC................................................................................................98

ANDROID 2.2 新特性综述 ........................................................................................................98

MAHOUT 0.3:  机器学习开源项目..........................................................................................98 

[特别专题：那云，那计算] 

云计算七问七答........................................................................................................................ 100

OOPSLA辩论：被高估的云计算........................................................................................... 107

IBM院士谈云计算和云计算................................................................................................... 110

评论：微软的新云计算战略 .................................................................................................. 114

微软专家ERIC NELSON谈WINDOWS AZURE .................................................................. 116

谷歌工程师谷雪梅谈云计算 .................................................................................................. 120

云计算的虚拟研讨会 ............................................................................................................... 125 

[封面植物] 

太行花 ......................................................................................................................................... 135

iii 
 
 欢迎免费下载

商务合作：sales@cn.infoq.com 读者反馈/内容提供：editors@cn.infoq.com
  

人物专访    Interview

Philippe Kruchten谈论架构和技术债务 
Philippe 最近在 SDC 大会上讲述了关于架构的重要性，架构和敏捷方法的关系，以及技术债
务的影响。他讨论了一些敏捷和纪律之间，以及敏捷和架构之间的虚假对立。他也强调了上
下文在选择软件开发方法时的重要性。 

Philippe 是温哥华英属哥伦比亚大学软件工程学的教授。在他现在的工作之前，
他为 Rational 软件（现在是 IBM）工作了 16 年，在那里他是加拿大空中交通控
制系统的首席架构师，后来领导了 RUP 的开发。 

InfoQ：这里我们请到了英属哥伦比亚大学软件工程学的教授 Philippe Kruchten。Philippe，
你能不能向我们简单介绍一下你的背景以及你和软件工程的关系？ 

Philippe：我本来并没有计划做一名软件工程师。事实上，当我涉足软件圈时，正在努力成
为一名机械工程师。在我距离拿到机械工程本科学位还有几个月的时候，IBM 雇佣了我，后
来就那样了。现在我已经很难彻底脱离软件产业，毕竟，在 70 年代，那个行业是看起来最
有钱的地方。我为 IBM 工作了很短暂的时间，然后在法国电信研究院做了一些研究，在那
里学习了一些软件。我也去了阿尔卡特，在那里学到了很多东西，因为那正是开始使用计算
机的时候，特别是使用大规模联网的微机，来使电话交换机精确转换，以及使其他很多电信
相关的东西工作得更好。 

那是一段用大量软件建造大型软件系统的重要学习经历，有很多关于“性能”的讲法，比如
“可用性”“可靠性”等等。 

之后，我来到 Rational 软件，主要以软件咨询师的身份在大型指挥控制系统中做软件架构师。

我一开始在欧洲各国工作，然后在太平洋区的某个地方，最后作为加拿大交通控制系统的首
席架构师在温哥华工作。当我 5 年后结束这份合同时，我开始了当时称为“Rational 方法
（Rational Approach）
”的开发，但这之后被称为“Rational 对象过程（Rational Objectory 
Process）”，最后改名为“Rational 统一过程（Rational Unified Process）”。我在那里工作了 5

1 
  

年，直到 IBM 并购了 Rational 我才离开。然后我达到了“彼得原理”（注【1】）中最终无以

胜任的那一级——  教导本科生。 

InfoQ：我肯定这不仅仅是教导本科生而已。Rational 统一过程和敏捷的世界似乎被看做是直
接对立的。你曾经在敏捷方法刚刚出现的时候写了一篇文章，把很多敏捷相关的东西和
Rational 统一过程联系起来。你是如何跨越这两者的鸿沟的？ 

Philippe：我并不觉得它们两者是完全对立的。它们分别在不同的背景、不同的项目中产生，
但是统一过程可以用很敏捷的方式使用，也可以用很愚蠢的方式使用。你甚至可以用完全荒
谬的方式使用它。有个人又一次告诉我“哦，是的，初始（inception），这是我们写需求的
时候。精化（elaboration），这是我们做设计的时候。构建（construction），这是我们写代码
的时候。”是的，你可以以一种荒谬的方式使用它。 

我觉得 RUP 包含了很多敏捷的原则。它虽然没有像敏捷方法一样有一些对人的关注，但是

可以从迭代开发、开发流程中引入的纪律、运用于多种环境的流程等方面看出来，而这些也
是人们没有注意到也没有做到的地方。他们试图用“开箱即用（out of the box）”的方式来
使用 RUP。“哦，天哪！定义了 27 个目标，但我们只有 6 个人！我们怎么办啊？”“定义了
37 个工作产品，我们怎么办？”我们开发  RUP 的任何人，都没有想把它当做类似于你打开
一个盒子，然后按照里面所写的全部东西来做的事物。它更像一些实践的目录，你可以选择
特定项目所需要的实践。 

我对一些敏捷方法有相似的感觉。它们在适合它们运作的环境下产生。所以当你在类型相似
的项目，大小相同的团队中使用它们时，会很奏效。但如果你把它们延伸至完全不同的背景
下时，你会开始碰到一些困难。它们会变成“有一些尚待解决问题”的工具。通常，人们希
望通过采取作者定义的所有实践，无论是 RUP 还是 XP 还是 Scrum，来解决他们项目中的所
有问题。事实上，我认为你应该反过来做  ：问问自己我们遇到的困难是什么？我们可以从
哪里得到一些改善？然后采取能解决问题的流程元素和实践。 

InfoQ：我听到你不止一次地提到“有纪律的敏捷”的概念。你能告诉我们那是什么吗？ 

Philippe：我在一个相对大型的复杂系统中学习软件，我们有庞大的团队，有些时候系统的
安全性很关键。你必须要有一些纪律！想象一下，你不能只是跟别人说说话，做些结对编程，
让设计随着沟通和重构渐进。你需要有一些预测性，你需要能够证明你达到了一些之前定义
的质量标准。我觉得这和一些敏捷原则是完全兼容的，像交流、迭代、循环反馈、从自己的
进展和错误中学习等等。你可以把这两者结合使用。我觉得 Barry Boehm 把书命名为“平衡
敏捷和纪律（Balancing Agility and Discipline）”是件很遗憾的事情，这让他们看起来是对立的。

2 
 
  

我觉得你必须有一些相对的纪律性，才能使敏捷开发获得成功。 

InfoQ：关于敏捷和架构，很多敏捷方法暗示我们需要容许架构的渐进。 

Philippe：哦，是的，那是另外一个决定于上下文的问题。很多很多的项目，可能 80% ‐ 85%
的软件项目，它们的架构是在第一天到位的。当你开始你的项目时，重大的问题已经决定了，
像语言、平台、框架，以及你能想到的其他的。对于架构的疑虑可能只对一小部分软件开发
项目适用。你要敏捷，以及你要重视架构可能又是一组虚假对立。你可以都做！ 

架构，是指做一些对于系统有长远影响的重要决定。如果你忽视架构，而只是赶快把可见的
功能点开发出来，那你很快就会陷入技术债务。当然，你可能快到第一次发布的时间点了。
但是如果你不重视架构，如果你总是以“哦，这是庞大的预先设计（BDUF）”，
“你们不会需
要它  (YAGNI)”，
“让我们推迟到最后负责时刻（last responsible moment）再说”为理由拒绝
架构设计，那你可能能够完成第一次发布，但之后你会受困于许多技术债务。 

架构上的决定，或者以前做的决定，是很难在以后挽回的。团队中一些人，也许不是所有人，
必须持续关注架构。大多数架构难点都和质量参数有关，而不是功能需求。这是我们实现安
全性、可扩展性、可维护性、高可用性系统的方法，也是有很多艰难决定的地方。 

仅仅是用 Scrum 来驱动项目，从 backlog 中拿一些东西出来做，在 sprint 结尾的时候演示，

可能会过早地把你引入技术债务。当然这还是取决于背景和上下文。在有些背景中，对架构
的关注是重要的，在其他的背景中，架构并无所谓，只要好到我们能做我们的事就可以了。 

InfoQ：你很强调上下文和选择的重要性。这是不是你今天想要传递的关键信息？ 

Philippe：是的，这是我要传递的重要消息之一。北美的地产商说：房地产有 3 大重要因素：
位置、位置和位置。我觉得我们应该注重上下文、上下文和上下文。有人认为我们会在某天
找到某个绝顶聪明的软件开发者，他将勾画出能替代所有方法的终极方法  ‐‐  我不相信！我
们当今工作的软件产业中有太多种完全不同的软件开发类型，无论从商业领域、项目大小、
难度或是质量参数、复杂度，都有着巨大的不同。我们找不到一种方法能适用于全部。我们
必须从现有的方法和实践中学习，理解它们所能解决的问题。当我们开始一个新项目时，我
们必须理解这些方法中的哪些部分是可以使用的。 

也许我们要选一些 RUP 中的生命周期管理，也许我们要做一些结对编程，也许我们想要测

试驱动开发，也许我们不需要架构；这都跟上下文有关。项目的范围很广。我们看到的基于
网络的数据库、网络服务器、通过网络的连接等，它们都有一些共同的特征。这可能是一些
敏捷实践能“尝甜头”的地方。我也很关心你的项目如果不能尝到那些甜头时会发生什么。
非常庞大的项目（世界上还是有一些这样的项目）、嵌入式软件项目、对安全性有高要求的

3 
 
  

项目、有严格性能约束的项目——它们需要很多关注。它们不会随着每周的重构慢慢形成。 

InfoQ：我们现在的方向在哪里？软件产业将会走向哪里？Philippe Kruchten 又会走向哪里？ 

Philippe：如果我知道就好了。如果哪里有个水晶球，也许会有帮助。如我之前所说，我们
必须放弃那种有人会创建一种流程适用于全部软件产业的想法。我们必须学会什么是好的，
什么适用于哪些上下文。我们也必须学会“人”才是软件开发中的关键重要因素，这是敏捷
告诉我们的。这才是软件开发背后的“机制”
。我们建造不出一个软件工厂，把需求推进去，
把软件拿出来。虽然这仍然是很多人的梦想。如果你跟模型驱动（model driven）的人说这
个，他们会试着抬高抽象的级别。就像我们已经摆脱了有一种终极编程语言的想法一样，像
三、四十年前的 PL 1 或者 ADAR，我们终会承认不同方向的软件流程能应对不同的问题。 

我们会面对一些不同的挑战：比如多核系统很可能会改变现有模式。我们还不能确切知道如
何充分利用大规模的并行。而且，我们开发的软件和我们对软件的大部分思维模式，都基于
一些串行线程，虽然可能会在这里那里有一些调换。多核将会改变很多事情。我们看到越来
越多的软件用现成的软件组成。SOA 只是一个范型（paradigm）或者模式（pattern）来组合
软件。会有越来越多的人用现成的模块组装软件，而不是真正在写 C++或者 Java 代码。那我
们现在使用的方法是不是适用于这种新的模式呢？我不知道，我们还没到那一步，我们会继
续发展，也许会找到一种新的编程语言，也许是函数式语言、领域特定语言来应对不同的问
题。 

互联网也在改变很多事情。有所谓“信息超载”之说，我们需要找到其他办法，在一个复杂
系统或一组协同工作的系统中组织信息，以减少终端用户方的信息超载。所以，我不知道，
我没有水晶球，但是看着事情发生会很有趣。 

从我个人来说，最感兴趣的是做决定的流程，人们是如何做决定的，以及背后的原因。我觉
得我们已经离传统的工程模式很远了，在那个时候工程师列举问题和解决方案的标准，然后
列举可选方案并评估确定最佳方案。这不是软件开发中的情况。很多决定是基于经验瞬间做
出的。这是非常有趣的东西，也是软件开发背景中很少涉及到的。它有趣是因为在引出需求
和理解需求所解决的问题之间有连续性。它在商业分析师和产品经理之间、产品负责人和架
构师之间也有连续性。 

我们倾向于把它们看得非常不同，使用不同的上下文和模式。但是我越看它越觉得人们在做
同样的事情，做选择和做决定。他们以不同的方法表达，但是当你在需求层面或者架构层面
做一个决定的时候，其实是一码事。当一个层面有了一个决定，它就成为另一个层面要解决
的问题，而这个问题又需要做决定来解决，接着又会成为这条链子上下一个人的问题。整件

4 
 
  

事情对我来说都是连续的。这可以使软件开发中的不同方面和谐起来。我们的各个分支并不
是相互独立的，并不是商业分析师用他们自己的语言和自己的概念模型做他们自己的事情，
软件设计者也做自己的事情，等等。这两者可以通过某种渠道和谐起来。 

InfoQ：你在英属哥伦比亚大学的研究重点是什么？（也许你已经回答了这个问题） 

Philippe：现在很难找到资助，特别是政府对软件工程的资助，对我感兴趣的那部分软件工
程的资助，因为它太软性了。如果你和资助方代理谈软件流程，他们会说：“我们资助了软
件流程 30 年了，我们能得到什么好处？”我仍然对架构感兴趣，我正在观察架构的两个方
面，第一是做决定的流程，把架构看成一系列决定的产物，而不是一组 UML 图表（这个应
该解决得差不多了）。把架构看成一系列设计决定后，我们就可以深入研究“这些决定是如
何做出的”，这些设计决定背后的道理是什么，这些道理之间有什么联系。我们更多地进入
了软件设计者和商业分析师类似于心理的领域。 

另一个和架构相关的方面是技术债务，技术债务是错误架构决定后的不幸阴暗面，我已经和
软件工程学员有一个相关的合作小项目。人们是怎么看技术债务的？我们能对技术债务制定
成本或定价么？有什么策略和行动可以让你摆脱技术债务？这是一个似乎未被开发的领域，
除了 Steve McConnel 和 Martin Fowler 写了一些文章以外，还没有对技术债务真正的研究。 

我另一个感兴趣的地方更偏向于技术，触摸屏的使用，特别在软件开发中的桌面屏幕，大屏
幕的交互触摸使用。大型分布式团队在不同地点不同时区协同工作时如何使用触摸屏，我在
研究这个方向，它提供了很多有意思的研究话题。我也很幸运地拿到了政府赞助，因为这个
研究能直接扶持加拿大的本地经济。 

InfoQ：非常感谢你。最后一个问题，你现在在新西兰参加即将开始的 SDC 大会。能不能透

露一下你将为我们讲什么？ 

Philippe：今年 SDC 大会的主题有一点和我个人兴趣偏离：商业分析。我是被软件教育局、 

Shane 你、还有 Martyn Jones 所邀请，我会尽力把我的兴趣和大会的主题结合起来。我会做
一个针对商业分析师的软件架构的讨论会，讨论我作为一个软件架构师，期望商业分析师了
解多少软件架构。我也会说一些技术债务、发布计划、以及如何把好的事情和坏的事情结合
起来，像架构和功能，解决现有缺陷和避免技术债务，还有我本人对发布计划和迭代计划（或
者 Scrum 中的 Sprint 计划）的巧妙结合。 

译者注：【1】彼得原理指在区分等级的组织中，员工如果胜任当前的职位，就会得到升职，
直至他无法胜任当前的职位为止。 

5 
 
  

原文链接： 

http://www.infoq.com/cn/interviews/philippe‐kruchten‐technical‐debt‐cn 

相关内容： 

 预先设计的大架构——过早考虑伸缩性之一例？ 

 丰富的设计技能胜过特定于平台的知识 

 豆瓣首席架构师洪强宁的年度展望 

 一个技术观察者的年度展望 

 架构师修炼之道 

6 
 
 时刻关注企业软件开发领域的变化与创新

我们的 使命：成为关注软件开发领域变化和创新的专业网站
我们的 定位：关注高级决策人员和大中型企业
我们的 社区：Java、.NET、Ruby、SOA、Agile、Architecture
我们的 特质：个性化RSS定制、国际化内容同步更新
我们的 团队：超过30位领域专家担当社区编辑
……

每日要闻 深度文章

企业软件开发

视　频 迷你书

讨 论 组 ：groups.google.com/group/infoqchina
编辑电邮：editors@cn.infoq.com
广告合作：sales@cn.infoq.com
  

热点新闻    News

RubyGems.org取代RubyForge成为
Gem托管站点 
作者 Paul Blair 译者 丁雪丰 

Nick Quaranto最近发表了一份声明，RubyGems.org已经成为了RubyGems的默认Gem源。
gemcutter.org、gems.rubyforge.org和rubygems.org这三个域名现在都指向同一个地方，三者
都可用于Gem  服务和安装。RubyGems.org是主要的Web前端，另外两个站点都会重定向到
RubyGems.org。安全站点https://rubygems.org在  3 月 23 日时依旧在提供服务。 

托管了大约 11,500 个Gem的RubyGems.org已经取代了RubyForge和GitHub，成为了社区中的

默认Gem托管站点。  GitHub在去年 10 月宣布不再自动构建Gem，仅为已经存放在GitHub的
Gem提供一年的托管，并推荐使用  Gemcutter进行托管。之后不久，Gemcutter背后的团队，
RubyGems和RubyForge宣布RubyForge将被逐步淘汰，Gemcutter将取而代之，并更名为
RubyGems.org。 

Gemcutter 于去年问世，作为一个 Gem 库它旨在简化 Gem 的托管和发布。有了 Gemcutter

的 RubyGems 插件，一句简单的 gem push 命令就能将 Gem 发布到 Gemcutter 上；在 RubyGems 
1.3.6 版中，该功能已经成为其包管理器的一部分了。RubyGems 中关于 Gem 的下载和安装
的唯一改变就是使用 RubyGems.org 作为默认  Gem 库。 

对于 Gem 的发布者，RubyForge 的账户已经迁移到了 RubyGems.org 上；RubyGems.org 的新

用户可以使用  RubyForge 的账户信息来登录。 

RubyGems.org关注Gem托管；RubyForge的其他特性，例如网站托管、文件托管、Bug追踪、
论坛、邮件列表，这些功能正在被转  到其他专注于这些服务的托管站点上。RubyGems包管
理器和RubyGems.org站点的支持一起放到help.rubygems.org了，这里提供了知识类的文章、

7 
 
  

论坛和问题追踪功能。 

虽然 gem push 和 gem owner 命令已经整合进了 RubyGems 包管理器中，gemcutter 插件依然

存在，提供了一些额外的命令。gem yank 命令能从 RubyGems.org 索引中删除一个 Gem，删
除后该 Gem 依然可以  下载；使用 gem webhook 命令，在 Gem 更新时，它能调用事先注册
的 URL 通知用户。 

RubyGems.org的其他特性包括每个Gem页面上都有一个链接到Caliper的“Metrics”按钮，它会
为每个上传的gem  生成metric_fu结果。RubyGems.org还提供了一个基于Web的API，通过API
能创建并查询  Gem，管理拥有者，完成很多在RubyGems.org网站上的交互动作。 

原文链接：http://www.infoq.com/cn/news/2010/04/rubygems 

相关内容： 

 Maven与JRuby近况 

 rails_best_practices：轻松运用Rails最佳实践 

 Eclipse Git插件EGit发布了 

 Rip：一个全新的Ruby包管理系统 

 JRuby综述：GitHub:FI 

 
 

8 
 
  

热点新闻    News

Python有望成为金融语言 
作者 Jonathan  Allen  译者  李明（nasi） 

美国证监会（SEC）提议绝大多数资产抵押证券（Asset Backed Securities，简称ABS）要包含
一个可下载的程序，“该程序能够实现交易协议中资金流转的相关条款（或称之为‘瀑布’）”。
Jayanth R. Varma教授摘录了两个引人关注的段落： 

“
根据本提议的要求，投资者能够下载并运行该源码，并能够以编程的形式，输入自
己对于未来业绩和资产池中现金流的假定，这些假定包括但不限于：未来的利率、  违
 
约率、提前偿还速度、违约损失率以及其他必要的假定  ...  （第 210 页）   

这个瀑布计算机程序可以使用资产级别的数据文件，该文件将与源代码一同提交，之
后将会定期提交。（第 211 页）   

软件开发者需要注意的是，其中的术语“瀑布”在金融领域有着完全不同的含义。它指的是将
证券分级，按照级别从高到低的优先顺序，把回收的贷款本息还  给不同等级证券的持有人
（详见Marketplace Whiteboard）。因为这些计算非常复杂，而且哪怕是公式和参数中的轻微
缺陷都会造成巨大影响，因此使用正式定义的计算机程序是非常必要  的。 

目前，美国证监会正计划将 Python 作为报告要求的编程语言。尽管其他语言亦在考虑之列，

但 Python 却拥有一些显著的优势。除了拥有一个开源且独立的编译器以外，Python 还能够
运行在 Java 和.NET 平台。在 Windows 平台上，.NET 可以将 Python 与任何基于 COM 的语言
结合在一起；而在 Linux 平台上，Python 可以使用基于 C 的扩展来实现特定的需求。 

原文链接：http://www.infoq.com/cn/news/2010/04/Python-ABS

相关内容： 

 用于.NET的财务函数 

 关注网银系统：安全模型和架构设计 

9 
 
  

热点新闻    News

iPhone开发者许可变更：反响强烈、结果难料 
作者 Abel Avram 译者 张龙 

最近有报道说Apple变更了iPhone开发者许可，进而阻止使用除Objective‐C、C和  C++之外的
其他语言编写应用，也不允许“借助中间转换、兼容层和工具”来访问API。人们对此反响强
烈，这种效应很有可能波及到整个业界。 

用于开发iPhone、iPad和iPod Touch应用的iPhone SDK 3.2及之前版本在iPhone Developer 
Program License Agreement（DPLA）中都声明了如下条款： 

3.3.1——应用只允许以Apple规定的方式使用Documented API，不允许使用或调用任何私有的API。

最新的iPhone OS 4.0 SDK目前还处于Beta版并已向注册的开发者提供下载。Apple对DPLA的多
处变更还处于保密状态，John Gruber则报料说 3.3.1 的条款已经变成了下面这个样  子： 

3.3.1——应用只允许以Apple规定的方式使用Documented API，不允许使用或调用任何私有的API。
应用从一开始就必须使用Objective-C、C、C++或JavaScript编写（由iPhone OS WebKit引擎负
责执行），只有用C、C++和Objective-C编写的代码才能编译并直接链接到Documented API上（比
如，不允许通过中间转换、兼容层和工具将应用链接到Documented API上）。

这意味着今后必须使用 Objective‐C、C、C++或 JavaScript 编写 iPhone 应用了，严格禁止跨编

译器的行为，这将对很多公司  造成影响。由于许可说明还不是十分清楚，这也导致了人们
的各种猜测。 

Apple的这个举动对Adobe造成了直接的影响，他们刚刚在市场上发布了Adobe Creative Suite 
5（CS 5）。Adobe鼓吹CS 5 的一个主要亮点就是可以将Flash FLA文件导出为IPA，创建可以部
署在iPhone上的应用，根据Adobe Creative Solutions的业务经理John Loiacono所述：我们非常
高兴地宣布开发者可以使用Flash开发工具在iPhone上构建、编译并运行应用了。   

这类应用不会在运行期编译代码，理应与 App Store 所销售的其他应用享有同样的审批过程，

但 Apple 对开发者许可的变更改变了这一切。 

10 
 
  

Adobe CTO Kevin Lynch对新的许可条件发表了如下评论： 

“
昨天，Apple 对其 SDK 许可进行了一些改变，限制了开发者可以使用的技术[…]。 
 
我们依然会将该功能放到
  CS 5 中，随着时间的流逝，Apple 还会不断改变规则，是否
允许这些应用就是他们自己的事儿了。 

Unity 3D有个游戏开发工具，开发者可以使用该工具在多个平台上创建游戏。目前有成百上
千的iPhone应用都使用到了这个工具，其中一些还在App Store上热卖。Alex Blewitt认为Unity
会深受这种变更的影响： 

“
作为一个 3D 工具，Unity 可以用在多个平台上，能够加速游戏开发。然而，它却是
Apple 明令禁止的“兼容层或工具”。 
 
 

Gruber认为Unity不会受到什么影响： 

“
一开始我还以为这将禁止使用Unity3D编写游戏呢，但或许并非这样——Unity3D会生
成一个完整的Xcode项目和Objective‐C源文件，这看起来更像是一个预处理而非跨编
 
译器，很  难说。如果要我打赌，那么开发者使用Unity3D编写C#代码的事实则违背了
规则。 

Unity 3D自己不知道该说什么。他们已经与Apple取得了联系并在焦急地等待澄清结果。 

“
我们希望自己安然无恙，但显然这种希望并不能保证什么。我所能保证的就是我们
将在力所能及的范围内一如既往地完善 Unity3D，只要获悉了更多信息，我  们会在
 
第一时间通知大家。   

还有很多工具都受到了许可变更的影响，如MonoTouch、Titanium、PhoneGap和Ansca Corona
等。他们都提出了类似的问题：并不知晓Apple对许  可进行变更的意图是什么，他们也深信
一切都会好起来的： 

“
MonoTouch：  我们与Apple进行了接触以了解其意图，相信在 4.0 SDK最终版发布前
还有很大空间修改我们的方向。 
  
如果Apple的动机在于技术，想让大家使用他们的工具链，那么MonoTouch很容易就
能满足SDK的条款。MonoTouch只能运行在Mac OS X上并与Xcode和iPhone SDK紧密集
成。 

11 
 
  

 
Appcelerator Titanium：我们坚信自己的做法完全符合iPhone OS 4.0 服务条款[…]。 
 
使用Titanium的前提是开发者必须要安装Apple iPhone SDK和Apple Xcode工具链，必须
在Macintosh上安装Titanium，只有具备了合法的Apple开发者资格后才能创建基于
Titanium的  iPhone/iPad应用。 
 
Titanium会在应用创建阶段生成合法的Xcode项目、Objective‐C（有时是C/C++）代码
并使用Apple公开发布的API通过  xcodebuild将Xcode项目编译为本地应用。 
 
PhoneGap：每个  人都对新政策松了一口气。Apple已经认可了phonegap应用。 
 
Ansca Corona：我相信Corona没问题，我们一直致力于创造最棒的多平台游戏工具，
为Apple和Android设备创建应用，我们还会一如  既往地向Corona中增加新特性，期待
每次发布的新版本都能更上一层楼[…]。 
 
到目前为止，Apple尚未以官方和非官方的方式通知我们不兼容的问题。Apple还为 4
月 3 日iPad Store的盛大开幕批准了几个Corona应用，这个事实再次表明我们是符合服
务条款要求的，为iPhone/iPad生态圈创造了巨大的价值。   

很多人都对Apple的这个举动感到困惑甚至有些义愤填膺。Dan Grigsby是一位企业家，同时
也是一个iPhone开发者，他已经放弃了iPhone： 

“
Apple 想要巩固 App Store 的地位，这我没意见。如果他们将 App Store 看作是品牌扩
展，这也很好。如果这就是他们的目标，那他们应该全方位清理 Store 了，剔除那些
 
糟糕但没恶意的糟粕，像 Android 那样提供  无限制、平滑的脱离于 Store 的应用。 

我这个人讲求原则，但 Apple 已经触犯了我的原则。我决定不再开发 iPhone 了，我

再也不想在这种需要征得许可的环境下工作了。 

Sun前主管及XML的联合编者Tim Bray最近加入了Google以提升其Mobile OS的竞争力，他认为
Android更加自由： 

显然 Apple 认为你可以利用 Internet 所带来的好处，同时他们又操控着哪些程序可以运行、

哪些栈可以访问、哪些话可以说等事项。 
 
我认为他们错了，我现在所从事的工作将证明这一点。 

12 
 
  

直接部署应用而没有利用App Store的企业将不会受到此次变更的影响。但如果他们同时使用
了这两种方式（既有直接部署，又利用了Store），那就必须得遵循许可的要求了。 

一些人认为Apple只是想保证为iPhone所开发的应用具有良好的品质并充分利用了iPhone的
能力。其他人则谴责Apple断了那些开发了  iPhone本地工具Xcode替代者的开发人员们的后
路。不管怎样，所有人都在焦急地等待着Apple的澄清。 

原文链接：http://www.infoq.com/cn/news/2010/05/iPhone‐License‐Change 

相关内容： 

 Flash vs. HTML5：RIA领域当前的混战 

 MonoTouch.Dialog  让iPhone对话框的创建更加便捷 

 MonoTouch：  用.NET开发iPhone应用 

 Rhodes 1.5：使用Ruby为智能手机开发应用，已支持iPad 

 微软与苹果网站可用性大比拼 

13 
 
  

热点新闻    News

独立的BPMS当真已逝？   
作者Boris Lublinsky  译者  马国耀 

最初有SOA已死的说法，而现在Tom Baeyens，jBPM的创始人又为目前的独立业务流程管理
系统（BPMS）贴出了新的讣告，他称，独立的BPMS有两大问题： 

 构建成本高。这指得是购买软件并使之运行起来，以及让所有人员跟上技术的发展。 

 BPM 系统与外界集成的成本高。Web 服务或者用于集成其他应用的具体适配器都会带来

很高的门槛。 

这表明，要想证明 BPM 的效用，就必须要实现需多复杂的业务流程，而这并非易事，原因

之一是企业的 BPM 尚未成熟。所以，BPMS 的使用成为 BPM 集成的昂贵的切入点。 

Baeyens 为该问题提出的解决方案是在其最常使用的场所提供一个业务流程平台。比如
jBPM： 

“
自从 jBMP 诞生之日，我们就重点面向开发人员。我们向开发人员的双手送去了 BPM
和工作流的能力，我们是在开发者的世界里提供那些特性的。 
 
 

jBPM 的框架即可用于构建嵌入在应用系统之中的业务流程或者将其扩展成全面的 BPMS。 

“
它降低了使用 BPM 的门槛并且打开了 BPM 使用的新世界。由于使用简单，即便是很
小的流程使用 BPM 系统也是值得的……通过开源  发布与应用系统的可植入性，jBPM
 
显示出 BPM 可以扩展成为比任何其他独立的 BPM 产品在过去获得的更广泛的使用。 

Baeyens 所提到的将 BPMS 作为应用实现之基础的另一个例子是企业内容管理（ECM）系统： 

“
ECM 系统是一个很好的环境，在这里嵌入的 BPM 可以更少的投资收获果实。拿每月
一开的例会来说，会议记录要供人参阅，而且只有  在关键参会人批准之后才能被发
 
送到更广泛的读者。你会为此建立 BPM 系统吗？我不认为你会这么做。但如果此项

14 
 
  

能力在 ECM 系统中提供了，那么就能立刻产生  投资回报。此外，这也是我们的战略，

即在通用的 BPM 职能之上不断进行扩展。 

很难用“BPM 实现的切入点的成本已经降低了”反驳 Baeyens。jBPM 也的确是个很棒的框架。

但真正的问题是 BPM 真的是开发者的工具吗？。  诚然，将 BPM 用作高层开发语言的场景
的确不少，然而 BPM 的真正力量，特别是当其与 SOA 联合使用时，是它打破应用系统边界
并实现企业范围的业务流程的能力。而且，从这个角度看，真正的 BPMS 不仅仅是一个执行
环境，而且还要有建模，仿真以及业务活动监控（BAM）的支持，这才是 BPM 的光彩之处。 

原文链接：http://www.infoq.com/cn/news/2010/05/BPMSDead 

相关内容： 

 BPEL为何不是BPM的圣杯？ 

 社交BPM，你听说过吗？ 

 争论：SOA已死？ 

 SOA依旧已死？ 

 在SOA中实现业务规则和业务流程 

15 
 
  

热点新闻    News

与Josh Bloch探讨Java未来 
作者Josh Long  译者  宋玮 

Josh Bloch在Sun公司多年为Java平台作出了杰出贡献（如果你用过Java Collections框架就会了
解这一点），现在Google就职，是获奖图书《Effective Java》及《Effective Java  第二版》  的
作者。最近他在基于Web的Red Hat中间件 2020 大会上做了一场演讲，其主旨是对Oracle所
管理的Java平台的未来表示出审慎乐观和忧虑。InfoQ采访了Josh以了解其在  这方面的更多
想法。因为有许多不同的、现实的观点交织在一起，这次讨论（尤其考虑到Sun人才从Oralce
流失日益加剧以及为Oracle如何管理社区  和Java智力资产而担忧）是最近以来最热烈的一
次。我们很高兴能与Bloch一起讨论这些问题。 

InfoQ：你最关切的是什么？   

Josh：这不是个单选题，过去几年有很多因素纠缠在一起，导致了 Java 风向发生了变化。 

InfoQ：为什么你会觉得 Java 的发展步伐慢下来了？ 

Josh： 

1. Sun/Apache 纠纷以及 TCK 许可权之争都严重干扰了 JCP 过程运作。 

2. Sun 支持力、领导力和透明度的缺乏使得 Java 7 发展缓慢。我不知道在过去几年里 Sun

分配给 Java SE 的资源到底有多少，但结果是非常明显的：JavaOne 年年都在办，但 Java 
7 却还遥不可及。Java 支持者间的许多争端也着实让人讨厌。前期，Sun 所扮演的乐善
好施的角色还是有助于减少内部矛盾的。 

3. OpenJDK 使用 GPLv2 许可阻碍了人们采用 OpenJDK，即便是那些不太关心 TCK 问题的人。

“copyleft”吓跑了很多潜  在的公司使用者。结果，为了同时发展 Harmony 和 OpenJDK，
资源被一劈两半。由不同 JCP 成员针对不同标准的不同组件所使用的不同许可实在是混 
乱不堪，结果实际上给 Java 平台的发展带来了负面影响。 

InfoQ：对于 Sun 所不能及，Oracle 有更好的解决方案吗？ 

16 
 
  

Josh：Oracle 有支持 JCP 改革以终结争端的历史。而且他们在经济上也比 Sun 更有实力，所

以他们能够承担起复兴这一平台的重任，  而且他们也公开宣传要这么做。最终，由于这次
易主，一些历史遗留问题将就此终结。对于 Sun 来说不可接受的一些变化，Oracle 或许会从
全新角度去看待  ——“为什么不变呢？” 

InfoQ：是否所有症结都归结为许可问题？ 

Josh：不，许可问题只是其中的主要问题，但还有其他问题。正如我以前提到的，对于资源、
领导力、焦点的缺乏也都是问题。 

InfoQ：Apache Harmony 项目（被作为 Android 类库的基础）的境况可接受吗？（在 Google

采用 Harmony 作为 Android 类库基础之  前，Harmony 与 Sun 就 TCK 许可问题斗争得很激烈。
Google 决定使用 Harmony 而非 OpenJDK 对 Harmony 的  TCK 许可争端影响并不大，却对 Sun
决定其 OpenJDK 使用 GPLv2 许可影响很大。如果没有更宽松的许可协议，Google 的合作伙
伴不会同意使  用。Apache 组织一度被授予了一个受限的 TCK 许可，但其仍被拒绝，因为使
用领域的限制对 Apache 和 JCP EC 来说都是不可接受的，他们认为这一限制违反了 JCP 协定。） 

Josh：不能接受。正如以前我所提到的，它阻碍了平台的健康成长。而且它给众多公司带来
了巨大的工作压力，造成在 Harmony 和  OpenJDK 之间不必要的资源拆分。 

InfoQ：你希望 Oracle 对 Harmony 这类东西做出何种反应？ 

Josh：我希望他们能履行在 2007 年 12 月 12 日 JCP EC 会议上所提出的决议：   

决议  1  （Oracle 提议，BEA 附议） 

“执行委员会认为 JCP 应该成为一个开放的、独立的、厂商中立的标准化组织，在这里所有

成员参与的公平竞争场所具有以下特点： 

1. 成员为开发提供资金并管理开支 

2. 一个合法的实体、理事机构、会员资格等等。 

3. 一个新的、简化的知识产权政策，允许最广大的实现。 

4. 规章需要有兼容性 

5. 致力于促进 Java 编程模型 

此外，如果这一变革实际对 Java 社区影响较小，EC 应该尽快为此制定计划。” 

至于说“新的、简化的知识产权政策”，如果所有 Java 规范的所有组件都采纳像 Apache 或 BSD

17 
 
  

这样被广泛接受的宽松的开源许可，我认为这将非常有利于整个社区发展。 

InfoQ：你怎么看 Oracle 的角色？ 

Josh：我很乐见他们能够纠正 Sun 领导力不足及 Java 平台发展缓慢的问题。当然现在的情况

有点不同了，世界已经改变了。其他组织将贡  献更多的资源并享有更大的控制权。 

InfoQ：你认为像 Dalvik 这样的东西能适应新的 Oracle Java 环境吗？ 

Josh：在崭新的开源世界里，有多个相关平台是既定事实。有许多类 Unix 操作系统及许多

Linux 变种（为多种用途做了优化）。我认为  Dalvik 作为 VM，有着截然不同的设计目标，并
且受到 HotSpot 或 JRockit 的制约。 

InfoQ：另外，你怎么看 Java ME 的发展？彻底被取代了？Sun 会“祝福”Android 成为下一代

Java ME 吗？在 Android/iPhone 当道的今天，Jave ME 如何与之竞争？ 

Josh：我认为我不适合就此作出推测，但是需要指出的是，在开发界“功能手机——featrue 
phones”（相对于“智能手机——smart phones”）仍有一席之地，而 Java ME 正是为功能手机
而设计的。 

InfoQ：最近，Tiobe语言排行不止一次显示出Java使用率下降的趋势。你怎么看？ 

Josh：其显示 Java 使用率轻微下降，相应的 C 使用率却在上升。我不确定这是真实情况的还

是某种统计异常，但是看到一个已存在 35 年之  久的“通用汇编语言”排在了第一位还蛮有趣
的。当然，我承认 C 在我心里是一软肋。 

InfoQ：这一点或许可以证明，但是你觉得是本身 JVM 使用率下降了，还是由于

Ruby/Scala/Jython /Groovy 的增长导致了 Java 份额的下降？   

Josh：实际上你提到的这几门语言都没有排在前 20。这并不意味着他们不重要或没有价值。
但他们还不是主流。不过，近些年语言研究和设计  发展的数量让我感到震惊，涌现出许多
好的思想，更不可思议的是人们正在探索这些语言。 

InfoQ：你认为 Java 在衰退吗？我们应该为此而感到担忧吗？ 

Josh：我认为，公平地说 Java 正处在困难期。但是我不认为该平台或语言在衰退。我觉得其

有衰退的危险，但是我希望 Oracle 和  Java 社区能够防止这一情况出现。没错，我觉得它让
大家感到担忧。我认为一个强大的 Java 对编程大众是有益的：包括公司、高等教育、K‐12、
开源社  区。 

InfoQ:  依你之见，谁有希望替代它（而且不在 JVM 上）？ 

18 
 
  

Josh：除过 CLR（其实际上仅是 Windows 上的平台）之外，还没有哪一个能与 JVM 处在同

一水平线上。实际上，还没有谁能真正替代  Java 编程语言。是有许多很好的编程语言，但
是没有一个有同样的“设计中心”。语言是工具，我们应该针对不同工作使用正确的工具。没
有包治百病的药。 

InfoQ：有无发放 JRE 许可的商业案例？ 

Josh：或许有一些高深莫测的变相案例。但是我认为保持 JRE 被广泛使用符合 Oracle 的利益，

这和在 Sun 的时候一样。   

InfoQ：接着上一个问题，当然也是单独一点：关于在 JRockit JVM、Sun JVM 及其他各色 VM

技术之间进行协调的观点，你怎么看？ 

Josh：理论上，我认为把各个 JVM 的优点抽取出来组合成一个更好的东西是一件非常好的事

情。但是请记住 Sun 甚至从未成功将客户端和服  务器端的不同 HotSpot 加以整合。整合多
个系统是非常难的，可以实现但绝不容易。一旦失败成本将非常高昂。 

InfoQ：还有什么要补充的吗？ 

Josh：我只想提醒一下大家，许多近期的Java成功案例都被淹没在前途暗淡的声音之下了。
这些案例中包括Google Collections、Guice、你前面所提到的JVM语言、以及  Android。有了
Oracle方快速、果断的行动，加上Java社区的广泛合作，我觉得Java平台的前景非常光明。 

原文链接： http://www.infoq.com/cn/news/2010/05/bloch_java_future 

相关内容： 

 Java 6 中的线程优化真的有效么？ 

 Java 6 中的线程优化真的有效么？——第二部分 

 Google图表及gchartrb初探 

 开发者眼中的Android手机平台 

 JRuby on Java ME/CDC 

19 
 
  

热点新闻    News

讨论：当前运维团队在软件开发中的角色 
作者 Srini Penchikala 译者  侯伯薇 

在过去的几年中，随着云计算和开发加运维现象的出现，出现了对传统的运维团队的角色的
讨论，因为在当前的软件开发团队中经常会看到他们的身影。  InfoQ 将会深入地探究此次讨
论，以更好地理解其中所涉及到的各个不同的方面，以及各种方法之间的平衡。 

本次讨论的核心是这样的重大问题： 

谁应该负责对生产环境中的应用程序进行管理、监控和运维？ 

在开始关于此次争论的讨论之前，我们先是邀请了New Relic公司（基于SaaS的应用程序性能
管理工具的提供商）的工程主管Bjorn Freeman‐Benson和  InfoQ运维社区的首席编辑Carlos 
Armas。然而，这只是讨论的开始，随着讨论的进行和展开，InfoQ会将最近的讨论更新到本
文中，并且还可以通过关注#roleofops标签来关注  Twitter上的讨论。我们希望你也参加到本
次讨论中，所以请选择发布带有#roldofops标签的推特信息，或者向feedback@infoq.com发送
邮件来说明你的看法，也可以在本文的评论中留下你的声音。  

 
Bjorn Freeman‐Benson：关于改变运维的角色这个主题，已经有了大量的言论、网志以及幻
灯片。在大量的交流中，  人们提出了将开发和运维变得更加紧密的要求。他们称之为开发
加运维或者其它术语。尽管我在 New Relic 公司的同事和我在总体上都持赞同的意见，但是
我们认为公司应该考虑采用更具有决定性的步骤，以达到更有效的运维管理——也就是，考
虑让每个开发  团队都负责他们自己的应用程序的部署和性能问题。  

让我们考虑一下，为什么这并非像它听起来那样不同寻常或者极端。 

首先，对于应用程序，谁能比创建它的团队更了解它呢？这使得在将应用程序部署到数据中
心或者云中的时候，应用程序开发团队需要与业务应用的所有者商  讨，然后对应用程序进

20 
 
  

行设计、架构和编码，选择、测试并集成应用程序的各个组件（应用程序服务器、操作系统、
数据库、集成中间件等等），创建原型，执行功  能测试，可能还要进行负载和可扩展性的测
试，向业务人员演示应用程序的功能，最终为生产环境准备就绪。几周甚至几个月来日积月
累的知识怎么可能一下子就传  授给运维团队呢？ 

开发团队应该做出重要的部署选择吗？——增加或者扩展硬件服务器，是否对服务器采用虚
拟化，哪种 CPU 和内存是最佳的等等。开发团队应该决定他们所  需要的最佳的性能监控和
日志记录吗？开发团队应该监控、处理警告、把握性能和有效的时间，并且在应用程序崩溃
的时候处理来自于业务部门歇斯底里的电话吗？  （为什么运维人员会处理这些有趣的事
儿？）我知道这种方法会有用的——在 New Relic 公司中，我们自己就使用它来管理世界上
的最忙碌的 SaaS 应用程序之一。很讽刺的是，我们的 SaaS 应用程序耗费了将近 4000 个开
发团队来管  理他们的生产环境中的应用程序。 

Carlos Armas：这样的想法很具有吸引力，因为设计和构建系统的团队最适合对其进行运维、
监控和扩展。由这个逻辑递推，  我主张开发团队应该负责处理公司的账务，因为软件开发
者都很擅长处理数字，或者由于他们对环境很关心，因此应该在工作之后清理办公室并将垃
圾箱倒到外边的回收处。这样做就忽略了几百年来的重要实践：分工。事实上，开发团队比
其他人更加了解应用程序，但这并不能成为要他们负责对发布到生产之后的代码进行运维 
和维护的原因。 

我假定自己是公司所有者的角色，并给出三个原因，说明为什么我不想这样的事情发生在我
的公司中： 

1）财务上的：软件开发者的平均工资总是要比运维支持工程师的高。作为公司的所有者，
为什么我想要让我最昂贵的团队做运维任务呢，那种任务可以由其  它团队完成，那样更节
省资金，更有效。在任何敏捷团队中，任何好的 Scrum 教练都会告诉我们，他们的主要任务
之一就是移除障碍，并让隐藏的工作可见，从  而开发团队能够更有效地开发代码。为什么
我想要将更多的障碍和额外的工作强加给开发团队，从而降低他们的效率呢？ 

2）质量：我相信检查和平衡，因为没有人是完美的。当团队负责应用程序完整的生命周期
时，客户最终要吞下这个苦果：很差的用户体验。当开发代码的团  队同时也负责决定其质
量是否符合发布标准的时候，那么发布不完善代码的风险就会大大提高。拥有完整的生命周
期使得人们自满，并会滋生“我们总是可以在生产  环境中修改它”的错误想法。 

作为公司所有者，我更喜欢对系统进行检查和平衡，从而我们可以更好地服务客户，并因此
得到他们的回报： 

21 
 
  

 我不希望开发团队负责 QA（质量保证）工作，而是由 QA 团队来负责代码的质量。 

 我不希望 QA 团队来发布程序并运维生产环境中的应用程序，应该由运维团队来负责彻
底地测试应用程序，从而问题可以在早期发现，在它被客户  使用之间就被退回给开发
团队修改。 

 我不希望运维团队承担限制我们向客户发布新功能的频率的角色，他们应该负责应用程
序的可用性和性能，并负责发布和维护代码，还要反馈缺陷  和不足，不论是在检查还
是测试过程中发现的。 

实质上，我希望质量是大家分享的责任，各个团队对于非常特定的区域和责任相互负责。我
希望团队之间的关系是一种积极的矛盾，从而为持续的质量改进提供动力，并且在头脑中将
客户作为唯一的目标。 

3）机会的浪费：如果软件开发团队忙于运维工作，那么谁会开发新的特性并改善应用程序
呢？谁来修复软件的缺陷呢？开发者会和生产团队会仅仅因为一个  页面跳出来，警告他们
Amazon EC2 的一个实例出错，而被滞留在下一代软件的设计过程中吗？ 

Bjorn Freeman‐Benson：其次，当应用程序被部署在云中时，运维的真正任务是什么呢？越
来越多的网络应用程序被  部署在公有或者私有的云架构中。在 New Relic 公司中，超过 40%
的客户将应用程序部署在云中，并且我们期望这个比例在 2010 年末会很大。就算大部分公
司都比较小，没有大公司需要处理的遗  留数据中心或者数据整合的麻烦。但是，每天我们
还是会与新的客户签约，他们可能是带有传统数据中心的大型组织，而客户的应用程序被部
署在 Amazon 或者其它公有云中。 

那么，在这些情况下，运维团队应该扮演什么样的角色呢？他们不会负责云的硬件、网络、
电话。他们不会对架构监控做出选择。在云中唯一属于他们公司的  就是应用程序的代码本
身。其它所有的一切都是由云架构提供商负责的。因此，坦率地说，当我的应用程序被部署
在云中，谁会需要运维团队呢？开发团队必须负责  基于云的应用程序能够成功执行。除了
他们，谁也做不到这一点。 

Carlos Armas：很有趣的是，看起来似乎人们期望云中的系统能够自我管理，那是错误的认
识。让我们退回几年来说明这个问题，并讨论一下托管服务。 

我们当前所知的托管服务是从托管提供商意识到他们可能会为客户提供硬件和带宽之外的
服务开始的，并且在他们的服务组合中包含了系统管理和对应用程序的管理。结果显示那是
很棘手的业务，很难保证交付时的一致性和良好的质量。只有少数提供商做到了这点，但是
付出了很大的代价。 

22 
 
  

从上面的观点中，云计算将系统管理和应用程序管理任务推回给了客户。（我们不想在此定
义云计算，那肯定会导致另一个讨论:)） 

那么运维团队在云中应该做什么呢？首先是系统管理。然后是应用程序的部署、监控、发布
扩展和响应。我们仍然需要 24x7 的电话支持，因为系统位于云  中。系统管理（针对 Unix、
Linux、Windows 等等）是开发者无法做好的事情，因为他们并非是该领域中的专家，就像
系统管理员不是好的软件开发  者或者好的市场人员和沟通执行者一样。 

然而，随着（并且如果）云计算变得越来越普遍，运维团队的组成也逐渐产生了变化。你之
前提到了硬件、电信和网络。显然对这些能力的需求会从云客户的  公司转移到云提供商。
客户还是要保留系统管理员角色，并且会和之前一样需要（甚至更加重要），因为提供商不
再为你管理虚拟服务器的操作系统。
（记住，作为  公司所有者，我想要软件工程师开发代码，
Scrum 教练防止他们做隐藏的工作，同时还要排除他们工作进程中的障碍） 

我们还可以认为，在这样的场景下，运维团队不再存在，而运维工程师变成了软件开发团队
或者其它团队的一部分。那是有可能的，事实上当前在小型团队中正是这样。然而，我不认
为我们在这里是在关注组织结构图，而应该关注在合并的托管技术环境中运维和开发的角
色。 

本质上，我的观点是，软件开发团队不应该负责运维任务，并非是因为他们不能，而是因为
那在财务上、组织上和商业智慧上是不合理的。 

 
以下内容增加于 4 月 16 日 

Bjorn Freeman‐Benson：我的观点是开发者应该负责他们的应用程序在生产环境上的运维工
作，在为其提供另一个论据支持之前，让我先对 Carols 的论点做出回应。Carols，我想在你
说“[可能]开发团队应该负责公司的账务工作，因为软件开发者最擅长处理数字”的时候，是
在开玩笑。是的，我并非是说开发者能够做其他所有人的工作。但是，我们并非是说让开发
者使用能力范围之外的运维技能。开发者对财务完全是外行。但是配置硬件、部署软件、管
理指定应用程序的服务器容量、确定备份日程——这些运维任务都是在典型的开发者能力范
围之内的。 

此外，当提到云的时候，你说：“看起来似乎人们期望云中的系统能够自我管理，那是错误
的。”是的，很明显云架构不会自我管理。但是我们所说的是与云相关的系统管理工作是由
云提供商完成的。因此我说如果我们在将应用程序部署在云中的公司中做 IT 工作，为什么
还需要系统管理员呢？我们应该让开发者来做大部分应用程序管理工作，这样就不需要再建

23 
 
  

立云团队了。如果一个公司使用的是云平台——RightScale、Heroku、Stax、Gigaspaces、
EngineYard 等等——中的一种，那么大部分的与系统管理相关的工作都是由平台自动完成，
而不是由系统管理员人工完成的。 

让我给出另一个观点，来说明为什么开发者应该对生产环境中的应用程序负责。谁能够比编
写代码的团队更好地找到性能问题的根本原因呢？假设运维团队得  到了应用程序的性能出
现了问题的警告，可能来自于性能检测工具，或者来自于不可避免的业务人员的电话，他们
在其中大发雷霆。典型的运维人员能做什么呢？如  果他们极度幸运，那么可能会将产生问
题的原因隔离到一些出现问题的架构中。坦率说那种情况十分少见。通常运维人员所使用的
各种架构监控工具会显示一切“绿灯”。往往问题都在于应用程序之中。谁能比开发团队更知
道在虚拟机中发生了什么呢？大多数运维人员都不是开发者，他们不会读代码，也不能跟踪
原因隐藏在程序中的问题。为什么需要运维团队作为中间人来接受警告，然后他只是将问题
转交给开发团队？还是让开发人员来接受警告并更快地着手解决问题吧！如果问题在于他们
的代码之中，那么他们就应该是修改该问题的不二人选。这样做额外的作用就是让开发者对
于他们发布到生产环境中的代码更尽心，因为知道他们需要对结果负  责。 

 
 以下内容增加于 4 月 19 日 

Carlos Armas：是的，我当时是在开玩笑:) 

我发现使用幽默更便于沟通和理解。我越是阅读你的评论，越是觉得似乎我们的观点并非是
像旁观者乍一看所感觉的那样针锋相对。 

我同意开发者能够学习并执行很多运维任务，这是肯定的。但是请记住，我还是希望他们能
够专注于代码，将该项工作放在第一位，正如我坐在公司所有者的  位置而谋其事一样。我
在下面陈述你所作出的非常重要的观点时，会再回头来看这个观点。 

在此有一个很不固定，并且正在发展的概念：云计算。如果你让我给它下定义，我可能会逃
之夭夭。（我可不想作为现代云计算的布道者来吸引眼球） 

可以说云计算是个宽泛的概念，它关注的是需要最少或者可能根本不需要运维专业支持的服
务（Heroku，以及其它等等）。它还涉及到像 Amazon  的 EC2、Rackspace 的 RackspaceCloud、
Opsource's 的 OpsourceCloud 等服务，其中涉及到大量运维工作，这依  赖于所要支持的应用
程序的种类。 

还有强有力的证据，可以促使 Saas 提供商专注于非常特定的服务，让类似的团队从提出概

念到交付保持持续的服务（这可能正是在 New Relic 公司中的情况）
，并极度关注应用程序的

24 
 
  

交付。 

与之相对的例子可能是，公司决定不想花费大量的资金用来改善开发环境，并将其开发架构
迁移到 EC2。快速提供、迅速转向，或者是其它的什么。你还会想到很多其它的例子。 

所以这件事的问题在于，“具体情况具体分析”。 

我对你的观点的根本原因进行了分析，在提出我的反对观点之前，让我先强调一下你的一些
我观点： 

 这样做额外的作用是，当开发者将代码发布生产的时候会更尽心，因为他们知道需要对
后果负责。 

 为什么要让运维团队作为中间人来得到警告，然后不管怎样，只是将问题转交给开发团
队？ 

如我所见，如果开发者开始做运维的工作，那么： 

 开发者会更尽心，因为他们需要对将代码发布生产所带来的后果负责。 

 这会解决中间人综合症（运维人员）所导致的问题，他们无法修正导致失败的错误 

基于实战的经验，我要对上面的观点表示反对： 

 为什么是那样呢，在很多公司中（显然数量巨大）运维人员被认为（表现为）是妨碍改
变的因素，并且向工作流程中添加延迟，以致于几乎不可能  保持敏捷并向生产环境发
布代码。 

 为什么运维团队始终是开发团队的阻碍呢？ 

 为什么开发团队要应付严格的公司政策，最终购买云计算服务呢（因为运维团队无法在
第一时间提供服务）？ 

 为什么运维团队会因为漏掉了 SLA 目标而受到惩罚？前提是错误不是与有缺陷的架构或

者过程相关，而是与错误的代码相关的。 

 为什么运维人员无法从云服务的快速、灵活的部署能力中获益呢？难道是 70 年代的计
算实践中的“守护者”精神依然存在吗？ 

对我来说有些事情已经很清楚了：冲突是切实存在的，但是如果不熟悉信息技术实践的历史，
那么就很难梳理出为什么我们因此而受苦的原因。我有一条未经测试并且非常单纯的理论：
变更对于运维是有害的，而软件开发就是变更。因此存在最重要的矛盾，这需要聪明地处理。 

25 
 
  

新从公司所有者的角度来阐述，因为我要花费资金来试图提供管理冲突的过程（是聪明的
吗？）。我要使用敏捷的用户故事方式来说明，作为公司所有者，我想要： 

 软件工程师不负责公司的财务工作（你没看到他们过来吧？:)） 

 运维工程师主要专注于 24/7 服务的可用性。 

 软件工程师主要专注于服务的改善。 

 在开发和运维之间存在“零壁”规则。 

 运维工程师是敏捷团队的核心成员。 

 软件工程师经常会在第三级扩展的待命任务中轮换   

 这很痛苦，但会有教训 

 开发和运维团队都会对应用程序的可用性和延迟负责   

 在此我想坦率地说：丢失的目标，对于任何团队都无益，我不关心谁打破了它。必
然的结果是：财务上的问题，会有教训。 

 运维工程师需要学习服务应用程序层的核心、本质的部分。   

 现在他们已经可以为设置趋势监控提供帮助，并且能够预测构建场景中的错误。 

本质上，我还是想让我的软件开发团队编写代码，构建新的特性来吸引客户的眼球，而不能
被其它任何事情来分散精力（包括云计算）。我还是想让运维团队  （或者是拥有多名工程师
的团队，或者是兼职的远程系统管理员）来调整系统，并能够对构建客户想要的东西的团队
做出最快地响应。我还想让运维团队学习应用程  序层的关键知识，那样他们就能够不定期
地找到针对架构的缺陷（作为唇齿相依的关系，不再对变更抱怨）。 

 
 以下内容增加于 4 月 20 日 

Bjorn Freeman‐Benson：Carlos，多谢你明确了立场。简要地说，我同意大多数你关于开发者
如何认识运维人  员的说法（变更阻碍者），并且我想要增加对运维人员如何对开发者的认识
（一群疯狂的牛仔）。我看到，关于我们的讨论，有很多读者发表了有意思的评论。我已  经
在线下得到了一些关于影响的反馈（感谢@markimbriaco和@randybias），我的立场很明确，
强烈地反对运维功能。我  并非故意如此，并且希望我没有将运维人员描述为完全不必要或
者没有能力。我并不认为没有公司需要运维功能，很显然并非如此。 

26 
 
  

我的立场和观点都集中于应用程序，以及对它们负责的人。毕竟，如果不是为了应用程序的
开发和运维，IT 还有存在的价值吗？ 

让我用这次发布的内容来澄清我的观点，并对 Carlos 上面的一些评论做出回应。 

首先，我所听到和读到的来自于运维人员的讨论（其中很不错的一条评论就在本文下面，由
John Willis 发表）告诉我们，没有人知道，运维的角色已经产生了很大的转变，这比运维人
员本身还要大。Carlos，你的评论也显示出这一点。他们能够认  识到，数据中心和应用程序
比起几年前已经有了很大的改变。数据中心过去会是各种技术的大杂烩——一台大型机、一
些 AS‐400 机器、一些 RS‐6000 机  器、一些 DEC 的小型机以及一些“那些 web 家伙”使用的
Wintel 服务器，再加上一大堆存储设备，他们需要不时地对其进行维护和反馈。现在仍然还
有这  样的数据中心，对于支持它们的运维团队，我想可能没有什么变化。然而，现在数据
中心里面拥有 1000 台 Linux/Tomcat 的刀片服务器已经不是什么  稀奇的事儿了，所有这些刀
片服务器都彼此相同。另外，几乎所有应用程序都基于 Web 技术（Java, .Net, Ruby, PHP）也
不是什么稀奇的事儿，并且在那些数据中心中没有什么需要学习的管理工具，也没有需要支
持的专利系统。云计算将这种现象发展到了极致。因此在越来  越多的情况下，运维团队的
角色由于标准化和便利性而越来越简化。我们的观点是，我描绘的情况正在成为标准而不是
不常见的情况。 

即便是在高度标准化的数据中心（我的有 1000 台刀片服务器的例子中）情况下，仍然还有

运维的任务。有大量需要专业知识的工作——数据库管理、容量  规划、数据备份和恢复、
灾难恢复规划、电力管理、通信管理等等。执行这些任务的人是为整个数据中心在服务（或
者是为雇用他们的云提供商）。 

我的观点的关键在于，对应用程序的管理职责应该主要归属于应用程序开发团队，而不是运
维团队。另外，Carlos（这可能会让你感到惊奇），我完全  同意你下面的观点： 

我有一条未经测试并且非常单纯的理论：变更对于运维是有害的，而软件开发就是变更。因
此存在最重要的矛盾，这需要聪明地处理。 

我的观点是，开发者和架构师能够比运维团队更好地为部署、监控、以及突发事件管理决策
做准备，因为他们拥有与应用程序架构和语言最紧密相关的知识。  在应用程序管理的情况
下，运维和开发团队之间职责的划分没有那么有效。谁应该为应用程序的成功对公司负责也
不是很清楚。最终，通过把应用程序的进展管理直  接放到开发人员的工作描述中，应用程
序的质量会得到改善。我们不再允许开发者向运维团队发布代码质量低的应用程序，然后对
后来的烂摊子放手不管。 

27 
 
  

我喜欢你针对“公司所有者想要的是什么”的敏捷故事方法，但是在对其作出评论之前，我想
听听来自于读者的评论。 

 
 以下内容增加于 4 月 21 日 

Carlos Armas：尽管我非常愿意相信运维团队的任务正在变得简单（这也是我所期望的），但
实际的情况却恰恰相反。 

据我所知，在过去的 15 年间，人们误解了运维任务，并逐渐将其最小化了。不必感到奇怪，
因为这很大程度上都是运维团队的错。 

这开始于大型机时代，当时 MIS（信息系统经理）担任的还是“计算教堂中的神父”的职责。
在“机器时代”，玻璃墙后的评判者使用仪式、保密和分离的  原则进行运维工作。这对于监
视很有好处，也有利于在公司竞争范围中对挑战进行控制。 

那样的时光已经一去不复还了。正如我所见，工作中最简单的部分已经逐渐地消失了。我们
不再通过分离/bin 和/usr/bin 目录来对硬盘进行加速和减速，或者使用 12GB 内存的 Sun 
E4500，让它占据数据中心最重要的位置。我忘记了是什么时候我最后一次使用剥皮钳来做
电缆（谢天谢地！）。我也不再记得曾经是什么时候不得不编译一些  程序，因为 apt 或者 yum
会给我稍微旧一些的、无法处理的版本。 

我认为运维的物理任务很早以前就从我们的工作描述中消失了，而被放到初始化/支持任务
中。另一方面，我们的工作变得越来越复杂。多服务器的同构数据  中心（甚至是虚拟的、“云”
的）带来了不同的、更高级别的让人头疼的工作和复杂度。随着 kickstart，puppet，以及其
它相关的自动部署机制一  起，所谓的“原子任务”也随之而来了。在单一服务器中的简单拼
写错误/etc/sudoers 很容易修正——但现在在我们的系统中存在自动的乘法/加速效应，那会
让错误在几秒到几分钟内扩展到成千上万台服务器中。 

每天我们面临的挑战也发生了变化，从“为什么编译失败？”变为“怎样我才能骗过傀儡模块，
它将应用程序 Y 部署到 120 台服务器上来安装发布 X，但是  在完成之前无法发布 X+1，所以
最终我没有在生产实例中发布 alpha 测试质量的代码”。我很喜欢现在的情况，因为“现实世
界中的约束”不会成为云提供商  的环境中的障碍。协商、斡旋、统筹、分离和配置工作都应
该提前做好。那就是过程。这个趋势为云计算铺平了道路，并且肯定会很受欢迎。而我的工
作肯定不会变得更简单，尽管我使用自动化的方式来帮助我更好地铺平了道路。 

我们可以这样认为：它变得更加复杂，但现在我拥有更好的能为我们提供帮助的工具。并且，
作为通向下一个目的的途径，我非常感谢创建这样的自动化工具的开发者们，那也是我想要

28 
 
  

它们一直为新的想法做开发，而不是管理部署后的应用程序的原因所在。 

我同意你关于开发人员和架构师的观点，他们正在准备更好地做出部署/监控/突发事件的管
理决定。毫无疑问，在我的意识中，开发者和架构师比任何人都  更了解它们所创建的应用
程序。 

对于谁应该为公司对应用程序的成功负责这个问题，我仍然持这样的观点（可能是过时的），
应用程序是服务生态圈中的一部分，没有支持它的架构基础就无  法生存——即便是在云环
境中，架构也需要管理，我更希望在该领域非常专业的人来执行那些任务。我想可能是看问
题的角度的问题，我们更可能在此通过同意的方  式来表达反对。 

现在，让我们回顾一下开发者在他们的工作描述中增加对应用程序在生产环境中的管理的责
任，正如你所提到的：我喜欢！非常喜欢。“放轻松一些，年轻  人”。将你的开发者轮换到
运维团队的岗位，从而他们能够得到交付一致的、24/7 SLA 支持的用户体验相关的需求和挑
战的第一手经验，同时给他们灌输应用程序级别的知识。这和新雇佣的开发者一样的。作为
对等（反击），我会将我的运维工  程师轮换为你的 SCRUM 团队，并且体验第一手的“排除障
碍”的工作，由于延迟和红色条所带来的挫折等等。这对于消除团队之间的（人为的）壁垒
非常有益，那样就不会再有“我们  vs  他们”。 

上述的内容会确保我让开发者做的是我需要他们做的（作为公司所有者）：创建新的功能，
同时有助于传递知识，从而能够在生产环境中更有效地支持应用程序。 

 
 以下内容增加于 4 月 27 日 

Bjorn Freeman‐Benson:  这是非常有趣的一周。很抱歉我已经有好几天没有发表内容了。我
在我们的 SaaS 工具上  部署了很棒的新特性，并且开始了下一轮的开发。现在我们在应用程
序性能监视工具中包含了对生产环境的概要分析。我们至少每周都会推出一些新特性，并在
一周之内做几次 ad‐hoc 的补丁。这让我们一直都很忙。我还要说，在 New Relic，我们仍然
拥有非常棒的系统管理员，他叫 Bayar Carlin。我知道，通过我的评论，你可能会认为我们
没有任何运维人员。但是，我们确实有一名。他也是应对我们的员工的需求的内部 IT 部门。
在以后的内容中我会更多地谈到 Bayard。 

在查看来自于读者的一些评论的过程中，我看到了很多非常好的评论，想在这里强调并做出
回应。在下次发布的内容中，我会总结从所有这些反馈和  Carlos 的观点中所学到的东西。 

首先，David Sims 评论道：“让我们的开发者深入参与到技术支持中真的很好，因为这让他们
产出了更好的产品。然而，正如 Carlos 所指出的，作为小公司的所有者，  我知道让开发者

29 
 
  

来回答问题并非是对资源最有效的利用，有技能的支持工程师同样可以处理。”我对两位的
意见都表示同意。我已经看到让开发者参与到生产环境的会让产品质量得到稳步地改善。我
们也同意 David 的意见，他说对于开发团队，当还有新的代码要写的时候，花费时间做运维
的工作是一种挑战。然而，如果  David 的意思是运维工作并不具备足够高的价值，那么我就
要表示反对。我不会为运维团队所做的工作分配比开发团队做的工作少的价值，只是之间有
所不同。 

其次，Geva Perry 关于云计算造成的影响以及对运维的角色的影响的分析的思考非常有价值，
可能某天我们会在新的文章中对其进行扩展。在 New Relic 中的一些应用程序位于云中，而
另一些位于传统的托管环境中。然而，我们有大量的客户，部署在各种各样的云环境中，我
们听到其中的某些客户谈到，  他们在新的部署环境中遇到了很多新的、不同的需求。 

第三，我对 John Allspaw 的评论同时持同意和反对的意见。我不同意他所说的（云中的）自

动化不会明显减少运维人员的数量。我认为这是不可避免的趋势。我同意在大多数  大型的
公司中，仍然还会与运维团队，并且我们可以用他们学会协作的程度，而不是抹杀他人的成
绩的程度来衡量成功。 

第四，我喜欢 Sellers Smith 的意见，“健康的运维环境的标志”。我认为他处于正确的轨道上。

我还是喜欢将应用程序和服务等级中更多的责任成功地迁移给开发者，从而在开发人  员和
运维人员之间没有过多的传递，而有更多在思想来创建应用程序和应用程序平台。想一下在
工业工程和客户产品中的对可维护性的设计的运动，你就会明白我所  想要表达的意思。 

下次发布时我会总结我所学到的，并继续征求你们的意见。 

原文链接：http://www.infoq.com/cn/news/2010/05/debate‐role‐of‐ops 

相关内容： 

 OOPSLA辩论：被高估的云计算 

 讨论：Internet正在被分裂成多个部分吗？ 

 Symbian的开源是否为时过晚？

 以生产力为导向的决策：原因，影响和局限

 洞察动态语言与静态语言之争 

30 
 
时刻关注企业软件开发领域的变化与创新

Java .NET Ruby SOA Agile Architecture

Java社区：企业Java社区的变化与创新

.NET社区：.NET和微软的其它企业软件开发解决方案

Ruby社区：面向Web和企业开发的Ruby，主要关注Ruby on Rails

SOA社区：关于大中型企业内面向服务架构的一切

Agile社区：敏捷软件开发和项目经理

Architecture社区：设计、技术趋势及架构师所感兴趣的话题

讨 论 组 ：groups.google.com/group/infoqchina
编辑电邮：editors@cn.infoq.com
广告合作：sales@cn.infoq.com
  

推荐文章    Articles

你是个软件架构师吗？ 
作者Simon Brown 译者 晁晓娟   

编者按：  本文作者  Simon Brown  ，在三月的QCon London上发表了同样主题的演讲

《Software Architecture for Developers》。 

开发和架构的界限难以捉摸。有些人告诉你它根本不存在，架构只是开发者们所做的设计过
程的简单扩展。  另外一些人认为这是一个鸿沟，它只能由那些做到高度抽象，而且不会陷
入实现细节的开发者才能跨越。通常，在这两个极端的观点中间某处有个可操作的平衡点； 
不论如何，怎么从开发转换为架构师都是个有趣的问题。 

经常被用来区分软件架构和软件设计开发的关键几点包括  伸缩性和抽象程度的增加以及作
出正确设计决策意义的增强。软件架构是通过一个全局的观点，宏观的视角来理解软件系统
作为一个整体如何工作。 

即使这能够帮助区分软件开发和架构，它并不能帮助理解某人如何从开发提升到架构。  并
且，它也不能帮助识别谁能够成为一个好的软件架构师，如果你想雇人的话你如何去寻找他
们以及你是否是一个软件架构师。 

经验可以判定但你需要更深入地了解 

要成为一个软件架构师并不是一夜之间或者一个职位的提升就能简单达到的。  这是个职责，
而不是头衔。这是个进化的过程，你将会逐步得到担当这个职责所需的经验和信心。 

当你寻找架构师时，需要考虑各方面的素质，他们过去的经验往往是他们有能力担当这个职
责很好的判断。由于软件架构师的职责是多种多样的，所以你需要再深入了解他们在不同领
域的参与度，影响力，领导力和责任感。一般来说，在大多数项目中软件架构可分为两个阶
段，架构的定义，然后是它的交付。 

31 
 
  

软件架构的定义 

架构的定义过程看起来非常简单明了。  你需要做的是理解需求并设计一个系统来满足需求。 
但实际上并没有那么简单，根据你不同的做法，软件架构的职责之间差距很大，以及如何认
真看待自己的职责而定。如下图所示，这个职责的架构定义部分，可以进一步细分成不同的
元素。 

 
1. 管理非功能性需求：软件项目经常陷入问用户要求是什么，什么是他们想要的功能，但
很少问他们需要什么非功能性需求（或系统  质量）有时候，干系人会告诉我们，“这个
系统必须很快”，但是这太主观了。非功能性需求如果要满足的话需要明确，可度量，
可获得以及可测试。大多数非功能  性需求本质上是技术层面的而且经常对软件架构有
很大的影响。理解非功能性要求是架构师职责非常重要的一个部分，但假设这些需求是
什么并不一定是对他们的挑战。你见过多少系统真正需要 24x7 的运行呢？ 

 
2. 架构定义：捕捉到了非功能性需求后，下一步是开始思考你打算如何去解决干系人提出
的这些问题并定义它的架构。  公平的说每个软件系统都有一个架构，但并不是每个软
件系统都有一个定义好的架构。这正是问题的关键。架构定义过程让你想清楚你打算怎
么在兼顾需求和限制的  情况下把问题解决好。架构定义是将结构，方针，原则和领导

32 
 
  

力引入软件项目的技术层面。定义架构是作为软件架构师的工作，但是从头开始设计一
个软件系统和对  已存在的系统扩展是相当不同的。 

 
3. 技术选型：技术选型通常是一个有趣的练习，但它也有公平的挑战,因为你需要综合考虑
成本、许可、供应商关系、技术策略、兼  容性、协作性、支持、部署、升级的政策以
及最终用户环境等各方面。综合这些因素，通常会导致简单选择类似富客户端技术而进
入了完全的噩梦。接下来的问题就是这些技术是否能真正有用。技术选型是彻头彻尾的
风险管理；复杂性或不确定性太高的时候要减轻风险，当有机会或利益的时候要引入风
险。技术决策需要考虑多种因素，而且所有的技术决策需要被检查和评估。这包含软件
项目的主要组成部分乃至开发中引入的类库和框架。如果定义一个架构，你还需要有信
心认为选择这项技术是正确的。同样在技术评估中也还是存在开发新系统和向现有的系
统增加新技术的不同点。 

 
4. 架构评估：如果你设计软件，你需要问问自己你的架构是否有用。  对我来说，一个架
构是成功的，如果它满足非功能性需求，而且为其他部分的代码提供必要的基础，并为
解决和存在的业务问题提供足够的平台。软件的一个最大的问题就是它复杂而抽象，导
致很难从 UML 图或代码本身去设想出运行时的特性。在软件开发周期中我们进行了很
多不同类型的测试，这样我们能够有信心我们发布  的系统在推出时能够正常运行。我
们为什么不对架构也这样做呢？  如果能够测试你的架构，那你就可以证明它是有效的。
如果你能尽早做到这一点，你就能减少项目失败的风险，而不是简单地希望一切都好。 

33 
 
  

 
5. 架构协作：任何一个软件都不是与世隔绝的，需要很多人理解它。  包括从需要理解和
切入架构的直接开发团队到其他对安全性、数据库、运营、维护、支持等有兴趣的干系
人。要想让一个软件项目成功，你需要和所有的系统干系人  紧密协作来保证架构和所
在的环境很好的集成。不幸的是，现状是与开发团队的架构协作很少发生，更不要说外
部干系人了。 

软件架构的发布 

对于架构的发布也是同样，对于成功的软件项目参与程度的不同，也决定了软件架构职责的
不同。 

34 
 
  

1. 拥有全局的视角：为了把一个架构成功地实现，我们需要具有全局的视角并把贯穿软件
开发生命周期的愿景加以宣传与推广，必要的话在整个项目中展开和完善，并对成功发
布负责。如果如果你定义了一个架构，参与并保持不断发展的架构才是有意义的，而不
是选择把它传递给一个“执行小  组”。 

 
2. 领导力：拥有全局的视角是技术领导的一个方面，但是还有其他事情在软件项目发布阶
段需要做。这包括承担责任、提供技术指导、作出技术决策以及具有权力作出这些决定。
作为架构师，你需要进行技术领导来确保每件事都被考虑到，而且团队在朝着正确的方 
向持续前进。软件架构师职位是需要内在领导力的，虽然这听起来很明显，但很多项目
团队并没有获得他们所需要的技术领导，因为架构师认为一个成功的发布并不一定是他
们所关注的问题。 

 
3. 教练和指导：在大多数软件开发项目中，教练和指导经常不被重视，团队成员得不到他
们需要的支持。虽然技术领导是引导整个项目，但个人也经常需要帮助。除此以外，教
练和指导提供了一个强化技能的方式，并帮助提升职业生涯。这应该是软件架构师份内
的事，  而且指导团队架构和设计与帮他们解决代码问题是截然不同的。 

35 
 
  

 
4. 质量保证：即使是世界上最好的架构和领导，很糟糕的交付也足以让一个具备其他成功
条件的项目失败。质量保证在架构师职责中  占很大一部分，但这并不只是简单做代码
检查。  比如，你需要一个基线来确保，这意味着引入新的标准和工作实践。从一个软
件开发的角度来说，这可能包括代码标准、设计原则和源码分析工具甚至于使用持续集 
成,自动化单元测试以及代码覆盖工具。可以说大多数项目质量保证做的并不够，所以你
需要搞清楚什么是重要的并给予它足够的保证。对于我来说，一个项目的重要部分包括
架构上的重点，关键、复杂或高度可见的业务。你要关注实效并认识到你并不能保证一
切，要知道做总比不做好。 

 
5. 设计、开发和测试：软件架构师的职责范围的最后一件事是设计、开发和测试。作为一
个实际动手的架构师并不是需要你每天都要写代码，但是它的确意味着你一直在参与项
目，而且积极帮助打造和交付它。说了这么多，为什么每天写代码不应该成为一个架构
师职责的一部分呢？大多数架构师  都有写代码的经验，因此让这些技能保鲜是有意义
的。而且，架构师能体会到团队里其他人的痛苦和感受，这样能让他们更好地理解他们
的架构从开发角度看是什么  样的。很多公司有政策阻止软件架构师从事写代码，因为
架构师“去做那些廉价的工作太贵了”  ，这显然是个错误的态度...如果架构师已经花了那
么多时间精力为项目做架构，何必从政策上不允许他们多走一步来帮助项目达到最终的
成功呢？当然，有些情况下卷入代码级别并不现实。比如，一个大的项目通常意味有一
个更大的“全局观”  来考虑它，而且可能有时候你就是没有时间。但一般来说，一个写
代码的架构师比只在旁边观望要更高效和快乐。 

36 
 
  

你是一个软件架构师吗？ 

不管你认为软件开发和架构之间的界限只是一个幻觉还是个巨大的鸿沟，以上强调了人们对
整个软件架构中的经验水平往往有很大的差别，而这取决于他们怎么样工作以及他们如何认
真地看待他们的职责。大多数开发人员不是在某一个星期一的早晨醒来就宣布自己成为一个
软件架构师的。我当然也不是，我成为软件架构师的路线是一个渐进的过程。话虽如此，但
很可能同样那些开发者已经做了一部分架构的工作，不论他们的职位名称是什么。 

为软件系统的架构作出贡献和自己负责定义它有很大的区别，拥有持续的、跨不同领域的技
能、知识和经验构成了软件架构的职责。跨越软件开发者和架构师的界限取决于你自己，但
是首先你要明白你的经验水平，才能开始架构师之旅的第一站。 

关于作者 

你可以认为Simon Brown是一个写代码的软件架构师或者理解架构的软件开发者。当他没有
用.NET或Java开发软件的时候，Simon通常在做咨询，指导或者培训。  Simon还写过关于Java
的书，在行业活动做过演讲，并且整合了一个叫Software Architecture for Developers的培训课
程，  该课程基于他在Coding the Architecture描述的软件架构。你可以通过e‐mail或  Twitter找
到他。 

原文链接：http://www.infoq.com/cn/articles/brown‐are‐you‐a‐software‐architect 

相关内容： 

 Felix Bachmann谈软件架构评估 

 测试驱动开发与遗留代码的问题 

 数据库驱动应用程序中影响性能的反模式 

 Tech Lead的三重人格 

37 
 
  

推荐文章    Articles

DSL的演进 
作者Peter Bell   译者  王丽娟 

简介 

领域特定语言（DSL）  是针对特定问题领域的编程语言，而非通用语言。要创建“不重复自
己”（Don't Repeat Yourself）、“业务用户可读”的代码，DSL可是个好方法。在过去的几年里，
有关DSL的文章比比皆是。 

创建一种领域特定语言并非难事。但我们对领域的理解总是不断深入，要让DSL长期有用，
我们就需要一种不断完善DSL的策略。如果你正在开发一个大  型项  目，或是一条软件产品
线（SPL），  在很长一段时间内都需要使用DSL的话，那你最好考虑清楚该如何处理DSL的演
进。 

从借助版本化实现的向后兼容性，到语句的自动转换，本文将着眼于不断简化 DSL 演进过程

的 DSL 构建方法。 

避免问题 

在第三代编程语言（3GL）的世界里，语言设计者非常清楚向后兼容性的重要性。无论 Java
的下一个版本会有哪些变化，都不太可能破坏先前版本中添加的任何功能。不过使用 DSL
时，随着我们对问题空间的进一步探索，我们对领域的理解会发生彻底改变。在单独项目中，
业务专家往往会在后期提出新的领域概念，这就迫使你要追根溯源，重新考虑怎样才能最好
地为领域建模。软件产品线里的每个新项目都会带来不同的需求，这些需求则会对 DSL 的优
化设计产生影响。 

过去，我们始终建议大家在进行领域特定建模（DSM）时，只有在业务规则频繁变化、而领

38 
 
  

域结构却相对稳定时再引入 DSL（两个条件分别是为了提高开  发 DSL 及其相关工具的投资

回报率，减少改进 DSL 结构时遇到的问题），从而减少这些问题。不过 DSL 现在应用得越来
越广泛，理解与 DSL 演进相关的问题、处理这些问题的一些策略就非常重要了。 

问题是什么？ 

有些类型的 DSL 演进根本不是问题。如果你想增加一个新的领域概念，或是给概念新增一个

可选特性【译注】，你只用扩展 DSL 语法就可以了，而这并不会破坏任何已有的代码。但在
有些情况下，你必须考虑语法的这些变化会对已有的语句产生什么影响。这些情况有： 

 删除一个概念或特性 

 添加一个特性，不同语句需要的特性值可能会有所不同 

 将特性连同其子特性转变为一个独立的概念 

 增加一项新的约束，而已有的语句可能并不满足该约束 

抽象语法（Abstract Grammar）vs.  具体句法（Concrete Syntax） 

有一个重要的 DSL 概念能让接下来的讨论稍微简单一些，那就是抽象语法和具体句法之间的

差异。DSL 的抽象语法描述了有效语句的结构，也包括所有相关的约  束。具体句法则描述
了如何在 DSL 中正确编写语句的细节问题。 

举例来说，假设有一个描述状态机的DSL，它可能包括一个这样的概念：一个对象能有多个
状态。抽象语法只能传达“一个对象能有多个状态”，
（还有所  有的约束，比如每个对象至少
要有一个状态、给定对象的每个状态都应该有唯一的名称）。具体句法则可能是建模工具里
的图、XML文档、Groovy或Ruby这些DSL本身的代码、电子表格、基于DSL的数据库  Schema，
或者是自定义的文本句法。尽管在特定的具体句法中对DSL的某些内容作出改进会更具有挑
战性（比如处理与图形化语言相关的位置和图形数  据），但我们还是要着眼于抽象语法，来
讨论大部分问题和DSL演进带来的影响，要明白表述语句的具体句法只是个次要问题。 

进行DSL演进的方法 

在已经有 DSL 语句的系统中，进行 DSL 演进的常见方法有三个： 

 依靠向后兼容 

39 
 
  

 语言进行版本化 

 自动进行语句转换 

向后兼容性 

解决问题最简单的方法就是回避问题。对 DSL 语法的修改坚决不能破坏已有语句。人们使用

DSL 一段时间后，往往会演进 DSL 语法，却不关心修改是否  会破坏已有的语句。最终，用
例会在这些演进的地方突然出现问题。 

语言版本化 

对于可能会破坏已有语句的DSL演进来说，最快捷的解决办法是对DSL进行版本化。无论你使
用的是某种内部DSL的内置分析，还是“外部DSL+显  式的解  析器”（或许是ANTLR、Xtext，
也可能是使用XML具体语法时用到的XML解析器），  当你需要做重大更改时，你只用发布解
析器的新版本、确保你的系统支持多版本，在语句需要利用后续版本中可用的扩展语法时，
只要更新语句就可以了。这个方法在一定程度上可以说是相当不错的，但对语言多版本进行
维护、支持、调试的开销最终会变得难以承受。 

语句转换自动化 

理想的解决办法是能对DSL语句进行自动演进，只要你修改了语法，
（如果可能）语句就可以
自动更新。最简单的处理方法之一就是将转换应用到语法，然后使用脚本语言或是XSLT、
ATLAS这种允许模型到模型（M2M）转换的语言编写脚本，将同样的改变运用于DSL语句。 

转换示例 

假设我们使用 XML 这一具体句法来描述应用中领域对象的 DSL。最初，我们可能有两个领域

类——User 和 Product，如清单 1 所示。 

清单 1：User 和 Product 领域对象的 XML 句法。 

<domainObject name="User" />

<domainObject name="Product" />

很快，我们决定添加 Property 的概念，而且每个 domainObject 可以有 0 到 n 个属性。这个

转换并不会破坏现有的语句。它只涉及“添加概念”  和“添加可选关系”，也就是说，我们增
加了一个新的概念——属性，以及一个新的可选关系（每个领域能有 n 个属性，但属性并不
是必需  的）。清单 2 是带有 Property 概念的语句： 

清单 2：带有属性的领域对象。 

40 
 
  

<domainObject name="User">
<properties>
<property name="FirstName" />
<property name="LastName" />
</properties>
</domainObject>

<domainObject name="Product">
<properties>
<property name="Title" />
<property name="Price" />
</properties>
</domainObject>

现在再添加一条——属性可以有一条验证规则。这样我  们就有了“添加可选特性”的转换，
这里我们要为属性添加可选的“validationRule”特性。同样，由于特性是可选的，先前的语句
仍然有效，所以  对语法应用了这一转换之后，我们并没有破坏当前的 DSL 语句，也就不需
要对语句做什么处理了。 

比方说我们就这样工作了一段时间，XML 最终就像清单 3 所显示的那样。 

清单 3：带有验证规则的领域对象属性。 

<domainObject name="User">
<properties>
<property name="FirstName" />
<property name="LastName" validationRule="Required" />
</properties>
</domainObject>

<domainObject name="Product">
<properties>
<property name="Title" validationRule="maxlength=50"/>
<property name="Price" validationRule="isNumeric" />
</properties>
</domainObject>

不过现在我们意识到，有些情况下，我们要为一个属性  关联多个验证规则。这一问题有很
多解决办法。让我们看看其中之一。首先，我们可以只改变 validationRule，使其成为以逗号
分隔的验证规则列  表。这一变更不需要对现有语句进行任何修改（假设当前所有的验证规
则中都没有逗号）。但语言中会出现容易让人误解的特性，因为  validationRule 支持以逗号分
隔的规则列表并不是很容易理解。 

接下来可能会采用的转换是“为特性重命名”。将  validationRule 重命名为 validationRuleList，

你会有一个从语义上来说更有意义的特性名称。要做到这一点，你要有方法将这  类转换应
用于已有的语句。最佳方法因使  用的具体句法而不同，但 XML 具体句法（或是任何能与 XML

41 
 
  

工程互相转换的内容）要  做到这点还是相对容易的，这只是举了个例子。 

我们继续扩展应用，不幸的是我们发现验证规则需要更  复杂的参数。例如我们有一个规则，
用户在网站上注册时密码和确认密码必须匹配。这个验证规则可以写成清单 4 所示的 XML
片段。 

清单 4：带有密码和确认密码属性的验证规则。 

<validationRule name="PasswordMatchesConfirmation"
type="propertyValuesMatch"
firstPropertyName="Password" secondPropertyName="PasswordConfirmation" />

我们现在的问题是要将“特性应用到关联的概念转换上  去”。让我们分析一下。首先，这个
特性要“转换概念”，因为我们将 validationRule 作为属性使用，而现在要替换为单独的 
validationRule 概念，这一概念在 XML 具体语法中用单独的 XML 元素表示。这个特性还要“转
换为关联的概念”，因为我决定在  语言里用独立的片段来描述这些规则，而这些规能被不同
的属性重用。举例来说，如果 FirstName 和 LastName 都是必需的属性，那它们就可以用同  一
个“Required”验证规则。更适合这些情况的替代方法是使用“转换为组合概念的特性”——每
个属性可以包含规则。 

XML 片段使用“组合概念”的特性会是清单 5 所示的样子。 

清单 5：带有“组合概念特性”的领域对象。 

<domainObject name="User">
<properties>
<property name="FirstName" />
<property name="LastName">
<validationRule name="Required" />
</property>
</properties>
</domainObject>

<domainObject name="Product">
<properties>
<property name="Title">
<validationRule name="maxlength" value="50" />
</property>
<property name="Price" validationRule="isNumeric">
<validationRule name="isNumeric" />
</property>
</properties>
</domainObject>

清单 6 显示了使用转换为关联概念的特性后，XML 的样子。 

42 
 
  

清单 6：带有“关联概念特性”的领域对象。 

<domainObject name="User">
<properties>
<property name="FirstName" />
<property name="LastName" validationRuleNameList="Required" />
</properties>
<validationRules>
<validationRule name="Required" />
</validationRules
</domainObject>

<domainObject name="Product">
<properties>
<property name="Title" validationRuleNameList="TitleMaxlength" />
<property name="Price" validationRuleNameList="isNumeric" />
<validationRules>
<validationRule name="TitleMaxlength" value="50" />
<validationRule name="isNumeric" />
</validationRules>
</properties>
</domainObject>

同样，这些转换都可以自动应用于已有的 DSL 语句。 

自动化的局限性 

当然，有一些转换是不能自动进行的。当你想应用“删除概念”或“删除特性”的转换时，你使
用的工具很有可能会自动扫描已有的语句，但无论你是必须基于转换脚本提供的报告进行手
工修改，还是不得不使用“deprecate”来代替“删除”转换，每当工具发现这些条目，不让你添
加新条目、却又不会强迫你  移除那些条目时，这些工具可能都会让你觉得相当痛苦。 

同样的，如果你想用“添加必要特性”的转换为所有属性添加一个数据类型特性的话，除非你
能给出缺省值（没特殊说明就是字符串）或一些智能的脚本规则，否则自动化工具最好能提
供一个高效的 UI，能为历史语句填充所有的条目。 

内部DSL vs.  外部DSL 

认识到内部 DSL 的局限性是很重要的。在“最终用户可读性”方面，内部 DSL 提供了很多好处，

不过对于那些使用某种语言内置 DSL 编写的语句来说，  自动应用转换通常会比较棘手。内
部 DSL 很好，但你要是在大型项目或软件产品线中广泛使用这些内部 DSL 的话，就要确保你
要有一个将转换应用到这些 DSL  上的策略。否则在项目的生命周期里，为外部 DSL 创建工

43 
 
  

具所花的那点儿时间与使用内部 DSL 相比来说可能更划得来。 

结论 

本文最重要结论的是，只要你的 DSL 是成功的，那你最终会有许多使用这些 DSL 的语句。要

真是这样，如果你确实需要演进你的 DSL，你最好是有一个  处理这些语句转换的策略。 

此外，认识到这个问题还没有解决也很重要。这一领域还需要很多工作要做，除了来自
MetaCase 的 MetaEdit+之外，大部分领域特定建模工具都不能很出色地处理元模型演进。 

引用 

 领域特定语言 

 不断演进的领域特定语言中，语句转换的自动化 

 MetaEdit+ 

关于作者 

Peter Bell是SystemsForge的  CEO兼CTO。他开发了生成自定义Web应用的软件产品线，该产
品线融合了特征建模、产品线工程和领域特定建模。他的文章和演讲遍布全球，内容涉及领
域  特定建模、代码生成、精益/敏捷开发，以及Groovy和CFML等JVM上运行的动态脚本语言。
他的Blog为：http://appgen.pbell.com/。 

原文链接：http://www.infoq.com/cn/articles/dsl‐evolution 

相关内容： 

 创建内部DSLs——Groovy比Java更好吗？ 

 多语言和DSLs会使Java成为最后的大语言吗？ 

 RGen：Ruby建模和代码生成的框架 

 使用LESS或Sass重构CSS代码 

 外部DSL：成功与失败的因素

44 
 
  

推荐文章    Articles

Scout ‐  可扩展的服务器和应用监控服务 
作者 Robert Bazinet  译者  杨晨 

Scout 是一个服务器和应用扩展监控服务，它主要关注于安装和配置的易用性。Scout 默认提

供了报警功能，帮助管理员更快地在不同负载的情况下  理解应用程序的行为，同样，Scout
也允许程序员创建插件来扩展 Scout。 

Scout 的威力并不仅仅体现在其本身的功能，还体现在能够通过编写 Ruby 插件来扩展功能。

例如能够监视 Ruby on Rails，Phusion Passenger，Nginx，Mysql 等的插件。 

InfoQ很荣幸对Scoutapp.com的创始人之一Andre Lewis进行了采访，一起讨论了Scout的相关
内容，以及它是如何以一种不同的方式帮助开发者和系统管理员同时对服务器和应用进行监
控。 

Robert Bazinet（RB）：首先，能简单介绍一下 Scout 吗？ 

Andre Lewis（AL）：Scout 是一个托管服务监控程序。我们曾经这样问自己：开源监控解决
方案最优秀的部分是什么？是  灵活性。那么最坏的部分呢？是安装和持续维护。所以，我
们将托管服务和一个灵活的插件系统绑定在一起。 

结果表明：Scout 是监控你生产环境的最简单的解决方案。你可以跟踪你架构中的每一部分，
获得关于趋势或者阈值的 Email、短信警报，并且可以  对数据图表进行研究。 

RB：你是如何让客户对你的服务所提供的数据安全和隐私保护感到放心的呢？ 

AL：我们的安全规范符合工业标准。所有的数据都是通过 SSL（你的银行也是使用这个技术）
传输。在我们的服务器上严格管理这些数据。最后我想强调一点，现在可以作为服务的软件
非常多，比如作为邮箱服务的 Gmail，作为商业信息服务的 Salesforce，作为源代码服务的 
Github，还是作为个人理财的 Minty。所以，可以看出托管方式的接受程度是很高的。 

RB：Scout和其他市场上的工具例如New Relic RPM有何相似之处呢？ 

45 
 
  

AL：如果服务器崩溃，或者磁盘空间不足，或者工作队列回滚，如果使用 New Relic 的话，

你可能找不到问题的所在。要知道，其中任何一个事故都能够造成 web 应用中断，这时候
Scout 就会发挥作用了。Scout 和 New Relic 组成了一对功能强大的组合  ‐  我们有大量的客户，
他们使用 New Relic 来分析 Rails 性能细节，然后使用 Scout 来监视任何可能造成 web 应用崩
溃的程序。在你有大量服务器的时候，Scout 的价格也非常合理。根据你的安装数量，New Relic 
RPM 的价格可能会是 Scout 的 4 倍到 10 倍。 

RB：Scout和传统工具例如Nagios相比又如何呢？ 

AL：我用一个家庭场景来举例：某天，我想重新装修一下我的浴室。我将会学习很多知识，
但是我也要面对一些烦人的问题。仅仅听见我妻子喊叫“没有热水”就足够让我头疼了。在折
腾了一天之后，请一名专家来做这个工作会简单很多。Scout 就是这样的专家。收尾的工作
一般很少，而且它不会使你从核心工作中（也许并不是设置监控程序）分心。如果你有时间
的话，Nagios 和 Ganglia 之类的软件将会非常有用。由于开发者和系统管理员的分工，时间
通常都不充裕。 

另外一个选择 Scout 的原因是：我们一直在更新和改进它。虽然它是托管服务，但是你可以

在不需要重新安装或配置的情况下进行升级。 

RB：Monit是如何处理这种情况的呢？ 

AL：Monit是一个非常棒的自动干预工具（例如如果内存使用超过 200MB则重启进程）。我
们也使用Monit，它的确非常容易设置。我曾经写过一篇关于Monit的博文，叫做“Monit入门
”。 

RB：Scout 哪些部分是需要技术进行配置的？哪些部分是内部就已经构建好的呢？ 

AL：从用户角度来说，只有一件事情是你需要的：Scout Agent，这是一个作为 Ruby gem 分
发的 Ruby 小程序。一个 cron 作业每几分钟运行一次 Scout agent，然后收集系统的性能指标。 

这些指标会通过 S‐HTTP 回馈给 scoutapp.com。有时候我们需要回答这样一个问题“agent 是

否打开了一个端口或者接受任何连入链接？”答案是否定的  ‐‐  它只是向外发送数据，而且仅
仅通过常规的 HTTP 80 端口。 

在服务器端，Scout 是基于一系列的开源项目：Ruby，MySQL，RRDTool，Apache 和 Linux。

我们使用 Ruby on Rails 以及 Sinatra 应用架构：Sinatra 是一个低开销的轻量级架构，它增强
了数据收集机制。Rails 的功能则要丰富许多，而且也增强了 UI，当你登录 Scoutapp.com 的
时候就会看到。 

46 
 
  

我们使用的所有技术组件中，RRDTool可能是最不出名的一个。RRDTool是一个优秀的快速高
效存储海量时序数据的工具。它制作出了你在Scout上面看到的所有性能指标的图表。如果
你是一个  Ruby开发者，而且你希望知道我们是如何使用它的话，请访问我们编写的Ruby  库
与RRDTool的接口文档。它同样能够制作你一年或者更久之前收集的性能指标的图表，这对
于长期趋势分析和生产能力计划是非常关键的。 

RB：像 RRDTool 这样的开源工具为你的公司带来了什么好处呢？ 

AL：RRDTool 带来的好处是非常惊人的  ‐‐  如果没有 RRDTool 的话，我们的进度落后至少一

年以上。高效管理海量时序数据是一个巨大的挑战，我非常高兴地看到 RRDTool 能够很好地
解决这个问题。 

事实上，我们一度尝试过独立开发工具以替代RRDTool，不过结果是一场灾难。我从中吸取
了一些教训，并且将这些惨痛教训写在了我的博客上。 

RB：你为什么在Scout中选择Sinatra和Rails呢？这些工具有什么优点？ 

AL：我们使用Sinatra收集Scout agents发送过来的数据，Sinatra不得不面对海量的处理请求，
因此它必须高效快速地处理这些请求，而且必须是高度稳定可靠的。Sinatra在  这方面的确
是个中翘楚。它的请求‐响应循环是非常轻量级的。以Sinatra为基础架构并没有给我们的业
务逻辑增加开销，反而使得代码易于理解和维护。 

主要的 Scout 应用从另一方面说更像是传统的 web 应用。用户可以创建账户，查看警告，配

置触发器阈值，浏览图表等。这些功能的实现离不开  Rails 套件的巨大帮助。从重量级上来
说，Rails 比 Sinatra 大一些，但是它提供了大量的基础功能，使得编写 web 应用易如反掌。 

将数据收集机制（Sinatra）从终端用户（Rails）拆分出来的好处是：我们可以升级用户的站
点，让其以零接口收集数据。我们更新  scoutapp.com 比较频繁，因为我们要添加新的功能
或者是处理用户反馈。从运营的角度来看，我们希望能够在推送更新的时候不影响业务相关
的数据收集机制。 

RB：使用开源组件对你的业务，产品或者客户会有什么风险呢？ 

AL：我还没有看到任何风险。反而，事实上‐‐如果我们基于传统的闭源技术（OS，数据库，
应用服务器等），由于许可证的费用，我们  的最终价格可能会非常高。这反而会对我们的业
务带来风险，同样对于我们的客户来说也不是一个好的解决方案。开源是创建一家科技公司
的最好方法。 

RB：Scout 仅仅监控 Rails 应用吗？ 

47 
 
  

AL：Scout 可不是仅仅监控 Rails 应用。它还监控许多系统级的服务，因此无论你使用什么应

用架构，Scout 都是非常有用的。我仅仅列举几项 Scout 可以监控的东西：CPU 负载，磁盘
使用量，MySQL 性能和 Slow Query，任意数目设备的 IO 状态，Apache 状态，Nginx，EC2 
Cloudwatch 等等。我们发现，当实际应用中某个东西出了问题，实际上却还有其他的服务也
同时表现出了问题。能够对所有活动的服务状态产生直观的视  觉监控是 Scout 的强项。有
的服务之间的关系非常难以追踪，但是你可以利用 Scout 轻易找出。例如，你可能看到你的
应用的吞吐量下降但是 CPU 的负载却上升，或者你可能会看到异常大量的 MySQL slow 
query，通过 Scout，你可以将这些现象和你的 IO 状态联系起来，然后发现原来是一块磁盘
出了故障。 

有些时候这是最简单的将你于焦头烂额中拯救出来的办法。每一次 scout 的安装都会设置一

个触发器，自动在磁盘使用率在 80%（当然你可以将这个阈  值设置为你想要的）的时候发
送电子邮件通知你。它最近就发送给我一个关于我的某个开源项目的通知。设置了这个功能，
这个 80%阈值通知的 email 能够让  你观察事情的进展。例如，之所以会收到这封邮件，是
因为我忘了配置 logrotate 转储日志，所以磁盘被日志填充满了。 

RB：如果 Scout 能够用于监控数据库，例如 MySQL，那么如果要使用 Scout 的话，Ruby 是必

须安装在用户希望监控的设备  上？ 

AL：对，你需要安装 Ruby 来运行 Scout。Ruby 环境的使用率正在逐渐提高，所以这并不是

一个问题。很多 Linux 发布版已  经安装了 Ruby，如果 Ruby 还没有安装的话，也只是一条
‘apt‐get’或者‘yum install’命令的问题。 

RB：我发现现在有很多开源的插件，Scout 插件系统的架构是如何呢？ 

AL：插件系统是Scout的核心部分，它使得Scout功能更加丰富，扩展性能更强。插件都是基
于我们提供的API构建的Ruby的小脚本。你可以在我们提供的目录中下载插件，由于这些  插
件都是经过我们审查过的，所以你无须担心什么。如果你需要修改插件的行为，那也非常简
单，因为插件的源码非常短，而且也很简单。 

RB：开发者创建插件是免费的么？ 

AL：当然──如果你需要监控某个全新的东西，那么写个插件吧。你将能够在我们的网站上
找到开发和测试插件的全套详细教程。一旦你的  插件开始运行，在 Scout 中它也是权限很
高的：你可以绘制其数据的图表，创建触发器，当某些值超出临界状态的时候获取 email 通
知，以及追踪重要的趋势变化。 

不仅如此，如果你希望分享你的插件，那么告诉我们，我们将会对这个插件进行审查。我们

48 
 
  

已经在社区里面组织了一些相当聪明的开发者，他们创建的插件质量也非常优秀。两个生动
的例子便是 Delayed Job（一个 Ruby 应用的后台任务进程）和 Redis。每时每刻都有新的插件
正在被开发，所以客户可以一直从 Scout 中获取新的功能。 

RB：你是如何看待即将发布的 Rails 3 给你的业务带来的影响呢？或者会有影响么？Rails 的

新架构为应用提供了如此多的新特性，Scout 是不是会从中受益呢？能否详细谈谈？ 

AL：作为技术人员，我非常喜欢 Rails 3。我已经安装了 beta 版本并且升级了一些项目、从

操作上来说，它不会影响 Scout 太多。Scout 和 Rails 应用之间的主要接口是通过日志文件， 
所以我们只需要做到我们的 Rails 插件及时地在日志文件格式上符合 Rails 3 要求即可。我们
现在非常肯定 Scout 是和 Rails 3 beta 兼容的。关于 Rails 3 提供的改进版的 instrumentation
模型  ‐‐  我不可能把这个功能排除在外，但是我们现在还没有计划利用这个功能。对于高级
Ruby instrumentation，我们推荐使用 New Relic RPM 辅助。 

RB：你打算如何在你的产品中使用 Rails 3 呢？ 

AL：从业务角度来看，我们将内部架构升级到 Rails 3 需要点时间。幸运的是，我有一些编

外项目以及开源的工作可以做，我可以在那里试验 Rails 3。 

将会带来更大冲击的是 Ruby 1.9，它的速度远远快于 1.8。这将带来巨大的性能差异，因为

我们在 Scout 收集的指标上会进行大量的后台计算。Ruby 1.9 将使我们能够在当前硬件环境
下进行更多的计算。不仅仅是我们，每一个使用 Ruby 1.9 的人都将获得好处。我真的非常期
待基于 Ruby 1.9 构建的 Scout。 

RB：我看现在 Scout 已经发布了 Rackspace Cloud 版本。你能告诉我们一些更多的信息吗？

例如两者之间的关系以及 Scout 如何工作在 Rackspace Cloud 平台上。 

AL：有些时候合作关系是需要重要的投资的。我们非常幸运能够和 Rackspace 合作。当我们

开始谈判的时候，我们意识到我们都不  需要改变什么就可以使得对云环境的监控更加便捷。
因为这些工具我们双方都已经拥有了。 

在 Rackspace 中使用 Scout 是非常简洁的  ‐  将登录到云的新服务器自动用 Scout 监控，一条

在 crontab 中的命令就可以搞定。Rackspace 管理云环境的接口是当前最简洁的，同样实践
起来  也是非常便捷。仅仅在 crontab 中增加一个使用 Scout 备份的命令即可。 

也许监控云环境最大的问题便是其动态性。通常是使用脚本启动一个新的实例，而且你需要
这些脚本尽可能地简单。因为所有的监控逻辑都是由我们托管，而且是基于我们的接口进行
升级，它减少了在云环境中移动碎片的次数。 

49 
 
  

RB：如果你有大量云环境的话，Scout 是如何工作的呢？ 

AL：在传统监控工具中，增加一个任务可能需要一整天的时间，而 Scout 只需要几分钟。监

控新的实例是自动的，你可以一次请求监控所有实例。 

无论任何时候你在一个新的云实例中运行 Scout，它会自动寻找到监控记录，无论图像是用
什么工具创建的。所以，只需在 Scout 中设置好你的图表  路径，你就可以放手不管了。类
似的，如果你有大量的运行实例，你可以轻松地将一个插件安装到所有实例中。你只需点击
几下鼠标告诉 Scout 需要更新所有实  例而已。 

RB：未来客户可以从 Scout 期望得到一些什么呢？ 

AL：我们的目标是使得 Scout 成为服务器的“烟雾探测器”。有了烟雾探测器，你仅仅需要的

是放入电池，它便能自己开始工作。没有  维护需求。我们的客户需要 Scout 变成他们系统
中最稳定可靠的部分。所以，我们的大部分工作关注在如何使事情便得明了，简单和高效。
这可能意味着我们有  一天需要更新某个插件的文档或者选择最高效的方法来判断是否所有
的节点健康运行。我们没有一个固定的路线图  ‐  客户的反馈来自于各个方面  ‐  但是它的最
终目标还是成为服务器的烟雾探测器。 

RB：Andre，谢谢你百忙之中能够抽出时间来谈论 Scout。 

更多关于Scout监控服务器和应用程序的信息可以在Scout官网上找  到。使用代码为‘infoq’的
礼品卷，客户可以在第一个月获得 10 美元的折扣。Scout也有一个 30 天适用版本，所以 10
元折扣可以在 30 天使用之后  生效。 

关于Andre Lewis 

Andre Lewis 是 Scoutapp.com 的创始人之一，这是一个监控托管服务器和应用的公司。Andre

对于构建敏捷，有用的商业行为充满了热情，并且相当  有成果。他的工具是 Ruby ‐‐  他从
2006 年便开始使用 Ruby 和 Ruby on Rails 工作，而且写过一些 Ruby 的书籍，他现在维护着
一些开源项目。他的地址是加州的圣弗朗西斯科。 

原文链接：http://www.infoq.com/cn/articles/scout‐extensible‐monitoring 

相关内容： 

 云计算时代：LAMP何去何从？ 

 Activiti是否有能力应对BPM的挑战？

50 
 
  

推荐文章    Articles

基于上下文图的策略性领域驱动开发 
作者Alberto Brandolini  译者  韩锴 

简介 

当应用程序逐渐变得庞大和复杂后，很多面向对象建模的方法都达不到非常好的可伸缩性。
上下文图是一种通用目的的技术，作为领域驱动开发大家族的一名成员，它帮助架构师和开
发人员管理他们  在软件开发项目中不得不面对的形形色色的复杂性。与其他广为人知的
DDD模式相比，上下文图可以应用在任何软件开发的场景中，在开发者进行策略性决策时， 
为他们提供一个高层视图，比如是采用全套的DDD实现，还是根据项目的特定条件进行取舍
等。 
 
在这篇文章中，我们将探讨界限上下文，以及如何在构建上下文图时应用它们，来支持软件
开发项目中的关键决策。 

多个模型共存 

领域驱动开发花了很大力气强调一件事，即维护应用程序模型的概念完整性。要做到这一点，
需要很多因素： 

 一种敏捷的流程，确保能从用户和领域专家那里频繁地获得反馈， 

 确保有若干领域专家在场，并且与他们开展创造性的合作， 

 （在应用和测试代码中）维护单一的、可共享的模型，并用通用语言精确地进行定义它，
 

 营造一种开放透明的环境，鼓励学习与探索。 

这些对于营造一个可以让高质量的设计繁荣发展的环境至关重要。即使是这样的环境，那些
常见的 DDD 元素，比如实体、值对象、聚合，也会逐渐地形成一个复杂领域模型。所以，

51 
 
  

如果不对模型的概念完整性进行妥协的话，传统的 DDD 方法也不能盲目地应用在一个无限

大的领域模型中。 
 
如图 1 所示，在 DDD 中，通用语言的关键责任是对模型进行完整性检查。无论是与领域专
家的讨论，还是最终的实现代码，都可以通过使用相同的术语，并将领域知识清晰准确地进
行定义，以此来保证团队中的每位成员可以分享都相同的领域知识和软件。 

 
图 1.  通用语言应该是用于表达模型的唯一语言。团队中的每位成员应该对每个特定术语达
成一致。这些术语不能有歧义，也不允许在不同角色间进行翻译。 

代码是表达模型的主要形式。虽然其他一些工件或许也能捕获需求或者局部设计，但是只有
代码自身才会与应用程序的行为永远保持一致。不过这种看上去美妙的建模方式其实非常脆
弱：如果满足了前面提到的四条要求，它能做到，但是不能被无限地扩展。真正让模型得以
最大程度地扩展，并且不必牺牲其概念完整性的方法叫做“上下文”。 

了解“界限上下文” 

在领域驱动设计的世界里，“上下文”是这样定义的： 

52 
 
  

         “一个单词或一个句子所出现的环境，这个环境会反过来影响它们的含义。” 
这段定义初看起来相当含糊。它并没有直接告诉我们“上下文”的大小、形状或者其他什么特
性。但是最后我们又发现这个定义其实非常准确地描述了“上下文”是什么，如果要想窥得其
全貌的话，大概还需要一些具体的例子。 

示例 1：术语相同，含义不同 

第一个例子很简单，它示范了在术语层面出现歧义的情况。有些词汇根据不同的使用场景，
会有不同的含义。 

假设我们正在开发一个基于 Web 的个人金融管理程序（PFM）。该程序可能用于管理银行帐

户（Account）、股票、储蓄，未来可能用于追踪预算和开销记录等等。 

在这个程序中，领域术语“帐户”可能是指不同的概念。谈论银行的时候，一个“帐户”在逻辑
上其实是“金钱的容器”；于是我们自然而然地为相应的类加上“余额”、“帐户号”等属性。但
是，在“Web 应用程序”的上下文中，术语“帐户”会有非常不同的含义，它和用户的认证、可
信度有关。如图 2 所示，相应的模型将是完全不同的。 

 
图 2.  一个出现歧义的简单场景：当术语“帐户”应用在不同的上下文时，它的含义可以是完
全不同的。 

这应该是我们在对应用程序建模的时候，所遇到的最简单的歧义场景了：一个术语，有两个
与上下文相关的含义。这个问题的解决办法通常是在类的全名（类名或者包名）前面加一些
前缀，以此来划分名字空间。但是在概念层面上，必须清楚我们在和两个上下文打交道，有
时不同上下文之间的区别很大，足以防止开发人  员犯错误，但有时这样的区别却非常微妙。 

53 
 
  

不过，在类名层面上解决问题的方式并不能用在所有的情况下：在银行的领域里，术语“银
行帐户”或许已经存在了，但却有不同的含义；或者领域专家坚持  使用“帐户”作为术语。此
时切记不要发明一个特殊的两头这种的术语，或者在专家术语和代码之间引入一个“翻译
层”。否则你将不得不面对两个独立的上下文。 

绘制第一份上下文图 

当歧义真的到来的时候，我们需要一种工具来让开发团队明白，应用程序中正存在着两个不
同的上下文。“歧义”是通用语言的头号大敌，我们必须铲除它。  消除歧义的最好办法就是
在上下文图中，将领域结构分拆在多个界限上下文中。 

 
图 3.  包含两个领域上下文的上下文图 

按照领域驱动设计一书的  描述，上下文图是用于将上下文边界变得更清晰的重要工具。其
基本的想法是在白板上画出上下文的边界，然后选择性地将相关类的领域术语填写在上面。
它不是一幅绘制精美的UML图：它是一个可用的工具，允许我们描绘那种模糊不清的状况，
因此它自身看上去模糊不清也就不足为其了。 

示例 2：概念相同，用法不同 

还有一种更加令人困惑的情况，就是底层的概念相同，但是使用的方式不同，最终导致了不

54 
 
  

同的模型。银行帐户的模型是一个 BankingAccount  类，如图 4 所示。 

 
图 4.  精简版本的 BankingAccount 类 

通常，有些 PFM 应用也允许我们管理支付行为，并且持有一个收款人（Payee）注册器。在

这个场景中，收款人可能与一个或者多个银行帐户关联，但是对于收款人来说，我们既不能
获取其银行帐户的内部情况，也不能在该帐户上触发任何操作。那么将“收款人帐户”与刚刚
定义的 BookingAccount 类关联在一起是否正确呢？ 

 
图 5. Payee 类与 BankingAccount 类 

恩......这听上去有些道理：毕竟它们都是相同的概念，在现实世界中，我们的帐户和收款人
的帐户甚至会处在同一个物理上的银行里。另一方面，这  样做似乎又不完全正确：因为我
们不允许调用收款人银行帐户的任何操作，也不能追踪他们的任何信息。更糟的是，这样做
了后，可能会在我们的程序中埋下一个概念的错误。 

55 
 
  

我们应该如何做？我们应该再一次回到应用程序的两个不同的上下文里去：这一次我们可以
采取两种不同的方式对同一个领域概念进行建模，因为对领域概念的两种使用场景明显不
同，每一种都需要一个不同的模型。BankingAccount 类仍然允许我们执行（或者跟踪）特定
的操作（比如存款与取款），同时  另一个独立的 PayeeAccount 类可能有一些和
BankingAccount 相同的通用数据（比如 accountNumber），但是有一个简化的模型和完全不
同的行为（比如我们不能访问收款人的余额信息）。图 6 所示的正是这种场景：尽管“银行帐
户”有着清晰的含义，其底层概念也是惟一的，但是在应  用程序中却以不同的方式被使用着。 

 
图 6. BankingAccount 和 PayeeAccount 类 

这看着似乎挺明显的，其实不然。当你设计类图，或者使用UML建模工具时，你可能很自然
地让收款人具有一个bankingAccount属性，而且会庆幸“我刚好有一个这样的类”。Pavlovian试
图去除代码中的重复，有时，它的作用会弊大于利。 

如图 7 所示的上下文图，可以用于表述上面讨论的示例。注意，只要我们关于环境的知识在
增加，就将它反映在图中。在这个例子中，我们将 PFM 的应用上下文分成了“银行”和“开销

56 
 
  

跟踪”。 

 
图 7.  非常简单的上下文图：画上了领域模型区域间的轮廓，可以看出在这些区域内保证了
概念的完整性 

在这个例子中，两个上下文拥有一些逻辑上重叠的区域，即“银行帐户”的概念，它在应用程
序的不用区域中，使用方式也不同，这意味着我们要使用不同的  模型。但是两个模型又可
能有非常紧密的交互。上下文图除了能帮助我们保证模型的概念在不同上下文边界内的完整
性，它还能帮助我们关注在不同上下文之间出现的情况。在这个例子中，假设同一个团队正
在两个上下文上同时工作，我们就需要让团队中的每位成员的明确两个上下文的区别，并且
就两个上下文中出现的术语和概念，分享同一个转换的映射关系。 

示例 3：外部系统 

再来考虑一下 PFM。很多这种应用程序都需要与某些金融在线服务进行数据交换。在这个
例子中，银行会为家庭银行服务提供实时的访问。其他的例子还包括允许用户下载通用标准
格式（比如 Money 或者 Quicken 格式）的银行对帐单。但是从上下文图的视角来看，无论
是交互活动还是通讯的方向（单向或是  双向），并不重要。有一件事是要关注的，我们有了
不同的模型。图 8 展示了 PFM 与在线银行应用程序的交互行为。 

57 
 
  

 
图 8.  在上下文图中，与外部应用的交互行为很自然地需要独立的界限上下文 

即使设计两个模型之初是让它们展现相同的数据（至少在一定程度上），但随着时间的推移，
它们还是会受到不同因素的影响，而且它们也会用于不同的目的。因此，分离上下文边界是
必须的。如果假设用户档案（User profiling）模块是由第三方库实现的，那么示例 1 也能够
归入到这一类中。 

管理多个上下文 

当应用程序跨越了多个上下文后，我们必须管理上下文之间的关联。不同的界限上下文之间
的关系，通常是我们深入观察项目的线索。 

有一件事情非常关键，即两个上下文之间的联系是有方向的。DDD 用两个专门的术语表述
它们：“上游（upstream）”和“下游  （downstream）”，一个上游上下文会影响到相应的下
游上下文，但是反过来就不一定了。这不仅体现在代码上（一个库依赖于另一个），还体现
在技术含义较少的因素上，比如进度、对外部请求的响应，比如，当在线银行服务更改了
API 或者其他什么原因，我们的 PFM 银行应用程序都必须要快速地更新。所以我们的 PFM

58 
 
  

上下文应该是下游的，而在线银行服务很明显就是上游的了。图 9 演示了这两种领域上下文
的关系。 

 
图 9.  分离的上下文之间的 Upstream‐downstream 关系 

如果外部系统发生变化，我们可以接受这种变化，来更新与外部系统通讯的方式。不过我们
仍然需要一些保护措施隔离来自上游上下文的变化，保证我们自己的“银行”的上下文的概念
完整性。DDD包含了几种组织模式，帮助我们描述和管理不同的上下文交互方式。最适合我
们在这里使用的是模式叫做反腐化层（Anti‐Corruption Layer，ACL），它会在代码层面上实
现显式的转换，转换可以在两个上下文之间，或者在“银行”上下文的外部边界上完成。这不
仅局限于技术上的转换，比如Java转化为XML，同时也是一个很合适的机会，能够管理各个
模型之间的所有微妙的不同。如下面的图 10 所示，我们在上下文图上添加了  ACL。 

59 
 
  

 
图 10. PFM 程序边界上的反腐化层，防止在线银行服务的变化影响到我们的边界上下文 

很明显，一个外部系统需要一个独立的上下文。然而对于一个已有的遗留组件，通常也伴有
一个非常难以修改的模型。尽管遗留组件是在我们组织内部来维护的，甚至这个模型也会受
到不同因素的影响，它会被其他的上下文所使用。如果必须和遗留系统进行交付，不同模型
之间的转换应该放在一个不同的界限上下文里。 

上下文图中还有其他的关系吗？我们能够根据相关的 DDD 模式对它们进行分类吗？如果假

设开发活动是在单一的团队内进行的，那这里的模式就不会引起太多的关注。但是，如果“银
行”和“开销”是由不同的团队来维护的话，团队之间应该是一种合作关系：他们的开发会朝
向一个共同的目标（这里谈论上游和下游没有意义，因为他们处于同一级别）
。如果 Web 用
户档案模块来自于外部，我们将会作为下游的上下文。 

60 
 
  

 
图 11.  加入了关系模式后的上下文图 

示例 4：向组织扩展 

到目前为止，我们只考虑了包含一个开发团队的简单场景。在这种场景下，我们可以忽略沟
通的开销，假设团队中的每位开发者都很明确“模型将会如何发展”（也许有些乐观）。更复
杂的场景中还可能包含下面的影响因素： 

 领域复杂度（需要很多不同的领域专家） 

 组织复杂度 

 项目跨时很长 

 项目需要大量的人天 

61 
 
  

 涉及到很多外部的、独立的或者遗留的系统 

 大型团队，多个开发组 

 分布的、离岸的团队 

 个人因素 

每个因素都会影响开发团队和组织的通讯方式，并最终影响到要交付的软件。 
 
每个独立的团队，尤其是一个处在敏捷环境的团队，团队内的成员间有很多共享信息的方式：
面对面的交谈，多人参与的设计讨论、结对编程、会议、信息散播装置 （information radiator）
等等。但问题在于，当团队规模、人数增加后，这些技术很难再继续使用了，跨团队地共享
模型的概念完整性也非常困难。 
 
毕竟，能够对模型保持统一看法，是沟通中相当成熟的方式，这涉及到对问题具有一致的理
解，以及对可行解决方案大致相似的看法。在那些沟通不顺畅的场景下，  “埋头干”很容易
取代了“识别和确认”。这种沟通瓶颈带来的典型后果就是在同一个代码库中的不同地方散布
着不同的类，它们做着基本上同样的事情。 
 
总有一天 PFM 应用会变得更大，这样就要有另一个团队（团队 B）和我们一起工作（显然
我们是团队 A），他们开发一个名为“交易”的新模块。团队 B 可能在一  个不同的房间、建筑
物、城市、公司里，他们全心投入到新模块的开发工作上。如下图所示，团队 A 与团队 B
共享了一些代码，虽然他们很可能会使用彼此独立的代  码。最后，团队 B 会写一些类（比
如图 12 所示的 A'）来实现自己所需的功能，不过这些功能已经存在于类 A 了。 

62 
 
  

 
图 12.  当不同的团队访问相同的代码库时，他们会去关心模型上的不同部分。物理上的团队
分割会令信息共享的效果大打折扣 

这是重复代码，万恶之源啊！在一个独立的、良好定义的、有界的上下文内，这是毋庸置疑
的。但是由于某些原因，这种现象几乎会出现在所有复杂的项目中。这通常是个信号，告诉
我们在项目的同一个区域内，或许存在没有恰当隔离的上下文。不过在有些时候，使用两个
独立的上下文是组织领域模型更加有效的手段，而不会强迫两个不同的团队不断地去整合他
们的模型。 

那么，我们如何在图上画出这些呢？上下文图反映了当前我们对整个系统的理解水平。一旦
我们学到了更多东西，或者环境发生了改变，还会马上更新它。现在，我们还不能准确地预
知接下来会发生什么，所以这就是“我们当前的理解水平”。 

63 
 
  

 
图 13.  尚未很好划分的“交易”上下文，它还需要进一步探索或更切合实际的设计决策 

图中的危险警告符告诉我们那里有些问题：两个上下文有局部的重叠，它们的关系还不是非
常清晰。这可能是需要解决的第一类问题，可以尝试着在上下文内设置一个被广泛认可的、
合理的关系，比如消费者‐供应者、持续集成或者共享内核（Shared Kernel）。不过，这是明
天的工作。上下文图是为今天准备的工具，而问题在今天还存在着，所以我们还把警告符号
留在图中。 

不要被图中的颜色和阴影搞迷惑了。我不过是想让上下文图的打印效果更好一些。一个真实
的上下文应该是很乱的，起码和你的项目一样乱。不过这个警告符  提醒我们这里有一个危
险区域，此处的上下文尚未被清晰地分离，事态很容易朝着“一团大泥球”发展（最有弹性的
DDD组织模式），除非我们采取行动。 

64 
 
  

一种非传统观点的视角 

上下文图迫使我们将非软件的因素也包含在整体考虑中，这样我们更能识别出一些污点热
区，而这些热区在传统架构分析的观点中是“不在范围内”的。 

比如，组织内部的信息流通方式会在很大程度上影响最终的软件。通常，在小型组织中，组
件自身的用途是定义上下文边界的主要因素，而在大型组织中，这个关键因素变成了沟通效
率和项目组织方式。像 Wiki、email 或即时消息软件会给我们一种假象——团队中每位成员
的知识都不断地保持着同步。但是我们都知道这只是个梦想罢了：在一个典型的大型项目中，
我们不是 Borg 人（译注：源自《星际旅行》中的外星生物，所有 Borg 人的思想是互联的，
可以完全共享知识）那样的智能联合体，很多人对于自己团队以外的情况知之甚少。 

在大型组织中定义上下文边界是一项颇具挑战的任务，但回报却也相当丰厚。很多时候，各
个团队并不清楚多个模型存在的事实；之所以概念的完整性会频遭破坏，是因为只有很少人
或者没有人看到完整的图景。绘制上下文图是一个不断探索的过程，很多部分的内容在首次
尝试时都是不正确的，边界在初期也是很模糊的，还需要很长的路要走，才能获得一个更清
晰的完整图景。 

 
图 14.  上下文图的最新版本。不要指望它是“最终”的，我们总是会学到一些新的东西。 

65 
 
  

涉及到的上下文还可能更多，比如“交易”模块可能需要链接到一些在线股票价格服务，但这
是交易模块的事！这个上下文图是关于我们（团队 A）的，我们的工作内容是“银行”和“开
销跟踪”模块：我们只对直接关联的、会影响到自身软件的那些上下文感兴趣。 

一旦我们收集到更多的信息，上下文图就会变得更加清晰。正如前面提到的，只要认识到应
用程序中存在着各种不同的模型，而且这些模型的完整性可以在一  个良好定义的有界上下
文中得以保存，这会为我们的领域建模的视角提供诸多益处。很多模型都在成长的过程中逐
渐失去完整性，上下文图会在这个方面给予我们很多帮助。 

谈谈策略性DDD模式 

此处我们使用模式的方式略有不同：尽管定义是一样的——为一类反复出现的问题提供解决
方案——但这些模式很少能展现出可供我们选择的解决方案。更可能的场景是，组织架构会
决定模式，我们惟一的希望就是在事态走到死胡同以前识别出它们。有些时候我们有机会选
择最好的选项，或者改变现有的状况，但是我们必须清楚的是，在组织级别的改变所需的时
间可能已经远远超过了项目持续的时间，或者这个改变根本就是不可能的。 

如果你还在犹豫应该从那里开始，那么就从开发团队开始吧。对于有效地共享模型信息来说，
一个团队应该是最大的组织单元。当识别出多个上下文后，可以由一个团队管理它们，这样
很大程度上将问题归结为架构的抉择。 

每一种模式都有不同的开销：即使它们解决的是类似的问题（相近的上下文），也不能简单
地交换。比如，反腐化层会在代码层面（一个额外层）上留下痕迹，并在组织里留下很小的
痕迹。尽管 Partnership 或者“客户‐供应者”模式可能需要更少的代码和一个单独的代码库，
但是如果没有有效的沟通渠道和良好的过程的话，也很难应用起来。企图在没有合作的环境
下安排执行 Partnership 模式，无异于自寻死路。 

结论 

让我们在回到“上下文”最初的定义上来——“一个单词或一个句子所出现的环境，这个环境会
反过来影响它们的含义”——它非常准确，而且可以应用在设计层面、架构层面乃至组织层
面上，却没有损失其准确性和有效性。尽管有些“对统一性的期望”是合情合理的，但是模型
不能被无限地扩张。界限上下文提供了一  种非常安全的机制，它允许模型在其内部不断变
得复杂，同时又不牺牲概念的完整性。 

当把上下文图应用到大型的项目上后，它还可以显示出当前组织内的隐式边界，并提供一个

66 
 
  

来自第一手的、没有 PS 过的项目境况的快照。一个好的上下文图能让你看到所面对的不利
条件的大致状况。可能你已经知道——但通常都是不知道——组织是否在扮演项目成功的绊
脚石，即使项目还没有开始。 

作为一名顾问，我发现上下文图能够奇迹般地让我快速获取客户项目的细节。上下文图还充
当了策略决策的支持工具（毕竟，这是“图”的本意）
。上下文图提供了系统的全局视图，帮
助我们关注在选择那些能在你的环境中真正可行的方案，而不是把钱浪费在对系统不切实际
的构想中，这是 UML 或者架构图所做不到的。 

关于作者 

Alberto 是来自 Avanscoperta 的一名咨询顾问和培训师。他致力于帮助客户管理软件开发的

复杂度。他坚信只有那种全盘考虑的软件开发方法才能开发出有用的软件。 

原文链接：http://www.infoq.com/cn/articles/ddd‐contextmapping 

相关内容： 

 凡客诚品架构总监栾义来的年度展望 

 SOA与DDD 

 SOA与DDD存在共生现象吗？ 

 在模型驱动工程中结合通用语言和领域特定语言 

 对象关系映射——用户案例研究 

67 
 
  

推荐文章    Articles

mySOA：敏捷的、治理的并且可持续的 
作者 William El Kaim  译者 马国耀 

SOA 是在各种报道中频繁提及的一个话题。在阅读了很多书、文章、软件提供商们的各种白
皮书以及博客文章之后，我仍然在探索如何才能使之成为现实。  本文的主要目的是邀您一
起参与我们的 SOA 之旅，不过它针对我们的一些限制使用我们自己的“语言”进行描述的。 

我们称之为 mySOA 方法。 

 SOA 显然指得是我们要构建灵活的，  治理的并可持续的跨企业的业务和技术的服务，

甚至可扩展至更广阔范围（云或 B2B 等）。 

 “我的”是因为 Web 2.0 的变革使得服务越来越多地用于社会交互，而不仅仅是点到点的

交互。“我的”还意味着它专注于我们的需求且与我们公司的业务对齐。 

我们并不求为该领域提供一个尖端的解决方案，甚至不求提供统一的方法论（我们使用的术
语是内部团队合作的结果）。但我们希望它将提供一个基础，能帮助你在此之上构建你的 SOA
方法，或者能鼓励你在该主题上扩展知识。 

最后，为了描述得尽可能具体些，文中将提到我们所使用的工具提供商或者工具平台。我们
诚挚地建议你购买任何技术解决方案之前要在你所面对的特定的上下文环境中做概念验证。
因为，没有放之四海皆准的法则，特别是 mySOA。 

mySOA：敏捷的，治理的，可持续的 

mySOA 方法基于三大主干：敏捷，治理以及可持续性 

mySOA 方法应该是敏捷的 

敏捷意味着我们将不再总是遵循那些文字所提到的“你必须”和“你应该”的法则（如，你必须
要有业务战略，你必须要有管理层的支持，你必须采用自顶向下的方法，你应该预先做好宏
大的规划）。 

68 
 
  

我们将通过迭代的方法，通过小团队管理特定服务集合的方方面面。目标是创建我们所谓的
“服务刀片”，它们可以被插入或重用在不同的业务及技术的环境中的。 

敏捷 

 因为在快节奏而且扁平互联的世界中，企业要生存，必须要敏捷。 

 因为我们的开发团队使用 SCRUM，因此转向敏捷非常自然。 

 也很必要，因为金融危机使得我们无法得到一大笔预算来开展若干年的完全丰满的 SOA
项目。 

mySOA 方法要求治理开始于 SOA 的第一天 

我们不仅把治理作为支撑业务和 IT 的新动力，还将它作为加强合作和对齐的方法。信任是
最大的挑战，而且总是这样，因为（出于整体利益的考虑）一些团队要将他们原有的决策权
交出去并且要接受一些新规则。敏捷还包含另外一层含义，即对例外管理应该作为治理流程
的本身的一部分。 

mySOA 方法应该是可持续的 

SOA 要允许对功能和技术竖井进行逐步且可持续性的改造，这样才能设计出可被各种业务流
程重用并且灵活的服务。而往往在一段时间内我们致力于寻找充分的资产为业务提供价值而
不是重用。如果我们不得不开发一个 portlet 来为某个特定客户提供业务服务（如 CO2 计算
器），那么我们一定会这么做，它可能被重用也可能不会，但这是最后才考虑的事情。 

可持续性还意味着，即便某些人（参与 SOA 之旅的人）会因为 SOA 的成熟以及新业务模型

或组织的产生而必须变换角色，还是要保证他们参与进来。往往，SOA 项目的结局是成本的
降低，外包（投资海外可能更为贴切）以及帮助构建 SOA 的团队的解散。mySOA 立足于人，
在公司内且把公司的每个人看作功臣并提升其价值。mySOA 的重心是为企业带来附加值。 

mySOA——选择你的通往成熟之路 

SOA 支持建立敏捷的企业，但是通往 mySOA 天堂的路却取决于你自己。对于任何 SOA 项目

或新方案，都要独立定位并让所有股东都能理解其开销、风险以及可能的收益级别，这点非
常重要。图 1 是一个来自可持续的 IT 社区的某个 SOA 项目的分类模型，它的优势是能够在
整改的、大检修的或扩展的 SOA 环境中为你的项目进行清晰地定位。 

1.   整改的 SOA. 

 不侵入现有资产：需要现有系统的辅助暴露服务； 

69 
 
  

 它不同于对现有系统的重写； 

 此类 SOA 依赖于现有系统的质量； 

 此类 SOA 可能在有限的情况下快速见效。 

2.   大检修的 SOA 

 利用服务重构现有的应用系统； 

 可以充分利用 IT 基础设施； 

 业务规则和业务逻辑依然封装在应用程序的代码之中。 

3.   扩展的 SOA 

 使用能提升系统灵活性的解决方案：业务规则管理系统、主数据管理及业务流程管理等。 

 
图  1：通往成熟 SOA 之路（来自可持续 IT） 

扩展的 SOA 是最“昂贵”（从时间、资源和投资上看）的，但是它能带来的实质性结果也最多。

扩展的 SOA 才是目标。为了遵循通往该目标的敏捷的方式，  最佳的路径是通过某些过渡性
的阶段，在这些过渡阶段中把主数据、业务规则和语义映射等从将要被访问的 Web 服务的
应用程序中清晰地分离出来，并在此基础之上建立服务。 

mySOA依赖于卓越中心 

我们做的第一件事是创建一个整合卓越中心（  ICC，Integration Competency Center）。该中心

70 
 
  

的命名故意没有使用“SOA”，因为“整合”是业务更容易理解也更喜欢看到的。这并不代表将
来不会有所改变（还是可持续性，我们的工作始终建立在过去的基础之上，而且是以敏捷的
方式！）。 

ICC 是一个分布式的组织，它主要由两个团体构成，如图 2 所示。解决方案中心（Solution 

Center）的任务是确保对所有项目的不变的可持续的执行，专家中心（Center of Expertise）
则为项目提供随需应变的敏捷的分布式的支持（或征求咨询公司）。 

 
图  2：ICC 的两个组成部分 

ICC 图表是我们创建的第一份文档，它定义了以下行动范围： 

业务层 

 业务整合及创新：在各业务单元间普及并宣传业务整合能力的价值。 

 业务域治理：通过定义服务提供方的 SLA 以及关键功能需求来支持业务（列出要提供的

业务服务清单，这些服务独立于技术）。 

IT 层 

 技术治理：创建技术标准并定义验证这些标准的规则，特别是围绕服务设计及接口设计
的标准。ICC 开发了一个技术标准最小集合作为必须要遵循的关键架构准则，如 XML 模
式标准、WSDL 模式标准、服务级定义模板标准等。ICC 还专门开放了一个内部网站和
wiki，用于讨论并进行答疑。 

 服务开发周期治理：ICC 并不负责服务的开发，因此它应与敏捷的验证点联合才能确保
所有的工作都是依照治理规则完成的（必要时还要改进治理流程，  治理流程本身也是
敏捷的）。 

 服务交付和运行时治理：全局地交付服务，负责安全，SLA，并在需要时创建适配的虚

71 
 
  

拟“服务”（或端点）
。ICC 管理所有服务的技术接口。 

解决方案中心由一个分布式敏捷的团队组成，该团队的成员都是全职员工，而将其部分工作
时间花在SOA之上。这样就可以避免“巴別塔”综合征，并能使这些成员忙活于如何让实际的
项目更加成熟，而不仅仅是管理和作报告。必要时该团队还可以雇佣合同工。 

图  3  对 ICC 所提供的服务进行了归纳。 

 
图  3：ICC 组织提供的服务 

寻找“我的”服务 

一直以来的一个关键问题是如何找到服务?如何找到合适的服务粒度？答案依然是很难。我
们遵循 3 种不同的方法： 

 自顶向下——业务服务诱导法 

 敏捷——遵循敏捷开发流程 

 自底向上——  改建式开发（Brownfield Development） 

业务服务诱导法（自顶向下） 

详细讨论如何发现业务服务已经超出了本文的范围。不过我们建议你阅读  《可持续IT架构》
[1]一  书或者在这里免费得到发布在知识共  享平台（creative commons）的文档及培训资料。 

72 
 
  

你可以遵循一些非常通用的步骤： 

 定义产品服务及他们的依赖：特定于有限业务域的业务价值链是什么（用敏捷的方式去
做）； 

 定义业务对象，它们的生命周期及关系； 

 定义主数据； 

 创建用于对业务对象或业务交互周期进行映射的业务服务; 

 尽早定义或预见服务的可变性。 

 敏捷——遵循敏捷的开发方法 

另一种方法是利用敏捷的开发流程，通过使用“向前版本控制策略”。与整合团队合作，设定
优先级，开发并进行测试。 

当然在多个迭代中都建立服务接口可能会产生一些问题，因为服务是不断发展的，而且服务
用户是不喜欢服务接口如此不断地变化，然而为了快速地实现能够满足需求的服务，这是不
得已而付出的代价。 

每个团队都要理解一点，如果要避免在未来进行全盘设计（这种全盘设计并非一定能奏效），
他们就应遵循一些规则。此外，还可以通过制定一些技术标准并经常进行检测来避免全盘设
计的发生。沟通依然是关键所在。 

这里不存在灵丹妙药，但是敏捷的确是为“恰当的”业务需求在“恰当的”时间寻找“恰当的”服
务的一种令人惊讶的方法（适时比正确更为重要）。 

改建式开发 

改建式开发是IT工业中常用的一个词语，它通常用于描述需要在现有（或遗留的）应用或系
统之间开发新软件系统的问题域。这意味这任何新的软件架构必  须要考虑到与现有的正在
运行的系统之间的共存性问题。若要了解更多信息，我们推荐阅读《吞下IT大象》 [2]。 

在这种情况下，我们建议： 

 对数据进行挖掘。全面了解你的系统所包含的数据并尽力挖掘其最大价值。 

 控制其生命周期。这是一个前提条件，比如，我们使用Convertigo对遗留的后台办公数
据进行访问，这样就不会破坏现有的流程，业务规则以及安全限制。 

73 
 
  

 保证其质量。这点不能忽视，而忽视它往往是最常见的失误。 

 定义一个权威的数据版本。定义谁是它的管理者，谁使用它的拷贝进行工作。你可以使
用 MDM 工具或构建一个联邦 MDM（通常需要在其之上部署一些中间件来管理数据的
同步及分发） 

 数据要面向服务，这是数据部分的最新型的工作。这项工作并不简单，因为它将带来
DBMS 端优化的工作负担和复杂性。 

Informatica将计划推出其新平台V9，它将为数据管理，数据集成和数据服务提供统一的方法。
为了在构建平台时更好地理解客户的问题，他们  与来自不同客户企业的架构师们（包括我）
进行了热烈的讨论。我推荐你阅读该对话中提到的一些经验及心得。开源数据集成提供商也
纷纷涌向这块肥肉，其中包括Talend和Xaware等。 

一些最佳实践 

阅读服务标识方面的文献，如 Accenture SIF， BPM携手SOAHandshake，InfoQ关于SOA标识方
面的文章，这本关于写作方面的文档，最后当然还少不了Thomas Erl百科. 

以下是一组非常有用的最佳实践。 

 避免通用服务，服务必须要有特定的价值。 

 服务效用依赖于服务的多变性以及多版本。 

 服务提供信息的某种特别的视图。 

 服务总是要遵循某个生命周期，而且服务应当被管理起来。 

我的SOA——敏捷治理的必要性 

由于要管理的服务数量可能快速增长，所以我们决定关注那些最“重要的”服务（这也是我们
团队的决定）。重要性的依据是业务需求（如客户的要求，新产品功能等）以及技术需求（如
安全支持，REST 支持，内容交付网络等）确定的。 

所以，我们创建了一个治理进阶来实现服务重要性与服务治理力度的对齐： 

1.   完全治理的：由 ICC 管理的服务——该类服务在全局范围内使用，并且对于遵循 ICC 治理

规则的业务是至关重要的。 

74 
 
  

2.   已知的且委托治理的：本地管理的服务——该类服务由本地资助开发并且遵循本地的治
理规则。 

3.   已知的，无治理（使用时风险自担）：未管理的服务——任何不遵循适当的治理规则或未
被监控的服务。 

4.   所有的：监控的——跟踪 SLA，条件允许时会生成报告。 

5.   快照模式：遵循治理——已经量化技术需求以及 SLA 需求并且能随时进行验证。 

不论如何，服务都应该在统一的存储库中声明并进行分类。 

服务提供者是服务的所有者，它可以是企业的内部提供者也可以是外部提供者。不论选择的
是那种服务治理级别，服务提供者都应该遵循以下基础规则集。服务提供者要： 

 对服务开发生命周期的方方面面负责。 

 熟知 ICC 定义的标准； 

 确保服务设计遵循 ICC 标准； 

 确保服务实现遵循 SLA； 

 保证 2，3 级支持可用； 

 确保在生产环境中同时运行的服务的版本不超过 2 个。 

ICC 负责管理服务并进行敏捷的垃圾回收。它检查服务是否依然有用，是否依然在使用中。
这对于避免产生无止境的服务目录非常关键。 

服务分类 

在我们的 SOA 视野中，所有内部业务部门都应该对交付服务作出贡献。架构蓝图可用于新

系统的设计和旧系统的重构。 

 对于业务决策者，理解组件的业务价值及其商品化级别有助于作出创建、购买、或租借
（服务）的决定，甚至还可能因为提供服务而发现业务机  会。 

 对于架构师而言，对不同分类的深入理解不仅有助于对现有服务以及新服务进行分类，
还有助于将恰当的功能定义在特定的服务之中，从而让服务  更有利于组合或重用。 

ICC 使用特定的分类方式对所有服务进行分类，如图 4 所示，服务调用的方向的描述如下： 

75 
 
  

 服务调用总是从上往下，而不是从下往上。 

 在中间层不是必须的情况下，服务调用可能跨过中间层 

 
图  4: ICC 的高层服务分类 

技术或基础域服务 

技术或基础服务包含一些通用的功能，它们不增加明显的商业价值，但却是 SOA 中任何业

务流程的实现所不可或缺的部分。它们通常是通过购买而来的或定制开发的，并且集中进行
管理。 

我们来看一个例子： 

 交互服务负责系统中消息的传入及传出，而不需要关心消息的内容。 

 工具服务提供了通用的，与应用无关的服务，他们处理传输消息之外的其他方面。 

 安全服务提供所需的安全相关的能力，如身份、隐私、机密及不可抵赖性等。 

业务域服务 

核心业务流程服务与以数据为中心和以活动为中心的基础元件绑定在一起，从而实现组织的
业务流程。他们通常是有状态的服务（管理服务流程状态）。流程  服务的一个例子是订单处
理服务。一个业务服务可能永远不会消费核心业务流程服务，而核心业务流程服务则会消费
业务服务。 

业务服务实现企业的业务级能力。它们通常是有状态的并且代表以活动为中心的基础元件
（或“原子动词”），企业的业务流程由它们构成。 

76 
 
  

业务实体服务将业务实体与它们在系统中的不同的生命周期中的状态分离开。他们通常是无
状态的服务。业务实体可以被看成是业务流程中以数据为中心的组  件（名词），如员工、客
户、销售订单等等。业务实体服务提供了对这些数据对象的操作，如下所示： 

 CRUD 操作：创建、查询、更新以及删除； 

 搜索功能； 

 基于业务实体的生命周期的可持续性操作。 

应用域服务 

应用域流程实现了特定的业务级能力或这某些以活动为中心的业务逻辑元素，它们是特定业
务应用语境所特有的。 

 有状态或无状态服务； 

 非 ICC 管理的服务。 

服务的生命周期 

我们的服务生命周期尽可能简单化。它包括图 5 中所示的几个基本步骤。 

1.  定义：判定是否需要某个服务，收集功能需求和服务级别需求。ICC 可以参与并支持此步

骤。 

2.  开发：开发核心业务逻辑和文档（敏捷迭代的方式）或（根据需要）租用服务的访问。
无论选择哪种方式，都要把所需的资产注入到注册库中。 

3.  验证：ICC 负责控制设计时的治理。该工作的重要性取决于服务所关联的治理级别。在该

阶段，必要时应回退到定义阶段  。 

4.  部署：ICC 建立运行时治理（SLA 控制、计费控制和业务活动监控） 

5.  退役：从生产环境以及 SOA 注册库中移除服务 

77 
 
  

图   5: mySOA 治理过程 

如果你喜欢参照完善的服务声明周期流程，如图 6 中所示的RUP，这当然也没有问题。你还
可以使用某些特定的工具（如软件服务的UML概要以及RSA SOA插件）并寻求咨询的支持。
可以敏捷也可以不敏捷，这仍然取决于你。 

 
图  6：改造 SOA 的 RUP 过程 

业务服务接口 

一个业务服务的接口： 

 是将所有必须的服务组合起来去支撑业务流程或扩增的功能或技术特性，并带来的关键
价值 

 是独立于其他服务的接口创建并配置的（如，尽可能让不同的接口之间无依赖关系） 

 是自包含的并且向客户端隐藏了其在技术平台上的具体的“投射”细节 

 其使用应该能被跟踪且可收费 

 其创建者可能是所有的业务单元、组织或第三方提供者（按需要提供） 

 由 ICC 管理或不由 ICC 管理 

 完全支持版本化 

业务服务接口的创建用于服务需求方以及服务提供方之间的粒度适配，如图 7 中所描述的。

78 
 
  

它是使现有业务服务和应用服务与业务流程中所需要的服务进行对齐的方法之一。 

 
图   7: ICC 高层服务分类 

mySOA，我们如何做到？ 

为简单起见，本文直线式地描述了 mySOA 以及我们要做的工作的方方面面。当然，在实际

的工作中，我们经历了成功也品尝过失败，也根据业务及 IT 的  成熟程度修改过我们的方法
并且希望把事情做好。然而即将开始的旅程引入了一些关键驱动力而进行了简化。 

mySOA的平台需求 

为了构建我们的企业服务平台，我们观察过一些最好的工具看看我们能否让他们无缝地整合
起来。我们的主要需求是： 

 企业服务平台应该是迭代地构建的，并且要基于热门组件。业务对该项投入非常清晰，
我们的任务并非构建一个 SOA 的平台! 

 一个独特的可管理的、可扩展的容错平台； 

 尽可能利用现有基础设施及许可证； 

 在必要时帮助遗留系统的离退； 

 能够为所有的服务分类及整合流所用； 

 提供端到端的治理； 

 提供业务和技术监控（设计时及运行时）； 

 降低维护和运行成本。 

79 
 
  

mySOA参考平台 

由企业服务平台提供的主要服务如下所列（见图 8）： 

 企业消息服务。提供安全的、受管的、可靠的消息服务（比如，在这里你可以查到一组
开源的Java JMS服务器，或从Amazon SQS使用云中的EMS，或 Microsoft的.NET服务）。 

 主数据管理服务。如前文所述，你可以找到记录的流程，最佳实践和商业的/开源的工
具。 

 语义数据整合服务。目的是创建并管理企业信息模型（在具有不同结构和语义的应用系
统及服务间进行仲裁），进而可以创建并集中管理用于校验以及仲裁数据的规则及操作。
语义数据整合可以自动化执行并管理，这些操作是保证数据质量的核心，如转换、聚集、
验证、业务规则执行。若要了解更多语义层的内容，请看《可持续的IT架构》文档。 

 数据分发服务。分发并确保数据按质按量地发送到需求端，提供安全的服务，定义标准
数据格式并在需要时进行映射，收集并报告 KPI 信息  （如，Tibco BusinessWorks 和信息
平台） 

 整合与编排服务。实现 SOA 标准，业务或技术编排层，收集并报告 KPI 信息（如 BPMS

工具、基于 SCA 的工具、BPEL 工具以及面向工  作流的工具等） 

 企业服务管理（Enterprise Service Management，ESM）。提供监控、策略描述和执行。它
控制SOA的动态交互并为其提供方向。市场上已有为数不多的昂贵的商业软件 
（Amberpoint, Progress, SOA Software）及一款开源工具（Microsoft Managed Service引 
擎）。 

 企业服务监控。服务监控通常由ESMP提供。然而现在有些工具能够以比ESMP更低廉的
价格提供此项功能（如 JaxView），或者是免费的引擎（如开源工具Microsoft受管的服务
），或者是即将与支持  Google Gadget的仪表盘一起发布的 WS02 注册库未来版 。 

 企业业务规则及事件服务。实现可持续是需要付出代价的。业务规则和事件的关联应该
与代码分开管理；业务规则应独立于企业业务实体被定义、  存储以及报告等；业务规
则应显式地进行定义，而且，规则定义的变更不应牵连到其他的规则；规则应与顺序无
关。 

 企业存储和/或注册服务。所有的生产及管理的资产应该在统一存储库存储并管理。一
个注册库还可用在运行时，用来发现服务的一些元数据从而  达到对服务的动态配置。 

80 
 
  

 安全及策略管理和执行服务。为 SOA 平台启用安全应该尽可能简单化。为了避免把安全

封装在服务调用之内，通常建议使用外部的安全策略与动态执行点  。所有的身份及访
问管理提供商都提供了这方面的能力。当然也有一些纯粹的供应商专门提供此项能力。 

 外部网关服务。它用于在网络边缘保护公司内部的服务，优化消息传输以及提高与服务
提供者的访问性能。最知名的提供商是layer 7或 IBM Websphere DataPower。 

 
图   8: mySOA  服务平台 

在表 1 中，我们为每个 mySOA 参考平台服务提供了以下信息：工具的成熟度评价，实施它

的知识系统的成熟度，是否开放服务，有无开源解决方案并且给出了我们所知的工具实例。 

第一步可以用代码或 XML 以及 XSD 完成，从很多企业范围的项目来看人们更倾向于选择后

则。而且，对于很多集成和应用开发场景（不仅仅在企业范围内），人们习惯于先商讨出
WSDL/XSD 的 Web 服务规范，然后再开始实际的实现服务功能的代码开发。然而，纯粹处理
XML 和 WSDL 很容易出错，WSDL 更是非常难对付，原因是原始 WSDL 规范支持非常复杂的
结构以及契约的定义。我们需要一些工具辅助我们一致且可靠地完成该级别的工作，而 
WSCF 就是为此而生的。 

 
 
 
 
  

81 
 
  

是否
有开
mySOA 平台服务  工具成熟度 知识体系  工具实例 
源   

  

IBM, Microsoft, 
企业消息服务  高  高  是  Mulesoft, Progress, Sun, 
Tibco 等 

IBM, Kalido, Orchestra 
主数据管理服务  中  高  是  Networks, SAP, Siperian, 
Sun, Talend 等 

服务配置主数据服务  低  低  是  需要自建 

Progress DataExtend SI, 
语义集成服务  中  低  是 
collibra, expressor 

Informatica, Tibco, 
数据分发服务  高  高  是  Pervasive DataCloud 2 , 
IBM 

Intallio, Tibco, 
集成与编排服务  中  低  是  ActiveBPEL, Oracle, 
Informatica 

通常需与存储库绑定，
设计时治理  低  中  是  同时我们使用企业服务
测试工具做质量测试。

Amberpoint SMS， 
Microsoft MSE，Progress 
企业服务管理  低  低  是 
Actional, SOA Software
等 

JaxView， Amberpoint 
企业服务监控  中  低  是 
SMS，CA wily, WSO2 等

Esker，Drools， Tibco业
企业业务规则和事件服务  低  低  是  务事件，IBM Ilog，
sci‐flex 

82 
 
  

Software AG Centrasite, 
WSO2, Mule Galaxy, 
企业注册与/或存储服务  低  低  是 
IBM WSRR, Adjoovo, 
Dragon SOA 

Amberpoint, Sun, IBM, 
安全及策略管理服务  中  中  是  CA, Oracle, Vordel, layer 
7, F5 

XML 设备（Vordel, layer 
外服网关服务  高  高  是  7, F5, IBM）或
Amberpoint 

SOASta， Parasoft 
SoaTest，Eviware 
企业服务测试  高  高  是  SoapUI，ITKO Lisa，
Actional Diagnostic与
SOA Cleaner. 

表  1：mySOA 参考平台服务分析 

实施mySOA参考平台的经验收获 

从演示走到在生产环境中运行正式的系统永远是一个挑战。这点非常正确，尤其在 SOA 的
产品市场尚未稳定而且标准如此繁杂、尚无最终定论和互操作标准的情况下。 

缺少互操作标准 

我们认为 SOA 采用和实现的最大阻力是缺乏合适的工具以及互操作性。现今，多数软件提

供商利用 SOA 来推动他们整个软件栈甚至有时还包括硬件的销售。 

在建模的一端，OMG的SOAML虽  然已经在主要的UML工具中的到实现，但尚未得到广泛接
受。Michael Poulin在这里说到，“SoaML不是面向服务的也不完全是架构建模语言，因为它
并不完全支持架构实体的建模，相反集中于它们之间的关系（它虽然很重要但并不  充分）”。
而后它被OASIS SOA参考模型标准与OASIS SOA参考架构标准‐草案所钟爱，他们定义了什么是
SOA，什么是服务以及服务如何适用于面向服务的环境。 

然而，我们的确认为SOAML可用于交互用途，这样就不需要整天与整个WS‐*标准纠缠在一
起了。另一个有趣的方法是使用语义来更好地定义服务及其  交互。目前，这方面的研究仍

83 
 
  

然在其初期（如Semeuse，欧盟资助的项  目 soa4all等）。 

缺乏工具的互操作 

除了SOA Software，Progress和Software AG（包含Centrasite插件的）
，其他所有的软件提供商
首先考虑的都是他们自己的软件栈（IBM，Tibco，Oracle，Sun，  Microsoft都是这样）。开源
公司更愿意开放，但是他们也越来越喜欢集成他们自己的工具（OW2，SOAPera， WSO2）。 

他们都声称支持 WS‐*以及 WS‐I，但是这并不够，而且众所周知。WS‐I 的用例无法快速跟进

SOA 实际的标准栈的发展，所以用户必须在其自己的  环境里测试所有可能的配置选项。 

Microsoft与Sun在互操作性上达成一致是个好事但这还是不够。在Sun Metro项目中，WSIT是
对  JAX‐WS的扩展，它提供了在Java Web服务与微软的Windows交互平台之间的互操作性。
它集中在增强Web服务的安全、可靠消息传输和自动事务方面的特性  。 

如proxisoft这样的新加入者，提出了一个有趣的，对我来说甚至  很有诱惑的方法。你开发
你的Java代码，它们能从你的Java Jar文件中创建你所需的服务。那样的话，你的服务就能与
最初的代码完全分离地进行管理，因此提供了一个功能的网关。 

投资语义数据的映射 

如果你可以通过 DSL 或一些高端建模语言（如 UML）创建出所需的能反映业务数据和服务

的企业数据模型会怎么样？如何每个业务对象生命周期和关系能够被定义，如果数据服务契
约能够自动生成，那又会怎么样呢？ 

如何你能深入现有数据并且将它们从真实的资源映射到这个新模型会怎么样？如果你可以
将业务规则重用到业务逻辑并且将路由逻辑描述成可以存储在数据库中的元数据又会怎么
样？你不觉得你的生活变得容易了吗？若干个月之前，市场上并无这样的解决方案，而现在
已有好几个了（Progress DataExtend SI，collibra，expressor）。 

利用EAI和ETL创建数据分发服务 

如前文所述，我们在最开始启动了（从其所在的竖井中）解放数据的项目。我们还需要足够
灵活，从而能在每次适配定制逻辑时不至于锁定某个解决方案。 

这件事可以通过三个辅助方法完成（如图 9）：使用集中主数据管理（MDM）、从应用创建

84 
 
  

数据服务以及创建标准格式来缓解企业内部与跨企业的数据分  发。 

如今大多数公司已经拥有EAI和ETL，也拥有了使用他们的知识。这些领域的开源提供者有一
大堆（除了MDM，只有两个选择——Sun的Mural项目和 Talend MDM），而且一些甚至以SaaS
的方式提供（Duns & Bradstreet Purisma）。 

创建对应用中已封装的数据的访问需要定义最少三个接口：CRUD，查询和管理（启动、停
止、数据连接器的状态）。我们称这些服务为基本服务。该方法可以受益于服务提供者与服
务消费者之间的“规范模式模型”（CSM）。CSM 缺省情况下会在任何消息（包括请求和相应）
路径中强制两次转换。 

 
图  9: ICC 数据服务 

模型驱动的 MDM 与语义集成工具的合并明显是一个双赢的局面。例如，如果你联合使用

Progress 的软件按 DataExtend SI（数据语义集成），Orchestra 网络  Ebx.Platform（主数据生命
周期管理）以及 Informatica Platform（数据质量，传输），你就能很快地创建一个强大的解
决方案，它部分基于模型驱动。 

不要忽略对服务配置主数据的管理 

服务常常不得不基于客户端而进行配置，该配置信息总是要与服务一起维护。例如，行程单
可以通过 HTML 邮件或 PDF 传送。对于每个客户端，该信息必  须要存放在某个地方。在外
部服务使用的情况这些信息更为重要（根据其合同某些能力可能都很大差异）。我们推荐将

85 
 
  

这些信息加入 MDM 工具或存放在专用的  LDAP 目录中。 

不要混淆SOA与整合 

SOA 不是集成，虽然它与集成共享着某些技术。SOA 关注创建服务，而服务封装了现有系统，

所以新的解决方案能够在消费这些服务的基础上进行开发，  而不需要重复创建获取这些信
息的功能。若信息没有重复，就无需同步和备份。信息管理是一个宽泛的话题，但在 SOA
中它通常指的是数据聚集、添加语义、应用  业务规则和提供富接口。 

在面向服务的架构中，服务接口就是那个规范模型（图 10）。它将服务消费者与系统信息记
录分离开。若服务被很好地设计时，所有的消费者调用一个特定的服务，而这个服务反过来
调用所有所需的后台系统。 

这就是SOA很难实施的原因。现有的工具无法管理必要的灵活性，这些灵活性在Jean Jacques 
Dubray的关于SOA的消息类型架构的文章中有很好的定义。我们仍然使用集成工具实现SOA，
出于不得已！因此我们尽量创建一个适用于大多数mySOA平台的基础。 

 
图 10：服务接口的规范模型 

86 
 
  

创建mySOA治理工作流 

设计时和运行时都应实现 SOA 的治理工作流程。这是首要的问题，因为大多数工具并不能

同时支持二者，不过，所有的 SOA 软件提供商都在尽力扩展他们的工具以提供对整合的支
持。与此同时，你也可以使用 BPMS 工具实现你的校验工作流，或者使用通常集成在存储库
中工具。 

设计时治理 

我们的设计时治理基于以下静态校验： 

 WSDL，在 SOATest 中我们通过 xpath 中定义的规则进行校验。 

 XML 模式，使用 xpath 中定义的规则进行校验。 

 Web 服务安全，我们使用标准的 SOATest 校验规则。 

 WS‐I 合规，我们使用 SOATest 中标准的 WS‐I 测试工具。 

 新服务对现有服务的影响分析。 

因此，我们的设计流程非常简单，它包含对所有我们创建并实现在 SOATest 中的标准的验证。

测试的结果同时与其他资产一起在配置库中进行存储与管  理。 

例如，有一个规则，它检查 WSDL 的每个元素是否非空格字符。 

 标准：所有的 WSDL 操作必须包含一个元素。 

 执行：SOA 测试规则，WSDL\CWT.OperationNullDoc。 

 错误消息：文档缺失，存在无文本的操作。 

然后，在 SOATest 中通过使用 WSDL 策略执行器对规则进行验证（见图 11）。 

87 
 
  

 
图   11：SOATest WSDL 策略执行器 

设计时治理——服务目录的圣杯 

服务目录是 SOA 治理的圣杯。

多数市场上的 SOA 软件提供商都在推他们的工具
（Software AG，
 
IBM，Oracle，Progress，HP，以及最近的 Amberpoint）或者通过 OEM 集成在他们的产品之
中。有些 UDDI 存储是基于客户端的，也有基于服务端的（但没有人会告诉你同步时会带来
的影响），有些实现了 WSDL tModel，有些没有。我们做的大多数产品之间互操作性测试都
失败了，其原因不仅有软件提供商实现的差异，还因为 UDDI 标准中的一些死角。 

SOA Software，HP Systinet 以及 Software AG 试图在他们的软件之间实现互操作，多多少少有

些成效（有些在一个版本中可以但是另一版本却不行，竞争总是存在）。 

就像旁注一样，服务目录已成为存储库的一部分。市场上不再有单纯的注册产品了，也许有
些开源工具（如Apache jUDDI）例外。UDDI注册已死，而存储库却能永  生。你可以创建自
己的工件并存储在注册库中，当然，你要为其找一个UDDI接口。 

结论：因为过度工程化的标准（UDDI），所以目前市场上几乎不存在真正可互操作的解决方
案。所以，提供商锁定的反模式是适用的。SOA 没有死，但你应该承认其模型的一个关键部
分已经消逝！我始终认为，对于一些能够提供存储/注册插件的公司来说有一个市场供他们
销售插件 

88 
 
  

设计时治理——Software AG Centrasite与Parasoft SOATest 

我们与 Sofware AG 在过去的两年内做了测试并进行了探讨。Centrasite 8.x 版本几乎覆盖了所

有我们所需的治理需求，特别在与 SOATest 集成上（见图 12，图 13 及图 14）。但我们不得
不承认，我们仍然无法说服业务部门在设计时存储库上花钱，最后我们的产品还是到期了。 

 
图   12：服务分类 

 
图   13：  有 Centrasit 提供的 SOSTest 插件 

89 
 
  

 
图   14：SOATest 设计时治理中的测试转换到 Centrasite 之后的结果。 

所以，我们必须只能走穷人路线，感谢开源软件的发展，我们有幸使用 MuleSoft Galaxy 和
Liferay portal 来建立至少可以满足服务目录需求的解决方案（见图 15，图 16 与图 17）。 

 
图   15：  ICC 服务目录——使用服务分类学 

90 
 
  

 
图   16：ICC 服务目录——TravelerProfileSearch.wsdl 

 
图   17：ICC 服务目录——有 WSDLDoc 生成的文档 

我们使用WSDLdoc记录WSDL和XSD，我们还测试了使  用Intalio创建MuleSoft Galaxy中不支持
的治理工作流并且发现它很好用。然而，我们认为开发SOA工具和把时间花在工具的集成上
不是我们的工作，这是为什么我们对  Centrasit机器“插件”（不过没有Firefox的插件那么易
用……）更感兴趣的原因。 

所以我们还在等待市场的成熟，等待价格下降以及等待软件提供商真正实现互操作性。开源
工具能促使软件提供商作出反应。  Mulesoft，Microsoft 服务引擎与 WS02 SOA 等工具已经

91 
 
  

在很便宜价格上提供了很多特性。我做一点补充，如果这些工具都能以 portlet（或 widget）

的方式提供出来，并能方便地集成到  WebTop（netvibes, Google IG）或门户中，那将会非常
强大。 

运行时治理——服务消费者管理 

ICC 在企业中职能的一部分是负责策略的管理以及受管服务及业务接口的报表。 

服务消费者代表服务的用户。服务消费者不是一个应用的 GUI 就是另一服务。服务消费者应

该信任任何受 ICC 管理的服务都是遵循标准的。具体的服务消费者的管理职能包括： 

 熟悉技术上的集成标准； 

 当发现某服务不合规或者需要增强时，应遵循 ICC 治理流程。 

为完成这些职能，ICC 必须确保所有服务消费者都是已声明的并且要定期报告其使用情况。 

在图 18 中，我们可以看到 3 个服务将被应用到 AmberPoint Proxy 上： 

 认证——通过存储在 AmberPoint LDAP 中的身份信息认证服务消费者； 

 用户凭证映射——使用静态用户名及密码对 Accenture 的请求进行认证；Accenture 认证

使用了 HTTP 基本认证； 

 日志——记录任何请求，响应以及错误信息。 

92 
 
  

图   18：ICC 服务目录——由 WSDLDoc 生成的文档。 

在图 19 中，我们将看到如何为这些服务定义性能约定。 

 
图   19：ICC 运行时治理——SLA 的定义 

运行时治理——最后一公里，史诗之战，说服IT运维。 

当你谈到运行时治理时，一般自然隐含了硬件，网络和负载均衡等。现在来到了 IT 运维的
地盘，ITIL 无处不在而 SOA 并非等同于 SMDB。最后一公里始终是你的 SOA 旅途中最艰难的
部分。我们花了一年多的时间去部署运行时治理工具，并且其主要原因是来自人的抵制。因
此，不要忽视这最后一公里！ 

运行时治理——SOA虚拟化 

John Michelsen的一篇好文解释了服务虚拟化为什么重要。在SOA中至少有三个独立点可以使
用虚拟化的概念： 

1.  硬件虚拟化。“这并非专属 SOA 的工作，当你在一台物理机器上运行很多操作系统的拷贝

时，虚拟化帮助你实现这些虚拟机器间互相独立”。 

93 
 
  

2.  虚拟服务端点。服务虚拟化架构通常伴随着（处在服务客户与服务实现之间的）服务代
理的想法。“在某种意义上说，你在为你的服务消费者创建一个虚拟的访问端点，该端点用
于服务访问而事实上你完全可以将真实的服务地址保护在后面” 

3.  虚拟服务。“他们对于在每个测试步骤上实现敏捷的 SOA 测试（更简单的、迭代的、需求

驱动的测试周期）特别重要，为什么?  因为如果你想提前测试，你要对未完成或开发中的组
件进行测试”。 

服务虚拟化应该由工具以服务的方式提供。 

运行时治理——仲裁服务 

仲裁服务实现两个目的（来自使用Jean‐ Louis Maréchaux的企业服务总线合并SOA与EDA） 

首先，仲裁保证集成异构系统所需的协议适配。因为两个不同的服务不一定使用相同的传输
协议，仲裁服务负责从一个协议到另一个协议的转换，这样交互才成为可能。对于在一个业
务交易中的所有参与服务，协议切换是透明的。 

其次，仲裁带来了转换数据内容的可能性，它是业务集成中的关键服务。它保证了通过总线
的数据能够被所有流程理解。另外，仲裁还可以为消息扩充任何信息。内容转换由总线负责，
并且对所有服务参与者透明。 

结论 

我希望你享受了这程 mySOA 之旅。建设 SOA 是艰辛的，标准和工具都很缺乏，而且其费用

对于大多数中小型企业来说仍然是高山仰止。这解释了为什么大多数时候人们做得都是带着
面具的 SOA，并招致了很多麻烦及失望。 

由于越来越多地提供了很多免费或低价的本地方式或者按需购买的功能，开源提供者正在撼
动着这个市场。 

如果开源产品还不够，你不能等，而且你不希望在互操作性方面进行技术投资，那么为大多
数平台服务选择同一提供商也许是短期或中期的最佳之选  （IBM，Sun/Oracle，Microsoft，
SAP）。 

SOA Software，Software AG，Progress，Tibco，Mulesoft 与 WSO2 也能提供最佳的初始模块，

如果需要，你还可将他们集成到你的私有解决方案栈中。 

94 
 
  

当工具能够帮助我们实现敏捷，为受管服务提供设计时及运行时治理时，SOA 才能真正让所
有人受益，才能为构建可持续的 IT 服务和系统作出贡献。 

致谢 

在这里感谢我的同事 Bob Donley（圣.路易斯，美国）与 Janusz Szyr（华沙，波兰）对这项工

作所作出的贡献。若没有他们的想法，没有他们所付出的劳动，没有不同文化的 SOA 版本，
就没有这件事的完成及这篇文章的问世。我还要感谢 Patrice Simon，我们的经理，为他不变
的信任和持续的支持。 

最后，我要感谢 Claude Mariaccia（IBM IT 软件架构师），Ghyslaine Ferre Morel  （Software AG

法国的销售工程师），Miko Matsumura（Software AG 的代理 CTO），Paul Davidian（MuleSoft
的客户总监）以及 Thomas Been（Tibco 解决方案顾问），感谢他们提供的支持与帮助并快速
响应我们提出的有关他们的方案及工具的技术问题。 

[1]可持续性IT架构，利用SOA进阶地翻修信息系统。BONNET Pierre,   DETAVERNIER 
Jean‐Michel,  ；VAUQUIER Dominique,  ；  BOYER Jér?me,  ；  STEINHOLTZ Erik, 3 月  2009, 
ISTE‐Wiley. 

[2]吞下IT大象：从绿地开发到棕地开发，Richard Hopkins与Kevin Jenkins，2008 年 5 月，  IBM

出版社。 

原文链接：http://www.infoq.com/cn/articles/mysoa 

相关内容： 

 SOA的好处、坏处以及尴尬之处 

 REST的业务用例 

 超越SOA：动态业务应用的新企业应用框架 

 有道搜索服务系统架构剖析 

 从实践出发探索架构的本质 

95 
 
  

新品推荐    New Products

FAI：Linux的自动安装、管理和自定义工具 

作者 Michael Prokop  译者 滕振宇  

FAI（Fully Automatic Installation，完全自动安装）是一种无须交互就可以完成那些重复
性枯燥乏味的、常常需要手动完成的 Linux 安装、自定义以及管理任务的自动  化系统。
现如今，FAI 被用户维护假根环境（chroot environments），虚拟机以及服务器。它可以
完成从几个独立系统到基于大规模基础设施和有数千个系统组成的集群系统的部署和安装。 

原文链接：http://www.infoq.com/cn/news/2010/04/fai

MongoDB不断发展：发布 1.4 版本，10gen提供商业支持 

作者 Michael Hunger  译者  丁雪丰    

3 月 25 日 MongoDB（取自“humongous”）1.4 版发布后不久，其创始人 Dwight Merriman

（前 DoubleClick CEO/CTO）宣布 10gen——开源文档数据库 MongoDB 背后的公司，将为
其提供商业培训和支持。InfoQ 采访了 Merriman，了解了 MongoDB 的特性、适用性以
及在 NoSQL 数据库社区中的地位。 

原文链接：http://www.infoq.com/cn/news/2010/04/mongodb 

Maven、Ant、Rake：JRuby 1.5 加强配置管理 

作者 Paul Blair  译者  丁雪丰    

随着即将到来的 JRuby 1.5 版本（预计将在四月底发布），JRuby 项目正通过集成 Maven、

Ant 与 Rake 不断改善 Java 与 Ruby 的互操作性。 

原文链接：http://www.infoq.com/cn/news/2010/04/jruby‐15

96 
 
  

IronRuby 1.0 发布 

作者Werner Schuster译者 张龙    

IronRuby 1.0 发布了。该版本兼容于 Ruby 1.8.6 并搭配 Rails 2.3.x。接下来的 IronRuby 1.x 目标直指 Ruby 1.9。 

原文链接：http://www.infoq.com/cn/news/2010/04/ironruby10

Internet Explorer 9 预览：新特性与分析 

作者 Dionysios G. Synodinos译者 张龙     

近日，微软发布了 Internet Explorer 9 的一个预览版，值得关注的是该预览版的性能得到了改进，同时还

采取了一些标准，如 SVG、CSS 以及 HTML 5 等等。 

原文链接：http://www.infoq.com/cn/news/2010/04/ie9-preview

与Jim Marino谈Fabric3 1.5 版的发布 

作者 Boris Lublinsky  译者  马国耀    

Fabric3 是一款 SCA 实现的开源项目，在其新版本中引入了许多新特性，包

括对集群支持的改进，与 WebLogic 应用服务器深入集成以及性能的提升。
InfoQ 就此采访了 Jim Marino，他是 Metaform Systems 的创始人也是 SCA
的功臣之一。 

原文链接： http://www.infoq.com/cn/news/2010/05/Fabric3 

97 
 
  

W3C发布XML新标准：XProc 

作者 张凯峰 

W3C 把 XML 管道的概念定义为一系列针对 XML 文档的操作。通过  XProc，可以自动

执行、管理以及共享管道。Quin 提到 XProc 跟 W3C 所有的推荐标准一样，都经历过
超过两年时间的大量开发和公开讨论。 

原文链接：http://www.infoq.com/cn/news/2010/05/xproc 

Android 2.2 新特性综述 

作者 Abel Avram  译者  张龙    

近日，Google 在 Google I/O 2010 上展示了 Android 第 7 版：Froyo。Android 在此次

大会上颇受关注，同时也是 Google 工程部副总裁 Vic Gundotra 的演讲主题。Android 
2.2 在企业集成、设备管理 API、性能、网络共享、浏览器和商店等领域都提供了很
多新特性。 

原文链接：http://www.infoq.com/cn/news/2010/05/Android‐2.2 

Mahout 0.3:  机器学习开源项目 

作者 Gilad Manor  译者  沙晓兰  

有关机器学习的开源项目 Apache Mahout 三月份的时候推出了它的 0.3 版本，

这个新版本在之前的基础上添加了一些新功能，比之前的版本更为稳定，性能
也有相应的提升。InfoQ 采访了 Apache Mahout 项目的开发者 Grant Ingersoll 和
Ted Dunning，其中 Grant Ingresoll 也是该项目的创始人之一。 

原文链接：http://www.infoq.com/cn/news/2010/05/mahout‐03 

98 
 
  

      特别专题

策划：InfoQ 中文站 

执行：霍泰稳  刘申 

那云，那计算 
 

     

    云计算七问七答 -   被高估的云计算 - IBM 院士谈云计算和云计算 - 评论：微软的新云计算战略

微软专家Eric Nelson谈Windows Azure - 谷歌工程师谷雪梅谈云计算 - 云计算虚拟研讨会

99 
 
  

      那云，那计算

云计算七问七答 
作者 吕维德  

缘起 

最近因为工作需要，又再度开始接触  Amazon EC2/S3（早在 2006 初这个服务刚推出不久时

曾用过一次，那时是 RoR 加一堆 merb，不过后来随着项目结束也就渐渐忘了这事），结果这
次随便查了  些资料却发现“云计算”这个单词似乎已无所不在泛滥成灾，也让我一时兴起想
了解一下到底现在大家口中所谓的“云计算”是在指什么。 

之所以这样好奇主要的原因是在许多地方都看到有人自称在提供云计算服务，但这些服务间
彼此的性质、形态与做法差异性却很大，例如EC2 与GAE两者  就不太一样，GAE与Salesforce
又很不同，搞到最后，似乎处处是云端，人人在漫步。 

根据维基百科的定义，云计算最宽松的定义是这样的： 

“
它它是一种计算方式，通过互联网将资源“以服务”的形式提供给用户，而用户不需要
了解、知晓或者控制支持这些服务的技术基础架构  （“云”）。 
 
（It is a style of computing in which resources are provided “as a service” over the 
Internet to users who need not have knowledge of, expertise in, or control over the 
technology infrastructure (”in the cloud”) that supports them.） 

如果你对这样的定义没问题，那非常好，不用再浪费时间看下去，去喝杯咖啡吧。 

很可惜这样的定义在我听来似乎宽松的有点夸张了，因为这样说来，我在家里摆几支 iPhone
跑些服务并开放 API 给人用，其实也算是云计算喽？（还  是高雅的 Apple 云哩）就因为这
该死的好奇心，我花了几天时间调查并整理了些相关资料，现在总算比较有个头绪了。 

请注意这只是我个人的心得整理，文中对于名词的定义与诠释，尤其是“云”，只是我个人的

100 
 
  

想法，如果有错欢迎各方大德赐教。 

从主机服务到VPS，它是真正的云吗？ 

基本上，如果要细究到底云是什么，可能可以先吵上个三天三夜还没定论，因为根据众多前
辈的说法，云这个字本来就是个流行词汇（Buzz Word），想用的人就随需取用好了，其实根
本没啥定义好谈的啊。因此，我打算先跳过试图去定义这个字的破题法，从实际的部署方式
来看这件事。 

以往一般人要提供网络服务，大多是去租虚拟主机，有钱一点就丢机器到机房去，这是最常
见也最传统的手法，这个手法最大的缺点在于：如果临时有大流量  需求，例如办个活动，
很难迅速扩充服务能量，不论是要搞到大量的机器，或无穷尽的带宽，都是个问题。 

因此，这几年来比较流行的玩法是所谓的VPS/VDS（Virtual Private Server），透过类似XEN这  样
的软体，将一台实体服务器虚拟化（Virtualization）  成多台虚拟机器然后出租，这样一来当
临时有大流量需求时，可以很容易地加买几台虚拟机器就撑过去了。 

前面开头谈到的EC2就  是这样一个服务，另外这一两年颇受好评的Slicehost也  是，在EC2 的

例子里，每一个虚拟出来的机器叫做一个实例（Instance）
，因此要应付大流量事件时，可以
狂开Instance撑过去，这比狂买实体  机器便宜多了。 

由于 VPS 真的超方便而且很好用，因此迅速受到大家欢迎，久而久之，VPS 这样的服务似乎

也就跟云画上了等号，但这个等号里，有个地方却值得进一步  讨论。 

简单来说，今天一个人在EC2 买了 100 个Instance，它们并不会自动联合起来工作，而是要

靠人工去规划，例如最常见的是在前面放个逆向代理  （Reverse Proxy），然后把请求平均导
向到这 100 台机器上（轮询负载均衡，Round‐robin Load Balancing），并且，更重要的是应用
本身在撰写时就要考虑到将来能支持跑在多个分散的机器上，例如Session要怎么维  持？全
局内存（Global Memory）如何分享？数据库是否也要散聚在不同机器上？如果分散的话，
要怎么维持资料同步？等等这一大堆相关的细节要处理，一个没弄好，呃，就成了  Twitter
第二了。 

从这个角度看来，VPS（不论是 EC2 还是 Slicehost）提供的其实是虚拟化与负载均衡服务，

至于在这个基础服务之上，用户要怎么玩就是各显  神通。但负载均衡与云似乎并不尽然相
同呀！ 

101 
 
  

世界上还有其它种类的云吗？ 

有，例如  Google App Engine（简称GAE）提供的服务。 

简单来说GAE是由三个东西组成的，分别是MapReduce、BigTable和GFS（Google File System），
其中最重要的特色就是MapReduce。MapReduce可说是一个演算法，也可说是一个框架（看
你读的文献来源），但它基本上是由  Map与Reduce两者组合，运作方式也很简单： 

 Map：主节点将工作切割成许多小块丢给子节点去执行，子节点可能会再切割工作成各
多的小块给其下的子节点去执行，因此这是一个树状的结  构。当子节点完成计算后会
将结果传回给主节点。 

 Reduce：主节点拿到子节点传回的结果后，将它组合起来，就完成工作了。 

对 MapReduce 有兴趣又闲的发慌的朋友可以去看看 Google 发表的一篇论文与简报（保证会

睡的很香甜:P）。 

类似 GAE 这样的服务，它们最大的特色就是会将工作切割成很多小块，然后经由多台电脑
联合起来一起运算，也因为要切割，因此通常会伴随者一个分布式  文件系统（在 GAE 的例
子里，叫做 GFS），通常也会有一个分布式的文件库，例如 GAE 里叫 Bigtable。 

当然前面讲的都是针对底层架构的设计，但对最前端的开发者来说它代表什么意义呢？很简
单，开发者可以完全不用管它有 100 台或 10000 台电脑在运  作，只要照着 GAE 提供的 SDK
开发程序，将来布署到 GAE 上后就会自动去调用一堆电脑（而且很有可能是分布在世界各
地数据中心里的）来发功，从这个角度  来说，开发者要担心或处理的细节是比较少的，因
此理论上上市时间也是比较短的。 

如果不想用GAE还有其它选择吗？ 

有，Hadoop是  Aapche基金会里一个基于Java的主要计划，基本上可视为开源版的GAE（很
多关键技术是依据Google开放的学术论文来实现的，例如Map Reduce、分布式文件系统等）
，
目前最力挺的开发者是Yahoo，  用于该公司的搜索引擎上，而Hadoop的创始者目前也在
Yahoo上班（今年红利会不会很伤？:P），这里有一篇iThome的中文报道值得一看。 

Hadoop主要由下列三者组成（其它详细说明请看官网）： 

 Hadoop Core：主要就是实现 MapReduce； 

102 
 
  

 HDFS（Hadoop Distributed File System）：参考 GFS 而来的分布式文件系统； 

 HBase：基于 HDFS 的分布式资料库（功能等同于 Google Bigtable）

。 

Hadoop/GAE与EC2 是互斥的吗？ 

不见得，要看比较的面向为何？但实际上它们是可能合作的，其中最著名的例子是纽约时报
在 EC2 上用 Hadoop 转了 4TB 的 PDF（这篇文章超级精  彩不看可惜）。 

故事大略是这样： 

NYT 有一大票 1851‐1922 年间扫描的一千一百万份文章要从 TIFF 图档格式转换为 PDF，由于

数量实在太庞大，转换起来不但耗时甚久，也需  要极大数量的机器，就算有钱如 NYT 也不
想当凯子爷投资这么多啊~~~（而且因为转换时间太久，也不太可能跑去 BestBuy 刷它个几
千台 PC 回来，然后  速速转完就退回去;P） 

最后 NYT 的工程师将所有档案传到 S3 放着，然后到 EC2 开了 100 个 Instance，再装个 Hadoop

利用这 100 台电脑跑分布运算，结果是  只花了 24 小时和大约 3000 美金就搞定（由于处理
速度实在太快，他们实际上还跑了两次吶……） 

这个例子也正好带出下一个主题。 

EC2 到底是不是云？ 

这要看你怎么定义云这个字，以我而言，我倾向认为 MapReduce 与分布式文件系统是云计

算的主要特色，因此在这个定义之上，EC2 并不符合首要  条件。 

但如果我们把问题转成：EC2 可以成为云吗？ 

那答案就是肯定的，从上面 NYT 的例子可以看出，EC2 提供 100 个 Instance 只是基础架构，

之后再上面跑 Hadoop 才是真正发功之所在。  由此我们也可以得到另一个结论：硬件本身
有无虚拟化并不重要（你可以买 100 台真的电脑连起来，也可以用 EC2 开 100 个 Instance），
重要的是在  其上协同运算的方式（MapReduce 是这里的关键）
。 

更简单的二分法则是这样： 

 Amazon 只是把硬件虚拟化，然后卖入门级计算能力。 

 GAE/Hadoop 则是提供分布式协同运算，打包的计算方案。 

103 
 
  

因此，或许我们可以把 EC2 视为云的前奏曲，拥有它之后，要不要做成云（例如装上 Hadoop）

则是个人选择。 

何时选择使用EC2 或云呢？ 

这是更重要也更实际的问题，而答案也很单纯，主要就是考虑下列因素： 

1、你要解决的问题是否能符合 MapReduce 的矩阵分割方式？ 

或是更白话一点的讲，你要做的事能不能被切割成小小的一块块来各个击破？例如日志文件
的分析就很适合，但 Friend of Friend 数据库就不见得适合。如果你的问题可切割成许多小块，
那就可以考虑下一点。 

2、Vendor Lock‐in 是否是个问题？ 

这个主要是针对 GAE 而来的，现在如果用了 GAE，基本上它的 Lock‐in（Vendor Lock‐in 意思

是你采用了一个技术，即将自己锁定在这家提供商身上，不能轻易转换提供商）特质非常强
烈，例如一定要用 Python 与  Bigtable，整个资料库栏位的规划方式跟传统 RDB 完全不同，
操作语法也不一样，将来几乎无法迅速移转到其它主机服务（虽然有人写了 GAE to EC2  转
换指南，但有没有胆量用是另外一回事）。喔，更别提市场上 Python 的人才有多贫乏这件事，
会 RoR 的人搞不好还多一点。 

当然这里可能的另一个选择就是效法 NYT，用 EC2+Hadoop 搞定制化分布式运算，而且用的

是 Java，人才四处可得，相对门槛就低一点（但搞  不定最后会死在 MapReduce 搞不定上：
）） 

SaaS是云吗？ 

这也是个好问题。 

现在很多 Software as a Service 的服务商，例如 Salesforce 也都宣称自已提供了云计算服务，

这又是怎么回事？我认为比较合理的看法是将云分成三个层次来看： 

 第一层是硬件层（100 台真的电脑，或 100 个 EC2 Instance） 

 第二层是框架（Hadoop、GAE 或者微软的 AZure 等） 

 第三层才是服务（记账、PDF 生成等） 

在这样的架构下，SaaS 是属于第三层服务这个范畴。 

104 
 
  

也就是服务商先搞定第一、二层后，在其上建构自已的专业服务，例如 Salesforce 的主力服

务是 CRM，因此它通过云提供一系列的 CRM API 给开发者使用。举个夸张的例子（注意，
这例子是假想的），搞不好 Salesforce 也是租 EC2 然后搞了个 Hadoop，接着在上面用 Java 写 
了一堆 API 给人调用。这时它就是三层皆备，可称云而无愧了。 

另外类似的例子则是像 Gmail、Google Reader 等，这些都是基于 GAE 的软件服务（先搞定一、

二层，然后建构第三层的专业服务）。 

附录 

原本我曾认为 EC2 的虚拟化可以做到将许多台实体电脑虚拟化成一台大的服务器，这样工程

师就只需要针对一台“超级电脑”来写程式即可，如果是这样，  那 EC2 其实也符合分布式运
算的标准，但我查来查去只不断看到类似下面的解释： 

“
EC2 是为可以跨多台主机进行扩展的应用而设计的，而不是那些需要大量资源的更大
的应用 
 
（EC2 is more designed for applications that scale well across many hosts, rather than 
larger applications that require huge resources.）   

可扩展性：Amazon 能让你方便地增加或者减少服务器，而不是为一台现有的服务器
（Instance）增加更多的电力/内存/硬盘等。这在你的应用设计  时就考虑可以跨多台
服务器进行扩展，以支持增加的负载的时候效果最好。 

（Scalability: Amazon supports easily adding or removing servers, not adding more 
power/memory/disk to an existing server (instance). This works well when your 
application is architected to scale across multiple servers to support increased load.） 

因此目前先初步认定 EC2 并没有提供这方面的能力，当然如果有错，欢迎指正。 

后记 

在研究期间叨扰了无数前辈，感谢他们牺牲周未时间情义相挺回答各种无趣的问题，在此致
上最高谢意。 

另外关于 EC2 vs. Slicehost 的成本或用哪家比较划算这档事，我也小小想了一下，从实际数

据看来，如果只是小型的网站或是创业公司，从省钱的角度来看，应该要选  Slicehost，因
为它的初始成本最低，例如花个$20 美元就可以有颇大的空间与流量可上线运行了。 

105 
 
  

但 EC2/S3 的好处则是安全性、稳定性与扩充性，而它最大的缺点则是成本相对较高，一个
Instance 开着不用一个月就要$72 美元，如果生意  好流量大那要交的费用就更多。 

目前台湾地区用EC2 的网站似乎并不多（Pixnet把  资料存在  s3 的站就多一点），可能主要是

连线反应时间不够快所以接受度不高吧，但我们服务的客户本来就多在北美，所以没差。 

原文链接：http://www.infoq.com/cn/articles/questions‐about‐cloud‐computing 

106 
 
  

      那云，那计算

    OOPSLA辩论：被高估的云计算 
作者 Morten Udnæs, Ruth Lennon and Lars Arne Skår  译者  李重辉  

现在对云计算的炒作就如同上百人在电话会议中狂吼一样喧嚣。回顾 20 年来 IT 的演变，较
为特别（其实也不那么特别）的一点就是每次新技术的诞生都发  生了喧嚣的炒作。以 4 到
5 年为周期的技术更新意味着大量赚钱的良机。从最早的大型机到客户端‐服务器、CASE 工
具、.COM、企业架构(如 EJB 和  DCOM)、SOA，以及发展到现在的云计算，IT 一如既往地关
注于如何想方设法赚钱。 

云计算广受期许的原因是什么？首先对于一般开发人员和架构师来说，确实非常赞同‘IAAS’
（基础设施即服务）的理念。无可置疑，这也难怪，由于在  开发过程中 IT 部门和外包服务
商常是制约项目进程的瓶颈，使得这些人过去多是生活在资源的“捉襟见肘”之中。但现在他
们终于可以不受限制地开发应用并任意  部署。 

对于拥有复杂技术的大牌供应商来说，（据说）可以通过预先配置和包装来让那些缺乏足够
技能和经验的用户也能够合理的配置并使用产品和服务。从而为它  们的产品和服务开辟了
一个全新的分销渠道。由于云计算缺少通用的标准，因为可以将用户的应用绑定在特定的供
应商平台上，这样客户就会很忠诚——然后提供富  余的硬件也是一条生财之道。 

对于业务主管来说，云计算既支持按使用付费，又很容易平衡成本和收益——这个设想非常
的美妙…… 

对于学术研究者来说，云计算预示着可在诸多领域进行探索的良机。同时它还使用到了很多
过去在并行计算，可伸缩性和虚拟化方面的研究成果。 

云计算的真相是什么？ 

 提供很多你不需要的东西 

 不是服务复用的圣杯 

 不是开发/托管全能的瑞士军刀 

107 
 
  

如果你只需一辆自行车，那么给你提供一架比自行车贵得多的航天飞机绝不是一件好事。问
题的关键在于复杂度。它不工作该怎么办？它不如预期工作该怎么  办？该如何操作它呢？
除非自己是个火箭科学家，否则会很被动。你已经拥有所有（甚至更多）特性的功能需求吗？
你在定制架构上拥有足够的技能和经验吗？如果  这些条件都不具备，那么无论是用云计算
还是别的什么就都没有多大区别了…… 

“软件开发成本如此昂贵，所以我们要尽量复用”。这句话没错，但是请看这条新闻：四十年
以来，我们一直试图复用代码但却从未成功！云计算在软件复用  上也根本没有任何进步。
复用要求非常相似的业务需求和上下文。而现在最主要问题恰恰在于每个用户的业务需求和
上下文都有些细微差别。从技术角度上看，同类  的云的集成服务会很容易，但在质量和安
全领域上复杂度却会增加。简单数据服务（如地图/地理数据）的复用会带来一些好处，但
这并不能改变用户仍然需要雇用  开发人员来开发新功能这一事实。 

IT 不仅指像 Facebook 和 Amazon 这类的互联网创业公司，它需要支持业务流程。除开少数

流程可以通过云计算来实现，绝大多数都不可以。它  们都需要云计算平台所不擅长的整合、
安全和灵活。 

SAAS（软件即服务）是个好主意，但也不够通用。即将出台的一系列标准将使 SOA 和服务

看起来很容易，但是其中绝大多数都会被忽略掉，进而根本无  法根据它们来做实现！重写
软件又是非常昂贵且缺乏商业价值。基于上述问题，未来 5‐10 年里将只出现少量的面向云
的应用。而到那时，取代云计算的下一个技  术革新将会发生。 

云计算擅长做什么呢？以下场景都是不错的利好方案： 

 没有基础技术设施而又需要可伸缩性的创业公司。 

 地理数据，政务信息之类的数据中心。 

 桌面办公（邮件，浏览器，日历类应用）。 

 游戏（拥有服务端和三维渲染的廉价终端的这类）。 

 需要动态处理大容量数据的业务。 

 具有大容量数据和低安全要求的应用。 

开发人员一直盼望的是什么呢？不是免费。IT 部门和（或）外包服务商应该提供丰富的包含
安全、标准、补丁等自助服务，从而可以用来开发现实的“自行  车”类方案的环境。实际上，
学术研究者应该停止附和 Garter 公司对云计算的不合实际的高估。把时间用来研究产品和

108 
 
  

市场的需求，这才是云计算等新技术诞  生并发展的源泉。 

大牌供应商应该意识到“大量打包用户并不需要的东西”的做法并不合理。他们应该降低开发
复杂度从而更好的帮助开发人员完成任务。 

业务主管应该改变 IT 部门的工作方式。敏捷和精益思考的出现使 IT 和业务无缝协作成为可

能。管理上则应该从成本导向（开发花了我多少钱）转为收入导  向（上阶段发布的新功能
让我们赚了多少钱）。 

邀请您来挑战我们的观点并指出其中的错误。我们不需要一套套的理论和逻辑，我们需要你
举出真实的场景。 

原文链接：http://www.infoq.com/cn/articles/oopsla‐cloud‐computing‐debate 

109 
 
  

      那云，那计算

    IBM院士谈云计算和云计算 
受访人 Jerry Cuomo  采访人Floyd Marinescu  

Jerry Cuomo 是 IBM 院士，同时担任 IBM 软件集团 WebSphere 部门的首席技术官。他是 IBM 

WebSphere 软件的创始元老之一。Jerry 在 IBM 工作近 20 年，涉及领域包括 TCP/IP，实时协
作软件，以及高性能事务系统。 

InfoQ：给我们讲讲企业级云，  以及 IBM 对于数据中心云计算的视野。 

Jerrry：   实际上我们对于云计算有着很宽泛的视野。你肯定听到我们谈起过 blue cloud 以及

blue house 等等，这些都是充分的关注在因特网上，又反过来为你提供充分利用因特网来构
建云的技术，不是有成千上万，也有成百上千的服务器供你处理。同样你  也可以想到，我
们也十分专注于如何帮助你来创建，和成为一个造雨者，来在企业内部防火墙背后创建你的
云。同样我们还关注那些能帮助你混搭虚拟镜像，将其部  署到你的云上，管理，测量，监
控，更新，控制版本这些镜像等等的技术。当然我们也将云计算看着从大型因特网应用到公
司内部网发散的这样一种范围。实际上我  们认为这里大有潜力，基于我们过去所做的工作，
甚至有一些成果我们认为垂手可得，在企业内部让事情发生并将神奇的技术带给我们的企业
级用户，帮助他们搭建  数据中心内部云。 

InfoQ：软件即服务如何适应于这一讨论？    

Jerrry：   这么说，我认为软件即服务在这里特别适合。首先我想说的是软件即服务这一术
语在这里有点不准确，因为其实并不是软件真正作为了服务，而是功能作为服务或者  平台
作为服务。所以我更愿意称之为 PASS 或者平台即服务。但我想其意义应该是一致的。我绝
对认为它是合适的。我将这一类的虚拟化进展讲作机器虚拟化，服  务器虚拟化；我之前曾
提到了，原子和分子。 

这是一种真正的进步，当你从平台本身去看待时。即虚拟化了平台，因此不必去跟云说：“云
啊，我需要这样的机器来运行这一类的工作，我也需要这么多的 CPU  和这么多的内存”，你
要做的是你对你的平台即服务的云说:“云啊，我需要你帮助我运行我的商务应用，我需要安
装一清单的产品”。所以你不是在要求服务器，  而是在要求它帮你完成任务。或者说“嘿，

110 
 
  

我有这样的业务流程，你去执行它！你得去搞清楚我需要多少服务器，是需要基于 Linux 的
服务器还是别的。” 
 
嗯，那就把我的应用拿去吧，这里，这就是我想要运行的，我会给你一些运维策略，比如响
应时间目标，吞吐量目标，我也会给你一些业务优先级，一些应用从业务  的角度会比另一
些更重要，我还会给你一些健康策略，但我需要这个平台来管理这些。我不想亲自去管理所
有这些特定的细节。再来思考软件即服务或平台即服务，  我想这就是虚拟化的前进方式。
实际上如果我要部署一个软件即服务或者平台既服务，我会使用云基础设施来做到。 

InfoQ：你提到你的 WebSphere Virtual Enterprise 是企业云的实现者。跟我们讲讲它是做什

么用的以及它是如何成为实现者的。    

Jerrry：   当然，我很乐意告诉你。我首先要说的是我会将 WebSphere Virtual Enterprise 或者

WebSphere VE 称为是一个状况转换器。它能帮你做的是，一旦你的云上安装了 WebSphere
应用，并安装到了你的共享资源池，它能帮助你找到合适的平衡与混合。它  能真正的转换
运行的应用集合，举例来说，如果你的存货应用非常繁忙，因为正处于仓储的时节，而你的
应收账目应用在这一特定时节比较空闲，它就会增加运行存  货应用的实例来满足需求。 
 
因此它能改变你的 WebSphere 云的状况，在这个例子中是偏向存货应用。而且它会基于策
略来做这件事，基于服务水平协议，运维，健康以及面向业务的各  种策略。而最终实际的
改变运行应用的状况。It will also based on these policies shape the inbound workload.因此当有
工作进来时，它会根据其目标的应用进行分类，并根据你的 SLA 来决定是否偏向于某个应用
的请求。据此就可以减慢某些应用而加速  另外的应用。这也是我之所以称它为状况转换器。
同样，它也能帮助你将应用作为虚拟集合来进行管理。我们关于 WebSphere VE 的工作已经
超出传统的 JEE 应用了。 
 
它当然也支持经典的 WebSphere 应用，JEE 应用，同样也包括了简单的 Web 应用，基于 Tomcat
的应用，WebSphere 社区版，还有新型的  用于动态脚本语言应用的 WebSphere sMash 环境，
以及 JBoss。因此它支持你为应用创建一个共享的应用云或是共享的资源池而不必考虑特定
的应用容器。它虚拟化了术语表，以及这些应用的  管理基础设施，因此启动，停止，部署，
监管变成了跨各种应用类型的共享词汇。重复一下，这就是创建了一个 WebSphere 云了。 

InfoQ：开发团队如何与虚拟企业进行交互呢？部署单元是什么，它是如何被虚拟化的？    

Jerrry：   如我所说，我们支持多样的应用容器类型，而我们大部分都是让这些容器来管理
自身，所以典型地你会用 EAR 文件与它们交互，或者是用于 Tomcat 的 WAR  文件，用于

111 
 
  

WebSphere 应用服务器的 EAR 文件。但你需要多做一件事，就是描述我称之为运维策略的这

样一个东西。除此之外第二部分信息就是你的  SLA 以及契约。它将帮助我们管理这一位于
WebSphere 云里的特定资产。我们知道如何与它们进行基本交互，同样我们也有管理代理与
之共同运行，来与  你的 EAR 文件或 WAR 文件一道的 SLA 和附加策略进行交互。因此通过将
其部署于你的 WebSphere 云中，我们就可以将其作为虚拟单元来进行管理了。  再重复一次
至于这个应用是 Tomcat 应用或是 sMash 应用或者 WebSphereJEE 应用一点也没关系了，它
们都是运行于 WebSphere 云的应  用。所以关于启动，停止，部署代码的等等动词和行动，
现在都变成了共通的并都被虚拟于这一应用管理系统。 

InfoQ：开发团队对于策略矩阵有多大的控制力？比如说，某一实例在内存中的人员对象超
过 10 个以上时，就停止响应更多的请求，这样可以做到吗？    

Jerrry：实际上你有好几个控制点。我们把它分解到运维策略，业务策略，健康策略等几方
面，因此你就可以做一些事情，比如在服务了许多的请求，上万个请求之后，循环  利用服
务器。仅当它是 Windows 系统时。你可以做诸如应用版本控制，并陈述应用版本策略例如“运
行应用版本Ｎ”，然后可以开始以这样的速率和步伐迁移  到版本 N+1。比如每一固定时间周
期，增加 20%的新用户。这样你可以在你的集群里开始为新的应用热身，同时又不会让用户
完全断绝旧的版本。你可以设置合  适的策略来描述使用矩阵，应用是如何交互的，速率和
步伐如何，整体的运行使用如何。再重复一次，你得以控制的方式是通过这些 SLA。 

InfoQ：Virtual Enterprise 是纯粹的软件解决方案吗，还是有一些特别的前提？    

Jerrry：   现今我所提到关于造雨技术的 Virtual Enterprise 是一个纯粹的软件解决方案，我认

为做出设备版的管理控制系统也是有价值的。你可能看到我们的数据动力产品曾获得的成
功，并期待使用我  们的一些造雨技术并将它们变成设备形式以用于管理一个共享的资源池。
试想一下获取 websphere virtual enterprise 的功能，将其加入你的数据中心，可能有一到两
个Ｕ的箱子，架起来，堆起来，将你的应用部署在上面就像虚拟设备分派员。我们肯定有想
法  来使用我们的技术并不断改进它，从现在的通用软件形式，到更多目的的设备形式。 

InfoQ：谈到将中间件以及其它形式因素作为设备来交付。你能看到的是，微软正在追随
Amazon 的脚步试图找寻将中间件产品成功的以 web  服务的方式进行在线按需给付。IBM 的
方式将会是怎样？    

Jerrry：   我们正面对着多种水平层次，比如我们有 Blue House 的这样的产品，Blue House

是软件集团对于服务器协作的一个出击，当然是由 Lotus 部门来领导的。Lotus 的一些协作
功能被作为服务来提供，我认为对于中小企业将  Lotus 平台作为服务将是非常具有吸引力

112 
 
  

的。在我们 Websphere 部门当然也有所动作，实际上整个 IBM 跨部门之间都在认真的对待

此事。我认为  Blue House 类型的功能来构建应用将会成为一种选择，以帮助托管预置平台
如 websphere,websphere 应用服务器，流程服务器，sMash 作为  服务的开发者更有生产效
率地马上构建他们的应用。 
 
但我确实收到了来自客户的很多反馈：“你知道，大规模的因特网应用还不是很安心，你能
在我们公司的防火墙的背后复制这些软件以作为服务环境吗？你能将这些  云建在公司防火
墙后面吗？”我想对于运行他们的服务，他们内部的部门和业务线，这些环境是一个机会。
我觉得两者都可以预见。我认为微软和 Amazon 所做  的对于大规模因特网来说非常有趣，
但同时我也认为以高度隔离的安全而健壮的方式在公司防火墙后面来进行这项工作也是非
常非常重要的。为了构建支持这些的软  件，如我所说，我们 IBM 作为造雨者我们想要帮助
你们来构建这些云，首要的就是在你们的企业。这就是我们所集中精力进行的事情。 

观看完整采访：http://www.infoq.com/cn/interviews/jerry‐cuomo‐cloud‐computing‐cn 

113 
 
  

      那云，那计算

    评论：微软的新云计算战略 
作者  张逸  

如今，云计算已经不是一个新鲜的概念，但云计算平台的竞争才刚刚开始。毫无疑问，在
Amazon、Saleforce与Google等厂商纷纷推出云计算平台与产品，并获得巨大利润的同  时，
微软的Azure云计算平台才刚刚起步。不过，微软对于Azure倒是信心十足，毫不隐晦对云计
算市场的野心与宏图。在Bill Gates退休后，担任微软首席软件架构师的Raymond Ozzie就将
Azure视为微软重新缔造商业帝国的契机与基础，因为它将改变软  件销售与付费的模式。 

数十年来，微软的组织结构与销售策略都基于传统的业务模式。操作系统被安装在个人电脑、
服务器或移动设备上，购买一份产品，支付一笔费用。在线软件  则大相径庭，软件的消费
者与开发人员只需要租借相关资源，通过实时协作完成工作。租用费用非常低廉，例如 Azure
制订的收费标准为：使用一台计算机的处  理器，每小时支付 12 美分；使用 1G 存储空间，
每月支付 15 美分。目前，微软公司内部的许多服务与产品都运行在云计算平台上，例如 Bing
搜索服务和  Xbox Live Gaming 平台。微软的真实目的是希望能够通过成功的真实案例，说服
一些跨国大型企业，例如可口可乐、富士通，让他们相信企业数据放在 Azure 平台上  是可
靠的，值得信赖的。当然，微软并不认为在云计算推行伊始，客户就愿意将企业的所有数据
与产品都运行在 Azure 平台上。客户可以尝试先将一部分不太重  要的业务转到云计算中，
例如邮件服务。万事开头难，只有建立了信任的基础，Azure 才能取得发展。微软的体系架
构服务部门总经理 Arne Josefsberg 在谈及 Azure 发展时，这样说道：“每天都在谈判与协商。”
但他坚信 Azure 平台将成为互联网上最大规模的软件，每年会有海量的  数据运行在该平台
之上。 

带给云计算的最大挑战是法律与安全问题。例如公司的财务数据与邮件等敏感内容，如果交
由第三方进行托管，那么值得信赖吗？如果存在非法获取的问题，  在法律上又应该如何防
范？很多法律专家和政府官员对此深表疑虑。此外，数据还可能存在被破坏或丢失的风险。
例如，微软就曾经出现过丢失至少上百万人移动电  话数据的事件（并非是在 Azure 平台上，
之后公司宣布几乎所有的数据已被恢复）。最近，Google 的 Gmail 也多次出现服务中断的情
况。不过，微软  宣称 Azure 平台会比当前公司的软件更加安全，因为它能够察觉来自中央

114 
 
  

位置的攻击，及时发现系统的补丁漏洞。 

云计算的前景究竟如何呢？IDC 的分析师 Michelle Bailey 持保留态度。她认为：“现在还看不

出将大多数业务移植到云中的可能。在数年时间，云计算还无法体现其真正价值。”她指出，
云计算的商业价值可  能还需要经历 10 年时间，而在法律制度相对宽松的发达国家，这个时
间会相对短些。不过，微软对此云计算却表现得信心十足。微软副总裁张亚勤博士坚信未来
计  算在“云‐端”。他认为，“将来的 5 到 10 年，会有更多新兴国家的用户受益于互联网时代，
受益于“PC+”，受益于“云‐端”  计算，受益于“软件+服务”的新模式。” 

不管怎样，微软急需Azure平台来挽回它在最近十年来股市上表现的颓势。在互联网刚刚开
始的时候，微软已经错过了一次商机。云计算的大潮已经不可  抵挡，微软自然不愿意错过。
现在，Azure平台已经蓄势待发。日前，占地面积高达 707000 平方英尺，位于芝加哥郊区数
据中心正式投入运营，这是微软耗资最多规模最大的数据中心。而在  2010 年 2 月，Azure
云计算平台也将全面进入商业运营模式，包括Windows Azure、SQL Azure与.NET Service都将
正式面向客户收费。这预示着微软的“软件+服务”模式全面开启，必将掀起新一轮云计算平
台的激烈竞争。 

原文链接：http://www.infoq.com/cn/news/2009/11/microsoft‐azure‐platform 

115 
 
  

      那云，那计算

    微软专家Eric Nelson谈Windows Azure 
受访人 Eric Nelson  采访人Ryan Slobojan 

Eric Nelson在英国微软工作了 12 年了，在此之前他是一位Unix开发人员，使用C和其它第 4
代语言。目前他隶属于微软Partner Group，负责与ISV的合作。他的Blog是
http://blogs.msdn.com/ericnel。 

InfoQ：云计算到底是什么？  

Eric：我接触这方面的工作已经 3、4 年了，主要是与 ISV 一起工作。伴随着 SaS（Software as 

Service)、Salesforce、NetSuite 的出现，人们开始谈论在云中按需运行程序。就是从那时起，
我开始关注这些事情，比如我的计算器  程序，我想让它运行在互联网上的某个地方，确切
地说是在其它某个人的机器上，并将计算结果存储在那里。 
 
虽然云对商业的影响很复杂，但是对我来说，它只是一个简单的东西：在其它其个人的机器
上进行计算和存储。观察各公司如何处理这个潜在变化是很有趣的。如果  你是一个传统的
ISV，那么现在就要面临一些使用云技术的竞争对手，它们会在几分钟内将产品发布到用户
手里。试试我们的云吧，切换到上面，现在就可以。 
 
有一种传统的观念，你需要 2 周的时间来发布产品。但是从纯技术的角度，我希望能有一种
方式让我可以在别人的机器上运行代码并存储结果。某种程度上，这比使  用自己的服务器
和数据中心更有吸引力。3、4 年前，我们花了很多时间来写一些指导文档，来帮助那些使
用 Windows 进行开发的公司理解，如何才能够从云  中获利，但是在 2 年前，我们做了重大
的改变，开始构建云计算服务。 
 
我尝试的第一个云技术是 SQL Server Data Services（SSDS)，那是在 2008 年的 3 月，它可以
将数据存储在云中。这是微软为开发人员开发的服务，相比微软其它已有的云服务——如 
XBox Live、Live Meeting——我更愿意使用 SSDS。这就是我的第一次，后来在同年 10 月，我
们在 PDC 上宣布了 Azure 服务平台。 

InfoQ：能更多谈谈 Azure 么？    

116 
 
  

Eric：Azure 服务平台很庞大，我认为我们在 10 月份（PDC）做的不错，我们探讨了不同的

技术，这些技术来自于不同的产品组。我们尽量消除大家的疑惑，但是  不可避免仍有一些
存在，现在我希望能够消除这些疑惑。Azure 服务平台实际上是一个标志，它让我们能够在
一个地方，将真正对开发人员有用的服务集成在一  起。我们会绘制一个 Azure 服务平台的
边界，在里面你可以单独使用某些服务，也可以将它们结合到一起使用。 
 
如果你看一下 Azure 服务平台的示意图，你会发现一个叫 Windows Azure 的东西，它和 Azure
服务平台不是一回事。我们喜欢将云称为 Azure 操作系统，因为它是构建在 Windows Server
技术上的，而且也的确使用了 Windows Server。作为一个开发人员，如果我想在基于 Windows 
Azure 的云中运行某些代码，它就会施展魔法让程序具有高度可用性、高度可扩展性、保存
我的数据并可以让我用多种方式访问数据。 
 
它会为我做所有的事，帮我记录日志、提供跟踪信息、让我控制验证和授权。这些都是与操
作系统打交道的事，它让我无须考虑我的程序实际上是运行在多个  Windows Server 节点上
的，它包装了 Windows Server。Windows Azure 让我能够在云中构建 ASP.NET 程序，不管是
传统的 web forms 还是 MVC。 
 
我可以简单的将已经构建好的 ASP.NET 程序放在里面，它就可以工作的很好。数据存储方面
也很有意思，如果我构建一个传统的程序，我需要使用 SQL Server、Oracle 或者 DB2，我需
要和关系数据库打交道，我需要用 ADO.NET 来实现。当我说“我想要它运行在 Windows Azure
中”时，我会使用 Windows Azure Storage。它不是关系型的，甚至完全不同。它是 RESTful
的，所以我会进入 HTTP 和 get/post/put/delete 的世界。 
 
我需要做一些大的改变来让程序的数据访问代码可以访问关系型数据，然后重写它来支持
Windows Azure Storage。这不是无法解决的问题，有很多成功的例子显示，可以将已有的使
用关系数据库的 ASP.NET 程序移植到非关系型数据存储中，但是仍然有很  多工作要做。你
的程序越复杂，越需要关系型数据存储。 
 
Windows Azure 是我们的操作系统，并且有它自己的存储方式，但是后来我们又有了 SQL Data 
Services。一开始它叫 SQL Server Data Services，后来在 10 月份我们给它改了名，以显示它
支持关系型数据存储。我们用了 1 年左右的时间发布了 CTP 版本，并得到了非常多的反馈。
很多人  喜欢自己做所有的东西，他们会说“我喜欢这样，我知道它是如何扩展的，我知道它
是半关系型的，但只要能让我添加一些特性就足够了”。 
 
但是，如果你是一个公司或者有一个依赖于关系数据库的应用时，你看到 SQL Data Services

117 
 
  

时会说“我希望它能在关系数据上做的更多，我希望它能够做关系数据库管理系统能做的
事”。就在上周，我们发布了修改后的 SQL Data Services，现在它是云中的一个完全关系型数
据引擎。我们会在 SQL Data Services 中使用 Transact SQL，就是 SQL Server 中的 Transact SQL，
你可以使用存储过程、触发器、视图，但是有些功能不能使用。虽然你不能做所有在 SQL Server
上能做的事，但是可以做大部分。 
 
这意味着，作为一个开发人员，我可以使用 Windows Azure 来作为我执行代码的地方，
ASP.NET、VB.NET、C#等等。对于存储，我可以使用 Windows Azure Storage 和 SQL Data Services，
具体使用哪一个取决于我要做什么。除了这些还有很多其它的服务，比如.NET Services、Live 
Services，我们还可以使用 Dynamics 和 SharePoint 相关的服务。对于我和我们已经完成的工
作来说，这就是“在云中计算，在云中存  储”，这就是 Windows Azure 和 SQL Data Services。 

InfoQ：Azure 和市场上其它云服务相比有什么不同，例如 Amazon？    

Eric：我们走了完全不同的路线。Amazon 非常成功，很多公司和个人可以使用它做一些仅靠
自己难以实现的事，你需要有很多钱才能做到同样的事。但我们用了完全  不同的方式。
Amazon S3 是最强大的存储方案，但也只是用一个 Key 和一点元数据来标示存储的对象。  “我
只是想要存储些东西，我有一个 key 可以让我将他们取回来，
并且还有一点点元数据来描述”，
这与关系（数据库）差的还很远。 
 
虽然我们的存储方案——Windows Azure Storage——也是基于这种方式的。但是 Windows 
Azure Storage 内建支持队列、大对象和表。在 Windows Azure Storage 中你可以说“我想要一
个表，表里有一些列，我想将数据存在里面”，然后你就可以在里面做查询。我们不用 SQL
语法，但是你可以用它来查询。  如果你要存储大对象，你可以存储非常大的对象。如果你
想存储 50GB 的对象，你可以直接存到里面，也可以存成多个块，但是最终你会有 50GB。
我们还有队  列，我们可以很容易将东西放进去，然后在另一端将它作为列表做些工作，这
也是 Windows Azure 的一部分。 
 
即使是在基础层面，它也比 Amazon S3 提供了更多的功能。SQL Data Services 提供了完全的
关系模型。有些人会说 Amazon SimpleDB 也支持一些关系模型。但是它有很多限制，存储的
只能是字符串，当你想要将存储的数据取回来时，它会返回 250 个块，而且只有 250 个。我 
们没有这些限制，Windows Azure Storage 有数据类型，虽然没有你希望的那么多，但是 SQL 
Data Services 确实有很多类型。 
 
我们支持任何 SQL Server 拥有的类型，除了自定义类型，也就是 CLR 类型。所以我们没有

118 
 
  

CLR 集成。在数据存储层，我们有很多东西可以让开发人员使用起来更简单，“我  想创建非

常复杂的程序，而且有非常多的数据”。在计算部分，如果我想在云中构造一个计算器，
Amazon 有一个简单有效的模型，“我们提供给你一个虚拟  机”然后“这就是你的虚拟机，在
虚拟机上你可以跑一般的程序，做什么都行。” 
 
但这只是一个或一些虚拟机。我们在 Windows Server 上还做了大量的抽象。Azure 团队开发
了 Hyper‐V，因为他们知道你想要用虚拟化技术做什么，从开发人员的角度使用它不会让你
感觉是在  部署一个虚拟机。我可以构建程序然后说“这就是我的 web 程序”，我会创建一个
web 项目，写些代码，做 XML 配置然后说“可以帮我运行 25 个实例  么？”，Azure 就会分配
一些虚拟机来做这件事。 
 
但是从开发人员的角度来看，这就像是部署在一个平台上，而不是管理 25 个虚拟机或者是
用某些工具。这就像是云中运行着一个操作系统，为我们简化了很多工  作。我们已经知道
了人们想要做什么，并且在实现上有了很多经验，我们只是试图让这一切尽量简单，能够帮
助开发人员将程序尽快运行起来。 
 
另一方面，这与在自己的计算机上写一个 ASP.NET 程序是不同的方式。我们可以说大多数是
相同的，但不是完全相同。你无法写那些依赖文件系统的东西，如  果你需要保存数据，应
该用 Azure storage 或者是 SQL Data Services，我们一直在写一个指导文档来说明这些。 

观看完整采访：http://www.infoq.com/cn/interviews/VS2010‐Eric‐Nelson‐cn 

119 
 
  

      那云，那计算

    谷歌工程师谷雪梅谈云计算 
受访人 谷雪梅  采访人  霍泰稳 

谷雪梅，谷歌资深工程师，毕业于卡内基梅隆大学，六年前加入谷歌，负责谷歌中国基础架
构方面的工作。 

InfoQ：云计算发展它的背后的  主要助推因素是什么样子？或者说云计算现在对大家有什么
好处？比如说推广云计算的厂商，包括 Google，包括微软，包括 IBM，还有使用云计算的
这些终端用户，包括那些想在云计算平台上工作的架构师。   

谷雪梅：因为我本人也是工程师，我觉得还是给大家举一个工程方面的例子，我不知道你做
过没做过网站？你当时做网站有没有感觉说，你可能需要什么软件，我得把这个网站搭起来，
然后我打电话注册一个域名，然后再出去找这个服务器，然后还得找数据中心，然后可  能
自己还得肩负点系统，叫什么 System Admin，网管员的工作，做个网站就得这样吗。再做复
杂一点的，比如说你做一个电子商务的网站，支付了，然后所有的这些，比如像 Shopping Cart，
什么 Transaction，很多很多东西都要做。那么其实在云计算的时候，我给大家举个很简单的
例子，Google 有一个云上面的应用叫做  App Engine，App Engine 的概念是很简单，他就是说
好吧，你有什么样的自己的想法，甚至你是个小公司，你把你自己的想法用 Google 给你提
供的所有的工具，很容易的就形成你的网站，形成你的这个商业应用，你不用管，你不用再
去操心这个网管，你不用再去操心你需要多少的 CPU，多少的内存，多少的这个 Storage，  你
甚至不用再操心你去哪里租数据中心，你这些东西所有都不用管，你需要做得事情就是把你
的想法想出来，然后用一些简单的前台工具把它实现出来，所有这个底  层的东西，全让
Google 给你实现。这个事实上我觉得是云计算一个非常典型的应用，把大家从这个很多很
多技术上的这个很无聊的很乏味的很底层一些东西解  放出来，让你把自己的精力主要集中
在自己的这个想法的开发上面。 

InfoQ：下面我们看几个目前比较流行的一些概念和云计算之间的一个比较，比如说大规模
计算，分布式存储，还有什么 SaaS，就是软件及服务，包括虚拟化，那么你能简单帮我  们
解释一下这些概念之间的关系或区别吗？    

120 
 
  

谷雪梅：我觉得这些概念其实都是有联系的，比如说咱们先把云计算到一边，咱们先讲讲大
规模，比如大规模计算各分布式存储。那么大规模计算，这个是这样，它强调的重  点是在
多个计算机之间的协作。这个计算机的协作，比如说其实你看一个非常大的数据库，它实际
上是大规模计算的，它可能假如说要给你查一条东西的话，它要从  很多很多地方来查，查
完了最后把一个结果返回给用户。但是比如说大规模计算和分布式存储，它们两个就是一个
很配合的关系，因为首先大规模的计算经常会需要  很多很多的数据。那么这些数据，毫无
疑问是不可能存在一台服务器上的，或者如果你存在一台服务器那会很贵的，你只能把它分
布式存储，然后你通过分布式的存  储，你必须要设计各种的算法，然后把 Data，把这个数
据从不同地方拿过来进行什么样的计算，你要考虑到它的 IO，考虑到它在 Internet 上面的传 
输，考虑很多这种技术的问题，然后你前面实现了这个大规模计算。然后咱们再比如说，像
软件及服务这种也不过是说，我们把很多的就是原来放在单独计算机上很  独立的一些东西，
然后放到网上去，或者放到，你不用关心它是在那里实现的，你只关心它的结果，所以这些
你看，这些东西呢，我认为都是关联的，它们有几个重  点一定要有的，存储，大规模的存
储，这几乎是没有疑问，是一定要的，另外一个是需要很大的，我们叫 CPU Power，就是很
大的计算能力，因为你需要太多的数据，需要去把它算出来，那么算的结果，究竟是这个，
是变成服务的软件呢？还是说你有个想新的想法，是  一个互联网上的应用呢？还是什么东
西都没有关系，这个商务的应用实际上都是类似的，只是说这个商务应用一定会使用存储计
算，然后最后服务，就是前台的服  务。那么云计算，我认为是说把这些概念都集中在一起，
所以云计算，它更强调的就是说，我觉得它比较像软件即服务，这个服务在那里，你不用关
心，你需要关心  的只是它的一个结果，所以它更多的是一个应用层面的一个概念。 

InfoQ：那虚拟化在里边办什么角色？    

谷雪梅：虚拟化，我想是这样的，虚拟化当然是一定跟他前面这些概念是相关的。然后比如
像云计算，它所谓的虚拟化是说，所有的后台这些计算，存储什么的，都和你现在  的，你
自己面前的这个计算机事实上是脱离的，你不用管他在哪，他可能是在美国，还可能是在英
国，或者是在印度尼西亚，这些对你来讲已经没有关系了，你所需  要关心的只是你面前的
一个结果，所以我想后面对这些东西的话，他就比较虚拟，而不是你现实看到很多很多服务
器在你面前。 

InfoQ：那么另外一个说法就是说，有人将云计算比喻成互联网为中心的软件，你是如何理
解的？    

谷雪梅：我非常赞同，我觉得其实这对云计算是一个很好的，尤其对于那种不太了解云计算
的人，是一个非常好的说法，能让他很明白的理解什么是云计算。然后你看这里  边，其实

121 
 
  

我想强调一个重点是说，它是以互联网为中心的，这点为什么很重要呢？原来，假如说有些
我们的的研究人员，他有想法，他有很好的想法，比如说翻译，  那么翻译事实上，他那些
算法几乎已经定型了，他所需要的是什么呢？需要大量的就是说我们叫做 Training Data，就
是训练数据，这个数据量越大，结果就越准，现在如果这个研究人员，终于可以得到整个互
联网上所有的内容的时候，那么你想想看，他的训练的数据  就是整个互联网，那么其实这
个对他的结果就非常有好处，所以我认为互联网时代，比如他的翻译就是革命性的，它是云
计算一个非常好的应用。而且你可以从互联  网上，看到有很多很多新鲜的想法出来，这个
我们不用花时间再讲了，但是说以互联网为中心的，我非常赞同，就是人类从来没有那么一
个时候，可以让你在很简单  的，你在一个小小的计算机前面，可以看到全世界所有的内容，
从来没有过。 

InfoQ：非常好，那么目前 Google，刚才你也提到了，他现在已经有了成熟的这么一个云计
算的应用，我想问一下它的商务前景是什么样的？    

谷雪梅：Google 这个公司挺有意思的，从来不收大家钱，而且不收终端用户钱，不收。如
果你要是说几个产品，说我这个产品的商务模式是，我要收每个用户的钱，那  这个公司，
你是不会把它发布出去的，所以它的商务前景我想是在那里呢？首先有可能，我只说有可能，
可以把广告放上去，你今天有一个自己的新鲜的商务想法，  你可以用 Google 的云计算的技
术，在网上有了自己的这么一个家，我们不收你钱，但是你可能需要很多很多的资源，那这
个时候这个怎么办？我们也许可以把  广告放在旁边，也不影响你整个商业运作，但是也许
你会把一些广告给用户看，当然这是我个人的猜测，不代表公司。所以我认为这个商务前景，
Google 有自  己的一个理念，就是你把一个东西做得非常好，然后其他的就跟着来了，盈利
就跟着来了，现在所以我想还是，Google 还是在摸索阶段，怎么把自己在公司内  部非常成
熟，然后做得很好的，做得很快，规模很大，然后也很便宜，这么好的一个云计算的系统推
给大家，其实公司也在摸索，只是这个前景也很光明，比如  App Engine  在美国，他一发布
出来，好多好多人想去用，然后在网上设一个网站，很快都用满了，Google 只给那么多资
源，当然主要是想测试一下吗。然后现在大家有好  多在等，然后 Google 就是往上加，但是
想来用的人越来越多，所以大家只好都在等，所以那么现在怎么解决这个问题？也就是说它
的商务的模式怎么样？其实还是在摸索。 

InfoQ：那么如果说一个架构师要在 Google 的云计算平台，就是刚才提到这个 App Engine

上面做应用的话，他需要做那些准备？或者另外注意哪些事项？    

谷雪梅：我还是先讲讲做那些准备，注意事项，我想你在开发过程中可能总会遇到各种各样
的问题，这个没有关系，可以跟其他用 App Engine 大家一起交流就好了。准备现在是这样

122 
 
  

子，App Engine 的 API 提供了，我个人认为还不算太完备，他现在只有 Python 开放的 API，

他的 Java 的 API 还没有推出，但是很快会推出了，所以的  话，像一般架构，就说如果咱们
是写程序，程序员，工程师，可能更多的在语言方面，在 API 方面需要多注意一些，那么架
构的话，我觉得更多的是一种它的概念  的转换，就他原来可能是习惯是，他是软件开发的
这套思路，你现在把它变过来，你要变成它是一个 Internet Service，它是一个互联网的服务，
这个概念一定要转过来，如果这个概念转不过来的话，我觉得你会浪费 App Engine 资源。 

特别注意的，想想看，比如说它对数据库什么的，这个是不太好，因为 Google 不是做数据

库起家的，我们是做 File System 文件系统，都是拿这些东西起家的，所以的话，我觉得还
是刚才我讲的，就说一定要从概念上转变过来，不要再拿传统的软件开发的模式再像  Google
的 App Engine，这样不行的。 

InfoQ：OK，那么另外一个问题就是什么样的企业，或者组织是适合用云计算的，那么什么
样的企业或组织就是还不方便用云计算，然  后另外一个就是云计算的不足之处，你认为它
在哪里？    

谷雪梅：就像我刚才讲得，我还是想回到刚才那个电网的例子，如果有那么一天云计算真的
像电网一样方便了，你想没有企业不用电吧？当然云计算如果到了那一天的话，我  想没有
企业不适合用云计算，现在的话，这个云计算我个人认为，他基本上还是比较的，像先锋性
质的这样一个实验性的东西，所以这个如果有些企业，他可以，比  如说他想涵盖很大很大
的规模，或者比如很多地方，他现在架构是那种比较分布式的，这个他可能跟云计算契合会
比较方便一点，有些假如说传统的做财务软件的企业，然后你是开发的思路都是，像我刚才
讲的是传统的思路，那么你转到互联网的服务上面来，可能会花一段段时间，但我觉得就是
最终还是，大家可能都会往这个  方向转，因为实在是，每个企业对于自己维护自己底下一
大套的 IT 的东西是没有必要的，把这些都扔给云计算，都扔给那些服务器，然后减少自己
的这些费用，然  后把更多的精力投入到自己这种企业的商务开发上面会更好一些，我现在
是这么认为。就是互联网企业用云计算可能会更适合一些，跟互联网相关的 Video，网  上
的视频，或者网上很多很多的像这种，我们叫 Content Distribution，我觉得这个都比较适合。 

InfoQ：那是不是说那些比较关键性的应用？比如金融，包括一些购物还不太适合？ 

谷雪梅：我觉得你这个问题很有技巧，这个也不能说不适合了，像 App Engine 上面现在已

经事实上有不少像这种电子商务的网站，已经在上面了，我只是想说这个，有人说 Google
还是做搜索引擎起家的，可能在这个比如说  像金融的互联网安全，他是不是有特别的需要，
在这个方面，可能我们关注的力度还不够，更多的关注尤其是安全方面，更多的是说搜索这
个引擎所面临的问题，那  么的确你说现在是不是有用户的数据都非常非常的那种敏感的，

123 
 
  

就可以使用云计算，这个的确是个问题。

观看完整采访：http://www.infoq.com/cn/interviews/guxuemei‐cloudcomputing 

124 
 
  

      那云，那计算

    云计算的虚拟研讨会 
作者  Abel Avram  译者  马国耀  

云计算承诺提供几乎无限制的随需资源访问，人们一直追寻的业务延展性以及通过按需购买
的方式降低成本。在这个虚拟研讨会中，InfoQ 希望从这些顶  尖的专家们那里了解到云计算
带来的好处以及使用时有何限制，私有云和公共云哪一个更好，是否需要云互操作，提供基
础设施和提供平台的区别，客户如何加强规  范遵守等等。 

回答我们问题的专家们包括： 

Jerry Cuomo，IBM副总裁，WebSphere产品线CTO 

David Linthicum，Blue Mountain Labs的创始人 

Geva Perry，GigaSpaces Technologies云计算总经理 

Jamin Spitzer，微软 Developer & Partner Evangelism Group 部总裁 

云计算给企业带来的好处是什么？ 

David：基于旧分时模型，云计算是比传统方式更加追求共享、经济和高效的一种新方法。
通过规模经济，企业将  可以使用原先他们根本负担不起的资源，包括分析服务，企业应用
以及在按时按需购买的基础设施服务等。此外，网络方面的好处是和使用 Web 绑定的资源
的能  力，比如社区网络，它比在本地集成资源的方式要容易得多。它是一种旧的计算方式
在新技术市场上的新表现，并且，它使得企业能够更经济地重建计算基础设施以  及企业架
构。 

Geva：云计算从两个方面推动企业进步。从战术上，提高效率，节省成本。从战略上，助
力开发人员和企业用户快  速和高效创新。 

125 
 
  

1）提高效率和节省成本：云计算利用规模经济的优势，通过让很多用户共享相同的基础设
施，云的提供者可以获得更高的资源利用率，而原来只能在特殊的  专属环境下才能达到。
另外，随着越来越多的公司将他们的 IT 提供成“云源”，云提供者可以更专业，更高效地运
行大规模数据中心，而他们客户们只需要关注自  己的核心业务。 

2）快速创新：云计算加速了个人和企业的创新能力，缩短了产品和服务进入市场的时间周
期。之所以云可以做到这点，是因为它节省了大量的 IT 预投资，  通过流水线或自动流程（比
如提供服务器，从测试环境到生产环境的移植等服务），向开发人员和企业用户提供直接的，
自助的 IT 资源访问，从而提高了他们的生  产力。 

Jamin：下一代计算潮流——被称之为“便宜革命”的集中式计算资源和大量高性能设备带来的
边界能力的结合  ——让用户和企业便利地选择远程计算资源和个性化设备体验。云为用户，
企业和开发者带来这样的体验机会：可以利用更高效、更广阔的技术基础设施平台来创建  和
访问应用，从而增加现有投资和传统的部署选项（比如，企业数据中心，个人电脑等）。我
们应该把云看成是现有计算平台的扩展。最终，一组良好定义的准则将  会出现，帮助企业
理解在什么时间，如何对长期持续的投资作出重新调整。 

Jerry：我们实实在在地看到云计算模型让企业更智慧地工作。在当前金融危机的影响下，我
们仍然看到完美的风  暴式发生的事件，通过使用先进的技术（例如虚拟化）对齐业务模型
（如 pay per sip）和标准/架构（如 Web 和 SOA），从而获得相当可观的计算输出。因此，它
对任何人都有吸引力。企业不需要于先付费，并且/或者，将一部分 IT 运  维外包出去，如
此他们可以将更多宝贵的时间集中的他们的核心业务上。IT 可以将精力集中于基于应用程序
的需求来扩展基础设施（过去系统使用率总体低下的日  子将离我们远去）。软件开发人员不
再等待 IT 提供系统，他们可以（在云中）自助获取合适的软件。 

当公司决定采用云计算架构时，需要牢记哪些实施上的限制？ 

Jerry：当你思考云架构时，我们建议使用面向服务的方法。考虑到一个成功的面向服务的架
构是从一些业务目标  开始的，最好你也从业务目标开始。降低人力和能耗，加速产品到价
值的转变是一些关键的业务指标。设定一个很低的门槛，让一些企业（或企业的部门）有使
用的  机会采用云，而在传统的模型中，这些企业可能根本没有机会。最近我正在写一篇关
于我们的云模型的博文，在里面我还写到了如何将云分解成一组服务层，每一层都为企业带
来特定的价值。服务的层级包括基础设施层，平台层和应用服务层（当然还有其他层，通常
我们谈得最多的是这三层）。为合适的任务选择正确的云服务，也不要担心创建自己的云。
并非所有云都一样——这就出现了关于私有云和公共云（或超云）的差别的问题。我们很多

126 
 
  

客户关心安全以及应用程序和数据的隔离——因此我们的多数客户是在防火墙之后开始（私
有）云的。 

David：性能和安全首当其冲。在我们将国家机密放入云中之前，云提供者还有一段路要走，
但是基于高速发展，  我认为“足够好”的安全系统会出现的。性能是另一个问题，主要由于
网络和系统的延时，但这个问题因云提供者的不同可能有很大差别。还有一个限制是互操作 
性，后面我们会谈到。企业应该要有这样的认识：不是所有的应用程序都适合云计算。 

Geva：有好几个问题需要仔细考虑，比如安全和可移植性，但是在这里我要强调的是可扩
展性。在一个专属的静态  的环境下的一些假设和最佳实践在云环境里可能不会想当然成立
了。或者，即使能用，他们也不会让你能享受到如 Amazon EC2 带来的云的优势。 

比如，我们说在云的世界里人们可以按需扩展或收缩资源，并且只为使用的资源买单。这固
然很好，但是很多应用程序的架构本身并不允许方便地实现在需要  时资源时扩展到多个服
务器，而不需要时收缩——并且要在几分钟内完成。好在越来越多最佳实践和产品在解决这
方面的问题，我一直在和几个公司合作并评估解决  这个问题的几种可选方案。 

再比如，HighScalability.com网站报道了我的朋友们在Rocketier如何在 10 台商业服务器上搭
建一个系统，这个系统可以每天处理10 亿条事件。这个系统还可以根据需要随时扩展和收
缩，因此可以利用到按使用付费系统（如EC2）的优势。这  个系统通过使用一个分块的内存
数据网格作为记录系统，这种做法与我们大多熟悉的集中式数据库系统不同。 

Jamin：在应用程序层，若采用云，针对每一个应用需要考虑一组问题：在给定负载下部署
和运行的费用？如何实  现针对应用程序和数据管理安全和私有需求？你需要哪种 SLA？可
定制化和可配置化程度的需求? 

企业关心的重点不仅仅是本公司和其员工的需求，他们越来越多地关心来自他们的消费者以
及合作伙伴的技术需求。通过提供跨企业和网络的集成功能，并且  提供多设备来访问能力，
企业可以获得更高生产力，更忠诚的客户以及更高效的供应链。因为云带来的部署可选性，
企业可以灵活的选择将应用部署在本地还是在云  中（或者二者都有），从而可以重新思考如
何通过灵活性、易用性、安全性以及丰富性提高商业利益。这种方法把 IT 人员解放出来，
他们将首要考虑功能性价值，  其次是如何部署这些功能的相关技术。企业应该考虑那些既
能推进现有资产的投资又能创建一组全新业务的应用场景。 

您如何看待提供商锁定以及云平台之间的互操作性？ 

Jamin：云之间的互操作性只是话题的一部分。拥有多年 IT 投资的公司需要在现有环境和云

127 
 
  

环境之间架起一座坚  实而灵活的桥梁，从而使得本地部署的应用程序和部署在云中的新应
用程序能够顺利交互，既推动业务发展，又不需要新增数据集成方面的投资。很多情况下，
多数  公司关于云互操作性的讨论是对过去本地的互操作性和可移植性的扩展。 

在云中，互操作性非常重要。云平台中规定互操作性术语的标准很快会出现，它们使得云‐
云，云‐企业数据中心之间的互操作成为可能。 

Microsoft的Azure服务平台是一个通过Web寻址、SOAP、XML以及REST等标准定义开放的、
灵活的平台；这种做法的目地就是要  确保可扩展的编程模型，使单个的服务可以被运行在
微软的和非微软的产品族的应用程序和基础设施所用。详细信息参见这里。 

Jerry：我祝福任何尝试把锁定策略拿到台面上的提供商。在当前时代，客户要开放的软件和
系统——以及由它们  带来的可选性和互操作性。现在是一些新生标准日趋成熟的  “成型
期”，然而，（提供商们）共同的担心已经汇聚。以云基础设置为例，IBM曾经和工业界联合
致力于为客户带来一个基于Java的中间件世界，现在我们  正努力为我们的客户带来相同的
利益。“写一次，到处执行的”仍然是个非常诱人的想法。和Java一样，我们正努力让我们的
客户将基础设施虚拟化一次，即可  在任何地方使用（云和/或Hyper‐Visor）。目前有好几个
标准正在为客户带来这个级别的灵活性而努力着，Open Virtual Format （OVF）就是重要的
标准之一。实际上，在IMPACT 2009大会上，我们发布了一个WebSphere Application Server 二
进制的可选购买方案，包括预安装的，预配置的（包括操作系统），虚拟镜像（使用OVF标
准）等。一旦  客户购买（或升级）到某方案，它就不需要重新安装WebSphere，他只需要
将介质拷贝到OVF感知的hyper‐visor，然后服务自动开启并运  行。 

David：这是一个大问题，因为云提供者已经创建好他们的平台，这些平台大多基于私有架
构、API、以及语言  等。因此，一旦你的应用程序是基于某个云平台上创建的，你就很难将
其移植到本地或者另一个云平台。不过一些进行中的项目致力于形成支持可移植性的标准，
但  是我们离云计算空间的一组准业界标准的距离还有点远。 

Geva：我写了一篇博文，名为谨慎对待尚未成熟的（云标准的）阐述，在这篇博文中我讨
论了这个话题。如我所写，最终获得云操作的互操作性，甚至正式标准，是广泛采用云计算
的关键  所在。然而目前还为时尚早，我们需要小心谨慎，而不是随大流跟风。现在我们甚
至对标准所需要解决的问题都没有足够的认识。 

不过，一些有意思的发展是可以跟踪的，比如GoGrid  已经开放API，并且正在努力让其他供
应商采纳这些API。有一个名为EUCALYPTUS开源项目已经实现了Amazon EC2 和S3 的一些API。
其他如Enomaly等供应商也提供开源的云软件，并开放了云计算互操作性论坛。随着时间的

128 
 
  

推移，市场将会做出投票，准业界标准将会出现，正式标准也终将形成。 

为什么有些人选择私有云而不是公共云？ 

Geva：一些大的公司或企业已经为 IT 基础设施投入了大量资金，其中很多公司在为特定业
务或企业的需求建设高  效数据总线方面已经拥有相当深入的技术和经验。为什么 Amazon
决定进入 IaaS（基础设施即服务）的业务呢？因为他们已经意识到自己在运行极其高效的 
Web 基础设施方面做得很好。当然，也有很多公司拥有这样的技术（并且是与他们特定的
业务和工业相关的技术）。他们对规范遵守可能还存在一些疑虑（如医疗  行业的 HIPPA 约
束），这种疑虑阻碍了他们使用公共云，或者是因为他们的 SLA 太苛刻以至于其他云提供者
目前无法支持。 

也许，更加有意义的问题是私有云与普通的数据中心之间的区别。首先要记住，“私有云”
并非只能在公司本地数据中心上运行。在公共环境下创建虚拟私有  云的技术已存在，如
CohesiveFT的VPN‐Cubed就是一款应用该技术的好产品。 

对于某些大公司，即使运行一个私有的，内部的（本地的）云也是有意义的。这些企业可以
采用云的基本原理，如多租户架构、虚拟化、自动化和自助服务  等，从而可以获得三个方
面的好处：1）高效的硬件利用率  2）高效的 IT 运维  3）快速创新周期。 

Jerry：在IBM，很多客户都对私有云的前景感到振奋。事实上，我们的云策略始于“人工降
雨”的思想。当我向客户传递“在企业内部‘播种’云”这种思想的时候，我经常使用这个词，这
个思想公共云服务的场合也是有意义的。我们的客户  正在构建私有云，而我们的工作重点
是辅助他们创建、使其自动化，优化以及管理那些云。基于两个方面的考虑，很多客户选择
私有云的路线，安全（应用程序和数  据的安全）是一方面，另一方面是他们已经在基础设
施建设上投入了很多资金和人力，他们希望能够将这部分投资利用起来。我们看到客户创建
私有云并在云上运行  很多饶有趣味的任务。用于测试和开发的云越来越流行。事实上，我
们现在正使用一个用于测试的私有云（利用我们最近引入的技术WebSphere Cloudburst）来
测试我们的WebSphere应用服务器（WAS）。这种做法让我们共享资源，简单来说是（基于
安全和可复用的模式）创  建了一个测试环境，减少了日常的安装和卸载环境的运维工作。 

Jamin：如果私有还是公共的问题指得是本地用户管理的还是提供商托管的的问题的话，那
么上述关于实施限制的  讨论已经覆盖了这方面的内容。这个问题主要是关于控制的，企业
在实施或客户化他们的基础设施、平台和应用程序时，仍然需要权衡他们在过去考虑的那些
控制因  素。 

129 
 
  

David：安全、性能和控制是关键问题。所以，你可以在防火墙后面架设可共享的基础设施，
享受云计算带来的高  效的资源共享，按需获取资源等好处。这将是云计算最大的成长空间，
因为，至少在最初，很多公司并不希望放弃对他们的核心 IT 基础设施的控制权。 

有的云提供商提供基础设施（Amazon），有的提供平台（Google），应用架构师通

常如何选择？ 

David：依赖于业级架构和应用程序的需要。Amazon 允许你通过资源的类别（存储，数据库
等）来消费，而  Google 则提供全套的应用程序开发和部署平台。因此，首先你要理解你的
需求是什么，定义需要解决的业务问题，然后再选择合适的解决方案——本地部署还  是由
云提供，或者取二者兼有。 

Geva：在大多数情况下，平台即服务(PaaS)的提供者会很大程度上限制使用场景和技术栈。
这样的限制带来  的好处是，开发和运行时管理变得非常简单。如果使用场景和技术栈的限
制正好满足你的应用程序需求，那么就是一个好的匹配。需要指明的是这些平台区别也很 
大。因为Google指定Python  作为编程语言，以及特定的数据模型以及多线程技术等，所以
Google App Engine上应用程序可能不需很  大改动就可以轻松地移植到其他平台。Force.com
就是一个完全私有化的  PaaS，它甚至包含私有的编程语言Apax。你的应用程序如果不重写，
那么几乎不可能在别处运行。还有一种如Heroku这样的PaaS，尽管它需要你按照特定的方式
为应用程序写一些元素，  才能使之运行在Heroku的平台上，但这些做法都是“最佳实践”，
而且你的程序不会绑死在Heroku上。 

Amazon Web服务和GoGrid这样的IaaS（基设即服务）提供供原始IT资源，如计算能力、内存
和存储。这种方式更灵活，但需要更多的管理工作；它不提供高  层服务如开箱即用可扩张
性（包括自动扩展）和容错机制。然而，随着时间的推移，IaaS提供者开始提供附加的上层
服务，基础设施和平台服务之间的界限模糊  了。此外，一些第三方提供者如RightScale  和
GigaSpaces也致力于缩减IaaS和PaaS之间的差别。 

Jerry：基础设施服务的强项是允许用户在云中运行他们现有的应用程序和中间件。大多数基
础设施提供商提供通  用的基础设施支持，包括操作系统以及基本中间件栈。用户提供其他
的——应用程序和应用运行的“技术细节”（扩展，安全，执行）。比如，在  WebSphere环境
里，基于 10 多年在WebSphere部署方面支持客户的经验，
我们的基础设施服务已吸收这些“技
术细节”。我们引入Patterns的概念，模式是一种虚拟的  部署方案，它将安全、高可用性以
及性能等方面的最佳实践都融入在一起。此外，我们已经在公共云中提供我们的软件镜像，

130 
 
  

像Amazon一样，为我们的用户提供一个非常低的门槛，让他们使用IBM  的中间件产品（包
括开发，测试和其他）。 

通过平台服务——巧妙划分的基础设施——你需要专注的是应用程序以及服务。很多云平台
都具备一些特定的编程模型（这又回到了绑定的问题上去  了:‐)），这些编程模型让应用程序
更具可预见性，因此，平台可以更加自动地进行扩展，安全以及执行。对于新建的应用程序
来说，这是很好的。然而在移植现  有的应用程序时，通常需要开发人员重写应用。这些平
台经常以公共云的方式提供——因此，伴随着应用程序的大改——使得它（平台）对于某些
公司来很具吸引  力，而对另外一些公司却不然。显然，对于Java提供商来说是一个明显的
机会，通过为云创建基于Java的支持，给用户带来云平台之间的可移植性（包括公  共云和
私有云）。 
我认为还有一些混合模型也是相当有趣的。比如，在 2009 IMPACT大会上，我们介绍了BPM 
BlueWorks，这是一个为业务领导提供的托管服务。BlueWorks应用程序为业务专家提供一个
门户，让他们学习，分享和相互协作来创  建业务战略和流程。一旦业务资产被创建出来，
它可以导出到本地的云基础设施（可能以一种基于标准的BPMN 2.0文档的形式）。这样就产
生  了一种“在公共云中开发资产，在私有基础设施服务中运行”的混合模型。对于这些混合
模型来说，关键是要在公共云和私有云之间搭建一个安全的通道。稍后对此作更多介绍。 

Jamin：对于那些要移植现有应用的架构师来说，考虑到要对现有应用程序做必要的修改，
他们可能认为向云移植  的好处有限。在某些情况下，优势立刻就能体现，用户很快就可以
感受到将云实例外包出去带来的好处。然而，还有些用户已经抱怨：与原有的私有数据中心
相比，  在虚拟化的云中维护遗留系统的开销更大。 

对于一些架构师，他们可能正在设计全新的应用场景，或者已经预见到可以利用云平台的优
势来建立新应用。在一个平面型的云平台如微软的 Windos Azure 上写应用或移植应用比在
传统的基于实例的基础设上做要更高效。然而，没有一个通用公式来计算最佳的效果，架构
师们要分析各种备选方案，基于需求  和现有应用的架构，现有的开发技能以及其他因素综
合作出正确的决定。 

客户如何加强规范遵守？ 

Jamin：为加强规范遵守，客户必须和云提供者一起合作，共同来确保当工作被外包时，所
有的数据和私有规则  （包括法律的和私有协议）都可以得到保护和加强。与云提供者之间
的协议不仅要包括可靠性 SLA，还要包括遵守性 SLA，这样才能确保客户的数据在任何地方 
都合法地使用和管理，从而最大限度满足客户需求。 

131 
 
  

David：这里有两个层面：技术和程序。在技术上，要确保创建合适数量的系统管理规则，
包括对核心资源的访  问、审计路径以及管理所需的其他约束。选择一个外部机构来为你审
计，确保所有事务的合法性。在程序上，应保留所有的法律文档以及将整个过程文档化。 

Geva：在某些情况下，在云环境中维护规范遵守和在传统上托管，收集和管理本地数据中
心并无区别。从某些方面  来看，客户完全依赖于云提供者，必须预先明确提供商采取哪些
步骤来确保规范遵守。（例如，Amazon 发布了它的安全实践的白皮书）。一些人已经成为这
方  面的专家，如 PCI 规范的设计者。 

Jerry：云计算的一个非常有意思的话题是将云虚拟化成基础设施，平台和应用服务等三个层
面，从而可插入控制  点。IBM主要在云架构的各个层面为用户提供管理云的使用的能力。
客户利用这个能力获取他们的系统被如何使用的密切信息，用户还可以利用云作为控制点，
来  加强策略和规范的遵守。例如，我们的WebSphere Cloudburst产品可以产生详细的报表，
该报表包括谁在使用云，如何使用等信息。管理员可以使用这些数据生成用于管理和控制的
个性化报表。另外一个  例子，我们看到一些用户使用我们的WebSphere DataPower SOA  设
备和Service Registry来发现服务和（细粒度地）控制对这些服务的访问，在公用云和私有云
中都有看到。DataPower可以为私有云创建公共通道，也可以为公共云提供。一个安全  的网
关可以帮你挡住云的各种威胁，同时提供一个审计双向应用服务通信的控制点。对客户来说，
不论是否有实际的规范遵守的需求，在云周围架设一个双向的  （web）应用程序防火墙也
是一种更加聪明（和安全）的设计方法。 

专家组成员介绍 

Jerry Cuomo：IBM 院士，副总裁和 WebSphere 产品线 CTO，他是 WebSphere 的创始  人之一，

在 IBM 研究院和软件部共工作了 20 年之久。Jerry 是高性能事务系统，中间件设备，和企业
云计算以及 Web2.0 领域的开拓者。 

（Dave）是国际知名的云计算和面向服务的架构（SOA）专家。在他的职业 
David Linthicum：
生涯中，他形成和发展了很多现代分布式计算（包括 EAI，B2B 应用集成和  SOA 等现在广为
使用的技术和方法）背后的理念。最近 10 年，Dave 专注云计算方面的技术和战略，曾与多
位云计算的创始人合作。Dave 的业界经验包括  多家成功软件公司的 CTO 和 CEO，多家财富
500 强公司的高层管理职位。 

Dave 专注云计算的最佳实践和实际业务价值，包括技术在企业需求环境中的实际价值。他
的专长是使用熟悉的工具和通俗的词语描述业务在哪里可以和云  计算结合。 

132 
 
  

Geva Perry  ：Geva 最近 5 年都在 GigaSpace Technologies 工作，在那里，他曾担任过多个管

理职务。他目前是云计算总经理，在这个职位上，Geva 负责 GigaSpaces 全球所有云计算  相
关的市场化活动，包括战略和定位，产品市场化以及战略联盟等。在加入 GigaSpaces 之前，
他是 SeeRun 的 COO，负责实时业务活动监控软件的  开发。Geva 在 Hebrew 大学拿到学士
学位，获得 Columbia 新闻系研究生院的硕士学位和 Columbia  商学院的 MBA。 

Jamin Spitzer：是微软 Developer &Partner Evangelism (DPE)在 Redmond 的平台战略执行官，

加入微软已有 5 年光景。在加入微软之前，他在 J.D Edwards 的业务应用站和 PeopleSoft 工
作多年。 

原文链接：http://www.infoq.com/cn/articles/Virtual‐Panel‐Cloud‐Computing 

 
 
 
 
 
 

133 
 
  

      推荐编辑  |    Java 社区编辑 曹云飞

大家好，我叫曹云飞，是 InfoQ 中文站 Java 社区的编辑，很高兴在这里和大家

交流。暮然回首，我已经从事软件行业多年了，涉及的行业变过很多  次，最近
一年来从事中间件的研发，其中不变的，是对技术的追求，对 Java 的喜爱。 

作为一名技术爱好者，从 InfoQ 中文站一开始，就关注  这个网站。三年前，在

李剑的鼓励下，我加入了 InfoQ 编辑的队伍。刚开始翻译的时候，水平很差，而自己还不知
道，李剑细心地指出我每一个字的错误，有时  候一篇文章被打回来好几次，文章经过 5 审
甚至 6 审之后才合格（脸红 ing……）。梅花香自苦寒来，正是经过这样的锻炼，我的翻译水
平，对技术词汇的理解能  力逐步提高了，翻译的质量提高了。在后来的工作中，我也是这
样一个字一个字的审阅其他编辑的文字，这都得益于李剑和其他编辑对我的帮助。除了翻译
水平的提  高，更重要的是，其他编辑对工作认真负责的态度对我的积极影响，是不可估量
的。 

做技术翻译工作，除了能够和其他人分享知识，其实对自己的学  习也很有帮助。人对知识
的掌握分 3 个层次（忽悠开始），第一层次是自以为学会了，第二层次是把学会的知识讲给
别人听，第三个层次是把学会的知识写出来。知  识从脑海中到字面的转换不是一帆风顺的，
这需要对知识的加工和再次理解。翻译技术文章，正是这样一个过程。读懂原文是第一层次，
翻译出来，写成文字是第三  层次。同样看一篇文章，看一遍和翻译出来，对文章中知识的
掌握程度是大不相同的。所以说，翻译文章，既分享了知识，又促进了自己的学习，何乐而
不为呢？除  了翻译，写原创文章也是很好的习惯，在梳理了知识的同时，还可以分享给社
区，帮助大家共同进步。 

要想为技术社区做贡献，当然来 InfoQ，  因为这里有良好的氛围，有热情的团队，有优秀的

编辑们，加入 InfoQ，是你理想的选择（画外音响起：黑头发，中国货，相信我，没错的）！ 

134 
 
  

封面植物 

太行花 
形态特征：多年生草本，根系
发达，主根长达 50 厘米。基
生叶为单叶，卵形或椭圆形，
长 20－30 厘米，宽 2－8 厘米，
先端圆钝，基部常截形或圆
形，稀宽楔形，边缘具  有粗
大钝齿或波状圆钝齿，下面 
几无毛或在叶脉基部有疏柔
毛，有时在中部以上有 1－2
枚小裂片，花高 4－15 厘米，
有 1－5 枚对生或互生的苞片，
花两性或单性异株，单生于花
顶端。稀  2－3 朵，花直径 2.5‐4 厘米，花萼无毛，萼陀螺形，萼片 5，卵状椭圆形，白色，
雄蕊多数。 

分布与习性：主要分布于太行山区南部的中山地段，目前仅见于河南省西北部修武县一斗水
篥县西郊黄华墁崭山和潭金登山一带，生于海拔 1000－1300 米的疏林中间悬崖峭壁缝隙中。
 

应用：稀有种。太行花的经济用途尚未查明。经细胞学资料表明，此植物为两体，是古老的
残遗种，对于阐明蔷薇科某些类群的起源和演化问题，有科研价值，应加以保护。 

135 
 
  

 
[

136 
 
  

架构师  6 月刊 
每月 8 日出版 

本期主编：王丽娟 

总编：霍泰稳 

总编助理：刘申 

编辑：李明  胡键  宋玮  郑柯  朱永光  郭晓刚

读者反馈：editors@cn.infoq.com 

投稿：editors@cn.infoq.com 

交流群组：
http://groups.google.com/group/infoqchina 

商务合作：sales@cn.infoq.com 13911020445 

本期主编：王丽娟，InfoQ 中文站架构社区编辑

王丽娟，04 年大学毕业后一直混迹于 Java EE 中间件领域，关注软件架构

  技术，有志成长为一名优秀的架构师。 

《架构师》月刊由InfoQ中文站出品。 

所有内容版权均属C4Media Inc.所有，未经许可不得转载。 

 
137 
 
 

1