《魔兽世界》(World of Warcraft )对于暴雪公司(Blizzard)来说是最为重要的一款产品。开发团队对于外界来说无疑有着神奇的色彩。这篇 An Inside Look At The Universe Of Warcraft 给我们带来不少关于《魔兽世界》开发团队的信息。暴雪开发团队也是采取三层的管理方式(还好不是更多层)，但是实际的汇报是根据具体的小团队而异的。他们心目中理想的的团队规模是 5-8 人，当然实际上这是办不到的事情。

目前这棵摇钱树程序代码量有 550 万行之多，程序开发人员有 32 位，当然都是顶级工程师。平台服务部有 245 人，其中 QA 部门自从游戏上线后处理了 18 万个 BUG，惊人！程序差不多似乎千锤百炼了。

《魔兽世界》目前使用大约 13250 台刀片服务器 ，75000 个核的CPU ，内存使用超过 112TB 。服务器数其实并不是特别庞大(国内有些游戏公司，比如盛大，服务器数量也差不多这样)。 不过相信随着接下来几款重量级游戏升级版本的推出，服务器数量会暴增。数据大约有 1.3 PB。服务器分布在 10 个 IDC ，不到 70 个人运营，人力产出很惊人。维护战网的人有 150 个左右。这里面有个有趣的观点是，游戏公司对于服务的可用性要求的看法与电子商务公司的并非一致，只要不是每周都有问题，一个月遇到一次问题似乎不大。算不上致命的问题，应该是用户忠诚度更高的缘故吧。看看国内的戏剧性起伏就知道了。

另外，据我了解，魔兽计费的数据库是采用的 Oracle RDBMS 。2006 年的时候大概是跑在 RedHat 上，单个 DB 超过 1T 的数据，且据说要迁移到 HP 平台。但还不了解如何跨多个 IDC 同步 DB 数据，或许简单的分片就成了，这是面向游戏的应用设计上唯一不费力的地方。

Note: 先大致描述个轮廓，等以后了解更多再逐渐补充。

--EOF--

• GDC Austin: An Inside Look At The Universe Of Warcraft
• Blizzard outlines massive effort behind World of Warcraft
• Iceland: New Hot Spot for Data Centers?
• Refer Solidot

在刚刚举行的系统架构师大会上，支付宝首席架构师程立分享了《面向生产环境的SOA系统设计》这个技术话题。现在把 PPT 第一时间和大家分享一下。

程立在 SOA 功底深厚。上次在 InfoQ QCon 会议上程立的话题也是有关 SOA。本次演讲内容侧重与上次侧重点不同。只是因为会议时间有限，所以有几页没有完全展开来讲，稍稍有点遗憾。

感谢程立。大家针对该 PPT 有任何问题的话，请留言或者发邮件给我，我将第一时间转给他。

关于 PPT 作者：

程立是支付宝公司的首席架构师。他从2004年起参与支付宝与淘宝网的建设，2005年正式成为支付宝人，随着支付宝的业务与技术的成长，从开发工程师、架构师到首席架构师一路走来，全身心投入并见证了支付宝业务与系统发展的完整过程。

支付宝一直在招聘软件架构师，我们是 Java 开发环境。如果您对支付宝感兴趣，并且想让自己做的东西服务于两亿多的用户，不妨联系我们或者直接发简历到: [email protected] 。

--EOF--

对于国内存储市场来说，3PAR 是不折不扣的后来者。也是个相对陌生的存储产品，以至于其竞争对手的人员甚至都不知道这家公司已经杀入中国市场。

3PAR 在 1999 年成立，几个创始人主要出自 Sun ，前身叫作 3PARdata ， 2008 年上市。要知道在存储技术领域竞争还是比较激烈的，EMC / HDS 等控制着高端存储的主要市场，3PAR 能突破技术壁垒并最后成功上市，没两把刷子那是绝对做不到的。

InSpire 硬件结构

3PAR 背板采用全网状的连接结构，每个控制器节点之间高速直连。因为是全网状的，所以基本上一个链路坏掉只影响直连的两个节点的通信，对其它节点无影响。每个控制器节点内置一块硬盘，用于操作系统安装。控制器节点最多可以扩展到 8 个，是 3PAR 存储最核心的组件。

