揭秘eBay架构与存储

eBayd Web领域树立了一个典范。从一系列的数据当中都可以看到，这样一个超大规模的网站，其数据和计算量对技术的要求非常之高。为了能保证全球两亿多用户的正常访问，除了要有优良的技术架构作为支撑外，每天产生的海量数据也需要精心保存。作何一个开发人员和信息管理人员面对这样艰巨的任务都如履薄冰。为此本刊组织了两篇eBay的技术文章，以飨读者。



扩展：不仅仅关于架构

文/Frank Sommers 译者/靳黎明



在2006 SD论坛中，两位eBay的架构师发表演讲，总体阐述了两个主题：eBay的架构是如何处理每天十亿次的页面访问请求，以及该架构是如何从当初的Perl脚本演化到目前的运行在8个数据中心的1万5千个应用程序例。该演讲所得出一个结论就是，扩展仅仅是架构中的问题。



eBay系统架构的演化

在2006 SD论坛中，Randy Shoup和Dan Pritchett都结合eBay发表了关于eBay架构的演讲。Pritchett随后在他的Blog中发布了一个演讲幻灯片——标题为eBay的架构。

意料之中，他在演讲中提到了一些令人惊叹的统计数字，具体如下：

l         2亿1千2百万注册用户

l         每天10亿次的访问量

l         每天260亿次的SQL查询和更新

l         超过2千万亿的数据量

l         每秒价值1590美元的货物交易

l         超过10亿张的图片存储

l         7种不同的语言

l         99.94%的系统可用性

与开发过程和特性相关的其他统计数据，如下：

l         每季度网站新增300多项新特性

l         每两周发布超过十万行的代码

根据他的演讲，尽管eBay的架构已经达到了如此大的规模，但是，eBay期望能够在短短几年内实现它的目标——处理通信量高达十倍的额外增长。另外一个架构目标是，能够处理峰值载荷，并且在非常负载或者系统瘫痪的情况下能够使组件安全地停止工作而不致受损。

根据演讲的内容，目前，eBay的系统架构正朝着第四个版本努力。当然，演讲中最吸引人的技术部分也主要是关于这个版本的各种技术信息，例如，演讲者所讲述的是扩展应用程序层的第一步：摒弃大部分的J2EE特性。取而代之的是，他们注意到“eBay采用Servlets 和一个重写的连接池进行扩展。”

根据演讲的介绍，关于应用程序层扩展的另一吸引人的方面是，在应用程序层完全不保存会话状态信息。取而代之的是，“在cookie或者scratch数据库中保存过渡状态。”为了实现数据存取，eBay使用内部开发的Java O/R映射解决方案。

在扩展该网站的搜索方面，演讲者注意到一个与众不同的需求，而这是Google这样的通用Web搜索引擎所不会遇到的问题，即：eBay的用户期望能够在搜索结果中立即查询出他们对数据所做出的变动。同样地，拍卖者确切地知道他们所期望的搜索结果——举个例子，他们刚刚列出的项目必须出现在所有相关的搜索结果中。显而易见，在最新版eBay搜索的重架构出现之前，仅仅是更新一次搜索的索引也需要9个小时。

演讲者说到了很多类似的具有挑战性的问题，同时也深入探讨了问题的解决方案。然而对我而言，演讲中令我最感兴趣的话题是，关于eBay架构本身是如何演化的介绍。关于这个话题，我们需要对第一版本的架构进行一些思考，例如：

l         1995年的一个周末Pierre Omidyar构建了第一版本的架构

l         每个项目是一个单独的文件，由Perl脚本生成

l         没有搜索，只能够按照类别进行浏览

l         系统硬件是由能够在Fry商店购买的商品零件所组装的

从1995年到1997年9月，eBay一直使用这个架构。演讲提到，那时，eBay已经是一个比较有名的网站了，而且它的架构也达到了5万项的最高值。

接下来的几次迭代使得eBay的架构进入了3层架构的阶段，最初是在微软的IIS服务器上，然后转移到Java中。最终的几个版本表明，需要摒弃J2EE的很多特性，以高度化定制的架构来满足eBay的独特需求。

