Architect 201112

2. 篇首语 Editor’s letter 虚拟化技术在软件开发过程中的应用 虚拟化技术是一个悠久的技术。最早出现在大型机上,后来基于虚拟化技术的虚拟机软件开 始在桌面系统上流行。大家开始普遍认识虚拟化技术,应该也是从这个时候开始的。比如早 期众人熟知的 VMware 和 Virtual PC 虚拟机软件,以及后来出现的开源 VirtualBox、XEN 等。 不过,现在虚拟化技术的发展重点又回到了服务器上。可以说现在如火如荼的云计算的基础 之一就是虚拟化技术。 本期的《架构师》,我们来谈谈虚拟化技术在软件开发过程中的应用。对开发人员而言,虚 拟化技术一点都不陌生。甚至对于移动互联网 APPS 的开发者来说,基本每天都会用到基于 虚拟化技术的设备模拟器来调试程序。而很多开发团队已经在利用虚拟化技术来支持软件的 测试以及交付工作。 虚拟化技术除了提高大家的生产效率外,还能大幅提升软硬件资源的利用率。这样做,不仅 减少了硬件的购置费用,也降低了 IT 管理的成本。同时,由于其硬件利用率高,能效比也 有显著提高,在如今讲求低碳、可持续发展的环保理念下,虚拟化技术的使用更是必不可少。 在这期的架构师中,我们将通过调查问卷、采访和文章等形式,向大家介绍国内一些团队在 使用 VMware、Hyper-V、XEN 等虚拟化技术促进开发、测试、交付的实践和案例。 本期主编:朱永光 1
4. 目 录 [篇首语] 虚拟化技术在软件开发过程中的应用 ................................................................................... 1 [人物专访] INFOQ 专访:COVERITY 谈“开发中测试”与程序员最常犯的编码错误 .................... 4 [热点新闻] REST API 用得也痛苦 .............................................................................................................. 7 阅读者(十七):编程珠玑,字字珠玑 ................................................................................. 9 展望 HADOOP 和 PYCON 中国大会 ................................................................................ 11 ADOBE 预将 FLEX 赠与开源社区,继续解雇原核心软件销售人员 ............................ 17 大数据: 发展还是变革? ...................................................................................................... 21 讨论:烦人的细节 ................................................................................................................. 23 [特别专题] 使用云和虚拟化技术实现持续交付 .................................................................................... 27 微软虚拟化技术——构建高效开发与测试环境 .............................................................. 34 虚拟化技术在软件开发中的应用调查 ................................................................................ 43 虚拟化——互联网时代的产品开发加速器 ....................................................................... 47 厂商视点 .................................................................................................................................. 54 [推荐文章] 圆桌论坛:SOA 与云计算 .................................................................................................... 60 语言设计的艺术——读《松本行弘的程序世界》 .......................................................... 72 2
5. 一个前端工程师眼里的 NODEJS ......................................................................................... 77 [新品推荐] JQUERY MOBILE 1.0 发布,人们反响不一 ...................................................................... 85 GOOGLE ECLIPSE PLUGIN 现已开源 ................................................................................. 85 EBAY 使用 HADOOP 和 HBASE 成功构建下一代搜索 ................................................... 85 VISUAL STUDIO 11 预览: 新的编程语言功能 ................................................................. 86 SQL SERVER INTEGRATION SERVICES 2012 将支持 ODBC ........................................ 86 ENGINE YARD 增加对 NODE.JS 的支持 ............................................................................. 86 ZING 5.0 发布,包含原生支持 LINUX 的无停顿垃圾回收器 ........................................ 87 CHRONON 2.0 支持 POST EXECUTION LOGGING .......................................................... 87 APACHE WICKET 1.5 发布 .................................................................................................. 87 [推荐编辑] 翻译团队编辑 李永伦 ........................................................................................................... 88 [封面植物] 宝华玉兰 .................................................................................................................................. 89 3
6. 人物专访 Interview InfoQ 专访:Coverity 谈“开发中测试”与程序员最 常犯的编码错误 Coverity 公司位于美国加州旧金山,他们的产品包括 Coverity Integrity Control、Coverity Static Analysis 等一系列代码分析工具与解决方案。日前,Coverity 公司产品副总 Ezi Boteach 先生 就“开发中测试”、代码复查和开发人员最常犯的编码错误接受了 InfoQ 中文站的采访。 InfoQ:能否介绍下 Coverity 的“开发中测试”理念和你们的 Development Testing Platform? Ezi:“开发中测试”是新出现的一种技术,包括一系列流程和软件,例如静态分析。开发中 测试的目的是要帮助开发人员、管理层和业务人员能在开发周期的早期,找到并修复质量和 安全方面的问题,这些代码还在开发之中,不会影响上市时间、成本或客户满意度。 “开发中测试”扩大了传统测试范围,可以包括功能测试、性能测试和安全审核,为开发团 队提供更快、更便捷的方式来测试代码中的缺陷,而且是以非侵入的方式。这种方式下,开 发人员能够把注意力集中在创新上,管理层能够在开发周期早期尽早了解问题以作出决策, 业务人员能持续向市场交付高质量的产品,获得竞争优势。 InfoQ:代码复查是人们高度推荐的编程实践。如果使用你们的产品,对于代码复查,您有 什么建议? Ezi:代码复查是软件“开发中测试”很重要的部分,而且其成本很高,因为需要另一个开 发人员来复审代码,很多时候这个开发人员还必须是资深人员。在代码复查之前先做静态分 析,这能让代码复审过程更快,而且成本更低。使用自动化分析来检查变更以及于系统其他 部分的集成点,以此来识别和消灭代码错误,代码复审就可以更集中于逻辑和功能错误,而 不是代码的缺陷,这样做更划算,能够自动化,而且易于重复。 我们推荐测试驱动开发所有的工具和实践,包括代码复审、单元测试和代码覆盖率。当然, 要是能和 Coverity 的自动化代码测试工具一起使用就更好了。 InfoQ:你们的产品如何与像 xUnit 这样的工具一起配合使用? 4
7. Ezi:单元测试是“开发中测试”的重要组成,需要支持测试驱动开发。使用 Coverity 5.5, 我们引入了“开发中测试”的平台,能够让多种不同工具与测试工作流集成。目前我们还不 能专门与 xUnit 集成在一起,但是我们的客户现在能够很方便地把他们使用的测试工具与 Coverity Development Testing 平台集成。举个例子:Coverity 5.5.1 版本包括与常用 Java 静态 分析工具 FindBugs 的集成。这样的集成让管理人员能够降低维护多个测试工具的成本,并 通过统一的工具来推行策略。开发人员也有统一的界面来查看缺陷,并排定解决的优先级。 InfoQ:你们的产品是否能与持续交付流程集成? Ezi:Coverity Static Analysis 可以与多个构建系统集成,包括 Jenkins 这个常用的持续集成系 统。一般来说,与 Jenkins 和持续集成系统的集成是为了确保所有的持续构建都能运行自动 化代码测试工具。如果分析中发现了新的缺陷,一个构建版本就是失败的。这确保新的缺陷 不会引入到交付的软件的主干代码中,而交付过程是持续交付流程的一部分。这也能保证失 败的构建版本不会进入流程的下一个阶段,一般来说是 QA 阶段。Coverity 就像是交付过程 中的一道闸门。 InfoQ:除了使用你们的产品,您是否还能为开发人员和架构师提供一些其他的原则与实践? Ezi:确保软件的质量,防止安全漏洞,这需要良好协作、工具和开发流程管理这几方面的 结合。从清晰的需求文档开始,这是开发任何新功能的基础。需求文档之后,就是功能和系 统架构师完成的功能和需求设计。代码开发完成后,“开发中测试”应该是这个流程的有机 部分。不仅仅是一个产品,而应该是流程和技术的组合,帮助开发组织在开发周期早期、撰 写代码的时候,就能修复软件的问题,确保代价高昂的缺陷不会进入后续阶段和生产环境。 架构师要确保软件的架构良好。这需要人工复审和架构分析,此外还要有经过考验的软件开 发方法论。与之类似,开发人员也要保证,除了使用静态和动态分析的自动化测试之外,也 要使用代码复审和单元测试。质量保证(QA)是任何软件开发过程中都很重要的阶段,以 确保功能测试和性能测试顺利通过。最后,安全审核也很重要,保证在识别、修复、移除代 码缺陷时不会带入新的安全漏洞。 InfoQ:根据 Coverity 收集的数据,您能否列举一些开发人员最常犯的错误? Ezi:开源项目 SCAN(scan.coverity.com)能够很好地发现开发人员常犯的错误。从 2006 年 开始,Coverity 与美国国土安全部一起,研发了 Coverity SCAN 项目,来保证开源软件的安全 性和完整性。Coverity SCAN 分析了超过 290 个开源项目,包括 Linux、Apache、PHP 和 Android, 识别出 49,654 个缺陷,开源软件开发人员已经修复了超过 15,000 个缺陷。下面的表格就展 示出了开源软件中最常出现的缺陷,商业软件也与之类似。 5
8. SCAN 项目中的出现频率 风险程度 NULL 指针引用 27.60% 中 资源泄露 23.19% 高 非原意图表达式 9.76% 中 读未初始化的值 8.41% 高 释放后使用 5.91% 高 缓冲区溢出 5.52% 高 很重要的一点要指出:像 NULL 指针引用、内存泄露和缓冲区溢出常常会带来很严重的质量 和安全风险。很多这样的缺陷,使用传统的测试方法,有时难以找到。使用 Coverity 的工具 会更易于发现类似问题。 要想了解更多关于 SCAN 项目的信息,可以访问 2010 SCAN 报告,其中包括对于 Android 核 心代码的分析结果。 InfoQ:对于代码分析可视化的重要性,程序员们认识得越来越明白了。您能否列出 3 个最 重要的相关分析图? Ezi:Coverity 的 Development Testing 平台能以代码可视化形式让开发人员和管理层看到代码 的质量。可视化能够在几个方面起到帮助作用:它有助于标识代码的所有者和缺陷,能帮助 展示出软件代码的整体可读性,以及质量和安全风险较高的代码区域,还能有助于推行代码 完整性的检查策略。 只谈 3 个图很困难,但我想选的是:未解决的缺陷与已解决的缺陷的对比、每个软件组件中 的 缺 陷 个 数 、 新 的 Integrity Control 热 度 图 。 可 以 访 问 http://www.coverity.com/products/integrity-control.html 来获得更多有关 Integrity Control 热度 图的信息,其中还能看到演示。 原文链接:http://www.infoq.com/cn/news/2011/11/coverity-interview 相关内容:  颠覆者生存:互联网产品测试观点、高效程序员的 10 个习惯  虚拟座谈:JavaScript 单元测试现状、关于测试的若干误解、探索式测试的秘密 6
10. 热点新闻 News REST API 用得也痛苦 作者 Boris Lublinsky 译者 马国耀 日前,Subbu Allamaraju 在博文中谈到当前 REST API 使用过程中的一些问题,并提出了一些 改进办法。 Allamaraju 认为,人们在使用 REST API 时面临的几个主要问题是: 接口不匹配:因为 API 是由其提供者创建的,所以往往体现创建者的视角——几乎所有 API 的最大共同特征都是最大化其使用和重用。这一特点往往导致 API 的粒度过细,这样每个消 费者就可以调用 API 集合的任何子集,并且可按照任何次序进行调用。 “ “ 在此过程中,[提供者]必定要牺牲消费者的某些特殊需求,而且尽量坚持于那些通性征。 这就导致了消费者需求和 API 供应之间的不匹配。 编写客户端代码比较慢,繁琐而且经常重复:使用细粒度 API 产生多次调用,然后将所有返 回结果聚合起来。 如果没有一个处理这些 API 的 SDK,你需要花很长时间去处理 2*n 次调用以及其响应(译 注:Allamaraju 在博文中举了一个示例,该示例的客户需求是查询一组产品的 ID、详细 信息以及相应的用户评价,在该场景中首先需要先做一次查询,得到 n 个产品 ID,然后 对每个 ID 做两次调用,分别是查询详细信息和查询用户评价,如总共的调用次数为 2*n)。 除此之外,每次 API 调用时客户端程序还需要构建请求和解析响应。 等待 API 提供者的功能增强往往耽误时间:因为 API 提供者要支撑许多消费者,并且按照自 己的工作计划行事,该计划往往与消费者的计划不同,特殊的消费者需求很难与提供者的计 划同步。此外,因为提供者通常要衡量 API 的重用,所以很难为某个特定的消费者单独提供 一个 API…… API 调用常常很繁琐:繁琐的客户端指的是为了完成一次功能需要发出多次 HTTP 请求,从 而导致严重的性能下降及网络超载。不论从性能还是从网络利用率的角度看,直观的感觉是 使用粗粒度的 API 会更好。 7
11. RESTful API 的一致性没有我们相像的那么重要:理想情况下,保持 API 实现之间的一致性固 然很好,但是 Allamaraju 认为,REST API 的最重要的特性是互操作性: “ “ “ 我宁可把时间花在互操作性上,而不是一致性上。 Allamaraju 在博文结尾如此总结: 客户端的主要挑战是对发起请求(fork)和合并响应(join)的聚合、并行处理和编排。 那么,如何解决这一问题呢?Allamaraju 提到: ……在 eBay,我的团队正在建设一个新平台,通过它可简化上述案例:  减小调用 API 的客户端代码规模  根据需要自动编排 API 调用  通过包装现有的以提供者为中心的 API,创建新的面向消费者的 API  降低带宽使用率及延迟 Allamaraju 不是唯一提到此类平台的人,早在今年旧金山举行的 QCon 上,来自 NetFlix 的 Daniel Jacobson 就介绍过一个正在实现中的相似解决方案。 Allamaraju 和 Jacobson 提出的解决方案极有意义,但又不禁让人想问:它和 ESB 有何区别? 而 ESB 却好像被指为致使 SOA 失败的主要原因之一?难道问题不在于 ESB 而在于没有用好 它?或者它一直是很好的模式,而现在又得到第二次机会? 原文链接:http://www.infoq.com/cn/news/2011/11/APIPain 相关内容:  Web API 的版本控制方案分析  如何查看我的订单-REST 的流程 API 设计案例  REST 服务开发实战  RIA 的强力后盾:REST+海量存储  REST 与 Web 即平台,Subbu Allamaraju 访谈 8
12. 热点新闻 News 阅读者(十七):编程珠玑,字字珠玑 作者 丁雪丰 无论你自称是“程序猿”还是“攻城师”,只要在写程序,都免不了要和算法打交道。说起 算法,第一本从你的记忆中检索出的图书是什么呢?是经典的大部头《算法导论》?还是之 前大红大紫的《编程之美》?以前它们几乎是同时映入我脑海的,分不清谁先谁后,这两本 书我都读过,前者是在学校的算法课上,而后者则是在毕业求职前。 编程珠玑(第 2 版) 最近,我终于有了一个明确的答案,在这 些算法相关的书籍中,最让我爱不释手的是《编程珠玑》这 本薄薄的小册子,因为它真正激发起了我对学习算法的热情。 不愧是培养了 James Gosling(Java 之父)、Charles Leiserson (《算法导论》作者)等众多大师的“超级大师”的传世之作。 与学校里接触的“教材式”的书不同, 《编程珠玑》更像是“问 答式”的,抛出一个由实际问题简化而来的问题,然后一步 步进行分析解答,作者将想要传达给读者的知识与技巧贯穿 其中,期间还经常让人发自内心地感叹一下,原来还能这么 做。 以书中第 8 章为例,我把问题简单描述为“输入一个长度为 n 的数组 x,求其中任意连续子 元素相加的最大和”。最常规的思路就是写一个三层嵌套的循环,算法的执行时间为 O(n3), 时间似乎有点长,做点优化,充分利用之前的计算结果,可以节省一层循环,于是得出了一 个 O(n2)的算法。如果引入“分治” 的思路,将数组拆开,分别求解,然后再合并起来,这样 只需 O(nlogn)的时间。别以为这样就结束了,终极方案总是出现在最后的,直接从头开始扫 描数 组,一次扫描得出结果(具体算法请允许我卖个关子),O(n)时间内就能解决问题,神 奇吧。千万不要以为这是专门用来教授算法知识的假想的“教学问题”, 这可是源自布朗大 学的 Ulf Grenander 曾经遇到过的真实问题,可见设计一个好的算法是多么重要。 在日常工作中,估计大多数人都不太有机会遇到太复杂的算法,就算遇到了,也可以侥幸依 靠强大的计算和存储能力来解决问题。诚然现在的服务器计算能力越来越强,1 个内核可以 抵得上从前的几个庞然大物,更何况 CPU 还是多核的,内存都按 GB 计算,但不能因为这样 9
13. 就认为现在算法和数据结构的重要性不如从前了。假设上文提到的问题中不是计算数组元 素,而是每次循环需要操作数据库或者调用远程服务,一次操作就要耗时几毫秒,甚至是几 百毫秒,那么 O(n3)和 O(n)的区别就显而易见了。加服务器不是唯一的解决方案,有时简单 地调整算法能让你省下大把的金钱和时间。 再来说说空间的问题,节省空间似乎已经不再重要了,对某些人来说是这样,但不可否认还 是存在很多场景,需要锱铢必较,仔细地设计算法和数据结构。嵌入式设备就不说了,来说 说眼下流行的 Redis,为了能最大限度地使用好服务器的内存空间,减少浪费,antirez 在编 写 Redis 时就煞费苦心地改良数据结构,真的是能省 1 字节算 1 字节。HDFS 和 BigTable 面向 海量存储,照理说它们都是不缺空间的主,可是其中还是提供了 LZO、Snappy 等众多压缩算 法,用“闲置”的 CPU 运算时间来换取更多的空间……类似的例子还有很多,所以在编写代 码时,如果条件允许,请再多考虑一下自己的实现。 多数 Java 程序员应该都有 GC 调优的经历,遇到 GC 过于频繁,耗时太长的情况,通常会对 JVM 的堆配置做调整,如果调整的效果都不明显呢?来看看代码吧,也许对代码稍作修改, 优化下算法,就能把陡峭的内存增长曲线将下来了。啊哈,算法! 书中还时不时地回顾下历史,比如二分搜索,相信大多数人都知道是怎么回事,可是你知道 么,第一篇二分搜索的论文 1946 年就发表了,可是直到 1962 年才 有人写出了第一个完全 正确的二分搜索程序,太让人惊讶了,这个可是如今算法教材上的标配啊。还有那些在编码 规范中经常出现的最长不要超过 80 个字符,其中 80 的由来原来和早期的打孔卡有关(如 果对这个话题感兴趣,可以阅读阮一峰的这篇文章)。 薄薄的《编程珠玑》,两百多页捧在手上完全没有板砖的压力,可以将其作为教材以外的辅 助读物,工具书以外的休闲读物,亦或者是和我一样,将其作为睡前读物,每晚睡前读上几 页,和算法聊上几句,和数据结构打个招呼。 12 月份虽然进入了一年中最冷的时候,但是丝毫不影响国内技术社区的热情,12 月初举行 的 Hadoop 中国 2011 云计算大会和 PyCon 中国 2011 大会就是例证。在盛会到来之前,我们 不妨看看这些相关技术的最新发展趋势和动态,提前热热身。 原文链接:http://www.infoq.com/cn/news/2011/11/programming-pearls 相关内容:向 Java 开发者介绍 Scala、使用应用心理学帮助软件工程师、阅读者(十二):番 茄工作法图解、阅读者(十三):数学那些事儿 10
14. 热点新闻 News 展望 Hadoop 和 PyCon 中国大会 作者 崔康 Hadoop 中国 2011 云计算大会 Hadoop 的热潮已经扑面而来。在 InfoWorld 最新公布的 2011 年十大新兴企业级技术中, Hadoop 名列第四: “ Hadoop 由 Apache Software Foundation 公司于 2005 年秋天作为 Lucene 的子项目 Nutch 的一部分正式引入。Hadoop 是一个能够对大量数据进行分布式处理的软件框架。但是 Hadoop 是以一种可靠、高效、可伸缩的方式进行处理的。Hadoop 非常可靠,因为它假 设计算元素和存储会失败,因此它维护多个工作数据副本,确保能够针对失败的节点重 新分布处理。由于以并行的方式工作,通过并行处理加快处理速度,因此 Hadoop 效率 很高。 各大公司和厂商也在积极地利用 Hadoop 解决自己和客户的问题。 eBay 在 Hadoop 世界(Hadoop World)大会的主题演讲中展示了一种全新的搜索引擎 Cassini 的架构,它使用 Apache Hadoop 来支持每小时进行的索引更新,使用 Apache HBase 对随机 存取信息提供支持。Hugh E. Williams 介绍了项目的规模、使用的技术和完全重建 eBay 核心 站点搜索过程中得到的经验。这次重建工作由 100 多位工程师耗时 18 个月完成。 “ 新 Cassini 平台将能支持:9700 万活动的买家和卖家;每天 2.5 亿次查询;2 亿多件商品 和 5 万多种分类。eBay 已经在 Hadoop 和 Teredata 集群存储了 9PB 用来做分析的数据, 但这将是生产环境里提供给用户直接使用第一个应用。Cassini 将保留 90 天的历史数据 在线——按 照目前的规模是 10 亿条数据记录,包括用来做排名的用户和行为数据。支 持搜索系统所需的大部分工作是由每小时在 Hadoop 上运行的批处理作业完成的。 Hadoop 环境使 eBay 能够恢复或重新分类整个站点的库存,这是一项重大改进。记录存 储在 HBase 里,通常在每个小时索引更新的时候进行扫描。当一 条新的记录上线,几 分钟内就能从 HBase 里进行查询,并被加入实时索引里。Williams 提到,团队熟悉 Hadoop 的运维,系统运行很稳定,基本没 出什么问题。与此相反,他指出 HBase 似乎很难驾 11
15. 驭。 Amazon、Cloudera 和 IBM 都发布了它们的 Hadoop-as-a-Service 产品,Microsoft 的类似产品 也将在明年问世: “ Amazon 是最早推出 AWS Elastic MapReduce 的,可以追溯到 2009 年,在 EC2 和 S3 上运 行 Apache Hadoop。 同 Amazon 的其他 IaaS 产品一样,这项服务提供了大数据分析所需 的最基本的硬件和软件,把很多配置和编程的工作留给了客户,这需要不少专业知识。 假 定公司有这样的能力,它可以成功配置并运行 Hadoop 任务,就像 New York Times 一样,以相当低廉的价格,在 100 个 Amazon EC2 实例上运行了一个 24 小时的 Hadoop 任务,将内容为 1851 年到 1922 年发表的公开文章的 1100 万张图片转换成了 1.5TB 的 PDF 文档。 Cloudera 将 Amazon 的 MapReduce 服务又超正确的方向上推进了一步,推出了 CDH3,这 是一个调优过的 Hadoop AMI,包含很多附加软件,可以帮助管理、运行 Hadoop 上的复 杂任务,例如:Apache Mahout、Flume、Sqoop、Pig、Oozie、Hive、HBase、ZooKeeper、 Whirr 等等,其中大多数都是开源项目。但是 目前还是有些问题,仍然需要大量的专业 知识,安装、配置一些东西,CDH3 安装指南(PDF)还是有不下 175 页的篇幅是在说明 如何从基础开始,对 JDK、CDH3、Snappy 以及系统的其他部分进行配置的。 Microsoft 最近在 PASS Summit 2011 上宣布他们会在 Windows Azure 和 SQL Server 中整合 Hadoop-as-a-Service 服务,在 2012 年提供给那些在其平台上处理大数据的公司。目前还 没有太多的细节,只知道 Microsoft 承诺会保持与 Apache Hadoop 的兼容性,并且将代 码贡献给开源项目。他们还提供了一个基于 Sqoop 的 SQL Server-Hadoop Connector,这 让 SQL 数据表与 Hadoop 的 HDFS 之间的双向数据传输成为可能,因为 Hadoop 需要将数 据保存在自己的文件系统中以保证能够高效地处理大量的数据。 IBM 也发布了自己的产品,使用 IBM InfoSphere BigInsights 软件,在 SmartCloud Enterprise 上运行 Hadoop。BigInsights 有两个版本,基础版是免费的,非常适合项目评估,企业版 用于生产环境。IBM 的解决方案是迄今为止看起来最为成熟的,基于 Watson 技术,这 是一个 AI 系统,它打败了两名今年的 Jeopardy!最佳选手(译注:Jeopardy!是美国的一 个电视智力竞猜节目,比赛问题内容涵盖多个方面,1964 年开播至今)。Watson 并非在 大集群上运行 Hadoop 来回答问题,而是包含了超过 100 项技术来“分析自然语言,识别 源数据,发现并生成假设,寻找证据并评分,对假设做合并和分级”。因此,这并不仅 仅是一个运行大数据任务的平台,它还提供了发现数据并解释它的能力,这是处理问题 的过程中最复杂的部分之一。 12
16. 另一个值得一提的解决方案是 EMC Greenplum Analytics Workbench,一个 1000+物理节 点的集群在运行 Hadoop 集成测试,是由 EMC 及 Intel、Mellanox Technologies、Micron、 Seagate、SuperMicro、Switch 和 VMware 这些合作伙伴一同推出的。Greenplum 并不提 供 Hadoop-as-a-Service,而是提供了一个超过 10000 虚拟节点和 24 PB 存储容量的平台, 用于对 Hadoop 本身进行测试。 Hortonworks 公司(由 Yahoo!和 Benchmark Capital 于 2011 年 7 月联合创建),宣布了一款基 于 Hadoop 的数据平台(Hortonworks Data Platform)的技术预览版。该公司雇佣了众多 Hadoop 项目的核心人员欲以提供相应的支持和培训。 “ Hadoop 0.20.205 之外,HDP 1.0 还将若干开源项目包含其中,用来增强其平台自身的管 理能力,诸如:Ambari,一款开源的安装和管理系统。HCatalog,一个元数据管理系 统, 此外还有一些常见的与 Hadoop 平台相结合使用的,Pig、Hive、HBase 及 Zookeeper 等。 在接下来的几周 里,Hortonworks 计划发布基于 Hadoop 0.23 的 HDP 2.0 版本,该版本 的 Hadoop 实现了下一代的 MapReduce。 在激烈的市场环境中,与其他竞争者相比 Hortonworks 有着自己的优势。出身于名门 Yahoo!, Hortonworks 拥有着许多 Hadoop 架 构师和源代码贡献者,这些源代码贡献者以前均效力于 Yahoo!,而且已经为 Apache Hadoop 项目贡献了超过 80%的源代码,Hortonworks 这样说道。 这些工程师同时也为分布式领域的一些其他项目(如 HCatalog、 Ambari 和 Pig 等)做出了 贡献,此外,在 Yahoo!还都曾参与过在 4 万台服务器规模集群中运行 Hadoop 的经验。 正如李明(Nasi)在 InfoQ《大数据时代的创新者们》一文中所说"Hadoop 是大数据时代数 据处理的首选": “ 脱胎于 Google MapReduce 的 Hadoop 凭借其开源和易用的特性,很快成为了大数据时代 的最耀眼的主角。目前,Hadoop 已经成为大数据生态环境中不可或缺的一环,是拥有 海量数据处理需求的公司的标准配置,许多商业创新和产品创新也都是围绕着 Hadoop 展开的。 虽然 Yahoo 是 Hadoop 最大的贡献者,也进行了 Hadoop 的商业化,但却没法阻止其他 的颇具实力的竞争者进入这个前途无限的领域。Cloudera 便是其中最耀眼的一个。且不 说联合创始人中有 Facebook 和 Google 的精英们,就连 Hadoop 的创始人 Doug Cutting 也从 Yahoo 离职加入了 Cloudera,这一举动当时在业界还引起了不小的震动。Cloudera 最开始的模式是帮助企业管理数据,后来则转型为软件厂商。他们推出的软件发布包可 以帮助企业更方便地搭建以 Hadoop 为中心的数据管理平台。Cloudera 也是通过技术支 13
17. 持、培训和咨询 等付费服务来盈利的,目前融资已达 3600 万美元。 如果说 Cloudera 是依靠其华丽的精英团队来吸引客户的话,那么 MapR 则是通过过硬的 产品来让业界认识到他们的价值。据称,经过 MapR 改造的 Hadoop 的速度可达原来的 3 倍。对于 Hadoop 的 MapReduce 模式,相 信现在基本上已经没人提出质疑了,然而大 家更关心的是,这玩意还能不能更快,MapR 则很完美地回答了这个问题。EMC 也宣布 在一些产品使用 MapR 版本 的 Hadoop,而 MapR 也刚刚完成了 2000 万美元的融资。 除了速度以外,Hadoop 的易用性也是一个用户所关心的问题。虽然相比较其他的框架 而言,Hadoop 已经简化了许多使用 MapReduce 技术时所需要做的工作,但是对于终端 用户而言可能还算不得十分友好。近日宣布完成 570 万美元 A 轮融资的海量数据管理软 件商 Platfora,就在试图解决这个问题。Platfora 旨在提供一个更为友好且更具操作性的 用户界面,而且这个产品可以兼容包括 Cloudera 和 MapR 在内的各个 Hadoop 版本,能 够大大降低使用 Hadoop 的门槛,让更多的公司体验到 Hadoop 的技术优势。 不仅仅是 Hadoop 本身,就连 Hadoop 的周边也不乏成功的创新者。AsterData 已经成功 地被老牌数据仓库厂商 TeraData 以 2.63 亿美元收购,他们的核心技术叫做 SQL-to-MapReduce,可以将海量非结构化数据的处理 技术和结构化数据的数据仓库技 术结合在一起。而这种高速处理海量非结构化数据的能力,恰恰是传统数据仓库的公司 所欠缺的,这也是为什么 TeraData 肯花如此大的价钱买下 AsterData 的原因。 在这样一个发展背景下,Hadoop 中国 2011 云计算大会的召开就显得很必要,国内技术社区 在 Hadoop 方面的实践应用还有较长的路要走,大会也安排了比较丰富的日程,主题包括:  Hadoop 生态系统(Hadoop, Map/Reduce, HDFS, Hive, HBase, ZooKeeper, Chukwa, Avro…)新 功能/新特性研发  大规模结构化/非结构化数据离线或在线处理应用案例分析  虚拟化技术在 Hadoop 生态系统中的运用  支撑 Hadoop 生态系统的基础设施(数据中心)建设  NoSQL 系统实现,应用案例,性能评测及系统优化  Hadoop 生态系统性能评测,profiling,异常处理及性能优化  Hadoop 生态系统辅助工具(监控、记账、审计、CLI、Web 前端等)  Hadoop 生态系统安全技术 14
18. PyCon 中国 2011 大会 PyCon 中国 2011 大会是由 Python 软件基金会下的 PyCon.Org 授权中国举办的第一次 PyCon China 会议。 乍一想,读者可能觉得 Python 技术社区好像不是很火爆,有什么可说的?的确,相对于新 生语言 Dart 以及 Node.js 平台来说,Python 最近的新闻不是很多。不过,这恰恰说明,Python 的发展进入了稳定的青壮年时期,已经低调地在各种场景中发挥着重要的作用。 不要忘记,Python 赢得了 Tiobe 2010 年度语言大奖: “ Python 已经成为系统脚本“事实上”的标准(在这个领域,它是 Perl 的后继者),但现在 它还应用到了各种不同类型的应用当中。Python 是 Web 开发者热衷的语言,特别是与 Django 框架的结合。由于 Python 易学性,越来越多的大学开始将 Python 作为教学语言 了。 (PTVS)的 RC 版。除了支持 CPython 最近,微软的开发部门发布了 Python Tools for Visual Studio 与 IronPython 的重构外,此次发布还提供了对 MPI(Message Passing Interface)与 Microsoft HPC(High Performance Computing)的支持。Visual Studio Ultimate 用户还可以使用一款针对 CPython 的分析器。内建的项目模板有:Python/IronPython Console Applications、Python MPI Applications、IronPython with WPF、IronPython with Silverlight Web Page(本质上,它使用了 Python 而非 JavaScript 编写常规的网页)、IronPython with WinForms。Python 开发最重要的 方面之一就在于它的可交互性,而 PTVS 直接把一种 Python REPL 集成到了 Visual Studio 中。 REPL 窗口可以供之前提到的几种 Python 变体语言使用,并且支持自动完成、语法突出显示 和可视化等。对于习惯于 IPython 所提供的增强版 REPL 的用户,PTVS 支持 IPython 0.11。 对 于使用 IronPython 的用户,REPL 支持 Sho。 Python 已经成为 Heroku 的 polygot 平台官方支持的多种语言之一。Python 曾是大家要求 Heroku 提供支持呼声最高的语言,与其同时提供支持的还有 web 框架 Django。Adam 将 Python 看做“静静成功的语言,与 node 这种一直在产生大量喧嚣的有所不同”。他在博客中补充道: “ Python 社区有其自身独特之处。在快速前进的创新和勤奋努力的小心之间寻找平衡,这 是 Python 的文化。它强调可读性,最小化“魔法代码”,将文档看做第一等大事,并且拥 有良好测试、后向兼容的版本发布传统,这在语言核心和其生态系统的开发库上都有体 现。它让初学者很容易上手,同时大型项目维护起来也不困难,这使得它覆盖了科学计 算、视频游戏、系统自动化和 web 等多个领域。 15
19. 在 Adam 看来,Python 培养了现代 web 框架的发展,比如 Zope 和 Plone。 这些框架引入的 理念有:通过视图模板分离业务和展示逻辑、数据库交互用的 ORM、还有测试驱动开发; 早在 Rails 诞生 5 年之前,这些理念就已经体现在 Zope 之中了。它们没有在市场上获得成 功,是因为它们比较复杂,学习曲线比较陡峭,远远超越了它们的时代。后来,尽管一开始 Python 社区没有太多介入,Django 以 Rails 强有力竞争者的姿态出现。另一个成功的框架是 Flask,这是 Python 的一个微型框架,使用 Heroku 的平台作为 beta 版本的一部分。 虽然是低调的成功,但是 Python 技术社区同样需要分享和交流, PyCon 中国 2011 大会提 供了这样的平台,来自国内外的技术专家会针对 Python 的各个方面做深入的剖析,其中让 人期待的演讲包括:  Python 游戏开发探索与发现——当前的游戏开发,存在着游戏内容越来越繁杂,服务 人数越来越多,市场变化越来越快等现状,导致一款游戏的开发的成本越来越高,风险 越来越高,规模也越来越大。这一直是最棘手的问题。如何才能利用 Python 高效的开 发速度来降低游戏开发的成本?如何用 Python 架构上万人在线的游戏服务器?如何使 用 Python 来快速开发图形和客户端逻辑?Python 在现今的多核体系下是否力不从心? 是否"高性能"永远不属于我们讨论的范围?Python 在各个游戏项目中的使用情况如何?  Python 在豆瓣的应用——Python 是豆瓣网开发的主力语言。从在线应用到离线运算到 后台维护,Python 都起着不可替代的作用。本演讲将详细介绍豆瓣网在各个方面是如何 应用 Python 的,以及我们的一些经验和教训。  易度 PaaS 云开发平台技术内幕——易度 PaaS 是国内第一个基于 Python 语言的企业应 用云端开发平台。演讲将分析现有的企业 PaaS 平台,讲述易度是如何利用现有开源技 术,依托 python/zope/pyramid 等主要技术来构建这一平台的。  Python 之于 Webgame 的应用——Python 已经成为了 WebGame 行业的主流编程语言, 本演讲将在使用 Python 开发 MMOGs 服务器端的领域上,比如大型 Python 应用的开 发模式、高性能 I/O、协程、通信,以及 Python 的优势与缺陷等,与大家分享和交流经 验。 更多技术会议和活动预告,请关注 InfoQ 中文站提供的《中国技术社区活动日历表》。 原文链接:http://www.infoq.com/cn/news/2011/11/hadoop-pycon 相关内容:Python 和 Django 登陆 Heroku、Nuxeo 公司探秘:从 Python 迁移到 Java、淘宝量 子统计架构设计中的核心点、eBay 使用 Hadoop 和 HBase 成功构建下一代搜索、Hortonworks 宣布一款 Hadoop 数据平台 16
20. 热点新闻 News Adobe 预将 Flex 赠与开源社区,继续解雇原核 心软件销售人员 作者 Charles Humble 译者 贾国清 继 Adobe 放弃在移动设备上开发 Flash 的消息不久,Adobe 最近又宣布了将 Flex SDK 捐赠给 现有的一个开源基金会的意向。 据现有消息还不能看出,Adobe 意向中的开源基金会到底会花落谁家,是创建于 2011 年 7 月,并宣称已经与 Adobe 进行合作的 Open Spoon 基金会, 还是另一个强有力的替代者, Apache 基金会。此举是在继 Adobe 收购 Nirobi,并将 PhoneGap 捐赠之后所做出的决定。InfoQ 特别联系 到 Open Spoon 基金会的董事会,希望能从中了解到更多的信息,但其解释道更多 细节仍在商讨之中,他们向 InfoQ 提供了一份声明: “ Open Spoon 基金会中的成员主要由 Flex 思想领袖和一些社区成员组成。我们已和 Adobe 在一个新的开源项目中进行了亲密的合作,这种模式同 Fedora 和 Red Hat 组织极其相似。 事实上,如果把 Flex SDK 代码看作叉子的话,我们的组织作为“勺子”,这两者间将产 生着微妙的作用。我们的目标也是尽可能地保证社区和代码的统一。 就在最近,Adobe 提出了一个向开源迈进新想法。与之前相比,这称得上是一个壮举, 我们坚信,这将加快 Adobe 和社区的投入,并对未来的发展起着积极的推动作用。受这 件事的影响,Flex SDK 将会捐赠给另外一个现存的基金会,比如 Apache。同时,项目的 主要负责人将会由 Adobe 代表和社区成员共同组成,同时还包含很多 Open Spoon 基金 会的成员。 不得不说的是,这个消息至今还不只是全部。依 Adobe 周五发布的 FAQ 文档所 述,Adobe 将继续 Flash Builder 的开发,Flash Builder 是一款基于 Eclipse 的用来开发 Flex 应用的集成开 发环境。尽管如此,从 FAQ 文档中仍可清晰的看出,Adobe 认为,在未来企业开 发人员还 是更应该关注 HTML5 的开发,而不是 Flex。“从长远来看,我们相信 HTML5 将会是企业应用 开发技术中最好的选择”,Adobe 如是说。 17
21. 不难想到,Adobe 的 FAQ 文档引发了开发者的一些不满。其中有人是这样回复 Adobe 关于 HTML 5 的评论的: “ “ 谁能告诉我,在 Adobe 在其官方博客中发表了这种声明后,哪个企业还会在大规模的 Flex 项目投入呢。我完全搞不明白,为什么这一切来的是如此突然,简直就是一场噩梦。 另一位开发者也写道: 我已经在 Flex 这个行业里摸爬滚打了数年。现在回想起来简直是在浪费时间。我确信, 那些在 Flex 上付出了大量投入的企业客户,也与我有着同样的困惑。 难道就没有过渡 方案么?为什么 Adobe 将 Flex 舍弃是如此突然?HTML5、JS、CSS 至今还存在明显的兼 容问题。对于我们来说,我们不构建简单的 Web 应用,我们只构建用户喜好的那些复 杂的数据可视化工具。现在我们该如何去面对我们的客户?难道要告诉他们,对不起, Flex 已死而且 HTML5 还并 不完善,还需要再等几年么? Macromedia,作为最初开发 Flex 的公司,在 Flex 最初的版本中(1.0 和 1.5)就已经将目标 瞄准了 Java 企业应用开发的市场。当时的产品还依赖于 Java EE 应用服务器,可根据需要将 MXML 和 ActionScript 实时地编译为 Flash 应用(二进制的 SWF 文件),该公司还在和企业级 Java 相关的新闻站点中投放了大量的广告。在 Adobe 收购 Macromedia 后不久,Adobe 便发 布了 Flex 2,同时还大量修改了许可模型和许可方法。即便如此,Adobe 仍通过 Flex 数据服 务的方式将 Flex 向企业解决方案中发展。结果,Flex 在企业开发人员中终于取得了深远的影 响。 2007 年 Flex SDK 3 发布后,Flex SDK 就被开源,至今 Adobe 仍是该项目的主要推进者,目前, Adobe 将会放弃该权利,依照 FAQ 所述: “ 这个项目将由 Flex SDK 团队中的开发者以及 Flex 社区中的核心开发人员共同主导,其中 也包括 Spoon 项目成员以及仍在企业中使用 Flex 的参与者。Flex SDK 的新特性将在新的 管理模式下开发,此外,Adobe 也会继续为 Flex SDK 做出贡献。 于此同时,开源的 Java 在企业中的地位并没有遭受明显的侵害,Java 得到了一些重量级企 业的大力支持,如 Apple、IBM、Oracle、SAP 以 及其他一些公司。也有一些公司对于开源 软件并不十分了解和信任,便通常会倾向于使用那些有企业在背后支持的软件,Jeff Roberts, Adobe 的"Flex and Fuse the Arch"讨论组管理者之一,在 Twitter 上说道: “ 恕我直言,任何一个企业级技术都需要一个单独的企业级管家来帮助其生存并获得成 功。Flex 现在就失去了其在企业中的靠山。 18
22. Roberts 告诉 InfoQ: “ 大型企业要想在某一项技术中投入,首先需要确保这项技术的可用性,通常的一种形式 就是看是否有相应的企业管家对其提供支持。Java 就是一个很好的例子。在它还没有开 源之前,是 Sun 在背后支持着,随后是 Oracle。在微软的技术中,这种情况也很普遍。 失去了企业管家,一些企业就在是否要拥抱一项新技术时犹豫不决,更别提还要在这个 基础之上构建关键业务应用了。当各家公司还在为是否使用开源软件的问题上举棋不定 时,我却要为在一些项目中获得使用审批,仅仅是为了能够在项目中使用一个单一的开 源类库,更别提使用一门开发语言了,可行性研究、讨论还有逐级的主管审批。 失去了企业做支撑,组织就不能通过合约的方式来获得相关的服务做支持。当一个组织 依赖于某种技术,而这种技术恰好已经开源的话,当遇到问题需要解决时他们又能求助 于谁呢?谁会在危急关头来帮助他们将问题解决呢? 现在讨论 Adobe 将会保留多少控制权以及还将会投入多少资金还为时尚早,但除此之外 可以肯定的是,将会有很多企业会对是否在这项技术中投入,或继续在这项技术中投入 而犹豫不决。不管怎样,这些组织所作出的反应都是可以理解的。然而,如果要想让组 织感觉好受一些或是继续使用 Flex 和 AIR 的话,还需要更多的来自 Adobe 方面的信息才 能判断出来。 InfoQ 还连线了 Frank Sommers,他是 Autospaces 的创始人和总裁,他告诉我们: “ 首先,我认为 Adobe 的消息很让人困惑:Flex 一直是他们发展企业开发的主要渠道,现 在他们竟然对这门技术敬而远之。已经有相当数量的公司在企业级 Flex 应用中进行了大 量投入。Adobe 最近的声明表明其不会在新项目中考虑使用 Flex。我相信,已经有很多 开发团队在周一早上得知这一消息后,花费了大量时间来讨论如何替换他们已有的通过 Flex 开发的用户界面。同样,如果最终使用 Flex 开发的机会比较渺茫的话,企业开发人 员还要再花时间来找寻其它替代方案。 我倒是非常希望能够看到有一个 Flex 和 HTML 5 共同存在的过渡期,现在来看,将 Flex 融入 HTML 是一件很容易的事情,但反过来的话,把 HTML 融入到 Flex 中却并简单。 就我个人来讲,我倒并不是很关心 Flex SDK,我所关心的是 Flash runtime 和 Flash Player。 Flex 的最大魅力之一就是已经在将近 98%的个人电脑上(也包含笔记本电脑)安装了 Flash Player。与 Swing 和 Java UI 开发相比,这有着很强的竞争力。Adobe 最新的声明使得我 们开始对 Flash Player 的未来有所担忧。在开源模式下继续 Flash Player 的开发,在未来 将会显得尤为困难,不仅是技术本身的复杂性,还因为 Flash Player 普遍依赖于 Adobe 19
23. 同 PC 厂商的配置模型。 或许,Flex 的时代真的已经结束。我个人当初转向 Flex 开发是因为基于 Java 的 UI 无法 满足企业的要求,同时,基于 HTML 和 AJAX 的 Web 开发还要与浏览器兼容性问题作斗 争。新一代的 Web 开发框架,诸如 Vaadin、GWT-Ext(Smart GWT)还有 Sancha 等等, 或许可以解决浏览器兼容性的问题,这样在某种程度上,也可减少对 Flex 的需求。 主流的富互联网应用(RIA,Rich Internet Application)厂商也许会同意 Sommers 最后一个观 点。微软不再重视 Silverlight、Adobe 也减少了 Flex 和 Flash 反面 的投入,都意味着他们也 认为 HTML 5 取得了胜利。Oracle 至今仍继续在 JavaFX 中进行着大量投入,近期 RIA 社区的 举动可算是为 JavaFX 创造了机会。但事实上,JavaFX 仅 与 RIA 有很少的关系,更重要的是 他是一个 Java 桌面程序的升级。 原文链接:http://www.infoq.com/cn/news/2011/11/flex-adandoned 相关内容:  PhoneGap 现状:转到 Apache 和 Adobe,插件模块化,PhoneGap/Build 服务  面向 Java 开发人员的 Flex 开发指南  WebGL, WebCL 及多核:在浏览器中使用 River Trail 实现并行 JavaScript 的现状与未来  社区动态:有关 Adobe 放弃移动版 Flash 的讨论  深入学习 FlexMonkey 20
24. 热点新闻 News 大数据: 发展还是变革? 作者 Mark Little 译者 黎伟 无论你是使用关系型数据库系统、哈希表,还是其它结构来维护数据,你肯定对 NoSQL 和 大数据有所耳闻。 目前,谷歌、雅虎和亚马逊等公司都已经在开发或者使用大数据/NoSQL 的解决方案。但除了一些非常具体的案例外,这些大数据的实现方案真的那么有用吗?在近 期的一篇文章中,凯捷咨询公司的史蒂夫·琼斯甚至指出有时候大数据可能就是一大骗局, 或者至少还不能完全成为一种万能药,可以解决原有关系型数据库管理系统实现方案中的各 种问题,这些你可能都已经注意到了: “ 我注意到市场上对大数据的宣传已成泛滥之势。有些公司将这种容量的爆炸式增长看作 是历史、新技术、新方法延续的一部分,只是发展而不是变革。诚然,Map Reduce 技术 很酷,但它的技术难度也远胜于 SQL 和数据库设计,因此这也意味着该技术远不能成为 一种商业上的万能药。 史蒂夫接着指出,可用于存储极为重要且有一定规模数据集的内存数据库技术(基于关系型 数据库管理系统)不久将成为现实。他通过引用一篇文章来阐述自己的观点,该文章讨论了 数年前,雅虎是如何使用一种经过重大修改的 Postgres 实现来存储 2PB 数据的: “ 下面是大数据的要点:它 95%以上都只是以指数级持续增长的数据,这是与增强的处理 能力和存储容量相匹配的,或者至少是随之增长的。(……)当然,对索引 的优化可能 更难,并且你可能要将数据来回移动到固态硬盘上,但严格来说,这样数据量就变得“更 大”了,而不是一次简单的数据移动。 我们过去也从 Mike Stonebraker 这些人那里听说过类似的事情,他表示许多用户都将受益于 诸如重新构建的关系型数据库管理系统和列存储等方法,从而尽可能多地利用主存和固态硬 盘,同时仍能保持传统较强的一致性、ACID 语义,并在某些情况下可以使用 SQL。但史蒂夫 接着重新强调了 Map Reduce 技术,并且认为这一实现方案背后的模型需要你就如何存储、 查询和操作数据有一种不同的思维方式,在某种程度上,用户要将这种解决方案集成到他们 现有的投资环境中就变得更加困难了。 21
25. “ “ 就像不会有那么多人能够准确地用多线程的方式思考一样,也不会有那么多人能够用 Map Reduce 的方式思考。 当我们经常听到新的实现方案,或者厂商指望着能鼓动我们采用他们的解决方案时,这又把 大数据置于何地呢?根据史蒂夫的观点: 我们发现人们使用大数据的方式和使用 SOA 一样,贴个标签,然后就宣称 “集成了 Hadoop”或“集成了社交媒体(social media)”,或者换个说法,“我们已经建立了一个连 接器”。看看刚刚那个让你大跌眼镜的说法吧。它只是一种老式的学校企业应用集成(EAI) 连接器, 不过连接到新数据源或新 ETL 连接器而已。 这可能算是一种笼统的说法,但也说明了一些事实。因为现在有过多的炒作,并且太多的厂 商都在自己的实现方案上贴上了 NoSQL/大数据的标签,但其实这些实现方案对于手头上的 任务并不适合,那么在这种“新的数据解决方案”的背后是否有丢失核心信息的风险呢?正 如史蒂夫所指出的,这种状况可能跟 SOA 的早期应用状况相似,那时各厂商都在自己的解 决方案上贴上 SOA 的标签,但实际上大多数方案都根本不是 SOA。那么你如何准确衡量你 需要的是大数据的解决方案,还是提供给你的是场大骗局(正如史蒂夫所言)呢?史蒂夫提 出了一些建议,至少可以在评估厂商的解决方案时使用。其中包括: 1. 你可以用“大数据库(Big Database)”来代替“大数据”吗?如果可以,那它就只是一 次更新。 2. “高级”可以简化成“我们刚刚获得一个企业应用集成连接器”吗? 3. 是否与 2009 年的产品基本相同,只不过在新产品上贴上了大数据/NoSQL 的标签? 4. 有什么方法可以将处理流程移动到数据上进行,而不是到处移动数据吗?这是过去包括 Jim Grey 在内的很多人都建议的做法。 不幸的是这些“规则”都不具有科学性,并且都需要某种程度的主观判断。那么还有其它规则 可用吗?如果你已经从传统的关系型数据库管理系统迁移到别的平台 上,那么你是使用什 么来决定迁移的必要性,以及如何选择要迁移到的具体实现方案呢?这种迁移工作是否成 功?如果不成功,又是为什么呢? 原文链接:http://www.infoq.com/cn/news/2011/11/bigdata 相关内容:大数据时代的数据管理、跟着示例学 Oozie、Platform 创始人王敬文谈云计算和 大数据、大数据时代的创新者们、构建高性能的微博系统——再谈新浪微博架构 22
26. 热点新闻 News 讨论:烦人的细节 作者 Abel Avram 译者 侯伯薇 Bob 大叔和 Simon Brown 关于描述系统架构时基础架构(infrastructure)所起的作用展开了 讨论。 在之前标题为 《尖叫的架构(Screaming Architecture)》的文章中,Robert Martin(也就是 Bob 大叔)阐述了这样的观点:软件产品的架构应该让所有人都很容易了解产品所要达到的 目的,并且系统的架构应该反应系统的用例而不是它使用的框架: “ “ “ 架构不是(或者说不应该是)关于框架的内容。架构不应该由框架支持。框架是我们要 使用的工具,而不是要符合的架构。如果你的架构基于框架,那么它就无法基于你的用 例。 此外,好的架构应该让我们可以推迟那些不确定的,与框架、数据库、web 服务器等等相关 的决定,Bob 大叔如是说: 好的架构让我们直到项目的后期才需要决定使用 Rails,或是 Spring,或是 Hibernate, 或是 Tomcat,或是 MySql 等等。好的架构也让我们能够轻松地改变这些决定。好的架 构强调的是用例,并把它与周边的关注点解耦。 Bob 大叔还谈到了互联网,想知道那是否也应该被认为是边缘关注点,并做出结论,网络也 是一种“交付机制”: 网络是一种交付机制,你的应用程序架构应该这么来对待它。你的应用程序是否通过网 络交付是一种细节问题,系统结构不应该取决于此。实际上,你的应用程序是否通过网 络交付是你应该推迟考虑的事情。你的系统架构应该尽可能地与如何交付无关。你应该 可以把它作为控制台应用程序、web 应用程序、富客户端应用程序、甚至是 web 服务应 用程序来交付,而不需要让基本的架构过度复杂或者对其做出变更。 Bob 大叔文章的结论是:你的架构应该告诉读者与系统相关的内容,而不是你在系统中所使 用的框架。 23
27. Simon Brown 是一位软件架构师,他对 Bob 大叔关于“交付机制”的观点发表了评论,称之为 “烦人的细节”。 他同意 Bob 大叔所说的系统架构不应该是它所使用的框架,但是他还说到, 他希望“看到软件架构能够落地,那就需要包括所选择的实现技术。” 关于推迟决定采用何 种基础架构,Brown 说到:“如果我们需要做出某些关键的技术决定,那么肯定就需要完成, 是吧?”,然后他问道:“如果我没有,或者 不能推迟做出决定,那就一定意味着我拥有很 差的架构吗? 我们难道不应该把推迟作为一种有意识的决定,而不是一种规则吗?” Bob 大叔在从架构角度考虑的时候只关注系统的核心领域知识,而 Brown 的方法则与之不 同,他认为“交付机制”当前是很大的一块工作,应该整合到总体架构之中,如下图所示: Brown 的结论是: “ 对我来说,架构不仅仅是包含在“应用程序”中的内容。结构很重要,但是还有很多重 要的内容,像非功能性需求、实际的交付机制(技术、框架、工具、API 等等)、基础架 构服务(例如:记录日志、异常处理、配置等等)、集成服务(内部和外部的)、满足所 有环境的限制(例如:运维和支持)等等。对我来说,所有这一切都与架构相关。 讨论并没有就此结束。Bob 大叔在另一篇博文《整洁的架构(Clean Architecture) 》 中对 Brown 的观点作出响应,他说,不管用户界面和数据库部分有多大,系统的架构都不应该面向这些 24
28. “较大的元素”,并且“其他部分应该与之解耦”。他继 续解释说,将核心领域知识与交付机 制解耦非常重要,并说他不会特意地延迟和停止作出与框架相关的决定,但是架构师应该总 是可以保持这两部分清晰地分离,即 便这两项工作同时进行: “ 我曾经做出的更尖锐的关于架构的评论是,好的架构让你可以延迟做出一些重要的决 定,像用户界面、框架、数据库等等。但有些人指出,客户不希望延迟用户界面方面的 工作。DBA 也不希望延迟数据库方面的工作。在每次迭代完成的时候,他们都希望看到 整个系统可以正常工作,包括用户界面、数据库和框架。他们不希望一次迭代只处理业 务规则问题。事实上,好的敏捷实践特别要求对整体架构做“长而薄”的切分。 当然,我完全同意这一点。然而,“长而薄”的内容不需要同时进行。好的架构让你可 以延迟做出重要的决定,它并不会强迫你延迟这些工作。然而,如果你可以延迟,那么 就意味着你拥有更大的灵活性。例如,你可以在前面的几个 sprint 中创建临时的简单用 户界面,然后再用更完备的用户界面来替换。 Bob 大叔做出结论说:“先处理这些烦人的小细节也没什么问题,只要你能够将业务规则与 它们解耦。” Brown 在对《整洁的架构》一文的回复中做出响应:他同意 Bob 大叔关于解耦的观点,但是 在处理基础架构方面提出了不同的观点:“交付机制并非是可以延迟到‘世界末日’的烦人 细节”,尽管 Bob 大叔坚持该工作是细节问题。Brown 的结论是: “ 1. 将应用程序的代码和技术解耦很不错,而且是我们应该尽力做到的。这样得到的代 码更易于做单元测试、易于替代、易于维护、易于修改等等。 2. 软件架构是与全局相关的,而应用程序的代码只是全局中的一部分。 3. 如果你仍然把“交付机制”这样的重要决定推迟,并且不考虑如何解决重要的非功 能性需求和约束,那么就不得不面临软件项目失败的风险。 在讨论中,Bob 大叔和 Bronw 并不真的是处于对立的双方。他们都支持要清晰地分离核心领 域知识与支持框架,但是前者更关注于领域知识,而后者认为还需要考虑并重视基础架构。 你的方法是怎样的呢? 原文链接:http://www.infoq.com/cn/news/2011/11/Debate-The-Annoying-Detail 相关内容: 了解云计算的漏洞、Hades——JPA 的开源实现、基于上下文图的策略性领域驱 动开发、SOA 领域建模,用 OOD 还是 SOA 方法? 25
30. 特别专题 策划:InfoQ 中文站; 执行:朱永光 虚拟化技术在软件开发中的应用 虚拟化技术的出现和发展已经有很长的时间,目前虚拟化技术已经应用到 IT 的各个方面, 如云计算、桌面。其实,在开发、部署过程中应用虚拟化技术,也可以让开发团队和运营团 队达到事半功倍的效果。本期《架构师》期望以“虚拟化技术在在软件开发中的应用”为题, 为读者呈现业界的一些应用情况和最佳实践。 使用云和虚拟化技术实现持续交付 微软虚拟化技术-构建高效开发与测试环境 虚拟化技术在软件开发中的应用调查 虚拟化技术--敏捷开发的得力工具 厂商视点 26
31. 特别专题 使用云和虚拟化技术实现持续交付 作者 冯智超 背景 现如今,单元测试、自动化验收测试、持续集成等技术手段已被很多项目团队所采用,它们 可以在软件开发活动中很大程度的保证开发软件的正确性,即是否满足了新的需求并且没有 破坏已有的需求。但是如果软件无法顺利的部署到生产环境上,就不能带来任何商业价值。 作为软件开发人员,为了验证软件是否能够部署成功,不应该只有当软件设计、开发、测试 等阶段结束后才向生产环境或准生产环境部署,而应该把部署作为整个软件开发活动的一部 分,从项目之初,在项目整个持续过程中,实现自动化的构建、部署、测试,即“部署流水 线”。 挑战 有了“部署流水线”之后,当我们在每次代码提交时,都有可能向测试环境、准生产环境等不 同环境部署软件并测试,会有如下情况涉及到自动化部署:  自动化验收测试前,需要使用最新构造的结果部署到持续集成的测试环境上; 27
32.  当测试需要验证某一个版本的产品时,可以自动的创建出来该版本的一个环境;  对于性能测试、UAT 验收测试、给业务人员演示(showcase)时,可以自动化创建出某 一个版本的环境;  自动化的向生产环境部署。 这就要求我们拥有自动化部署的能力,它有如下若干特点:  需要有自动化的基础设施管理能力,比如很方便的创建一个节点甚至一整套环境;  部署过程代码化,能够自动化的安装、配置软件;  在向各个环境部署时,使用相同的自动化代码;  各个环境与生产环境都需要尽可能的相似,有同样的操作系统底层组件网络配置等。 这样当我们将软件最终向生产环境部署时,同样的部署代码已经在类似的环境中使用并测试 过,对于这次发布我们就有足够的信心能够成功。 自动化部署 由上可以看出,自动化部署最主要的问题在于如何创建基础设施,以及如何安装和配置软件 产品。 在这里我们先说说如何自动化的安装和配置软件产品。只要是手工过程可以完成的安装和配 置工作,理论上我们都可以将其代码脚本化。开发人员或者系统管理员完全可以通过 bash 或者 PowerShell 来完成这些工作。这要求我们将部署代码以及更为重要的环境配置文件都 当作产品的一部分,放入版本控制库中。 现如今已经有了很多自动化准备技术可以帮助开发人员实现部署脚本,比如比较流行的 Puppet 和 Chef。以 [Chef](http://wiki.opscode.com/display/chef/Home) 举例,Chef 是一个 开源的系统配置和集成框架,它通过自定义的 DSL 领域语言来实现基础设施和软件环境的 搭建,并支持物理机器、虚拟机、云节点(理论上开放了 ssh 端口都可以)。由于 Chef 的 部署代码是 ruby 语言,所以我们也可以很方便的对其扩展,实现任何自定义的功能。 28
33. 有了自动化的部署脚本,既可以可控的可重复的执行部署过程。这里需要指出的是,当开发 或测试人员在某个环境上发现产品配置问题时(比如发现性能测试环境上应用服务器调用某 一个 API 服务的地址有误),应该极力避免开发人员直接远程连接到该机器上手工修改。一 旦在版本控制中有了自动化部署脚本和配置管理,就应该从源代码级别来修改,通过重新触 发一次新的“部署流水线”来修正问题并验证修改是否正确。 云和虚拟化技术 对于自动化的基础设施管理,近来年已经逐渐成熟的云和虚拟化技术可以给我们带来很大的 好处。云和虚拟化其实并不是一个新的概念,只是最近几年在技术圈子里很火热。抛去云和 虚拟化华丽的外表,其实这里只需要它们提供给开发人员基础设施管理的能力,使用云和虚 拟化的好处有:  快速响应环境的需求  平台标准化,屏蔽底层的硬件物理实现  实现对环境搭建的可重复性  可以维护环境基线,根据镜像或副本复制环境  可以对环境中的每个节点进行有效监控 当然云和虚拟化的合理使用也会带来成本上的好处,但更为重要的是给我们开发团队的自动 化部署、持续交付带来了可能。可以想象,通过云和虚拟化技术,开发人员可以在实现一个 需求后,通过一条命令可以几分钟内将其自动化部署到一个新创建的环境中,在向业务人员 做完演示后,又能通过一条命令将该环境清除。 下面举两个目前较为流行的例子,给出大家云和虚拟化技术对自动化部署时基础设施管理提 供的便利。 29
34. Amazon 平台 以 Amazon 的 EC2 服务为例,目前已经有了很多对其提供支持的工具,比如 [Amazon EC2 API Tools]( http://aws.amazon.com/developertools/351)。配置好 Amazon 的 key 后,我们可 以很方便的创建一个 EC2 Node: ec2-run-instances ami-a54d67d1 --instance-type t1.micro --region us-west-1 --key MY_AMZ_KEY # =>服务器在美国西海岸,大小为 micro,系统镜像为 ami-a54d67d1 但这样仅仅是创建出一台最基本的基础设施,对于开发人员来讲,仍需要通过脚本代码来对 其进行自动化配置。不过,目前已经有许多工具已经集成了对 EC2 的自动化部署。比如, Chef 通过一个插件 [knife-ec2]( https://github.com/opscode/knife-ec2)来直接对 Amazon EC2 进行支持。当我们用 Chef 写出对自己产品的部署配置代码后,可以通过一条命令自动化地 创建出一个具有某种角色的服务器,安装并配置项目的产品及其依赖,示例脚本如下: knife ec2 server create "role[rails_server]" --image ami-31814f58 --flavor t1.micro --availability-zone us-east-1a--ssh-key MY_AMZ_KEY # =>服务器在美国东海岸,大小为micro,系统镜像为 ami-a54d67d1,Chef 按照部署代码将 其配置为rails_server的角色 vagrant 对于虚拟化来说,现在也有许多技术可以给开发提供自动化基础设施管理。这里举 vagrant 为例。[vagrant](http://vagrantup.com/)是一个基于 VirtualBox 创建和发布虚拟化环境的工 具,它可以自动化创建虚拟机,并对其进行基础设施配置。vagrant 的使用非常方便,并且 vagrant 也直接支持 Chef 和 Puppet。我们创建一个 VagrantFile 表示一台虚拟机,简单脚 本内容如下: Vagrant::Config.run do config config.vm.box = "centos6" config.vm.provision :chef_solo do chef chef.cookbooks_path = "/PATH/TO/chef-repo/cookbooks" chef.roles_path = "/PATH/TO/chef-repo/roles" chef.add_role "db_master_server" end end VagrantFile 也是由 ruby 写成,这份 VagrantFile 表示是一台基于 centos6 box (vagrant 初 30
35. 始化一个虚拟机的镜像)的虚拟机,在创建时会通过 Chef 向其部署 `db_master_server` 的 角色。有了 VagrantFile 我们就只需要通过简单的命令就可以控制虚拟机了。 vagrant up # =>创建、启动虚拟机 vagrant suspend vagrant halt vagrant destroy # =>挂起虚拟机,保存状态 # =>停止虚拟机 # =>销毁虚拟机 镜像及部署脚本管理 大部分的云和虚拟化技术都支持从一个镜像(image 或 box)开始创建节点,然后再结合我 们的部署脚本对其进行安装和配置。对于有些已经比较固定的基础设置,或者一些配置耗时 很长的过程,我们完全可以直接将其做入镜像中。而对于属于我们产品的部分,以及一些很 容易变化的依赖,应该通过部署脚本来管理。 对于我们自定义创建出来的镜像,很难放置到团队的版本控制中去(一般这些镜像文件都会 很大),但是,我们可以把创建镜像的过程自动化,并将其添加到版本控制中(这就如同我 们的版本控制中只有源代码而不要保存二进制构建结果一样)。比如 vagrant 就可以通过简 单的命令将当前虚拟机做成镜像(box)。我们可以通过最基础的 box 创建虚拟机,通过 Chef 安装配置机器,然后再通过 vagrant 将其做成镜像,这个过程完全可以代码化。 环境管理 通过云和虚拟化技术,再结合自动化部署脚本,提供给了开发人员一种通过受版本控制的脚 本代码来自动创建部署机器的能力。但以上过程还是仅仅在针对一个节点的管理。基于这种 能力之上,我们可以实现完整的对环境的自动化管理。 31
36. 通过对项目系统拓扑结构的配置文件化,我们只需再添加少许工作,完全可以通过一个拓扑 结构的配置文件(比如一个 xml 或者 yaml)结合持续集成构造出来的产品库(二进制构建 结果),实现对整个环境的控制: environment create uat-env --topology.yml # => 创建出一个名为`uat-env` 的完整环境(集成多个节点) 项目实例 最后给大家提供一个实际的项目案例。在本项目中,团队中任何一个人员修改并提交了代码 (这里包括生产代码、测试代码、验收用例、部署脚本、配置文件等),都会在“部署流水线” 上触发一个新的流程:  打包:编译、静态检查、单元测试、构建安装包(rpm);  本地测试:通过 localhost 方式运行前台产品,执行自动化验收测试;  类生产测试:通过 Chef 在 Amazon EC2 上创建测试环境,部署多个节点,执行自动化 集成测试;  归档:将本次流程的构建结果(安装包、部署脚本、配置)发布到一个归档仓库中 32
37.  手工测试、用户演示等:任何需要新建一个环境的人员,可以使用已归档的安装包、部 署脚本和配置文件在 Amazon EC2 上自动化的创建出来一个环境;  准生产环境、生产环境:生产环境是部署在数据中心的 VMware 虚拟机上,当业务人 员需要发布某一版本时,使用同样的安装包、部署脚本和配置文件,执行自动化的发布。 这样任何人所作的修改都会得到一个渐进的增强,流水线走的越远,团队得到的信心就越强。 这种信心不仅仅只限于我们的代码功能实现的正确性,更重要是对我们的产品能够顺利部署 上线的信心。 总结 在自动化测试和持续集成之上,我们通过“部署流水线”可以实现持续交付的能力。可能对于 国内某些项目团队,特别是遗留系统,还需要付出很多努力。但是可以逐步实施,一步一步 打造每一个过程。云和虚拟化技术给我们提供了一个自动化基础设施管理的能力,很大的帮 助了我们持续交付中的每一个过程,最终达到了将团队每一个成员的工作能够顺利的转化为 线上的商业价值。 相关内容:将虚拟化技术作为云计算的平台、Jerry Cuomo 谈虚拟化,云计算和 WebSphere Virtual Enterprise、云需要服务器虚拟化吗?、云是虚拟化的战略性选择吗? 33
38. 特别专题 微软虚拟化技术——构建高效开发与测试环境 作者 徐磊 开发与测试–制衡 在中国的文化中,制衡之道往往是诸多治国明君都必须掌握的策略,不论是太平盛世也好, 车马乱世也罢,如果希望能够延续自己统治,管理好一个国家,一座城池乃至一个村镇,都 离不开制衡;其原因在于我们永远生活在矛盾之中,那么生存的守则就是要平衡这些矛盾, 这就是制衡之道。纪晓岚诚然是好官,但是没有和珅帮衬,很多事情乾隆也一样做不到。制 衡之道中最关键的一点是如何能够引导矛盾双方的冲突为我所用,在总体上获得好的结果。 项目管理也是一样,不同角色之间的划分,往往就是希望形成最优化的分权制,以便在角色 的冲突中将问题暴露,实现透明,最终改进和保证质量。任何的软件开发团队都离不开两个 基本角色:开发与测试。你可以没有项目经理,可以没有架构师,也可以没有设计师;但是 不能没有开发,否则没有人可以帮你实现产品;也不能没有测试,否则没有人可以决定你的 产品是否能够交付。这就好像你往杯子里面倒水必须要用眼睛看着,没有眼睛反馈的信息, 你永远不知道何时该停下来,也不知道停在那里;我们不希望水太少,更不希望水溢出来。 眼睛与手的反馈循环就是我们实现倒水这一动作高质量的必要系统,而开发和测试的有效循 环就是我们实现高质量软件的必须环节。 但是开发和测试本身的角色的局限性造成了他们往往没有办法有效地形成循环,比如我们经 常会听到这样的抱怨: 1. 测试:这个软件需要的环境太复杂,没有办法为每种情况都创建测试环境; 2. 测试:我没有办法保证测试的一致性,因为环境在不停地变化,恢复到原来的状态很麻 烦; 3. 开发:你是怎么测出这个 Bug 的,我怎么没法重现?测试:我忘记步骤了。 其实这些问题都和测试人员本身的定位有关系,测试人员的首要目标是发现软件中的问题, 要做到这一点他们往往专注于软件的反应而忽视了造成这种响应的原因,如:硬件软件环境, 34
39. 系统配置情况,操作一致性等等;而这些正是开发人员修复 Bug 最需要的内容。但是测试人 员不关心,或者没有更多的精力来关心这些内容,造成了非常多的“不可重现”的 Bug 的出 现。 借助微软的虚拟化技术平台和工具,配合 Team Foundation Server 所提供的测试和实验室管 理器(Test and Lab Manager)功能,我们可以有效地协助测试人员来完成这些繁琐的数据收 集工作,从而改善测试与开发的交互能力,实现无缝的反馈循环,最终达到提高质量的目的。 测试环境 测试人员遇到的第一大难题就是环境的架设问题,没有统一的环境,再好的测试人员和再好 的测试用例也测不出正确的结果;测试环境必须满足以下两个条件才算好的环境: 1. 统一性:测试环境必须在不同测试迭代和不同测试人员之间保持统一,首先测试用例的 设计应该是相互独立的,可以独立执行的,那么就需要每次启动测试用例的运行之前, 系统能维持在一个统一的状态才能保证每次测试结果的可比性;如果是团队开发,每个 测试人员之间也同样要保证这样的可比性才能保证测试本身的质量,也就是测试结果的 可信度。 2. 易用性:测试人员的工作核心永远是执行测试用例,验证产品的质量;为了能够专注于 这个核心,必须降低测试环境搭建的成本,特别是重复搭建的成本,这样才能实现测试 的高效率。 以上两个条件正是微软实验室管理平台所解决的首要问题: 图 1:微软 TFS 实验室管理平台架构 35
40. 实验室管理平台通过集成 Team Foundation Server 和 Hyper-V 虚拟化平台来实现,主要由以 下 3 个模块组成: 1. 测试用例管理模块:这部分主要通过测试管理器(Microsoft Test Manager)来完成需求 导入,测试计划,测试用例设计以及测试环境的配置;其目的是实现应用生命周期管理 中(ALM)的项目管理和测试管理的衔接。 2. 虚拟机管理模块:这部分主要通过 System CenterVirtual Machine Manager (SCVMM)来 实现测试环境的搭建,以及状态快照和回复的能力。 3. TFS 生成管理模块:这部分主要是一个工作流引擎,通过 Workflow Foundation 4.0 的工 作流引擎来驱动不同的操作;将以上模块所提供的内容(也就是软件产品本身)放入生 产线进行生产,典型的流程包括: a. 从源代码管理器获取特定版本的代码 b. 编译代码,构建版本进行打包 c. 部署版本到测试环境 d. 测试代理执行测试用例 e. 恢复测试环境到基线状态 f. 采集测试结果 g. 对测试环境进行快照 h. 部署版本到生产或者准生产环境 解决统一性问题 微软虚拟化平台的特点就是可以创建所需环境的模板,并根据模板自动复制环境。 36
41. 图 2:使用实验室管理器创建新的测试环境模板定义 图 3:配置测试环境 37
42. 图 4:激活自动化部署和测试执行能力,并根据需要启用网络隔离能力 以上的测试自动执行能力和版本自动部署能力不言而喻,而对于测试最有意义的还是网络隔 离能力。 网络隔离能力对于测试环境的统一性非常重要,如果有多名测试人员执行统一产品版本的测 试,我们希望每个测试人员所使用的环境都是一样的,比如:服务器 IP 地址,名称等等; 但是这样的系统部署在同一网络中会造成冲突。通过网络隔离我们让多个测试人员在同样的 测试环境的副本上同时执行测试。 自动化测试流程 敏捷开发中非常重要的一个工程方法就是持续集成,简单的理解就是自动化生成+自动化测 试;普通的持续集成一般使用单元测试来作为自动化测试的单元,所以不存在恢复测试环境 的问题(因为单元测试本身应该具备隔离性和独立性)。但是如果我们希望将集成测试或者 负载测试放入到持续集成中,那么环境的统一性就变得非常重要了。 38
43. 图 5:在 TFS 生成中使用快照恢复测试环境到统一状态 图 6:部署完成后,对测试环境创建快照,以便测试人员可以快速恢复某一版本的测试基线 通过以上两个操作,我们解决了将集成测试自动化中的主要问题,使得我们的持续集成可以 突破单元测试的限制,扩展到集成测试。 39
44. 图 7:通过实验室管理器查看正在自动化运行的测试用例 消除不可重现的 Bug 虚拟化平台可以帮助我们解决的另外一个问题就是消除不可重现 Bug。由于测试环境和开发 环境是隔离的独立环境,开发人员往往很难直接获得定位 Bug 所需的数据和信息,而测试人 员又很难保持自己的测试环境处于正确的状态以便开发人员可以使用。利用以上所提到的虚 拟机快照技术,我们就可以将出现问题的测试环境原封不动的发送给开发人员进行问题定 位,最大化的解决了不可重现 Bug 的问题。 40
45. 图 8:测试人员使用快照将处于问题状态的环境发送给开发人员 下一步 实现了测试环境的完整流程自动化后,下一步就是将最新版本推送给生产环境,将持续集成 推广成持续部署。这样做的好处是我们可以最快的获得用户反馈,以便改进我们开发迭代中 的需求。 下图就是利用持续部署推送到生产环境的 SSW 公司官方网站。注意最下面一行小字,是由 TFS 的持续部署脚本自动生成的。这种持续部署的方式,再配合内部的虚拟化测试平台,就 可以保证变更以最快的速度进入生产环境。 41
46. 图 9:SSW 公司的网站使用持续部署进行快速部署,每次部署的间隔不超过 24 小时 总结 开发和测试的制衡之道就是通过工具使他们都可以专注于自己的核心价值,同时能以最少的 额外投入给对方提供必要的信息;这样开发和测试可以在交互过程中消除摩擦,产生默契, 加快迭代的速度;最终实现高质量的研发团队并递交高质量的产品。 相关内容:  超越整合:使用 VMware 搭建更好的开发环境  企业的虚拟化早已上路  基于 Visual Studio 2010 进行敏捷/Scrum 模式开发  云测试、开放的云让业务更“闪亮” 42
47. 特别专题 虚拟化技术在软件开发中的应用调查 作者 朱永光 为了向大家分享国内开发团队在开发过程中应用虚拟化技术的优秀实践,我们特意选取了一 些具有代表性的开发企业和团队,让他们回答了如下调查问卷。通过借鉴他们的经验,期望 读者们也能把虚拟化技术应用到开发工作中,或者进一步优化应用的模式。 问题如下: 1. 请问你们使用的是那种虚拟化技术来辅助开发的? 2. 是基于什么原因选择这种虚拟化技术的? 3. 通过应用虚拟化技术,提高了哪方面的效率(编码、测试、集成、交付或其他)?提高 的效果怎么样? 4. 认为虚拟化技术对于软件的设计和开发是否有影响?有着怎样的影响? 5. 引入虚拟化技术,需要团队具备什么样的条件?或会对团队产生什么样的影响? 6. 还有什么内容需要和读者分享的? 参与问答的专家:  宋伟,百度虚拟化技术专家;  潘磊,阿里巴巴 B2B 高级技术专家,架构师,负责阿里巴巴国际网站架构设计;  刘连春,去哪儿网高级系统构架师。负责去哪儿网机票系统设计、优化;  刘传君,成都任我行,技术总监;  吴立峰,篱笆网。 InfoQ:请问你们使用的是那种虚拟化技术来辅助开发的? 宋伟:Type1 架构的虚拟化技术。 43
48. 潘磊:阿里 B2B 目前使用的虚拟化技术主要是 XEN。 刘连春:我们公司使用的是 XEN 虚拟化技术。 刘传君:Windows 2008 Hyper-V。 吴立峰:我们在测试环境中使用的 VMware for Linux Server 来搭建系统底层环境。 InfoQ:是基于什么原因选择这种虚拟化技术的? 宋伟:提供服务器利用率,节省成本,节省运维人力。 潘磊:目前使用虚拟化技术的原因是为了提高硬件利用率,所以挑选了性能比较好的 XEN。 刘连春:主要原因是 XEN 出现的比较早,周边的配套工具很完善,经过多年的实际使用, 很稳定。 刘传君:我们买了 Windows ,所以直接使用 Hyper-V 是最方便的。 吴立峰:因为测试环境的底层系统是仿照生产环境的标准化系统环境,所以使用 VMware 虚 拟化技术能更有效的对系统环境进行快速复制和维护,并保证所有系统的标准化。 InfoQ:通过应用虚拟化技术,提高了哪方面的效率(编码、测试、集成、交付或其他)? 提高的效果怎么样? 宋伟:交付,运维。 潘磊:在提高硬件利用率的同时。基本没有为软件开发生命周期带来额外的成本。 刘连春:通过虚拟化,主要是提高了运维的效率。就开发来说,申请一个开发机,很快就可 以创建好,使用完毕之后就可以把虚拟机机器关闭,可以提高资源的利用率。就生产环境而 言,可以快速的克隆一个现有的系统,然后快速添加服务器,在升级硬件的时候也不需要重 装系统或者重新配置,大大提高了运维部门的效率。 刘传君:其他提高不大。主要是部署开发工具、过程管理工具的效率。 吴立峰:通过虚拟化技术可以有效的提高搭建测试环境的时间,并可以灵活的规划每个系统 环境的硬件配置,并有效的节省了服务器资源占用。 InfoQ:认为虚拟化技术对于软件的设计和开发是否有影响?有着怎样的影响? 宋伟:如果说是允许在虚拟机里面的软件。从软件设计和开发的角度来说,是没有本质影响 的。但是由于虚拟机本身的限制,有些软件是不太适合运行在虚拟机里面的。比如 I/O 密集 44
49. 型的软件。当然,如果软件是需要访问真实的硬件设备,如一些 PCI 卡等,就需要看看该虚 拟机是否支持了,或者通过其他硬件技术如 VT-D 等把该类型的硬件暴露给虚拟机。另外, 如果还想精细化的让软件在虚拟机上面,运行的更顺畅,就需要考虑, 虚拟机的 VCPU 的调 度算法。总之,影响可以忽略。 潘磊:对应用来说,虚拟机技术基本是透明的。但随着我们生产环境服务器管理的自动化。 虚拟机的管理也将和我们的发布系统集成并实现自动化。虚拟化技术会是我们搭建”云”的一 个基础。 刘连春:虚拟化可以有效在系统级隔离应用互相影响,可以根据应用特点分配 CPU 和内存 资源,每个应用都独享一个系统,更容易部署。 可以将系统设计的更小巧,在一台实体机上创建多个虚拟机,而不用担心资源浪费,多个系 统的虚拟机共享一个实体机,这样当机器出现硬件故障时,每个系统都影响很小的一部分, 通过使用更多的小虚拟机,可以提高系统的可靠性,降低故障对系统的影响比例。 刘传君:更加充分利用电脑的能力。一台多用。对设计,开发不会有什么影响。 吴立峰:现在虚拟化使用下来觉得对于一般的软件开发和设计并没有什么影响,只有在涉及 压力测试和复杂的网络协议传输时会有一定的影响,主要是因为虚拟化技术本身的软肋,即 共享磁盘 I/O 和虚拟化本身的网桥方式共享网络协议。 InfoQ:引入虚拟化技术,需要团队具备什么样的条件?或会对团队产生什么样的影响? 宋伟:团队 对虚拟化技术比较了解,需要有底层内核,操作系统原理,计算机体现结构, 各种硬件规范的相关知识。虚拟化对人才的要求比较高。不光是需要内核知识,从应用层到 内核层,再到硬件层都要有相应的理解。 潘磊:需要有比较熟悉虚拟化技术的团队提供技术支持。实施虚拟化过程中会出现一些系统 或者硬件上的问题,需要有专人解决。 刘连春:总体来说,引入虚拟化技术的过程过渡很平滑。 刘传君:需要专人维护。 吴立峰:引入虚拟化技术需要团队将虚拟化技术使用到正确的应用上,比如不涉及磁盘 I/O 的内存交互应用,CPU 运算等,扬长避短,当然虚拟化的应用对于习惯了普通服务器的人来 说还是有颠覆性的 因为虚拟化可以轻松做到系统的横向无缝转移,这是普通服务器很难做 到的,当然虚拟化服务对于支撑它的底层硬件也有着很高的要求。 45
50. InfoQ:还有什么内容需要和读者分享的? 宋伟: 总之, 虚拟化技术在服务器和数据中心应用比较广泛,目前也比较成熟。大家在选 取虚拟化解决方案的时候,要看自己的需求和财力。底层的 Hypervisor 是 XEN ,KVM 或者 其他的都不重要。关键是平台和解决方案。没有好的平台,大量的虚拟机就无法管理和运维, 没有如数据备份、容灾等解决方案,虚拟化技术带来的好处就大打折扣。 潘磊:暂时没有。 刘连春:需要注意的是虚拟化对重 IO 的应用是不适合的,比如数据库,这些重 IO 的应用还 是适合使用实体机。 刘传君:对开发影响不大,最多管理起来简单些,标准化些。对于服务器的弹性配置更有价 值。 吴立峰:对于虚拟化暂时还是处于观望状态,虽然虚拟化最近几年非常流行,能有效的降低 成本,和便于管理。但是他的稳定性和性能还是有待考证,至少我们这边没有在生产环境中 使用虚拟化,以后如果使用的话也会从一些非关键应用切入。毕竟作为运维的角度来说稳定 胜过一切。 相关内容:  使用云计算和虚拟化技术实现持续交付  Forrester 宣称数据虚拟化技术已经成熟  数据库虚拟化——这样做值吗?  超越整合:使用 VMware 搭建更好的开发环境  Jerry Cuomo 谈虚拟化,云计算和 WebSphere Virtual Enterprise 46
51. 特别专题 虚拟化——互联网时代的产品开发加速器 作者 杜海 高技术高竞争的互联网时代,对产品的交付时间逐步变短,而对交付质量的要求逐步提高, 各种新创意、新产品层出不穷,市场允许的产品推出周期也越来越短,传统的软件开发模型 已经无法跟上当前的需求,高效、便捷、可迭代的产品开发模式也越来越为人们所关注,虚 拟化技术正是体现这种开发模式最重要的工具。 从功能上讲,虚拟化的优势一是提高资源的利用率;二是提供多样化的配置管理;三是提供 快照的保存和恢复功能;四是提供产品动态扩展的能力,这些也都是互联网产品开发模式所 需要的重要特性。 我通过一年前的项目经历和目前应用虚拟化技术后的项目经历的对比,来说说虚拟化技术如 何在开发、测试、上线部署各个过程中的作用。 简要介绍一下当时跟现在的开发条件。 一年前我所在的项目组一共有 6 台开发机,2 台测试机,6 个开发人员和 2 个测试人员,机 器由团队公用,每个开发人员会被分配一个以自己名字命名的独立账号,开发人员使用这个 账号登录系统并进行开发工作。相信这也是大部分公司的标准配置。 现在我所在的项目组有 10 台开发测试机,在功能上没有做特别的区分,一共有 24 名开发兼 测试人员,没有专门的测试人员。开发人员通过登录属于自己的虚拟机进行开发工作。 开发阶段的作用 虚拟化在开发阶段的作用有两个关键点: 第一,快速的环境搭建 开发初始,需要一个资源分配的过程,而开发人员往往无法得到需要的灵活的硬件资源,一 般可以得到的是一个账号,和一个确定操作系统的机器,这有三个原因,首先是硬件资源有 47
52. 限,无法保证每个开发人员能有一台独立的开发机,只能采用公用机器,通过不同账号进行 隔离的方式;其次由于机器共同使用,多人同时开发,所以无法依照自己的意愿进行环境调 整;第三是因为服务器进行操作系统变更的代价很高。如果开发确实需要定制的环境,需要 变更操作系统,在我们以前的团队里,需要提交单独的变更单,经重重审核后到系统工程师, 系统工程师到周五安排下周的操作,所以从提起申请到操作一般要经历一周时间。即使进入 实际操作阶段,系统重装耗费的时间也很长,安装系统的时间占用在 30 分钟左右,服务器 系统重启的时间在 8-15 分钟,重新下载和配置软件的时间在 1 小时-3 小时不等。总体说来, 重建一次系统环境至少需要半天时间。 在这种情况下,开发人员在开发伊始就没有得到期望的良好开发环境,只能在整个开发过程 中带着镣铐跳舞。 再来看一下目前的状况,我们应用 Xen 虚拟化技术,很好的解决了这些问题。开发人员在开 发进行之初,提交需要的环境配置列表,配置管理人员按照开发的请求,从镜像库里选择对 应的虚拟机镜像,再找一台合适的物理机由该镜像生成虚拟机,交付给开发人员使用,虽然 硬件资源依然有限,但由于虚拟机所占的物理资源较少,可以保障每个开发人员都拥有自己 独立操控的环境。而整个虚拟机的创建时间在 1-5 分钟即可完成。 由于拥有的是独立的一台虚拟机,其资源跟其他的开发人员完全隔离,开发人员可以自主进 行系统配置。在需要的时候也可以随时进行重装请求,重装操作非常简单,删除虚拟机,从 镜像库生成一台新的虚拟机即可,原先需要一周多提供的初始系统现在在 1-5 分钟即可完成。 图一:目前一个开发人员的的开发测试机 48
53. 第二,独立的运行环境 在以前的配置下,由于系统被多人共用,或者已历经开发多个项目的时候,很多系统环境参 数已经经过了多轮配置,导致整个开发环境暗流汹涌,隐藏着诸多冲突因素。同时,由于多 个账号同时使用,分属于不同账号的模块之间也会产生冲突,最常见的如端口冲突,这往往 通过开发人员之间协调好彼此模块使用的端口号解决,但也不可避免的遗留下一些问题,比 如我们遇到过一次故障,就是开发在提交产品时忘了修改内部某个模块的通信端口导致的。 还有一次开发人员在程序出错之后花费了大量时间精力查找原因,最后悲催的发现是另一个 开发人员在系统上做了某个工具库的升级。此外,由于某个开发人员的程序问题把机器跑死 从而导致其他程序无法运行的问题更是家常便饭。 迁移到虚拟化的环境下,共享开发环境的问题也迎刃而解。由于虚拟机自身的独立性,每台 虚拟机都是一整套完整而隔离的系统,虚拟机之间有充分的隔离,开发人员不用再担心端口 问题,系统参数问题等,用自己的机器自然对系统的一切变化均了然于心,当出现 bug 时, 开发人员也可以把时间精力集中在程序功能的调试上。 测试阶段的作用 开发完成后进入到测试阶段,虚拟化的重要性更加显现,虚拟化在测试中的重要性体现在四 个方面: 第一,灵活的环境选择 测试人员首先需要有一套良好的测试环境。在以往的测试中,需要由测试人员提出环境申请, 在测试机器上重装系统,按照测试要求配置好系统参数。在物理机上操作,一般 1 天左右, 测试人员可以拿到自己需要的环境。但由于测试的多样性,如果说开发阶段一天时间准备好 环境还能接受的话,对于测试来说这是非常难以容忍的,因为测试更强调环境的多样性。例 如我们的产品需要同时提供对 Windows 环境,Linux 环境的支持,以及对 Windows 和 Linux 的各个不同的发行版的支持。这种情况下,每次产品测试都是一个痛苦的过程,系统工程师 需要根据测试进度随时重装系统,以便提供出不同环境配置的机器,而测试则等待系统工程 师提供好环境后才能进行下一个环境的测试。 即使环境已经提供,每个环境里还需要加上不同的应用组合,比如前端产品需要测试对主流 浏览器的支持情况,浏览器包括 IE,firefox,chrome,safari,opera 等等,对于每款浏览器 还需要考虑不同版本,如 IE6,IE7,IE8 等。更可怕的是,同类型的很多浏览器不能同时装 49
54. 在一个系统里,IE 系列即是如此,这种情况导致了测试环境的变更极其频繁,系统工程师往 往不堪重负,测试工程师则抱怨需要的系统环境迟迟不能提供。 在我们当前的项目组里,该问题已经不复存在。虚拟化系统里早已创建好对应于多个不同操 作系统的模板,例如 CentOS 5.4,Ubuntu 10.04,Windows 2003 Server,Windows 2008 Server, Windows xp,Windows 7 等等,在测试需要的时候可以由模板迅速生成对应的虚拟机,每个 虚拟机的生成时间在 1-5 分钟。同时,对应不同的应用和环境的组合,也单独生成一个模板, 比如 Windows 2003 server+IIS 的模板,Windows xp + IE8 的模板,需要时轻轻点击生成虚拟 机,一套可用环境就出现了。模板的形式见图二和图三。 图二:截取的 Windows 部分镜像 图三:截取的 Linux 部分镜像 第二,资源的按需分配 虚拟化情况下资源的按需分配是一大重要特性。如果物理资源足够多,那么可以在每台物理 机上单独部署一套环境,提供给开发人员使用,但这种方式占用的资源极多,比如我们目前 已经保存的镜像环境就有 56 个,如果使用 56 台物理机搭建环境的话则是极大的资源浪费。 50
55. 正是由于测试环境的机器有限,需要虚拟化做到真正的按需分配资源。虚拟机只有在运行时 才会占用 CPU,内存,网络资源,当虚拟机关机时,其消耗的仅仅是镜像占用的磁盘资源, 目前我们每个初始镜像的大小都在 1G 以内,56 个镜像占用的空间都没有超过 50g。 同时,工程师在测试时也养成了良好的使用习惯,停止测试时关闭虚拟机,这样现有的 10 台测试机可以发挥 20,甚至 40 台机器的作用。 资源按需分配的另一点好处是测试人员可以轻松保留以往的测试环境,一年前我们隔壁的项 目组有个约 20 台机器组成的集群,是为很久前的一款产品测试准备的,那款产品还在维护, 所以这套测试环境大概每个月使用一次,但因为配置复杂,资源没人敢回收利用,只能由其 一直闲置。 而在用了虚拟化技术之后,我们对项目中对应于每个模块发布版本的测试环境,都做了做一 份备份,在测试完成后关闭虚拟机,制作镜像保存。在需要的时候再由镜像生成虚拟机进行 测试。其代价仅仅是多占用了一些磁盘空间。 第三,高效的快照回放功能 快照回放功能对于测试而言意义极其重大,实际上这也是最受测试工程师们欢迎的功能,没 有之一。其主要的应用场景有两点: 第一是用于分支检测的场景。产品从 A 点有两个选择方向 A1 和 A2,测试工程师选择路径 A1,当 A1 测试完成后需要回到 A 点进行 A2 的测试。在以前,我们是通过先重新走到 A, 再进行下一步操作的。当路径复杂之后,这是一项非常耗时的工作,而且因为两次操作不可 能完全一致(比如每步的操作延迟不同)可能会导致无法真正走到 A 点,从而降低了测试 的可靠性。 虚拟化快照是解决这个问题的最佳方案。从我们的实践经验来看,在面对分支选择时,只需 要在 A 点做一份快照,接下来便可以放心的进行 A1 分支的检测了。当 A1 检测完毕后,恢 复虚拟机至 A 点快照的状态,接下类就可以顺利的走 A2 分支了。整个过程非常流程,减少 了通过操作恢复 A 状态的工作,快照的创建和恢复都在 1-2 分钟内,大大节省了测试时间, 也提高了测试可靠性。 第二是故障现场保留。以往测试人员在发现产品 bug 后,会进入一个两难的境地,该 bug 很可能无法每次都顺利复现,那么如果继续测试会破坏现场环境;如果保留现场叫 RD 来查 找原因,可能临时找不到 RD,而且 RD 定位问题本身也需要时间,这种情况下环境被占用了, 进一步的测试工作就被耽误了。 51
56. 利用虚拟化快照技术,测试人员只需要在此时进行一次快照,保存完整的虚拟机环境,可以 在 RD 有空时恢复这个快照给 RD 看,或者直接将虚拟机镜像丢给 RD,RD 从此镜像生成虚 拟机,进行 debug 工作,原先的测试工作也可以顺利的走下去了。 对于 rd 而言,有了一份保存 bug 后的环境,也可以放心的进行各种调试工作了。 第四,特殊环境的模拟 由于测试环境的硬件限制,在很多时候无法模拟出产品的真正应用场景,比如我们正在做的 一个网络模块开发,需要测试三块网卡情况下的应用场景,但是测试机只有两块网卡,无法 模拟出来。于是我们在 Xen 的同一个网桥上了里创建 3 块虚拟网卡,就很好的解决了这个应 用场景面临的问题。 另外,我们另一个项目需要进行集群化测试,同样是由于测试环境的硬件限制,无法达到集 群化的机器数量要求,于是我们在一台物理机上搭建多台虚拟机,解决了这个问题,最后这 个项目是创建了 20 台虚拟机完成了测试。 最后来说说产品部署和运行阶段,虚拟化的意义。 部署、上线阶段 第一,增强产品预发布功能 在产品正式上线之前应该有一个预发布的过程,即将产品先在预发布环境上线,跑一段时间 稳定后再上线生产环境。因此预发布环境需要模拟生产环境的系统架构,并要保证机器数量, 由于硬件资源的限制,这个过程甚至经常被取消掉,从而增大了产品风险。 目前我们团队,基于虚拟机搭建了一套完整的预发布环境,跟生产环境做到了基本一致,在 多次的产品上线过程中也现了很多问题,做到了防患于未然。 第二,产品服务能力的动态扩展 产品上线后一天的业务流量往往并不是一个正太分布,而是较为极端,在早晨流量最低,在 晚上流量突发很高。以往的业务上线时,一般都按照预计的最大流量上线机器,当流量低时 系统资源十分浪费,比如很多物理机器的 CPU 利用率都在 1%以内。而当流量突然增大到预 期之外时又非常难以应对,紧急上机器时间不够,也十分容易出错。这是一个让运维人员非 52
57. 常头疼的问题。 我们线上也同样应用的虚拟机,使用虚拟化技术很好的解决了这一问题。现在上线前,只需 要准备好业务相关的镜像即可,通过流量和性能监控,随时观察系统的负载概况,在负载低 时可以选择关闭几台业务虚拟机,当负载突发时立即通过镜像创建更多的虚拟机提供服务, 从而高效的解决了流量变化的问题。 总结 虚拟化技术在产品的整个上线流程中起到了重要的作用,是互联网时代产品开发的有效工 具,虚拟化技术的按需分配,快照功能,隔离功能,动态扩展能力等都将为产品开发提供极 大的便利。 相关内容:  使用云计算和虚拟化技术实现持续交付  Forrester 宣称数据虚拟化技术已经成熟  监控和虚拟化技术在“去哪儿”中的应用  半静态语言–原理和价值分析  我眼中的云端架构 53
58. 特别专题 厂商视点 VMWare 谈虚拟化技术在开发团队中的应用 张振伦,是 VMWare 大中华区技术总监,他 2006 年 加入 VMWare,到今天已经超过五年了。他见证了中 国云计算的发展历程,也见证了 VMWare 从一家并不 为人熟知的公司,到今天成为云计算的领导者之一。 虚拟化对开发团队的价值所在 说到虚拟化对开发团队最大的价值,张振伦认为:提 升开发团队的效率,让交互的速度变得更快;这是最大的价值。原先新的项目交付可能需要 至少三个月,或者半年,甚至更长的周期。有了虚拟化,有了很多相关的一些开发工具和框 架的帮助,VMWare 很多用户的交付时间变成了两周,甚至更短的时间。IT 的运维和管理也 变得更为方便,企业的整体竞争力也得到提高。张振伦同时指出:当开发环境从传统的物理 机迁移到虚拟环境之后,开发团队里的角色也存在变化,传统管理模式也会发生变革。 比如传统的安全,往往是基于一些物理的配置来实现,比如基于交换机的端口,或者基于物 理位置来设定。但是在虚拟环境里面,所有的应用、服务都可以漂移,无法基于物理端口实 现,就需要重新考虑安全策略的配置。此外,传统习惯上,网络管理、应用管理,或者管理 服务,可能都是不同部门负责。但是今天这些可能也都要重新定位,因为网络资源变成了虚 拟资源,存储也变成虚拟资源,而这些资源如何与传统管理部门相匹配,也需要重新考量。 因此,虚拟化不仅仅是提升效率,同时还会带动职能的转变,整个组织架构内的一些角色实 际承担的任务也有转移和变迁,需要重新理顺相关流程。至于具体的调整方法,就需要针对 不同的企业,根据实际情况来分别去对待了,VMWare 也有这方面的一些专业服务。 虚拟化技术对应用的架构的影响 现在很多新的开发框架和开发工具,都已经提供了向云上部署的选择。从应用架构来看,架 构师需要考虑应用运行在内部私有云和外部公有云上的不同。同时还要考量如何在私有云和 公有云之间顺利、平滑地过渡、迁移。 54
59. 在张振伦看来:VMWare 有一个梦想:从技术架构角度,把公有云和私有云打通成为统一的 平台。一个应用在这两种云上的架构体系应该是一样的,这样才能够达到终级目的——混 合云。如果私有云和公有云应用的体系架构不一样,就很难走到混合云架构。 当然公有云和私有云在很多方面还是有区别,比如说扩展能力。私有云的扩展能力,可能很 难跟公有云匹配。公有云跟私有云上安全体系的要求可能也会有差异。在构建的时候,也要 考虑公有云和私有云在服务水平协议 SLA 的一些差别。在自己的私有内部云里面,可以确保 完全受控的事情,一放到公有云上,恐怕很难确保。VMWare 也希望能有法律、法规来确保 安全。 即将落地中国的 CloudFoundry VMWare 在国外提供公有云 PaaS 服务,叫 CloundFoundry。张振伦介绍说:CloudFoundry 是 业界第一款开源 PAAS 平台,目前 CloudFoundry 的服务器全部是在美国。但是 VMWare 计划 在明年把它迁移到中国来,到时候会有 CloundFoundry.cn 这样的全中文化界面,更好地满足 于中国开发者需求,同时加入更多的本地化服务。VMWare 在上海的研发中心,有一个针对 Clound Foundry 专门的研发团队,他们在后台去支持,让 CloudFoundry 在中国的落地更有保 障。同时,中文版与英文版除了语言之外,在支持的技术上没有差别。 在 CloudFoundry 上,没有对开发语言、开发工具、开发框架的限制,除 SpringSource 之外, Scala、Node.JS、Ruby on Rails 都可以支持。数据库同样支持 MySQL、PostgreSQL,MongoDB 等多种数据库,也包括 NoSQL 类数据库,当然还有 VMWare 自己的 vFabric Data Director, 可以让开发者能够更方便地去访问 不同的数据。同时他们不需要知道这些数据的差异。 VMWare 甚至支持所谓的 MicroCloud,开发人员只要在自己的笔记本上把一系列的套件安装 好,就可以模拟一个小的 CloudFoundry 云环境。 至于价格,张振伦特别提到:CloudFoundry 对于个人开发者,采取完全免费策略。 云时代,微软的研发新趋势——微软的“开发测试云”实践 李剑波,现任微软开发平台与工具事业部资深技术专家,在 IBM 软件部工作 过多年,曾经为人民银行、海关电子口岸、东软等提供软件开发管理和测试咨 询和技术支持工作,当前主要研究领域集中于敏捷方法的引入和云技术的应用 实践。 55
60. 1、什么叫“开发测试云” 近几年,“云计算”以及相关技术正在蓬勃发展,通过“云计算”应用的实践的深化,对软 件研发企业也带来了巨大的转变,很多软件企业不仅是“云计算”的技术提供者,也是“云 计算”的成功实践者。体现在软件研发技术和研发管理领域,“云计算”为软件企业提供了 一个统一的、面向服务的、动态规划的基础平台,这超越了简单“虚拟化”技术的技术瓶颈, 更强调从管理的角度考虑软件研发企业的整体管理体系的建立和灵活扩展,更加为软件企业 的企业级研发管理创造了价值。而这种将“云计算”和软件研发工作相结合,建立软件研发 企业高度弹性、统一管理的研发技术平台的模式可以简称为“开发测试云”。 2、“开发测试云”解决微软研发的问题 微软作为全球最大的纯软件公司,也如同所有大型软件研发企业一样,面临着很多来自方方 面面的挑战,而直接服务于软件研发人员和相关工作的各种方面和内容,是其中重要的组成 部分,主要包括: 1. 软件研发体系的统一质量标准和管理:微软的研发当前以敏捷方法为主,新的产品和项 目都建立在敏捷方法基础上,其中的质量要求和产品化发布是特别重点关注的内容,而 结合了微软复杂的质量管理、产品线管理和发布管理,为微软整个企业的产品研发管理 带来了更大的挑战。 2. 软件研发管理中的安全保障:安全一直是微软产品研发面临的一个关键问题,这里包括 代码的统一安全管理,外包人员管理的安全问题,系统存储和管理的等方方面面,微软 一直以来对安全都有极其强烈的必要要求。 3. 软件研发环境的弹性优化和扩展:以往微软的软件研发环境是以部门为单位,更多的是 在部门内采用"虚拟化"技术提升系统的利用率和使用效率,已经达到了一个瓶颈,则更 需要从各个研发中心整体管理并结合研发管理的情况考虑研发环境的优化和管理,实现 更有效的资源管理。 4. 软件研发服务的自服务模式:微软在内部采用了"虚拟化"的软件研发管理,但是当前的 工作模式以产品和部门为中心,直接为整个企业的 IT 带来了冲击,各种 IT 资源成本下 降不明显,并额外为企业 IT 带来了更多的工作量和压力,这对于 IT 的健康发展造成很 大冲击。 在微软内部的研发,无论从企业 IT,还是研发团队内部都已经发现,以往的以“虚拟化” 56
61. 为基础的研发管理的优化,已经无法满足的实际工作的需要,而将“虚拟化”技术进一步提 升,进而转入“开发测试云”的研发管理企业模式,将成为微软软件研发管理的发展方向。 3、当前,微软“开发测试云”的实施内容 在此基础上,微软结合已经完成部署的“虚拟化” (基于微软的 Hyper-V)技术,通过企业 IT 的有效提升,在各个研发中心基础上,引入了自服务、统一研发管理、自动化部署、产 品化发布等内容,构建了适合企业使用的“开发测试云”。 微软的“开发测试云”是建立在 Windows Server 2008 R2(含 Hyper-V)+ System Center + SQL Server 的产品基础上的,实现了以“自服务门户”(研发人员自助工作,企业 IT 管 理流程,统一自动化部署相结合)为特色的“开发测试云”服务,并进一步结合敏捷研发管 理方法和实践,为微软的部分产品研发团队提供了全新的研发管理服务平台。已经完成的部 分提供以下服务: 1. 企业级统一研发管理服务:借助于 TFS 的统一研发管理,结合各个产品特点定制的敏捷 开发流程,并集成 Visual Studio 等各种开发工具,进行受控的统一开发管理,保证各 个产品研发相关人员都在统一管理的基础上实现有效的研发工作,并尽量将"云中开发" 与原来的开发模式相结合,有效提升研发质量。 2. 动态研发环境服务:在"自服务"工作模式下,所有研发中心的资源是统一考虑、动态规 划的,基于底层的 Hyper-V 虚拟化技术,为研发统一考虑 IT 管理,提供了有效基础。 3. 外包研发管理服务:在微软的企业模式下,外包开发人员和公司是一个重要的环境,在 57
62. "开发测试云"上专门结合外包人员的工作特色,设定了"外包开发"服务,进行特定的安 全管理和开发管理流程,实现有效的、安全的、高质量的外包研发管理。 结合“自服务”的新工作模式,在“开发测试云”平台下整个研发工作的可以分解成为以下 典型的工作场景: 1. 产品研发平台和环境的统一管理:所有的产品线的各种研发环境和资产(包括软件、硬 件、源代码、各种资源等)都由研发中心负责统一管理,进行系统的统一规划和安全授 权,并且各种资源都可以以虚拟机的形式暴露提供出相应的服务。 2. 产品经理的自助式研发资源申请:各个产品经理,基于项目情况提交资源申请和资源规 划,统一使用的开发方法、开发环境、开发资源,经过研发中心系统管理人员授权后, 自动部署、分派,实现所要求的环境服务。 3. 具体研发人员自助式、弹性的研发资源使用:研发人员根据授权和使用的要求,访问特 定的资源,分层次的进行安全的代码开发,比如使用虚拟机访问代码或者访问特定代码 的权限,完成开发工作。 4. 研发资源的回收和后台管理:资源使用后,或者资源使用率较低的情况下,研发中心的 系统管理人员通过实时监控获取相关信息,实现资源的回收、归档、重用,并进行特定 的备份工作,方便使用后进行回溯。 通过这样工作模式,有效的提升了整个研发中心的资源使用率,实现了资源环境的集中管理 和弹性使用,也极大的降低了系统管理人员的工作强度,并能保障研发过程中各种安全要求。 当前在微软的研发部门中,“开发测试云”的尝试还处于初级阶段,主要在 Visual Studio 58
63. 等产品线中进行试点,随着不断的完善,还将进一步进行优化和发展,为微软的研发提供一 个不断优化的技术基础。 4、微软“开发测试云”的有效实践 在微软的“开发测试云”实践中,有几个特别需要注意的内容值得重点关注,这些部分的有 效实施对于“开发测试云”的成功有重要的意义: 1. 软件为主,适当的硬件资源投入:微软的“开发测试云”实现,主要是利用现有的服务 器硬件资源,只对扩展部分投入硬件,这有效的平衡了资源投入,真正提升了资源效率。 2. “自服务”的工作模式:“开发测试云”的后期维护和系统投入是一个需要持续关注的 内容,特别是 IT 人员的工作效率和开发人员的使用效率, “自服务”是完全建立在最终 用户的角度上动态使用资源的工作模式,即降低了使用的难度,又减少了 IT 的工作压 力,有效的方便了用户。 3. 安全和网络的统一考虑:安全是“开发测试云”的重要方面,需要重点考虑,特别是当 用户被划分为比如公司内部人员、外包人员等不同角色时,需要结合网络拓扑、用户授 权等方面统一考虑,有效保证其权限的完整性、有效性、可靠性。 4. 工具系统集成的使用模式:“开发测试云”重要的使用者是开发人员,需要保证其与各 种开发工具紧密集成,这样才能尽量减少对于开发人员工作习惯的改变,即提升管理, 又提高工作效率,真正让开发人员习惯、熟悉、喜欢新的工作模式,进而保证“开发测 试云”目标的实现。 “开发测试云”不是简单的企业 IT 工作提升,更不是“虚拟化”研发环境,更多的应该是 从研发整体管理的角度结合当前实际工作的角度引入“云技术”,真正服务于企业研发工作 和研发人员,这才是“开发测试云”有效实践的基础和重点。 相关内容:  使用云计算和虚拟化技术实现持续交付  Forrester 宣称数据虚拟化技术已经成熟  数据库虚拟化——这样做值吗?  超越整合:使用 VMware 搭建更好的开发环境  Jerry Cuomo 谈虚拟化,云计算和 WebSphere Virtual Enterprise 59
65. 推荐文章 Articles 圆桌论坛:SOA 与云计算 作者 Boris Lublinsky 译者 马国耀 在过去很长一段时间里,SOA 受到了软件行业的广泛关注。接着它被宣布死亡,然后它又(在 一定程度上)以云计算的形式重生了。当今的云计算就像几年前的 SOA 一样被疯狂地炒作 着。它们有很多相似之处?二者之间有何关系?根据该行业的传统,答案取决于你问的是谁。 VMWare 的 Rod Johnson 说: “ “我认为 SOA 时代的确已经过去。从架构层面上看,它的确是个好东西,但是从产品 销售的角度看,它却是个市场中孕育出来虚构概念……但云计算却不同,它背后有更多 实际的东西。但是,这些实际的东西已经模糊了,因为几乎任何事物都是云计算。” 另一方面,Oracle 的 Jürgen Kress 则谈到了在企业层面上需要使用面向服务的架构(SOA)来 支撑云计算。他在国际 SOA 与云计算会议上的演讲中说:“必须合理地构建架构”,即云计算 需要 SOA 的支撑。 本次虚拟研讨会中,InfoQ 与几位 SOA 和云计算专家探讨了 SOA 与云计算之间的关系,二者 通用的原则,怎样的应用能够有机结合 SOA 和云计算的优势,决定云计算成败的最关键因 素。 参会者: 1. Rob High——IBM Fellow 及首席 SOA 架构师 2. Miko Matsumura——Products Kii 副总裁,Sun 公司前首席 Java 布道,SoftwareAG 副总 裁 3. William Vambenepe——Oracle 架构师 4. David Linthicum——Blue Mountain Labs 创始人兼 CTO,《云计算与 SOA》及另外 12 本书 的作者。 5. JP Morgenthal——云计算、企业架构和 SOA/BPM 方面的风云博主、权威。 60
66. 问题列表: 1. 云计算的哪些方面可以看到 SOA 的广泛使用——将云计算资源定义成服务时?将应用 移植到云平台时?或者二方面都有? 2. 哪些 SOA 的原则/经验与云计算的关系最密切?云计算对 SOA 的影响有哪些? 3. 哪些方面能够帮助云计算避免像 SOA 那样失去开发者和分析师的宠爱? 4. 越来越多的云计算 API 正面临着 Web Service 几年前所面临和解决的相同需求/问题,如 异步消息传输、元数据交换、事件等。是否仍然需要那些 WS*标准回来才能解决这些问 题呢? 5. 怎样使 SOA 与云计算最好地结合起来? 6. 列举云用户可改进现行工作的三件最重要的事情。 1. 云计算的哪些方面能够看到 SOA 的广泛使用——将云技术资源定义成服务时?将应用 移植到云平台时?或者是二方面都有? Miko Matsumura:如果我们只是将现有应用当作服务,那我们得不到任何好处,因为粒度、 语义和重用性都存在问题。另一问题是,有些服务运行在古老的 DOS 上,如果过度使用, 它们很可能会当机。这意味着扩展性已经成为“逐底竞争”或“最弱环节”。幸亏云计算为 我们提供了更加灵活的基础,使许多服务至少不至于在物理上奔溃。而现在,它们只是逻辑 上失败,虽然同样很可怕,但是处理这样的问题却更加有趣。 William Vambenepe:大多是后者。当将业务应用转移到云环境中,不论从交互的角度(它 们之间如何交互,这是 SOA 关注的内容)还是运维的角度(云计算为此带来了更多的规范 化和自动化)你都需要能够将它们拆解成可管理的单元。如果你已经在 SOA 项目中完成了 此项工作,那么你就是在感知 SOA 的基础设施上完成的,之后,运维层面上的拆解就能处 于良好状态。 而相反,如果你不能有效地控制应用组件之间的交互与依赖关系,那么现在你就需要这么做 了,不然向云的迁移只是向虚拟化的迁移。虽然能够得到一些实际的益处,但这不是真正的 云计算环境。 David Linthicum:SOA 和云计算的融合实际上表现在如何定义 IT 资产,包括应用、基础设施 (比如存储)、平台等。一旦我们完成这一步,不论是重新移动现有服务还是创建新服务, 其流程都会更简单、更有逻辑性。所以,我的回答是二方面都有。 61
67. 事实上,我们可将云计算看作 SOA 延伸到基于云交付的资源,比如存储即服务、数据即服 务、平台即服务,仅此而已。这里的技巧在于如何找出哪些服务、信息、和流程是转移到云 平台的最佳候选,以及选择应该从已有或发展的 SOA 中抽象出哪些云服务。 此外,SOA 对于云计算非常重要,重点体现在几个方面: 首先,它是一个很好的架构方法,通过一些机制建成企业内外的信息系统,使它们能更好地 运行与协作。 其次,为了获得云计算的优势,你需要通过接口和架构延展出去并连接到云计算资源。虽然 很多人认为他们可以在核心企业信息系统和云计算资源之间简单快速地建立一些脏链接 (dirty link),但事实上,为了尽可能地享用云计算,企业内部却一定需要架构,譬如 SOA。 最后,你还需要通过一定的架构方法论和指导原则来组织并记录架构。过去大多数人关注那 些热点方面却忽略了这一方面。我们需要回到正确的道路上,重新寻找解决问题的最佳方法, 而如果按照正确的步骤做,SOA 就是一个好的方法。 JP Morgenthal:从业界对 SOA 的理解而言,SOA 最广泛使用的地方是 PaaS 平台的中间件组 件。然而,SOA 的特性决定了它可用于任何云服务(包括基础设施服务和软件服务)的创建 与交付中。 Rob High:总体而言,云计算与 SOA 的关系源于 SOA 的松耦合特征。从实践的角度,松耦 合是 SOA 的重点,因为人们希望位于信息系统中的服务与其依赖的底层技术、拓扑和组织 无关。这是过去 30 年里,IT 行业中广大分布式计算项目的终极目标。XML、WSDL、IDL、CDR, 各种分布式计算领域中出现的格式和协议,它们无一不是为封装技术差异、进一步通过支持 组件间的差异性而解决计算问题的。 快速转换到云计算,在运维和采购角度之上,你也会看到相同的目标——为了创建并利用 解决终端用户需求的能力,而无需关心其位置和实现技术。SOA 是在云计算中实现这种透明 性的自然之选。 再者,对于业务人员而言,从服务的角度思考他们为其用户和业务伙伴所提供的东西是很常 见的,这里的服务不是指 IT 或 SOA 中的服务,而是指 它们向市场提供的业务能力。同样, 他们也愿意从服务的角度去思考他们从其伙伴处消费的能力。一个公司可能提供财务服务, 另一个公司可能提供制造服务,而第 三个公司则可能提供人力资源服务。在企业与终端消 费者之间的全球价值链网络中,通过互联网和计算机获得并消费业务服务是自然并且显然的 发展方向。 62
68. 当把这些力量聚集一起时,云计算的一切就是服务——它是面向服务的。云基础设施本身就 是一种服务,一些人希望将自己编写的软件程序运行在它 上面,然后通过面向服务的 API 向其消费者供应该程序的功能。基础设施服务也可能被软件开发者暴露出来,用于提供自动 化管理的能力——注册及部署新服务、 设置 QoS 策略、获得运维感知等。而在云上运行的 程序本身可能是使用 SOA 技术实现的;云中提供的服务也可能通过企业内的服务和公有云 中的服务的组合从而 形成 SOA 复合应用。 所以,我们已经看到 SOA 在云计算多个层面的广泛应用。 2. 哪些 SOA 的原则/经验与云计算的关系最密切?云计算对 SOA 的影响有哪些? Miko Matsumura:应用 Provisioning 就是推陈出新……过去,你往往只能说“不”,因为你还 无法做到这一点。现在,你只需要问自己“这么做有商业价值吗?” 相比而言,更难的是业务价值判断的部分。财务人员可能会说,只要赚得比花的多,那就能 做。不幸的是,你还得遵循平台的生态系统规律,你不得不考虑诸如此类的事情——“我 们的销售会卖它吗?”,“它会不会导致我们的平台 API 频繁变更?” 这将产生一种新型的平台领导力,我们必须要能对平台用户说“不”,不是因为平台能力不 够,也不是因为其业务价值不够,却要根据应用是否符合某个特定平台生态系统的“风格”。 William Vambenepe:IT 服务管理和 SOA 治理,二者远远地注视对方(或有意地忽视对方) 已经很久了。配置 管理是困难的,云在云计算供应商与消费者之间划了一条线。你或者相 信这条线有魔术般的隔离效果,或者想出某种办法来管理并组织(译注:应用或组件间的) 依 赖关系和变更策略,使之在保证消费者服务的同时,允许云供应商执行必要的维护。这 里有更多有关云和 SOA 治理相关的思考。 David Linthicum:我想到两点:其一,通过良定义的服务和资源(应用及基础设施资源)交 互。其二,提供和管理敏捷的能力。 服务的使用是相关的。因为,我们不再面对数百,甚至上千的不兼容的服务接口,而面向一 组通用服务,它们提供应用行为、数据服务和工具服务。通过通用服务与那些资源和以及广 泛而位置独立的服务打交道,将云计算用户与资源隔离开。 我们对这些服务进行编目,掌握它们的用途,我们还可以通过它们混搭成新的解决方案,甚 至将他们与流程和复合应用绑定起来,而不需关心这些服务位于私有云还是公有云,甚至在 现有传统系统中。 敏捷的概念来自于服务的使用以及 SOA。你可通过混搭服务快速生成(再生成)解决方案。 63
69. 这使得 IT 人员可以快速调整并更改业务流程,比如,通过复合服务或改变业务流程来创建 新应用,不论服务位于云中与否。 至于云计算对 SOA 的影响,SOA 为云计算带来了一条非常逻辑的路线图,这些原因我在很 早之前就提到过,因此可以这么说,因为云计算的原因,SOA 获得了重生。这是我的书《云 计算与 SOA》中的内容。SOA 一直是设计、架构和处理 IT 资产的有效方法。云计算影响已 经为 SOA 带来了无限光明的前景。 正如我最近在 InfoQ.com 的一篇文章说 过,SOA 的治理和松耦合原则对于云计算极为重要。 从治理的角度,为了跟踪资源的使用和了解(在云计算中创建的)虚拟世界中部署的东西, 对服务编目的维护 极为重要。松耦合为云计算带来的好处是,它是避免(由特定云服务供 应商造成的)厂商锁定、新服务产生或变更时保持敏捷的最佳方法。 云计算为 SOA 带来的好处是能够更好的理解运维的职责。SOA 主要专注于开发,它的重点 是创造性解决问题的流程。云计算通过拥有强大运维流程的成熟的运维组织向终端用户交付 服务,使之以一致的、可重复的方式进行。 回到先前我谈到的松耦合在异构的分布式计算系统中的角色,这些年来我们一直努力争取的 是对底层技术的真正的封装与隔离。即便是现在,我们拥有强壮的诸如 WSDL、XML、REST 和 JSON 等技术,我们仍然能够看到底层实现技术在它不该出现的地方显露出来。这种现象 常常出现,一方面,隐藏这些细节需要一定的工作,程序员的大多数时间不用于设计与实现 优良的封装之上。这样的疏忽,注意到时已经为时已晚,因为任何项目的早期所面对的环境 并不是那么异构,所以就不会经历完全异构的系统表现出来的差异性。另一方面,云计算无 法容忍劣质的封装。如果对资源位置的是僵硬的,那么虚拟化和弹性就变得非常脆弱。具体 技术的数据类型也会限制或完全破坏消费者。无法隔离线程执行可能会将一个用户的信息泄 露给另一用户。云要求良好的封装,在缺乏封装的部署周期中问题会很早暴露出来。这些都 是 SOA 的基本信条,却也是云计算的关键成功因素。 3. 如何能让云计算不会像 SOA 那样失去开发者和分析师的宠爱? Miko Matsumura:对于这个问题,只能说“骏马已出厩” (译注:这是一个谚语,指马已经 出了马厩,此时再关门已经晚了)。云已经提供了极度简单的底层 API 并博得了开发者的喜 爱,比如 S3。谁不喜欢面前有个可直接扔东西的桶呢?它就像云中声明的核心设计模式一 样,开发者已经将他们的应用与其交织在一起了。 云计算的落幕将与 SOA 一样。只要是机器接口就是漂亮的,看着也舒服,而企业集成则是 地狱。沙特(Sartre)说得好,“他人即地狱”。当人们不得不与每个酷似来自于呆伯特卡通 64
70. 里的秃头老板交谈时,他们的生命能量条就开始消退(译注:这里通过呆伯特卡通里的秃头 老板说明,当这些秃头老板执意云计算时,即表明它开始走向衰败)。 William Vambenepe:这是自然界的规律,过度喧嚣之后就是相对的沉静。SOA 经历过,云 计算也将经历。若无法阻止过度喧嚣(对于云计算已经太晚了),则无法阻止它走向沉静。 这一点我不觉得有问题,因为我们已经得到了益处。这意味着我们在应用云计算时,应该关 注业务收益最大化,而不是循序那些炒作的标准。这才是喧嚣过后留下的东西,这才是许多 企业架构实施的 SOA,我相信他们会同样地实施云计算。 David Linthicum:脑海中浮现的是成功。随着云计算能够证明其在企业里的价值,IT 就会使 用私有云、公有云和混合云。云计算变得更容易理解,而现在也已经走向主流。然而,我们 的电视广告中说的是“迈向云计算!”而不是“迈向 SOA!” 云计算和 SOA 非常不同。云计算是一种计算方法,它使我们可以使用到本地或远程的资产, 而且它们可根据需要供应或回收。SOA 是某种你要去做的事情,或某种复杂的架构模式,他 使我们创建出来的架构便于改变。 许多 SOA 相关的 PR 问题都根源于这一事实,大多数 IT 人并不真正懂得 SOA。我不认为云计 算作为计算方法已经成熟,在迈向云计算的道路 SOA 将是最好的架构方法。 JP Morgenthal:非常有趣,我把 SOA 看作服务的设计和开发,而将云计算看作是服务的交 付和运维,但是显然二者的定义是多种多样的,这也是 SOA 一直挣扎和云计算将面临挣扎 的原因。明确云计算的定义有助于让企业更好地针对一组目标度量云计算的价值——比如, 云计算是 x,所以它将交付 y——也使得开发者和分析师能够量化分析它的价值。 Rob High:纵观过去 30 年的行业发展,每一种技术创新都可归结为三类:1)具有明确的价 值定位,技术本身有魅力,而且还为对它感兴趣并愿意买单的用户明确标识了它的真正价值。 2)能够扫清技术采购和使用方面的障碍,也就是说,它们便于使用和消费,而且容易获得 其承诺的价值。3)获得社区的青睐,从而可以形成一个生态系统。人们对 SOA 诋毁大多数 并不是在否认它满足以上原则的能力,它的根本问题是,SOA 实施者是能否在真正理解其价 值定位之后才开始实施它。我们常常发现 SOA 实施者的视野很局限,他们认为 SOA 是能够 理清信息系统的另一种技术——它是更漂亮的 EAI,或更糟的说法,它只是基本的系统整合。 他们从不知晓 SOA 有其主要的业务价值定位,即通过快速对应用(服务)组件的重新组装 以满足市场去求,让业务更敏捷,获得更好的产出。而那些真正理解 SoA 的架构的人却实实 在在地取得了 SOA 的巨大成功 ,因为对 SOA 的正确理解可以有助于他们合理安排投资优先 级,选择正确的设计及管理方法。 65
71. 云计算也一样。云的价值不仅仅在于如何降低 IT 运维的成本,而在于是业务人员更专注于 业务创新。在投资决策中正确理解和应用云的价值能够确保云计算的成功。 4. 越来越多的云计算 API 正面临着 Web Service 在几年前所面临和解决的相同需求/问题, 如异步消息传输、元数据交换、事件等。是否仍然需要那些 WS*标准回来才能解决这些 问题呢? Miko Matsumura:Web Service 里面装的都是垃圾。但是,请不要误读这句话,我不是说 Web Service“是”垃圾,我说的是它里面“装”的是垃圾。实际上它本身是好东西。厕所里装着 大便,但厕所本身却不是。 那么,如果你是一个 iPhone 开发者,你调用了一个 Amazon S3 服务。很好,你永远不需要 了解什么是 Web Service。你的生活会像麦片广告一样充满阳光,每天呼吸着新鲜空气醒来。 但是,很多开发者面对的是企业级应用。 Web Service 标准是人们在处理标准和策略标准化问题上唯一任何并可实施的方式。所以, 如果你的网站中存在一些垃圾,那么你就必须把它们装起来。因此,在这些情况下考虑使用 Web Service,否则,继续过你的阳光生活。 William Vambenepe:我曾就过去十年间应用WS-*标准解决IT自动化管理(“云”之前的叫法) 问题写过一篇博客。 这篇博客写于 2 年前,很明显,从协议的角度,WS-*技术现在已经不 可能再用于云API了。这里不是讨论SOAP和REST孰优孰劣的地方,但是在IT管 理上从一种技 术转到另一种技术的过程中,人们吸取了一些教训(比如专注于API使用的简单性),同时有 重新发明了一些特性(如,通知[notification]和部分资源操纵[partial resource manipulation] 等)。为避免在同一段落中过于频繁地引用我的博客,这里有对使用REST实施云管理的实施 方法分析。 David Linthicum:我希望如此。2000 年到 2009 年间,我们在 WS-*上花了太多精力。大多数 标准都定义得很好,也为新兴的云计算世界带来了价值。当今的一些云计算标准组织似乎在 重新制造轮子,他们应该思考过去创建的很多标准。人们似乎倾向于在新技术(如云计算) 诞生时发明新标准。我总是在会议中提醒人们回过头考虑 WS-*标准的那个人。 JP Morgenthal:许多云计算供应商好像都采用“REST”作为 API 的暴露方法。实际上这是一 个不公正的界定,它混淆了基于 HTTP 的 API 实现的许多方面。从本质上说,他们选择的是 使用 HTTP 的 POST 和 GET 动词,使用 URL 格式作为服务交互的方法,与此对应的是更为健 壮的消息机制,它提供可靠信息传输的功能。我要声明的是,我非常赞同 REST 使用 URL 标 识作为资操纵的方法。它意味相同的资源地址应该总能返回相同的资源。如果响应消息中基 66
72. 于 URL 的查询结果总在变化,那么它就应该是 RPC 机制,而不是 REST。 Rob High:SOA 绝不依赖于任何技术(包括 WS-*)才能取得成功。然而,标准的存在的确 能有助于社区的建立,采纳技术的目的是建立生态系统。WS-*技术的显著特征是,它们不 仅仅是一个标准,促进了社区发展,而且还能更好地支持服务质量,并将其作为技术的天然 属性。其他技术提供了非常基础的(通常是“够好的”)服务质量。但是,如果你要求更多, 那么 WS-*就非常有价值了。在此基础上,我一直提倡为不同的任务选择正确的标准。如果 REST 和 JSON 提供的基本 QoS 已经够用,那就用它们。如果你需要更多,则使用 WS-*。我 不相信哪一种技术标准能够应用于其本质特性之外的其他需求上。SOA 之美在于,作为一种 架构风格,它不关心装配复合应用时选择哪种具体的技术标准。 5. 怎样使 SOA 与云计算最好地结合起来? Miko Matsumura:SOA 和云看上去像巧克力和坚果奶油。当巧克力碰上坚果奶油时,他们 都很恼火。但是,当二者意识到二者结合之后的味道是那么好时,它们就成了朋友。 我的回答看上去很傻吧?首先,我们将云的好处想象成巧克力,当你的应用有难以满足的特 性,需要弹性扩展的能力时,云计算就找到了它的舞台,这是一类应用。现在我们来描述坚 果奶油这一边——SOA,这里有一些难以解决的应用,需要通过整合将它们连接起来。 老实说,大多数仍有希望的企业应用都具备这两方面的特点。所以,我来考你一个问题,你 能在企业内找到一个即不适合 SOA 又不适合云的应用吗?离开了企业应用,就不要再去打 扰 SOA 了。 William Vambenepe:二者联姻的最佳应用是对各种应用服务选择最佳的部署方式,同时保 持他们之间的整合关系,最重要的是,将它们当作一个服务去管理。例如,在一些业务应用 中使用了某个第三方 SaaS 服务,该服务可能要与运行在某个 PaaS 环境中的某个定制应用进 行协作(比如,作为客户化/扩展 SaaS 服务的方法,或者作为向外部客户交付服务的方式), 同时保持某些核心的、独特的应用在企业本地运行。一方面,需要使用 SOA 设计这一整合 的架构,另一方面,SOA 和云计算的结合有助于执行有效的管理。上述场景所依赖的 IT 管 理基础设既要以应用为中心,又要拥有云的能力。 David Linthicum:杀手级应用(Killer Application)应该具备使用复合应用或流程中的服务的 能力,它们即便是通过开放互联网提供的,但是使用起来却像本地服务。Google API 是一种, 但是还有成千上万的别的 API,它们提供各种服务,从地图服务到销售税计算服务。或者是 基础设施 API,比如公有云供应商(如 AWS)提供 的存储和计算服务。看看这类网站,想 想如何将这些 API 用作你的 SOA 服务,它们非常强大。 67
73. JP Morgenthal:正如我上面所说的,它们协同工作以交付完整的服务生命周期。 Rob High:我不得不对这一问题再老生常谈一次。SOA 是一种通过松耦合的系统组装复合应 用的很好的架构方法。云计算带来服务弹性和透明交付。只要有通过云的密集、透明服务交 互能够带来规模效益时,你就应该使用云计算——私有云、公有云和混合云。 6. 列举云用户可改进现行工作的三件最重要的事情 Miko Matsumura:我向大家推荐吃好、运动好、休息好(译注:作者诙谐地回避了正面回 答此问题,转向回答另一问题)。当然这样的回答还是比较傻。我更愿意回答下面这个问题: 你不愿看到却看到的云用户做的最傻的事情是什么?我的回答是他们忽视了依赖性。依靠别 人是很糟糕的事情,这些开发者依赖于其他企业,比如 Amazon EC2。一旦你依赖于其他企 业,而这些企业可能倒闭,或者开始了恐怖的吸金过程。所以,要实施安全的云计算,并相 应地去架构你的系统,这样你才能够在两个或以上的云供应商之间实现“负载均衡”。这是 独立性的首要模式,也就是选择。这是我们要注意的地方。. William Vambenepe: 1. 从应用的视角进行管理。仅仅监控基础设施或基本的应用指标(如一些请求的响应时间) 是不够的。你要非常细致地检测应用、跟踪请求、深入应用运行的各个层次。黑盒监控 (局限于从应用外部能看到的视图)能够得到漂亮的仪表板,但不可能进行优化和检测。 更通俗地说,就是要架构可支撑性(并使用技术设施提供商提供的这一能力)。云导致了 职责领域的划分,这种划分一般而言是强大的、大规模的,但是一旦问题出现时,它就 可能产生支撑上的障碍。许多角色都可能会牵扯进来,比如终端用户、终端用户所在组 织的支持人员、应用程序管理员、基础设施管理员、云环境或应用运行时供应商等。确 保应用基础设施能够产生全面的、可共享的时间报告,它们可能与基础设施管理工具相 关。此外,在共享支持信息的同时,还需要确保尊重应用的私密性规则以及及其边界。 2. 不仅仅要好的架构,还要满足业务用户的需求。确保你够生成资源消耗报表、管理各种 指标、管理退款、提供报告、监控 SLA、计划未来用量、在企业的子实体间分发配置。 换言之,要能够管理应用部署的各个业务方面。 3. 了解哪里需要标准(标准很重要),哪里不需要标准(标准不重要)。不要使那些专有需 求和不标准的框架溜进你的业务应用。另一方面,在生命周期管理端(如云 API)还需 要一些粘合代码,对它们不要过于担心。这一端暂时尚无标准,所以无需担心。只要你 使用了好的架构管理平台,运行管理就不至于失控。而应用的业务逻辑则是重点保护对 象,它们应该使用标准来保护。 68
74. David Linthicum:首先,一定要有好的架构流程去定义、开发、测试和部署解决方案。许多 IT 组织似乎缺少这一过程,而只是没有计划地扎进云计算。要用 SOA 方法来进行这一过程, 你可以从我和其他人写的书中学习如何正确使用 SOA。 其次,解决方案中一定要考虑治理和安全。当管理数百个服务和新的安全隐患时,这些概念 在你的云架构中应该全面。多数人都是事后做的。 最后,一定要考虑性能和稳定性。使用来自数百个位置的数百个服务,听起来是个好主意。 但是,它很容易导致性能和稳定性方面的问题,除非你非常了解这个系统,并密接监控它的 运行。你必须在解决方案中设计性能和稳定性,不论是云或非云。 JP Morgenthal: 1. 建立强大的成功度量规则。 2. 建立合适的治理框架。 3. 考虑你的云服务供应商消失的情况、提供超越你预期客户数的扩展能力、不要预支明年 的预算。本质上说就是计划不确定性。 Rob High:云用户包括云消费者和服务提供者。云消费者是指直接从服务本身获取使用价值, 或将服务与其他事物结合起来产生更大价值的人;而服务提供者则是指那些寻找更好的进行 规模运维和交付方法的人。不论是哪一方,它们都需要关注的是: 1. 遵循松耦合原则,特别是封装和透明化。 2. 意识到云交付形成了市场经济的基础;那么云服务的透明性就意味着消费者可以容易地 从不同的服务供应商间选择服务——服务的质量和价值在服务实现中变得越来越重要。 3. 云经济的一个重要驱动因素是运维成本的降低,它只能在服务的实现支持虚拟化、弹性 和高稠度的基础上才能实现,这些都是云基础设施提供的。所以,在许多情况下,你将 不得不明确地构建你的服务,以实现某种程度的细粒度、多租户和隔离。 总结 令人惊讶的是,虽然是从不同的角度看待问题,但是多数专家在以下几个方面的看法是一致 的: 1. 没有合适的架构,云实施不可能成功。这意味着两个方面都要运用 SOA,应用——合适 的分解;基础设施——基于服务的访问。 69
75. 2. 与云计算最相关的 SOA 原则是松耦合、治理和可管理性。 3. 正如标准在 SOA 发展过程中所起到的辅助作用一样,它对于云计算的成熟一样重要。 4. 从长期来看,过度炒作会损害云计算。云计算若要赢得持久的拥戴,就需要足够多的成 功案例。 关于研讨会专家 David S. Linthicum 是 Blue Mountain Labs 的 创始人兼 CTO,也是国际知名的 行业专家和思想领袖,也是 13 本计算科学著作的作者或合著者,其中包括最 畅销图书《企业应用集成》(Addison- Wesley 出版社出版)。Dave 在云计算、 SOA、Web2.0 和企业架构等方面的多场领先的技术大会上发表过专题演讲, 还频频作为计算专家出现在电 视与广播节目中。在其职业生涯中,Dave 已经在分布式计算 的诸多方面,如企业应用集成、B2B 应用集成、和 SOA,形成并加强了的许多理念,所有这 些理 念都至今都得到了广泛的应用。最近十年,Dave 集中于云计算相关的技术与战略的研 究以及如何使云计算为当今企业所用,此经历中包含了与好几个云计算新兴 企业的合作。 Dave 的行业经历丰富,曾是多个成功的软件公司的 CTO 和 CEO,也曾在财富 100 强企业中 担任过高层管理职位。此外,他已有 8 年的计算机 科学的副教授经历,并且继续在主要的 技术学院和大学中做演讲,其中包括弗吉尼亚大学、亚利桑那州立大学、和威斯康辛大学。 Dave 最近的著作是《云计算与 SOA》,你也可以在 Twitter 上跟踪 Dave。 JP Morgenthal 是 Smartronix 的云计算布道师。他有 20 多年信息技术的多个技 术及业务需求领域的经验,拥有丰富的完整 系统设计、业务价值分析和风险 /回报分析的能力。Morgenthal 先生能够与总裁级别的非技术人员和工程师级 别的人有效地进行书面及口头形式的沟通,也是云计算、企业架构、SOA/BPM 等领域备受尊敬的权威。他还编著 了三本书。 Miko Matsumura 目前是 Servo Software 和 Synclore 合并后的 Kii 公司的产品部 副总裁。在此工作之前,他曾担任 Software AG 的副总裁及首席战略家,在 Software AG 收购 webMethods 之前,它在 webMethods 担任 SOA 产品市场部 的副总裁,而在 webMethods 收购了 Infravio 之前,他是 Infravio 全球市场部 的副总裁。在此之前,他是 Sun 公司的 Java 平台部的首席 Java 布道师。他在许多软件创业 公司里工作过,为硅谷和海外的创 业公司募资超过 1200 万美元。他也与投资银行、风头公 司和创业者有紧密联系。Matsumura 获得了 San Francisco 州立大学的 MBA 和耶鲁大学的神 经科学系的硕士学位。 70
76. Matsumura 在 2009 年云展会上被提名为全球前 30 位最有影响力的虚拟化博主。它也是 《SOA Adoption for Dummies》一书的作者。 Rob High 是 SOA 基础部的首席架构师、IBM 董事、副总裁、IBM 科学院成员。 他负责确保使用 SOA 原则和业务流程优化 (Business Process Optimization) 实现业务和 IT 对齐的开放的行业架构定义,他还负责确保使用 IBM 软件和服 务来支撑架构以产生有效的 SOA 解决方案。这一职责 还延伸到其它 IBM 软 件品牌,如使用 WebSphere、Rational、Tivoli、Lotus 和 IM 的相关产品实现 SOA。 William Vambenepe 是 Oracle 的的架构师,他主要负责应用管理和云计算。 这里有他的博客和 Twitter:@vambenepe。  本文是 SOA 和 Cloud Computing 特色话题系列的一部分。  更多 SOA 内容:http://www.infoq.com/soa  更多云计算内容:http://www.infoq.com/cloud-computing  参考其他相关内容  SOA DIY:构建简易的服务注册库  SpringSource CTO Adrian Colyer 探讨云计算对企业 IT 的影响 原文链接:http://www.infoq.com/cn/articles/SOACloudPanel 相关内容:  百度私有云建设和开发部分云端服务  SOA 在新兴的 Hadoop 世界扮演的角色  2011 SOA 虚拟研讨会  专家视角看 IT 与架构  互联网超级云计算平台 71
77. 推荐文章 Articles 语言设计的艺术——读《松本行弘的程序世界》 作者 崔康 利用 QCon 杭州 2011 大会的间歇期,读完了《松本行弘的程序世界》的 最后几章,合上书还觉得意犹未尽。众所周知,松本行弘是 Ruby 的发明 者,这本书 是他的技术文集,主要章节在过去几年先后发表在日本的技 术杂志上。坦白的说,我对 Ruby 语言本身没有深入的研究和实践,所以 阅读本书的目的是想从一个旁 观者的角度了解编程语言在设计方面的 各种考量、各种语言的特性对比以及对编程开发的影响。毫无疑问,这 本书满足了我的需求。不想说太多空泛的话,在这里分 享一下自己的阅读心得和一些思考。 经常在技术论坛中看到类似于“xx 语言和 yy 语言哪一个更好?” “zz 语言有没有前途?”的 提问,然后众说纷纭,群情激昂。有一种观点认为:编程语言都一样,学会了其中一种,另 外的都触类旁通。这种说法有一定道理,各种语言在不少方面都存在共性,毕竟都是“语言”。 不过,语言之间的差距也非常大,这也是编程语言层出不穷的原因。大部分编程语言都是“图 灵完备”的,这意味着彼此可以实现等价的程序。不过,语言的选择在一定程度上决定着开 发效率。由于语言适用的领域各不相同,而且语言的生态系统(依附的厂商、集成开发环境、 虚拟机、社区推广、第三方函数库支持等)也许比语言本身更有影响力,所以我们只是从一 般的角度来分析语言在设计上的考量。 面向对象 面向对象的设计方法已经深入人心,大多数现代语言都支持面向对象编程。多态性、数据抽 象和继承是面向对象编程的三个基本原则。从数据抽象角度来说,Ruby 直接提供了栈等数 据结构的支持,并隐藏了实现的细节。多态性和继承密不可分。目前在编程语言中存在多种 继承方法,有多重继承、单一继承和 Mix-in 继承。对于开发人员来说,哪种方式更有效率呢? 单一继承(如 Smalltalk)的优点是:继承关系是单纯的树结构,类之间的关系不会发生混乱, 实现起来也较简单,缺点是:无法通过继承来共享多重程序代码,导致代码的冗余。多重继 承(如 C++)的优点是:可以继承多个类的功能,扩展了单一继承。缺点是:类之间的关系 72
78. 会变得复杂,一个类可能有多个父类,这些父类又有自己的父类,继承关系不如单一继承清 晰,继承的优先顺序和功能可能存在冲突。开发人员既想利用多重继承的优 点,又想避免 它带来的麻烦,所以需要引入受限制的多重继承。Java 提供的解决方案是——接口。Java 只允许开发人员继承(extends)单个父类, 但是可以实现(implements)多个接口。仔细 想想,Java 提供的这种解决方案是实现了“类规范”(即接口的方法声明)的多重继承,可 以满足多态性的要求。但是,如果开发人员需要复用类的实现代码呢?如何完成“类实现” (类的实现代码)的多重继承呢?Ruby 的设计者松本行弘在评估了各种语言在这方面的优 劣之后,借鉴了 Lisp 语言的 Mix-in 继承模式。这种模式的规则是:通常的继承用单一继承 实现;第二个以及两个以上的父类必须是 Mix-in 类。Mix-in 类的特征是:不能单独生成实例; 不能继承普通类。这种继承模式可以保证类的层次结构和单一继承一样的树结构,同时又可 以实现功能共享。开发人员可以把想要共享的代码放在 Mix-in 类中,然后把 Mix-in 类插入 到继承结构中,从而满足“类实现”的多重继承。开发人员利用支持 Mix-in 的语言做面向对 象编程时会更加方便。值得注意的是,松本行弘在设计 Ruby 的时候,Mix-in 模式并不流行, 但是他坚持了自己的判断,在 Ruby 中采用了该模式,时至今日,Mix-in 受到越来越多开发 人员的欢迎。松本行弘的前瞻性建立在对各种语言深入的分析和评估的基础之上,具有扎实 的依据,我们开发人员在预研某些技术时,不妨借鉴其做法。 元编程 元编程支持在编程语言特性中占有重要的地位,开发人员可能对反射等概念比较了解,“在 代码中动态分析、生成代码”的元编程能力对于基于编程语言的开发框架来说很重要,如果 语言自身提供了强大的元编程支持,框架的开发者会事半功倍。Ruby 提供了 attr_accessor 方法,支持开发人员动态生成访问变量的方法。Ruby 的反射功能可以获取、更改各种范围 内的变量值,而且能够获取、删除类方法,以及其他一些分析功能,当开发人员希望实现“通 用编程”的模式或者后面提到的猴子补丁时,这些元编程功能会提供有效的支持。相比之下, C、C++语言可能实现起来就比较困难,虽然存在宏定义等低效的办法。 高阶函数 高阶函数的使用同样可以提高开发效率,在函数模板化、容器迭代器等方面有着重要的应用。 高阶函数在 C 语言中采用了传递函数指针的形式来实现,但是存在局限性,即实现函数间的 信息传递只有两种方法,要么明确地传递参数,要么使用全局变量。这种限制导致代码编写 的低效。为了解决此问题,Ruby 和 Javascript 语言引入了闭包的概念,即函数(块)可以引 用外部的局部变量。通常的外部变量在方法执行结束时就不存在了,但是如果被包括进了闭 73
79. 包,那么在闭包存在期间,外部局部变量也会一直存在(当然,闭包也会引起潜在的内存泄 露问题)。Ruby 中的块结构是高阶函数的一种特殊形式,代码块可以作为参数传递给方法, 在被调用的方法中可以执行传递过来的代码块,执行后程序的控制权返还给方法,块中最后 执行的表达式的值是块的值,这个值可以返回给方法。块结构的经典应用是对集合对象(容 器)的处理,比如循环执行、条件排序、条件搜索等,开发人员只需把块结构传递给容器方 法,就可以方便的执行块结构中的表达式并返回结果。之前 C++和 Java 等容器类的迭代器, 使用别的类对象来处理容器元素,属于外部迭代器。Ruby 通过块结构和闭包实现了内部迭 代器,不用额外生成对象。Ruby 中的集合方法非常丰富,包括 all、any、find、map、min、 max、select、sort、inject 等,这样的设计能够让对数据结构和算法有要求的开发人员操作 起来更加简洁和高效。 设计模式 提到设计模式,大家可能首先想到了著名的“四人帮”,还有他们归纳的 23 个设计模式。设 计模式在软件开发中的作用不言而喻,开发人员会有意无意的借鉴这些模式,语言的支持程 度对开发效率的影响不可小觑。Ruby 的语言库很丰富,提供了多种设计模式的支持。比如 singleton 库支持 singleten 模式、delegate 库支持 proxy 模式、块结构支持 iterator 模式、clone 方法支持 prototype 模式、observer 库支持 observer 模式,当然语言库的设计也利用了不少 设计模式,比如上面讲到的容器集合方法 Enumerable 模块使用了 Template Method 模式来 支持开发人员通过块结构来指定所需的算法。语言的设计者一方面要利用设计模式来优化语 言库的结构,另一方面也会通过语言库自身来帮助开发人员在编程实践时更方便地使用设计 模式。 猴子补丁 编程语言对于猴子补丁的支持对软件开发同样重要。猴子补丁可以解释为,不改变源代码而 对功能进行追加和变更。软件开发过程中,有一个著名的开放-封闭原则(open-closed principle):对模块扩展必须开放,对修改必须封闭。模块是可以扩展的,比如追加新的数据 结构或者功能,能够满足未来的需求。修改是封闭的,指被引用的模块内部细节发生变化时, 对外接口应当是稳定的。猴子补丁能够遵循该原则,它的主要目的包括追加和变更功能、修 补程序错误等。Ruby 这样的语言提供了开放类,也就是说类定义之后也能任意的追加新内 容,不仅如此,Ruby 还提供了若干类操作方法,undef 可以取消之前本类或者父类定义的方 法,alias 可以给方法起一个别名,开发人员可以在重新定义的方法中用别名来调用原来的方 法,从而给原来的方法增加新功能,include 可以把其他模块的功能包含进来。Ruby 提供的 74
80. 这些方法使猴子补丁的实现过程更容易,对比 Java 等静态语言,读者可以发现 Ruby 语言在 这方面处理灵活,开发效率更高。 数据类型与文字编码 语言的类型定义和编码是开发人员接触的基本知识,在日常工作中应用广泛。因此,语言在 设计时对数据类型的内部实现是否具有扩展性和前瞻性就非常重要。比如语言选择的文字编 码,有 UCS(Universal Character Set)方式和 CSI(Character Set Independent)方式。UCS 方 式指输入输出时,语言把文本数据变成统一的文字集(如 UTF-8),内部对文本数据进行统 一处理。UCS 的方式得到各种编程语言的青睐。而 CSI 方式则指不对各种文字集和编码方式 做任何变换,原封不动的进行处理。UCS 和 CSI 方式的优缺点都很明显,这里不过多讨论。 举例来说,Java 采用 UCS 方式,内部字符编码为 UTF-16,所以 Java 的 char 类型是 16 位。Java 语言诞生时,Unicode 仅限于 16 位,可以猜想这也是其设计者选择 UTF-16 编码方式的原因 之一。但时过境迁,如今 Unicode 标准采用 21 位表示一个文字,所以 Java 的 API 需要升级 才能处理变化之后的 Unicode 字符,开发人员可能需要作出相应的变更。Ruby 采用 CSI 方式, 提供了若干编码方式的支持。我们不能笼统的说孰优孰劣,但是语言对字符类型和函数的设 计对开发人员的效率有着直接的影响。同样的,整数、浮点数的类型定义也是语言设计的考 察点。相比某些语言对数字类型的位数限制,Ruby 则提供了支持扩展的整数类型 Bignum、 浮点数类型 BigDecimal,还有能够表示分数的 Rational 类。 函数式编程 函数式编程是与面向对象编程相提并论的编程方法,最近越来越受到关注,它的最大优点在 于,程序可以按照数学的形式以及声明的形式来编写。支持函数式编程的语言能够帮助开发 人员把工作重点放在描述算法上,而不是具体的实现操作。像 Lisp、Erlang 和 Ruby 都支持 函数式编程,不少语言是各种结构化编程、面向对象编程和函数式编程的混合体,开发人员 可以根据需要选择高效的编程方式。说起这个话题,笔者不禁想起技术专家老赵,他经常会 在讲座前拿容器的集合方法为例对比 Java 和 C#的代码实现,强调声明式编程和 Lambda 表 达式的好处,Ruby 这样的语言在设计时对此有所考虑,并选择了有益的实现。 虚拟机和垃圾回收 虚拟机的诞生从某种程度上解决了语言在软件开发中的跨平台问题,虚拟机对开发人员隐藏 了操作系统级别的差异,语言库的 API 接口保持一致。除了少数传统语言,许多现代语言都 使用了自动垃圾回收机制。开发人员无需手动处理对象的内存,省去了不少精力。当然,自 75
81. 动垃圾回收并不意味着没有内存泄露,错误的代码会让垃圾回收器无法释放废弃的对象。除 此之外,垃圾回收器的性能也值得关注,如今垃圾回收算法多种多样,适用于不用的业务场 景,开发人员需要关注。语言所依赖的虚拟机其可靠性和性能如何,是考量的一个因素, Node.js 的创始人就是因为对 Ruby 虚拟机的性能不满意而选择了 C 和 Javascript 作为 Node.js 的实现语言。 动态类型与静态类型 静态类型和动态类型之争一直在持续。静态类型的优点在于编译时能够发现类型不匹配的错 误,方便做优化,提高程序执行速度。缺点是作为辅助信息的数据类型一定程度上影响了开 发人员对程序本质的关注,而且不够灵活。动态类型的优点在于源代码变得很简洁,可以灵 活的处理未指定类型的变量,包括只关心行为的 Duck Typing。缺点是在多数情况下,运行 速度逊于静态类型语言,而且不执行程序就难以检测出错误。Java 是静态语言,Ruby 是动 态语言,它们各有千秋,都有广泛的应用,但是目前看来,动态语言简洁的编程风格受到越 来越多开发者的欢迎。谷歌最近推出的 Web 编程语言 Dart 则是兼顾了两者,开发人员可以 根据自己的偏好和项目的阶段来选择是否为变量指定静态数据类型,按照其说法,项目初期 采用动态类型快速构建,后期通过静态类型使程序更稳定和模块化,为开发人员提供了一种 新思路。 小结 有关语言设计的讨论涉及到很多方面,我们无法一一分析。比如,语言对正则表达式的支持 程度如何?异常处理的设计是否合理?数据持久化是否方便?并行处理的能力如何?这些 方面在分析语言的优缺点时也需要谨慎的考虑。同时,语言的生态系统也是考量的重要因素, 集成开发环境、社区和厂商的支持、普及程度等都是开发人员在选择编程语言时无法回避的 问题。很多时候,以如此细致、理性的标准来决定使用哪门语言是没有意义的,因为开发人 员受到环境的各种限制,老板的命令、公司的成见、团队的意见、硬件的配置、IDE 的支持、 学习曲线的陡峭程度等等因素,都会影响开发者对编程语言的取舍。那么,我们学习松本行 弘的设计思想有什么意义呢?在语言学有一个 Sapir-Whirf 假说,认为语言可以影响说话者 的思想。计算机语言同样可以影响开发人员的思考方式和由此产生的代码。Ruby 语言在设 计方面的考量和选择,能够帮助开发人员以更广阔的视角和更高的层次来看待软件开发中遇 到的问题,解决的思路可以更加多样化。即使开发者的语言各种各样,Ruby 的思想在软件 开发的设计、编码方面仍然有宝贵的参考价值,《松本行弘的程序世界》是一个学习的切入 点。 76
82. 推荐文章 Articles 一个前端工程师眼里的 NodeJS 作者 田永强 JavaScript 单线程的误解 在我接触 JavaScript(无论浏览器还是 NodeJS)的时间里,总是遇到有朋友有多线程的需求。 而在 NodeJS 方面,有朋友甚至直接说到,NodeJS 是单线程的,无法很好的利用多核 CPU。 诚然,在前端的浏览器中,由于前端的 JavaScript 与 UI 占据同一线程,执行 JavaScript 确实 为 UI 响应造成了一定程度上的麻烦。但是,除非用到超大的循环语句执行 JavaScript,或是 用阻塞式的 Ajax,或是太过频繁的定时器执行外,JavaScript 并没有给前端应用带来明显的 问题,所以也很少有朋友抱怨 JavaScript 是单线程而不能很好利用多核 CPU 的问题,因为没 有因此出现性能瓶颈。 但是,我们可以用 Ajax 和 Web Worker 回应这个误解。当 Ajax 请求发送之后,除非是同步请 求,否则其余的 JavaScript 代码会很快被执行到。在 Ajax 发送完成,直到接收到响应的这段 时间里,这个网络请求并不会阻塞 JavaScript 的执行,而网络请求已经发生,这是必然的事。 那么,答案就很明显了,JavaScript 确实是执行在单线程上的,但是,整个 Web 应用执行的 宿主(浏览器)并非以单线程的方式在执行。而 Web Worker 的产生,就是直接为了解决 JavaScript 与 UI 占用同一线程造成的 UI 响应问题的,它能新开一条线程去执行 JavaScript。 同理,NodeJS 中的 JavaScript 也确实是在单线程上执行,但是作为宿主的 NodeJS,它本身并 非是单线程的,NodeJS 在 I/O 方面有动用到一小部分额外的线程协助实现异步。程序员没有 机会直接创建线程,这也是有的同学想当然的认为 NodeJS 的单线程无法很好的利用多核 CPU 的原因,他们甚至会说,难以想象由多人一起协作开发一个单线程的程序。 NodeJS 封装了内部的异步实现后,导致程序员无法直接操作线程,也就造成所有的业务逻 辑运算都会丢到 JavaScript 的执行线程上,这也就意味着,在高并发请求的时候,I/O 的问题 是很好的解决了,但是所有的业务逻辑运算积少成多地都运行在 JavaScript 线程上,形成了 一条拥挤的 JavaScript 运算线程。NodeJS 的弱点在这个时候会暴露出来,单线程执行运算形 77
83. 成的瓶颈,拖慢了 I/O 的效率。这大概可以算得上是密集运算情况下无法很好利用多核 CPU 的缺点。这条拥挤的 JavaScript 线程,给 I/O 形成了性能上限。 但是,事情又并非绝对的。回到前端浏览器中,为了解决线程拥挤的情况,Web Worker 应 运而生。而同样,Node 也提供了 child_process.fork 来创建 Node 的子进程。在一个 Node 进 程就能很好的解决密集 I/O 的情况下,fork 出来的其余 Node 子进程可以当作常驻服务来解 决运算阻塞的问题(将运算分发到多个 Node 子进程中上去,与 Apache 创建多个子进程类 似)。当然 child_process/Web Worker 的机制永远只能解决单台机器的问题,大的 Web 应用 是不可能一台服务器就能完成所有的请求服务的。拜 NodeJS 在 I/O 上的优势,跨 OS 的多 Node 之间通信的是不算什么问题的。解决 NodeJS 的运算密集问题的答案其实也是非常简单 的,就是将运算分发到多个 CPU 上。请参考文章后的 multi-node 的性能测试,可以看到在 多 Node 进程的情景下,响应请求的速度被大幅度提高(感谢 CNode 社区的 snoopy 友情测 试)。 在文章的写作过程中,Node 最新发布的 0.6.0 版本,新增了 cluster 模块。该模块的作用是 可以通过 fork 的方式创建出多个子进程实例,这些实例会自动共享相同的侦听端口。你可 以根据当前计算机上的 CPU 数量来创建相应的实例数,以此达到分发请求,充分利用 CPU 的目的。详情请参阅官方文档。在之前的解决运算密集问题中,工程师需要 multi-node 这样 的库或者其他方案去手动分发请求,在 cluster 模块的支持下,可以释放掉工程师在解决此 问题上的大部分精力。 事件式编程 延续上一节的讨论。我们知道 NodeJS/JavaScript 具有异步的特性,从 NodeJS 的 API 设计中 可以看出来,任何涉及 I/O 的操作,几乎都被设计成事件回调的形式,且大多数的类都继承 自 EventEmitter。这么做的好处有两个,一个是充分利用无阻塞 I/O 的特性,提高性能;另 一个好处则是封装了底层的线程细节,通过事件消息留出业务的关注点给编程者,从而不用 关注多线程编程里牵扯到的诸多技术细节。 从现实的角度而言,事件式编程也更贴合现实。举一个业务场景为例:家庭主妇在家中准备 中餐,她需要完成两道菜,一道拌黄瓜,一道西红柿蛋汤。以 PHP 为例,家庭主妇会先做 完拌黄瓜,接着完成西红柿蛋汤,是以顺序/串行执行的。但是现在突然出了一点意外,凉 拌黄瓜需要的酱油用光了,需要她儿子出门帮她买酱油回来。那么 PHP 家庭主妇在叫她儿 子出门打酱油的这段时间都是属于等待状态的,直到酱油买回来,才会继续下一道菜的制作。 那么,在 NodeJS 的家庭主妇又会是怎样一个场景呢,很明显,在等待儿子打酱油回来的时 78
84. 间里,她可以暂停凉拌黄瓜的制作,而直接进行西红柿蛋汤的过程,儿子打完酱油回来,继 续完成她的凉拌黄瓜。没有浪费掉等待的时间。实例伪代码如下: var mother = new People(); var child = new People(); child.buySoy(function (soy) { mother.cook("cucumber", soy); }); mother.cook("tomato"); 接下来,将上面这段代码转换为基于事件/任务异步模式的代码: var proxy = new EventProxy(); var mother = new People(); proxy.bind("cook_cucumber", function (soy) { mother.cook("cucumber", soy); }); proxy.bind("cook_tomato", function () { mother.cook("tomato"); }); var child = new People(); child.buySoy(function (soy) { proxy.trigger("cucumber", soy); }); proxy.trigger("tomato"); 代码量多了很多,但是业务逻辑点都是很清楚的:通过 bind 方法预定义了 cook_cucumber 和 cook_tomato 两个任务。这里的 bind 方法可以认为是 await 的消息式实现,需要第一个参 数来标识该任务的名字,流程在执行的过程中产生的消息会触发这些任务执行。可以看出, 事件式编程中,用户只需要关注它所需要的几个业务事件点就可以,中间的等待都由底层为 你调配好了。这里的代码只是举例事件/任务异步模式而用,在简单的场景中,第一段代码 即可。做 NodeJS 的编程,会更感觉是在做现实的业务场景设计和任务调度,没有顺序保证, 程序结构更像是一个状态机。 个人觉得在事件式编程中,程序员需要转换一下思维,才能接受和发挥好这种异步/无阻塞 的优势。同样,这种事件式编程带来的一个问题就在于业务逻辑是松散和碎片式的。这对习 惯了顺序式,Promise 式编程的同学而言,接受它是比较痛苦的事情,而且这种散布的业务 逻辑对于非一开始就清楚设计的人而言,阅读存在相当大的问题。 我提到事件式编程更贴近于现实生活,是更自然的,所以这种编程风格也导致你的代码跟你 的生活一样,是一件复杂的事情。幸运的是,自己的生活要自己去面对,对于一个项目而言, 并不需要每个人都去设计整个大业务逻辑,对于架构师而言,业务逻辑是明了的,借助事件 式编程带来的业务逻辑松耦合的好处,在设定大框架后,将业务逻辑划分为适当的粒度,对 79
85. 每一个实现业务点的程序员而言,并没有这个痛苦存在。二八原则在这个地方非常有效。 深度嵌套回调问题 JavaScript/NodeJS 对单个异步事件的处理十分容易,但容易出现问题出现的地方是“多个异 步事件之间的结果协作”。以 NodeJS 服务端渲染页面为例,渲染需要数据,模板,本地化资 源文件,这三个部分都是要通过异步来获取的,原生代码的写法会导致嵌套,因为只有这样 才能保证渲染的时候数据,模板,本地化资源都已经获取到了。但问题是,这三个步骤之间 实际是无耦合的,却因为原生代码没有 promise 的机制,将可以并行执行(充分利用无阻塞 I/O)的步骤,变成串行执行的过程,直接降低了性能。代码如下: var render = function (template, data) { _.template(template, data); }; $.get("template", function (template) { // something $.get("data", function (data) { // something $.get("l10n", function (l10n) { // something render(template, data); }); }); }); 面对这样的代码,许多工程师都表示不爽。这个弱点也形成了对 NodeJS 推广的一个不大不 小的障碍。对于追求性能和维护性的同学,肯定不满足于以上的做法。本人对于 JavaScript 的事件和回调都略有偏爱,并且认为事件,回调,并行,松耦合是可以达成一致的。以下一 段代码是用 EventProxy 实现的: var proxy = new EventProxy(); var render = function (template, data, l10n) { _.template(template, data); }; proxy.assign("template", "data", "l10n", render); $.get("template", function (template) { // something proxy.trigger("template", template); }); $.get("data", function (data) { // something proxy.trigger("data", data); }); $.get("l10n", function (l10n) { // something proxy.trigger("l10n", l10n); }); 代码量看起来比原生实现略多,但是从逻辑而言十分清晰。模板、数据、本地化资源并行获 取,性能上的提高不言而喻,assign 方法充分利用了事件机制来保证最终结果的正确性。在 80
86. 事件,回调,并行,松耦合几个点上都达到期望的要求。 关于更多 EventProxy 的细节可参考其官方页面。 深度回调问题的延伸 EventProxy 解决深度回调的方式完全基于事件机制,这需要建立在事件式编程的认同上,那 么必然也存在对事 件式编程不 认同的同学,而且习惯顺序式,promise 式,向其推广 bind/trigger 模式实在难以被他们接受。Jscex 和 Streamline.js 是目前比较成熟的同步式编程 的解决方案。可以通过同步式的思维来进行编程,最终执行的代码是通过编译后的目标代码, 以此通过工具来协助用户转变思维。 结语 对于优秀的东西,我们不能因为其表面的瑕疵而弃之不用,总会有折衷的方案来满足需求。 NodeJS 在实时性方面的功效有目共睹,即便会有一些明显的缺点,但是随着一些解决方案 的出现,相信没有什么可以挡住其前进的脚步。 附录(多核环境下的并发测试) 服务器环境:  网络环境:内网  压力测试服务器:  服务器系统:Linux 2.6.18  服务器配置:Intel(R) Xeon(TM) CPU 3.40GHz 4 CPUS  内存:6GB  NodeJS 版本: v0.4.12 客户端测试环境:  发包工具:apache 2.2.19 自带的 ab 测试工具  服务器系统:Linux 2.6.18  服务器配置:Pentium(R) Dual-Core CPU E5800 @ 3.20GHz 2CPUS 81
87.  内存:1GB 单线程 Node 代码: var http = require('http'); var server = http.createServer(function (request, response) { var j = 0; for (var i = 0; i & lt; 100000; i++) { j += 2 / 3; } response.end(j + ''); }); server.listen(8881); console.log('Server running at http://10.1.10.150:8881/'); 四进程 Node 代码: var http = require('http'); var server = http.createServer(function (request, response) { var j = 0; for (var i = 0; i & lt; 100000; i++) { j += 2 / 3; } response.end(j + ''); }); var nodes = require("./lib/multi-node").listen({ port: 8883, nodes: 4 }, server); console.log('Server running at http://10.1.10.150:8883/'); 这里简单介绍一下 multi-node 这个插件,这个插件就是利用 require("child_process").spawn() 方法来创建多个子线程。由于浮点计算和字符串拼接都是比较耗 CPU 的运算,所以这里我 们循环 10W 次,每次对 j 加上 0.66666。最后比较一下,开多子进程 node 到底比单进程 node 在 CPU 密集运算上快多少。 以下是测试结果: Comm. Type 500/30 500/30 1000/30 1000/30 3000/30 3000/30 单进程 多子进程 单进程 多子进程 单进程 多子进程 RPS 2595 5597 2540 5509 2571 5560 TPQ 0.38 0.18 0.39 0.19 0.39 0.18 80% REQ 72 65 102 85 157 142 82
88. Fail 0 0 0 0 0 0 说明:  单进程:只开一个 node.js 进程。  多子进程:开一个 node.js 进程,并且开 3 个它的子进程。  3000/30:代表命令 ./ab -c 3000 -t 30 http://10.1.10.150:8888/。3000 个客户端,最多发 30 秒,最多发 5W 个请求。  RPS:代表每秒处理请求数,并发的主要指标。  TPQ:每个请求处理的时间,单位毫秒。  Fail:代表平均处理失败请求个数。  80% Req:代表 80%的请求在多少毫秒内返回。 从结果及图 1~3 上看:开多个子进程可以显著缓解 node.js 的 CPU 利用率不足的情况,提 高 node.js 的 CPU 密集计算能力。 图 1:单个进程的 node.js 在压力测试下的情况,无法充分利用 4 核 CPU 的服务器性能。 图 2:多进程 node,可以充分利用 4 核 CPU 榨干服务器的性能。 83
89. 图 3:多子进程截图,可以看到一共跑了 4 个进程。 关于作者 田永强,前端工程师,就职于 SAP,从事 Mobile Web App 方面的研发工作,对 NodeJS 持有 高度的热情,寄望打通前端 JavaScript 与 NodeJS 的隔阂,将 NodeJS 引荐给更多的前端工程 师。 原文链接:http://www.infoq.com/cn/articles/nodejs-in-front-end-engineer-view 相关内容:  CNodeJS 社区的 Node App Engine 启动内测  Facebook 和 Heroku 结成伙伴关系  JavaScript 异步编程的 Promise 模式  Node.js 与 Rails 如何选择?  我为什么向后端工程师推荐 Node.js 84
90. 1
91. 新品推荐 New Products JQuery Mobile 1.0 发布,人们反响不一 作者 Roopesh Shenoy 译者 张龙 近日,JQuery Mobile 1.0 发布了,用户可以在其网站上下载。该框架构建在 JQuery 与 JQuery UI 之上,支持所有主流的移动、平板、电子阅读器、甚至 是桌面平台。借助于诸如 PhoneGap 之类的工具,用户甚至可以将 JQuery Mobile 代码转换为混合或是原生应用,这样就可以在所有流行的应用商店上发布了。 原文链接:http://www.infoq.com/cn/news/2011/11/jquery-mobile-1 Google Eclipse Plugin 现已开源 作者 Alex Blewitt 译者 贾国清 Google 已宣称将其 Google Plugin for Eclipse 开源。该插件于 2009 年 4 月作为封闭源代码 项目发布,继 Google 在 2010 年的 9 月收购了 Eclipse 工具厂商 Instantiations 后,在 2010 年 12 月将其中的拳头产品 WindowBuilder 和 CodePro Profiler 捐赠给 Eclipse 基金会。在 昨天以前,GWT Designer 项目还没有被开源。而现在,随着 Google Plugin for Eclipse 项目 的开源,GWT Designer 也在 Eclipse 公共许可下开源并且提交到 Google Code。 原文链接:http://www.infoq.com/cn/news/2011/11/google-plugin eBay 使用 Hadoop 和 HBase 成功构建下一代搜索 作者 Ron Bodkin 译者 詹涛 eBay 在 Hadoop 世界(Hadoop World)大会的主题演讲中展示了一种全新的搜索引擎 Cassini 的架构,该引擎预计在 2012 年上线。它对所有的内容和用户的元数据进行索引 来得到更好的排名,并每小时刷新索引。它使用 Apache Hadoop 来支持每小时进行的索 85
92. 引更新,使用 Apache HBase 对随机存取信息提供支持。 原文链接:http://www.infoq.com/cn/news/2011/11/eBay_new_search Visual Studio 11 预览: 新的编程语言功能 作者 Jeff Martin 译者 高翌翔 每个版本的 Visual Studio 开发环境通常都会在其 IDE 及其支持的编程语言中引入一 些新功能。微软开发部副总裁 S. Somasegar 最近展示了一些即将出现在 Visual Studio 11 中的新的编程语言功能。 原文链接:http://www.infoq.com/cn/news/2011/11/vs11_programming_features SQL Server Integration Services 2012 将支持 ODBC 作者 Jonathan Allen 译者 侯伯薇 SQL Server 已经放弃 OleDB,支持 ODBC,这样 SQL Server Integration Services 最 终支持 ODBC 也就不足为奇了。Attunity 是微软在此特性上的合作伙伴,它还正 在开发名为变更数据捕获 Change Data Capture 的 SSIS 特性。 原文链接:http://www.infoq.com/cn/news/2011/11/SSIS-2012 Engine Yard 增加对 Node.js 的支持 作者 Werner Schuster 译者 贾国清 Node.js 已被越来越多的服务提供商所支持,其中就包括它的主要赞助商 Joyent 以 及如 Heroku 这样的 PaaS 提供商。日前,Engine Yard 也宣布了对 Node.js 的支持。 原文链接:http://www.infoq.com/cn/news/2011/11/engineyard-nodejs 86
93. Zing 5.0 发布,包含原生支持 Linux 的无停顿垃圾回收器 作者 Charles Humble 译者 钮玉晓 Azul Systems 于 11 月 8 日发布了 Zing 5.0,Zing 5.0 不再需要 hypervisor,得以第 一次以原生的方式支持 64 位的 Linux。 原文链接:http://www.infoq.com/cn/news/2011/11/zing5-native Chronon 2.0 支持 Post Execution Logging 作者 Alex Blewitt 译者 贾国清 Chronon Systems 公司最近发布了 Chronon 2.0,这款记录 JVM 信息的调试器 在 2.0 版本里支持 Post Execution Logging,即允许用户先执行、后记录日志。 原文链接:http://www.infoq.com/cn/news/2011/11/chronon-20 Apache Wicket 1.5 发布 作者 Kostis Kapelonis 译者 张龙 在收购 BitBucket 一周年的时候,Atlassian 宣布:除了长期以来一直支持的 Hg 存储库之 外,BitBucket 将提供 Git 存储库支持。 原文链接:http://www.infoq.com/cn/news/2011/11/wicket_1_5 87
94. 推荐编辑 翻译团队编辑 李永伦 大家好,我是李永伦,很高兴可以在这里和大家分享我的 想法。09 年 9 月份的时候,我开始在我的博客写一个关于 Ruby 编程语言的系列文章,就在我发布这个系列第二篇文 章之后,我收到了霍泰稳的邀请,加入 InfoQ 大家庭,成 为 Ruby 社区的编辑。 作为 Ruby 社区的一名编辑,我翻译的最多的却是和.NET 相关的新闻,这是我认为 InfoQ 一个很有意思的特点--自由 选择。这里没有硬性的限制,每个编辑可以根据自己的兴 趣和爱好选择喜欢的新闻来翻译,如果关注的技术发生改 变,还可以转到别的社区去。这种以兴趣为主导的方式大 大提升了编辑的积极性。 InfoQ 作为一个专业的网站,它对质量的追求可谓不遗余力。还记得第一次写原创新闻的时 候,泰稳审阅之后指出了诸多不足之处,并退回修改,我自问对于写作质量的要求已经非常 严格,那次的退稿实在让我感到惭愧,于是把新闻重写。一路以来,编辑之间经常相互审阅、 提出改善建议,目的只有一个--为读者提供高质量的内容。 编辑之间的相互切磋形成了 InfoQ 的第三个重要特点--关注成长。在编辑邮件列表里经常可 以看到编辑分享翻译心得,推荐提高翻译能力的书籍,以及把某些需要商酌的翻译拿出来和 大家讨论,相互学习、取长补短。成长,是人的基本诉求,而关注成长,则是一个组织做到 以人为本的必要条件。 当然,InfoQ 编辑团队的发展也并非一帆风顺的,一路以来我们也遇到过不少问题,比如说, 每个编辑都有自己的正职工作,怎样才能保证网站内容的质和量成为团队时刻需要面对的问 题。或许制度和规则能够带来一些帮助,但我认为每个编辑自身的觉悟和认识更为根本,仅 当我们对于编辑这个身份有较深的认同和使命感时,才会对正在从事的东西感到较大的自主 性,而不是一种被动的接受和要求。这种自省的特质可以帮助我们对自己的选择和决定有一 个更加清晰的了解。 最后,我庆幸加入 InfoQ 编辑团队这个大家庭,庆幸自己能够在这里认识一帮有意思的人, 庆幸能够在这里得到的锻炼和成长,更庆幸有这个机会和读者分享我的想法。 88
95. 封面植物 宝华玉兰 宝华玉兰:(Magnolia zenii Cheng)落叶小 乔木,国家一级保护植物。产于江苏省句容 县宝华山,产地仅存 18 株,已达到绝种的 边缘。加上本种花大美丽,是园林观赏树种 之上品,对植物分类系统之研究具有一定的 科学意义。 形态特征 落叶乔木,高约 11 米,胸径达 30 厘米;树干灰色或淡灰色,平滑;枝斜 上伸展;当年生小枝细长,绿黄色,无毛, 有皮孔,2 年生枝呈紫色。叶膜质,倒卵状长圆形,长 7-16 厘米,宽 3-7 厘米,上部宽,先 端急尖或尾状渐尖,基部宽楔形或圆形,上面无毛,暗绿色,下面沿叶脉有弯曲长毛,侧脉 每边 8-12;叶柄长 6-18 毫米。花牙卵圆形,具淡黄色长毛。花先叶开放,芳香,花被片 9, 近匙形,长 5-6 厘米,先端钝或急尖;不同单株花色有变异,花被片外面自近中部以下紫药 色,中部淡紫红色,上部白色,长 7-8 厘米;雄蕊多数,花线紫色,药隔突出呈短尖;雌蕊 群圆柱形,长约 2 厘米,直径 2-3 厘米,木质;近圆形,有疣点状起;种子每心皮 1 或 2, 不规则宽倒卵圆形,微扁,长宽约 1 厘米,外咱皮红色,内种皮黑色。 仅产江苏句容宝华 山。生于海拔 220 米的北坡小丘陵地上。 生长习性 种产地年平均温 16℃,7 月平均最高温 32℃,冬季低温通常-6 至-8℃,极端最 低温约-14℃,年降水量约 900 毫米。土壤为沙壤土,呈酸性反应。 生物价值 本种仅分布在江苏南部一小块土地上,与其近缘种类区别明显,对于研究木兰属 的分类系统有一定的意义。树干挺拔,花大而艳丽,芳香,是珍贵的园林观赏树木。 89
96. 90
97. 架构师 12 月刊 每月 8 日出版 本期主编:朱永光 策划编辑:贾国清 美术编辑:胡伟红 流程编辑:金鑫 总编辑:郑柯 发行人:霍泰稳 读者反馈:editors@cn.infoq.com 投稿:editors@cn.infoq.com InfoQ 中文站新浪微博: http://weibo.com/infoqchina 商务合作:sales@cn.infoq.com 13581658359 本期主编:朱永光,InfoQ 中文站翻译团队编辑 朱永光,开发技术讲师与作者,微软 MVP,有长期编程经验,熟悉微软 相关技术和产品。他对各种前沿技术抱有极大兴趣,喜欢钻研开发框架、 软件构架和编程语言。热衷社区活动,愿意和大家分享知识和交流经验, 在 InfoQ 中文站担任社区编辑。个人技术博客 redmoon.cnblogs.com,微 博 weibo.com/heavenwing。现在他作为共同创始人经营着一家环境保护 技术公司,致力于用 IT 促进环境保护,并把环保理念带入到 IT。 《架构师》月刊由 InfoQ 中文站出品。 所有内容版权均属 C4Media Inc.所有,未经许可不得转载。
98. 1