相比之下，HDS 架构采用全光线交换方式（Universal Star Network），而 EMC 是采用直连矩阵方式(新一代产品采用虚拟矩阵架构--Virtual Matrix ，其实已经放弃了直连矩阵架构了)。这些连接方式的孰优孰劣历来是厂商攻击竞争对手的着眼点，能否最大限度发挥性能是用户最需要关心的。

3PAR 针对 I/O 指令和数据移动使用不同的计算芯片。I/O 指令(元数据/控制Cache)用 Intel 的芯片，而 数据移动/Cache 则使用专门设计的 ASIC 芯片来完成。

因为有专门的硬件 ASIC 芯片用于 RAID 5 XOR 校验，3PAR 号称有了其第三代 ASIC 芯片，实现的 RAID 5 是业界最快的，甚至 SATA 盘也能有不错的性能表现。(从 Oracle 公司测试的数据来看，和 RAID 10 速度的确相差无几。)

InForm 操作系统软件与虚拟化

3PAR 的操作系统叫 InForm，最初就是面向层次化的设计。与其他存储不同的是，3PAR 所有磁盘被分成 256MB 统一大小的小盘(Chunklet)，可以根据需要用多个 Chunklet 组成 RAIDlet(逻辑磁盘)。因为这个独特的设计方式，3PAR 是可以很容易做到不同容量的磁盘混用，同一个 RAID 组里都可以有不同大小、不同转速的磁盘混用，这是其他存储做不到的。而且，所有的磁盘都可以利用，因为Hotspare Chunklet 以更小的单位分散在不同的磁盘上，也不再需要单独留热备盘。空间利用率可以更充分一些。　

多说一句，有这个冗余机制，3PAR 更换磁盘也是与众不同：直接抽磁盘盒子(一个盒子可是四块磁盘啊)，我当初看到 3PAR 技术人员这么操作真是着实吓了一跳。

因为固定大小的 Chunklet 的存在，可以将 I/O 更为均匀的分散到多个磁盘上。

对于熟悉Oracle 的朋友来说，会发现这和 ASM 的思想非常接近。因而也可以和 Oracle 数据库进行无缝集成：

因为软件做得非常具有易用性，日常管理与维护远远没有其他高端存储那么复杂，新增磁盘这种事情，都是一行命令之后底层自动处理。其实在 Thin Provisioning 方面 3PAR 也是很值得一说的，比一些厂商的伪 Thin Provisioning 具体多了。限于篇幅，不赘述。

3PAR 在美国有很多金融证券行业的客户，也有 Web 2.0 行业的客户--MySpace 。在保证 I/O 响应在 10ms 以内的前提下，3PAR 的 IOPS 能力非常优异(这才是卖点，不难理解其客户多集中在证券、金融领域)。虽然有些厂商号称能得到更高的 IOPS ，但那是在 I/O 响应时间很差的情况下的数据。要说明的是，现在随着一些存储厂商在高端服务器上也支持 SSD ，未来几年如何还要再看。

前两年 3PAR 推行所谓 Utility Storage(功用存储) 理念，现在貌似改成敏捷存储了。说实话，我觉得敏捷存储真的挺适合的，3PAR 命令行批量创建 LUN 真的很让人感觉舒服。当然，也在宣传云存储和绿色存储的理念，那是题外话了。

3PAR 原来只做中高端市场，只有 T 这一个系列，现在也开始关注中低端市场了，推出了 F 系列的产品。软硬件体系基本没变，倒是没仔细看过。

(Note: 相关图片主要来自 3PAR 公开资料.)

--EOF--

最近在不同场合都遇到涉及 IDC 电力问题的讨论。对于这个话题我一直不是特别留意，直到昨天我说了一句比较武断的话之后，感觉到没有调查就没有发言权，所以找了一些数据来。

国内很多互联网公司关心 IDC 电力问题，可能有一部分是受了一些美国公司(尤以 Google 为代表)的影响。根据美国环境保护署的预测数据，到了 2011 年，美国数据中心消耗的电力将达到 1000 亿千瓦--这个数字够惊人的，这个问题如果放到美国的大环境上来看可能又不算什么，因为这个数字占美国总耗电量的比例 大约是 2.625%。那么中国呢? 考虑到中美能源利用效率的差异，我想现在数据中心用电量绝对不会超过 1%。Google 这类公司强调节能、绿色 IDC 之类的说法有他们的理由，且不说提高企业形象 -- 在欧美如果大企业不提倡环保，还不被那些环保组织骂死 ? 另外，省钱也的确是硬道理。此外，有一大票鼓吹绿色 IT 的家伙是各色商业公司，当然，宣传的目的是为了多购买他们的"更加省电"的产品。

