eBay的架构-引用

引用说明：原文来自于 http://brighter.iteye.com/blog/224637 的再次引用，为了方便本人阅读，文本格式略有调整。


eBay的架构
文/Todd Hoff 译/于晓潮

有谁不想知道eBay是如何开展业务的呢？成为世界上最大的高负荷量的网站之一，这个过程可不容易。创建这样一个庞然大物，需要真正的工程学：在网站的稳定性、运转速度、性能和成本之间达到一个平衡。

你可能无法模仿eBay增容系统的方法，但是其中的问题和可能的解决方案是值得我们学习借鉴的。

平台

○  Java

○  Oracle

○  WebSphere

○  Horizontal Scaling

○  Sharding                                      

○  Mix of Windows and Unix

统计数据

○  每天一般处理260亿个SQL请求，对1亿件供出售的商品进行跟踪记录

○  2.12亿名注册用户，10亿张照片

○  每天10亿次页面访问量，产生1.05亿张列表，2PB的数据。每月30亿应用程序接口呼叫。1999年6月到2006年第三季度间，页面浏览量、邮件的发送量、带宽增长了35倍。

○  99.94%的可用性，通过“每个人都可以使用网站的所有部分”与“在某个地方有些用户无法使用网站的至少一个部分”对比计算得出。

○  数据库虚拟化，涵盖分布在100多个服务器集群中的600种产品实例。

○  15,000个J2EE应用服务器。大概100组的功能（又叫做apps）。“池”的概念：处理所有销售业务的机器。[DSJ1]

架构

○  一切设计都依照“如果负荷增长十几倍会怎么样”来考虑。采取平行性增容而非垂直性增容，即拥有很多平行的盒子。

○  架构被严格分成：数据层、应用层、搜索、运行

○  表示层使用MSXML框架（即使在Java中）

○  oracle数据库，Websphere Java（1.3.1版本）

○  依照主访问路径、以及对一个主键的模数为界限，划分数据库

○  每个数据库至少有三个在线数据库，分布在8个数据中心。

○  一些数据库备份在15分钟、4个小时之后运行

○  数据库依照功能分割为70余项，包括：用户、项目账户、反馈、交易等。

○  不使用存储过程，有一些非常简单的触发机制。  

○  密集使用CPU的任务从数据库层移到应用层。因为应用服务器便宜而数据库则是制约瓶颈，所以参照完整性、连接和分类在应用层完成。

○  没有客户端事务处理和分布式事务处理。

○  J2EE：使用servlets、JDBC、连接池（具有重新写入功能），其它很少使用。

○  应用层中没有状态信息。状态信息存在于cookie或者scratch数据库中。

○  应用服务器之间没有对话——采用严格的架构分层。

○  网站上的一般商品在卖出之前其搜索数据（比如价格）改变5次，因此实时的搜索结果非常重要。

○   Voyager——eBay建立的实时反馈架构。使用基本数据库提供的的可靠的多点映射机制（multicast），来完成节点搜索、内存中的搜索索引、水平分割、N切片、在M个实例中平衡负载、存储请求等功能。

经验总结：
○  减容，而不是扩容

——在每一层上平行增容

——功能分解

○  推荐异步整合

——最小化可用性耦合

——增加增容的选择

○  虚拟组件

——降低物理依存

——提高配置弹性

○  应对故障的设计

——自动的故障检测和通知

——在商务特性中采用“失效保护模式”

○  因为数据库是制约瓶颈，所以将任务从数据库移到应用层。Ebay在这方面做的非常极端。我们看到其它的架构使用缓存和文件系统来解决数据库的瓶颈问题，而Ebay甚至用应用层处理很多传统的数据库操作（如表连接）。

○  按自己的意愿使用和舍弃，不必采用全套框架，只使用对你有用的。eBay没有使用完整的J2EE stack，只是采用servlets、JDBC、连接池等。

○  不要害怕构建满足你的需求并按需求发展的解决方案。每一个现成的解决方案都不可能完全让你高枕无忧，你必须自己走完剩下的路。

○  随着业务的成长，运行控制成为增容的越来越大的一部分。如果运行一个即时使用的系统，你必须考虑如何升级、配置和监视数以千计的机器。

○  架构进化——任何一个成长中的网站面临的主要挑战。在保持现有网站运行的同时，需要有改变、改善和开发新系统的能力。

○  一开始就过于担心可增容性是错误的。因为分析和担心可能永远也不会发生的流量而陷入恐慌是不必要的。

○  完全不考虑可增容性是不对的。事情永远不会做完，系统总是在进化和改变，你需要建立一个有能力应付架构进化的组织。并且一开始就把这些期望和能力融入你的业务中去，不要让人和组织成为你网站瘫痪的原因。不要认为系统一开始就应该是完美的，一个好的系统是在解决真正的问题和担忧中成长起来的，期待改变，适应改变才是正确的态度。