原文链接：http://glinden.blogspot.com/2006/02/early-amazon-splitting-website.html
原文作者 Greg Linden 毕业于华盛顿大学计算机学院，1997 年加入 Amazon，开发了享誉业界的 Amazon 推荐引擎。
著名的 Item-based 推荐算法的提出者之一；Findory.com 创始人。
其 Blog – Geeking with Greg 是个性化推荐领域最有影响力的博客（没有之一）。
本文首发 http://www.resyschina.com/2012/09/early-amazon-splitting-the-website.html，由 @raully7 翻译。
现在商用 Linux 服务器是如此普遍，以至于人们很容易忘记在上世纪90年代中后期关于网站究竟应该使用类似大型机的巨大服务器（类似 Sun 的 Star Fire）纵向扩展，还是使用便宜的硬件（诸如运行 Linux 的英特尔台式机）横向扩展的激烈争论。
在我1997年初加入时，亚马逊有一个庞大的数据库和一个庞大的网络服务器——big iron。
随着亚马逊的增长，情况变得越发不理想。不仅因为维护扩展 big iron 的成本高昂，而且我们压根不喜欢这个大个子的单点故障。亚马逊需要迁移到一个 Web 集群上。
在加入亚马逊几个月后，我成为负责站点并行化改造的两个团队之一中的成员。与我一起工作的是位非常有才华的开发人员鲍勃。
鲍勃就是一个疯子。似乎没有什么能难倒他。网站上有其它人不能调试出的问题？他会在线 attach 一个 obidos 进程（注1：亚马逊的页面渲染引擎）几秒内找到问题。数据库莫名其妙地挂起？他会启动一个进程跟踪运行中的 Oracle 数据库，发现 Oracle 系统代码中的 bug。太疯狂了！他似乎无所不能，没有什么是他不能攻破并搞定的。与他一起工作真是碉堡了。
鲍勃和我打算把亚马逊从单机迁到多机上（一个 Web 服务器迁移到多 Web 服务器上）。这项工作比听起来要困难得多。系统存在着很多依赖，而且 obidos 最初的设计是基于单机运行的假设。有的系统甚至直接访问 Web 服务器上存储的数据。事实上代码库中有太多的依赖，以至于为了在合理的时间内完成这个事情，我们需要尽可能的保持向后兼容性。
我们首先设计了一个粗糙的系统架构。其中两台开发机负责开发和运维，余下是一个在线服务器机群。开发机主要设计用来保证向后兼容：开发人员开发新的网站功能时，会用其进行数据共享；客户服务、测试和其他工具也将与中控机共享数据。这带来了一个好处，新的代码和数据测试时，中控机会成为隔离线上的最后一道防卫墙。
只读数据会通过管道推送，日志将会从在线服务器上拉走。为了日志处理工具的向后兼容，日志需要做合并，看起来就像是先从一台 Web 服务器获取数据，然后再放到另外一台文件服务器上。
插上几句，本来这里我们非常希望有一个健壮、集群式、冗余化的分布式文件系统。那样的话 Web 服务器操作只读数据将会很完美。
NFS 离要求差得太远。它不是集群或冗余的，当 NFS 服务器宕机时会冻结所有客户端。这太搓了。 更接近我们理想的选择，比如 CODA，当时则还（现在仍是）处在研究阶段。
没有一个可靠的分布式文件系统，我们只能手动为每个 Web 服务器生成只读数据的本地副本。又一次我们败在了现有的工具上。我们希望有一个足够快并且支持版本控制和回滚的系统。像 rdist 这样工具也是不够的。
所以我们只能自己写。这面临着巨大的时间压力。现有的 big iron 系统被淹没在超快增长的负载中，而圣诞节的临近则让情况变得更加糟糕。我们需要以最快速度搞定它。
最终我们还是按时完成了。新系统跑在了四台服务器的机群上；工作正常，工具也继续在起作用。鲍勃甚至为开发人员提供了个人网站，使测试和调试比以前容易得多。
好吧，某种程度上说也只是正常工作而已。我必须得承认，系统的某些部分比我预期的更早挂掉。由于我少的可怜的系统管理员知识，我写的日志推拉工具出了问题——一个有经验的黑客是不会犯这样错误的。更糟糕的是，系统在突发网络和机器故障面前很不健壮，部分原因是没能与管理机器自动上下线的负载平衡器集成好（一个早期版本的思科交换机）。
但它确实有用。没有我们所做的这些事情，亚马逊根本无法扛住1997年假期的巨大流量。我为是其中的一份子感到自豪。
当然，所有这一切都已经过时了。亚马逊改为使用 Linux（像其他公司一样），Web 服务器的数量大幅增加，而且最终亚马逊切换到了一套深度面向服务的架构。需求的改变，使得目前亚马逊的网站集群同我刚才所描述的已经没有多少相似点了。
但是后来，在构建 Findory（注二：作者实现的个性化资讯聚合器）的 Web 集群时，我再一次发现自己想要一个可靠的、集群化的分布式文件系统，却又再一次发现选项的匮乏。我再一次需要快速复制版本和回滚的文件工具，并再一次发现这东西根本不存在。当我尝试解决这些问题，似曾相识的感觉挥之不去。
注1：obidos 是亚马逊早期的页面渲染引擎，一直被使用到06年8月底。因临近亚马逊河的小镇 Óbidos 而得名。参见 http://en.wikipedia.org/wiki/Obidos_(software)
注2：Findory 是 Greg Linden 于2004年推出的个性化新闻博客的聚合器，采用了协同过滤算法，于2007年停止提供服务。参见 http://en.wikipedia.org/wiki/Findory
推荐阅读：
- Amazon Architecture
- Ex-Amazonian urges Google to sample Amazon’s secret sauce
- Why I, Jeff Bezos, Keep Spending Billions On Amazon R&D
