eBay的架构

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）。“池”的概念：处理所有销售业务的机器。

架构
 一切设计都依照“如果负荷增长十几倍会怎么样”来考虑。采取平行性增容而非垂直性增容，即拥有很多平行的盒子。
 架构被严格分成：数据层、应用层、搜索、运行
 表示层使用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、连接池等。
 不要害怕构建满足你的需求并按需求发展的解决方案。每一个现成的解决方案都不可能完全让你高枕无忧，你必须自己走完剩下的路。
 随着业务的成长，运行控制成为增容的越来越大的一部分。如果运行一个即时使用的系统，你必须考虑如何升级、配置和监视数以千计的机器。
 架构进化——任何一个成长中的网站面临的主要挑战。在保持现有网站运行的同时，需要有改变、改善和开发新系统的能力。
 一开始就过于担心可增容性是错误的。因为分析和担心可能永远也不会发生的流量而陷入恐慌是不必要的。
  完全不考虑可增容性是不对的。事情永远不会做完，系统总是在进化和改变，你需要建立一个有能力应付架构进化的组织。并且一开始就把这些期望和能力融入你的 业务中去，不要让人和组织成为你网站瘫痪的原因。不要认为系统一开始就应该是完美的，一个好的系统是在解决真正的问题和担忧中成长起来的，期待改变，适应 改变才是正确的态度。