中美电力使用的一个巨大差异是，美国工业用电与商业用电相对比较便宜，而居民用电反而比较贵。在中国倒是相反，居民用电相对便宜，而工业用电和商业用电是比较贵的(前不久的发改委才要求工业、商用同价格，参考)。考虑到地域差异，以及各种因素，美国居民用电平均大约 10 美分左右(信息来源)，而国内的价格，是一笔糊涂账，我所居住的杭州，正常时段的价格要超过 0.55 元，而且根据用电量大小、时间、类型等等有不同的计算价格，以我这个智商恐怕算不清楚的。不管怎么样，中美的居民用电价格是相差不大的，考虑到中美人民的收入，这里面实际差异还是很大的。(国内在 2008 年 7 月 1 日曾经提过一次电价，每千瓦时提价 2 分 5 厘-- 看似很小的涨价? 这意味着每年就可以多收近千亿的人民币。嗯，有点跑题了。) 限于这多少算技术贴，其他层面的东西就不说了。

工业用电价格贵，那么似乎的确应该节电了? 在目前国内，有一些数据中心的确已经面临电力问题，但这些问题集中在 IDC 如何抢到电力资源(毕竟不同地区电力资源分配不均衡)，而不是如何少用电，更为关键的是，你少用你那么一点点电(本来就没多用多少)，可能真的解决不了什么问题，因为如果收费的标准不根据你用了多少电来衡量 -- 体现到经济效益上来也就不会有多大，要是新闻联播每天少播 5 分钟，那全国要节省多少电阿... 很少有 IDC 根据电力对用户收费，更多还是根据物理空间、网络带宽等指标收费。作为用户一厢情愿的考虑 IDC 的问题乃至环保，或许还有点早(不是说不重要，而是这个问题不是我们最迫切的事情，当然，有这样的想法还是好的，是值得肯定的)。个人觉得提升计算性能充分发挥机器能力或是提供更好的产品给用户，可能也会节省大量资源，产生更大的经济效益。既然丁磊都说了"企业最大的慈善就是把产品做好"，我们可以套用一句，做好产品、给用户提供更好的体验也是环保...

对了，我那句武断的话是(洁本)：

三年内，中国网络公司不用担心电力太贵；五年之内，不需要讨论环保问题。

不是这方面专家，引用的数据或许有误，当然，我的结论也明显有问题，您就对付着看吧。

--EOF--

• 附1、中国电力平衡表(2008) 。缺电还是不缺电，一目了然。

电这个问题，如果 IDC 抢到的少，即使你用的少，别人也同样会用得多。经济因素影响真的不是那么大。

更新一下结论，IDC 如果抢不到电力，别的说什么都是收效甚微的事情。

没有一个网站的性能像 Twitter 这样这么令人牵肠挂肚，看见那条大鲸鱼总是让人感觉很无奈。Twitter 的运维专家 John Adams 在 Velocity 2009 上做了一篇题为 Fixing Twitter 的技术分享(PDF)，人家也是一直在努力阿。John Adams 在 2008 年七月加入的 Twitter ，对于 Twitter 的站点稳定的确做了不少工作。

Twitter 运维团队的职责：

• 软件性能(后端) Software Performance (back-end)
• 可用性 Availability
• 容量规划 Capacity Planning (metrics-driven)
• 配置管理 Configuration Management

看完这个接近 50 页的 PDF ，除了满足我们一小部分技术窥探的癖好，或许也可以学到点什么。

不重复发明轮子

对于监控，Twitter 用的就是 RRDtool，Ganglia、MRTG 这些已经成为很多网站标准配备的组件。而不是自己写一大堆功能重复的东西。值得注意的是， Twitter 也一直在用 Google Analytics 进行业务分析。

不重复发明轮子，可以打磨轮子，比进行如一些功能脚本定制之类的工作。

发明不重复的轮子

