Tag Archives: Arch

来自淘宝的架构经验

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

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 的架构介绍

本文介绍的 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–

再跟 Flickr 学习网站运维经验

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)的背后

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