关于eBay所经历的这四个主要的架构版本，一种观点是，这四种版本是一场进化。然而，另外一种观点是，这四个版本形成了一个完整的圆圈：刚开始时，采用设计定制的解决方案，最终又转回到定制解决方案上来。

根据对各个不同架构阶段的介绍，我非常希望了解，eBay的架构师在解决表现层扩展这一迫切问题上达到了哪种程度，他们希望在系统中实现可扩展性以此来处理将来的负载，那么这一目标的实现又达到了何种程度。即使是为将来考虑，那么，架构师需要预测未来某些假设的时间点处系统的可扩展性，他们的这一能力又达到了何种程度呢？

关于这些预测的一个问题是，即使目前的操作系统中保存的大量数据都是可供使用的，系统的使用模式也会发生改变的——举个例子，用户可能开始喜欢视频而不是简单的图片，或者语音电话作为系统交互的一部分。根据演讲的内容，这些使用模式的变化完全可以很快地到来，尤其是当平均架构生命周期变成了大约2-3年。例如，两三年前，听说过YouTube的人很少，但是，在该公司短短的两三年生命周期中，数百万的用户已经习惯于网络视频了。





实现扩展：组织能力+架构

   我认为最后争论的这个问题是这次eBay演讲主要信息之所在。对我来说，关于eBay架构的变革，最惊人的方面不仅仅是每一个架构时期所采用的解决方案技术的卓越，还有这个事实——eBay能够通过对系统进行不断的改进来迎接所遇到的各种挑战，所有阶段的努力使得这个网站长久不衰。

有趣的是，它建议你几乎可以从任何一种架构开始做起——甚至是使用Perl或者Rails或者JSP页面——当你需要扩展你的应用程序时，只要你知道如何转移到下一步，并且有能力实现。反过来，它也建议，可扩展性的关键并不完全是每个架构阶段之间如何进行扩展，而是一个公司或者一个组织如何把应用程序从一个架构阶段推进到下一阶段。这表明，扩展像技术问题一样是个人或者组织的问题。

当然，这并没有什么令人惊讶的，因为，与架构设计一样，扩展也总是可以实现的。（eBay演讲的最后一部分就讲解了扩展的可操作性这个主题——例如，它解释了1万5千个应用程序实例是如何通过八个数据中心进行管理的。）然而，如果从更宽广的视角来看待扩展的话，其中两个普遍存在的扩展方式可能在实际中是没有用处的。

一个方式是，从开始就过于强调可扩展性的设计。大多数开发人员都知道架构的扩展无法从一开始就确定，但是，在某些情况下，架构师仍然宁愿花费过多的精力来试图设计一个能够长期满足应用程序需求的架构。Pierre Omidyar基本上不同意这个观点，这就是为什么他会选择在他的初始版本中使用Perl脚本以及每个项目一个文件的机制，而不采用一劳永逸的方式。

第二个主张可扩展性无用的观点认为，可扩展性和性能一样纯粹是事后考虑的，而且反对在应用程序开发的初始阶段就考虑可扩展性。XP倡导者有些时候利用这一观点辩护，因为他们更热衷于快速地写代码，而不是考虑以后这些代码将如何进行扩展以处理将来的应用程序工作负载。

实际上，这两种观点都是没有太大用处的。更加现实的观点是，第三种观点，把扩展作为组织上甚至是业务层上的能力的一部分。预测将来的工作负载是非常困难的，我们需要认识到这一点，那么，如果可以预测的话，这个观点将主要用于这种架构——处理近期进行的扩展，同时允许对特性进行快速部署，以使应用程序的实际用户能够为支持将来的架构更新生成业务合理性。然而，远远不同于把扩展作为组织甚至业务能力开始，发展到能够处理系统的架构变化。这看起来正是2006 SD论坛上eBay架构师所做演讲的观点之所在。
那么在你的项目中，你什么时候开始考虑实现扩展性呢？