Twitter 开源了他们自己用的一个 Apache 模块 mod_memcache_block（a distributed IP blocking system），这个模块根据 HTTP 代码请求限制访问频率。熟悉 Twitter 的朋友会知道这是针对第三方应用程序的必须的一个功能，否则的话，会产生类似 DDos 的效果 :) John Adams 说这个模块是他多年以来就期待的东西，我相信，如果有人已经做了同样的事情，他们肯定不会自己再写一个。

尽可能的自动化

无论是配置管理还是针对各项功能的"开关"，都尽可能的自动化。依赖于人来控制一些事情容易"规范"，但是流程冗杂，节奏变慢。

更好的理解硬件

拥抱新技术体系，使用更有经济效益的硬件(比如对 8 核 CPU 的选型与更换)会带来更好的收益。而这个要建立在对硬件体系的正确理解上才行。

另外几句话要记住：

• Disk is the new Tape. (内存是新类型的磁盘. 磁盘是新类型的磁带)
• Kill long running queries before they kill you. (问题是如何提前发现? 有效的监控!)
• Use metrics to make decisions, not guesses.
• "Cache Everything!" not the best policy

或许还应该学到更多...

--EOF--

去年在对 SSD 做调查的时候就关注过这个五分钟法则，今天又发现了这篇文章的修订版(为了纪念 Jim Gray），这个话题倒是可以简单介绍一下，对架构师衡量 I/O 能力、Cache 评估和做硬件选型还是会有一些帮助的。

在 1987 年，Jim Gray 与 Gianfranco Putzolu 发表了这个"五分钟法则"的观点，简而言之，如果一条记录频繁被访问，就应该放到内存里，否则的话就应该待在硬盘上按需要再访问。这个临界点就是五分钟。看上去像一条经验性的法则，实际上五分钟的评估标准是根据投入成本判断的，根据当时的硬件发展水准，在内存中保持 1KB 的数据成本相当于硬盘中存储同样大小数据 400 秒的开销(接近五分钟)。这个法则在 1997 年左右的时候进行过一次回顾，证实了五分钟法则依然有效（硬盘、内存实际上没有质的飞跃)，而这次的回顾则是针对 SSD 这个"新的旧硬件"可能带来的影响。

随着闪存时代的来临，五分钟法则一分为二：是把 SSD 当成较慢的内存（extended buffer pool ）使用还是当成较快的硬盘（extended disk）使用。小内存页在内存和闪存之间的移动对比大内存页在闪存和磁盘之间的移动。在这个法则首次提出的 20 年之后，在闪存时代，5 分钟法则依然有效，只不过适合更大的内存页(适合 64KB 的页，这个页大小的变化恰恰体现了计算机硬件工艺的发展，以及带宽、延时)。

根据数据结构和数据特点的不同，对于文件系统来说, 操作系统倾向于将 SSD 当作瞬时内存(cache)来使用。而对于数据库，倾向于将 SSD 当作一致性存储来用。

这是一篇非常重要的文章(所以，建议读一下原文），其中对于数据库一节的描述尤其有趣（针对 DB 也有个五分钟)。限于篇幅，就不罗嗦了。

--EOF--

拜读了关于 LinkedIn 几位工程师写的构建 TB 级的 key-value 系统的经验：Building a terabyte-scale data cycle at LinkedIn with Hadoop and Project Voldemort。具体实现过程有大致的描述，就不鹦鹉学舌了。

其实现在很多公司可能都面临着这个抽象架构图中的类似问题。以 Hadoop 作为后端的计算集群，计算得出来的数据如果要反向推到前面去，用什么方式存储更为恰当? 再放到 DB 里面的话，构建索引是麻烦事；放到 Memcached 之类的 Key-Value 分布式系统中，毕竟只是在内存里，数据又容易丢。Voldemort 算是一个不错的改良方案。

值得借鉴的几点:

• 键(Key)结构的设计，有点技巧；
• 架构师熟知硬件结构是有用的。越大的系统越是如此。
• 用好并行。Amdahl 定律以后出现的场合会更多。

关于 key-value 应用的解决方案又多了一种。LinkedIn 对此应用案例也还在发展中。如果业务类型类似，不妨关注一下。

--EOF--

到处都是什么大规模啊，高流量啊，高性能之类的网站架构设计，这类文章一是满足人们好奇心，但看过之后也就看过了，实际收益可能并不大；另外一个副作用是容易让人心潮澎湃，没学走先学跑，在很多条件仍不具备的情况下，过度设计、过度扩展(高德纳大爷也说过，"过早优化是万恶之源")，所以，这里反弹琵琶，讨论一下小规模、低性能、低流量的网站该如何搞法。

