日前参加了一场淘宝网架构师黄裳带来的技术分享，在最后他总计了淘宝这几年来的架构经验，这里和大家分享一下：

• 1、适当放弃一致性
• 2、备份和隔离解决稳定性问题
• 3、分割和异步解决性能问题(类似 eBay 的 Asynchrony Everywhere)
• 4、自动化降低人力成本(类似 eBay 的 Automate Everything)
• 5、产品化管理

在这里不妨对比一下 eBay 的架构经验：

• 1、 Partition Everything
• 2、 Asynchrony Everywhere
• 3、 Automate Everything
• 4、 Remember Everything Fails
• 5、 Embrace Inconsistency
• 6、 Expect (R)evolution
• 7、 Dependencies Matter
• 8、 Be Authoritative
• 9、 Never Enough Data
• 10、Custom Infrastructure

关于一致性，可以延伸阅读 Amazon CTO 的大作 Eventually Consistent。此外，强调了"放弃集中的紧耦合处理"的原则。"备份"这里可以理解为"提供可用的副本"。"分割"是说水平拆分。

架构这东西说起来大致原则，其实都是类似的，但是具体如何在一些通用原则上做到运用自如，是很难的事情。前几天我还感慨，很多架构师对与"异步"与"批量处理"所能带来的益处的理解仍然相去甚远。

--EOF--

本文介绍的 SmugMug 是一家提供付费图片托管服务的站点，在 2002 年由 Chris MacAskill 与 Don MacAskill 父子二人创建，最初提供面向游戏的视频服务，随后转型为现在的模式。网站流量现在是全球 1800 多，盈利能力自称良好。

在 MySQL Conf 2009 上，SmugMug 的 Don MacAskill 做了一次关于SmugMug 网站架构的分享。

SmugMug 整个网站采用 LAMP 架构(其实也有 OpenSolaris)，300 多台 4 核（或更多）的服务器（大多是 AMD 的 CPU） ，分散在四个机房，两个运营的人员。SmugMug 充分运用了云计算服务，是 Amazon 的一个大客户，图片和视频总计达到了 PB 级，托管在 Amazon S3 上，图片和视频的处理也在 Amazon EC2 上。使用了 Akamai 的服务做前端的 CDN 加速，主要是 JavaScript/CSS 等文件的加速，此外，DNS 加速也带来了很好的收益。

结构化数据放在 MySQL 中，存储引擎多数用的 InnoDB，数据超过 2TB 的空间，数据库服务器为 4 核或更高配置，内存多达 64GB。缓存方面，用了 Memcached 做加速，有 1TB 的数据在这里面，平均命中率达到 96%。Memcached 里面尽量存放 MySQL 行数据，减小对 DB 的冲击。数据库设计思路是尽量做垂直分区，没有 Sharding。不过在反范式(denormalized)方面做得比较彻底，不用表连接(JOIN)方法者复杂的查询。多数查询依赖主键，更新或者删除数据也是单行，依赖主键。InnoDB 引擎打了 Percona 的 Patch，并发能力也有了很大增强。

对 DB 的数据完整性与写能力的要求高，而对于读的扩展性还是相对比较好解决。Linux 上的文件系统是 SmugMug 不太满意的地方，备份也成问题。ZFS 倒是能满足相关的需求，可惜不支持 Linux(妈的，早该支持 Linux了)。所以他们迁移到了 OpenSolaris 上。另外，对于复制中可能出现的风险，尝试了第三方提供的一些 Patch (参考 Google 发布的 MySQL Patch)。

采用 OpenSolaris 后，MySQL 放在 Sun Sushi Toro(Storage 7410，这个东西也支持 SSD ) 上，走 NFSv3 协议。写到这里，发现 SmugMug 的解决方案非常不具有通用行，看起来 Sun 是给了他们不小的硬件优惠，否则一般情况下不会有人这么搞的，用 NFS 协议走数据库，除非是测试环境或者是复制(我怀疑只是 Slave 端通过 NFS 走)，产品上真的有人跑么?

网站架构的进化，其实也是选定一个方向(比如用开源工具解决)，然后一直试错的过程。

--EOF--

Image via CrunchBase

学习了一下 Flickr 的运维工程师 John Allspaw 的这个Operational Efficiency Hacks 讲座内容。做一点笔记。

现在 Flickr 的数据相比2007年的时候真是有了显著的增长：

• 24 TB 的 MySQL 数据
• 每秒钟 MySQL 有 3.2 万次写操作
• 每秒钟 MySQL 有 12万次读操作
• 图片容量 6 PB
• 每天要用掉 10TB 存储
• 超过 15000 个服务监控点

在 2004 年的时候 ，Flickr 使用 ImageMagick (version 6.1.9)之后转移到 GraphicsMagick，我还以为是因为版权问题，现在知道这样做是因为速度，换用 GraphicsMagick 处理速度提升了 15%，而 ImageMagick 功能尽管强大，但都是 Flickr 用不到的功能。如无必要，勿增实体啊。GraphicsMagick 在并行方面(OpenMP)的支持也很不错(参考)。

除了技术手段的优化，Flickr 充分利用硬件本身的更新换代带来的好处，曾经用 18 台新机器替换掉原来的 67 台 Web 服务器，用 8 台新机器替换掉原来的 23 台图片处理的机器。无论从机架占用还是电力使用都节省了很多，而整理处理能力并没有削弱。我们总说摩尔定律，但是恐怕很少有人真的享受到摩尔定律带来的好处。Flickr 的做法是很值得学习的一个地方。精兵简政，不要只冲着人下手，动手"裁"掉机器，也会省钱嘛...

Flickr 技术团队随着网站的快速发展并没有增加大量人手，个人生产力的产出是相当的高。如何做到的呢？给出了四个非常有趣的原则：

• 使得机器自动构建 (Teach machines to build themselves)
• 使得机器自监控(Teach machines to watch themselves)
• 使得机器自修复(Teach machines to fix themselves)
• 通过流程减少 MTTR (Reduce MTTR by streamlining)

自动购建上，Flickr 使用了 OpsCode 、Puppet 以及 System Imager/Configurator 等。或许这几个工具值得我们关注一下。

Flickr 团队内部沟通工具也挺有意思，除了内部的 IRC 用于讨论之外，还利用 Yahoo! Messenger 的 IM Bot 记录更多的系统变化，并且，重要的是，将这些信息弄到搜索引擎里面 ... "信息查找"，是国内多数团队交流工具忽视的地方。

最后感慨一下 Flickr 技术团队仍然是非常有活力的团队。最近的另一个消息是国内的 Yupoo.com 原创业团队也即将重装上阵，重新接管 Yupoo 网站，要知道 Flickr 仍然是最有影响力的网站之一，所以，有理由期待 Yupoo 团队的精彩。

--EOF--

《魔兽世界》(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