如果站点起步阶段可能就是一台机器(或是一台虚拟机，比如 JobsDigg.com )，这个时候，去关注什么数据拆分啊，负载均衡啊，都是没影子的事情。很多大站点的经验绝不能照搬，辩证的参考才是硬道理。

拥抱熟知的技术

动手构建站点的时候，不要到处去问别人该用什么，什么熟悉用什么，如果用自己不擅长的技术手段来写网站，等你写完，黄花菜可能都凉了。所以，有现成的软件组件可用，就不要自己重新发明轮子。人家说 Python 牛，但自己只懂 PHP ，那就 PHP 好了，如果熟悉 .net ?，那也不错。用烂技术不是丢人的事情，把好技术用烂才丢人。

架构层次清晰化

起步的阶段应该清楚的确定下来架构的层次。如果都搅和在一起，业务一旦扩增开来，如果原有的一堆东西拆不开就是非常痛苦的事情。

Web Server <--> (AppServer)<-->Cache(eg. Memcached)<-->DB

层次清晰化的一个体现是(以 LAMP 架构为例)：即使只有一台机器，也应该起个 Memcached 的实例，效果的确非常好(除非内存小)--一般人儿我不告诉他...不要把什么都压到 DB 上，DB 一旦 I/O 压力走到磁盘上，问题要暴露出来是很快的。没错，DB 本身也会利用自己的 Cache，但 DB 的Cache 和 Memcached 设计出发点毕竟不一样。

数据冗余? 有必要

很多人并不是数据库设计专家，如果应用要自己设计表结构什么的，基本都是临时抱佛脚，但三个范式很多人倒是记得牢，这是大多数小型 Web 站点遇到的一个头疼事儿，一个小小的应用搞了几十个表... 忘掉范式这个玩意儿! 记住，尽可能的冗余数据，你在数据层陷入的时间越多，你在产品上投入的就会越少。用户更关心的是产品的设计。

前端优化很重要

因为流量低，访客可能也不多，这时候值得注意的是页面不要太大，多数流量低的站点吃亏就在于一个页面动辄几兆(我前两天看到一个Startup的首页有4M之大,可谓惊人)，用户看个页面半分钟都打不开，你说咋发展? 先把基本的条件满足，再去研究前端优化。

功能增加要谨慎

不是有个 80/20 原则么? 把最重要的精力放在最能给你带来商业价值的地方。有些花里胡哨的功能带来很大的开销，反而收效甚微。记住，小站点，最有价值的是业务模式，而不是你的技术有多牛。技术是为业务服务的，不要炫技。

有些网站不停的添加功能，恰恰是把这些新功能变成了压死自己的稻草。

从开始考虑性能

这一点是可选的，但也重要。设计应用的时候在开始就应考虑 Profile 这件事情。一套应用能否在后期进行有效优化和扩展，很大的程度限制在是否有比较合适的 Profile 机制上。需要补充的是，对性能的考虑必然要把有关的历史数据考虑进来。另请参见网站运维之道的容量规划以及其它小帖子。

好架构不是设计出来的

这是最后要补充的一点。好的架构和最初的设计有关系，但最重要的是发展中的演化：

发展-->发现问题-->反馈-->解决问题(执行力)--> 改进->进化到下一阶段--新问题出现(循环)

有些站点到了某个阶段停足不前，可能卡在执行力这个地方，来自用户的反馈意见上来了之后，没有驱动力去做改进。最后也是死猪不怕开水烫了。最怕听到的就是"业务不允许"的托词，试想如果不改进业务都没了，那业务还允许么? 其实就是一层心理障碍。

这篇文章有浓重的山寨风格，所以，你不要太认真。如果在用短、平、快的方式构建某些山寨网站的话，可参考其中对你有益的点，不赞同的地方可以直接忽视掉，就没必要费力留言进行争论了。

--EOF--

• 好的业务模式(产品) + 很好的技术 = 大赚钱
• 好的业务模式(产品) + 能用的技术 = 也赚钱
• 差的业务模式(产品) + 好的技术 = 赚吆喝(现在的SNS就差不多这样了)
• 差的业务模式(产品) + 差的技术 = 自己浪费资源