eBay的架构
2010-08-28 16:02 乱世文章 阅读(257) 评论(0) 编辑 收藏 举报一开始就过于担心可增容性是错误的。因为分析和担心可能永远也不会发生的流量而陷入恐慌是不必要的。完全不考虑可增容性是不对的。事情永远不会做完,系统总是在进化和改变,需要建立一个有能力应付架构进化的组织。并且一开始就把这些期望和能力融入业务中去。
有谁不想知道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、连接池等。
不要害怕构建满足你的需求并按需求发展的解决方案。每一个现成的解决方案都不可能完全让你高枕无忧,你必须自己走完剩下的路。
随着业务的成长,运行控制成为增容的越来越大的一部分。如果运行一个即时使用的系统,你必须考虑如何升级、配置和监视数以千计的机器。
架构进化——任何一个成长中的网站面临的主要挑战。在保持现有网站运行的同时,需要有改变、改善和开发新系统的能力。
一开始就过于担心可增容性是错误的。因为分析和担心可能永远也不会发生的流量而陷入恐慌是不必要的。
完全不考虑可增容性是不对的。事情永远不会做完,系统总是在进化和改变,你需要建立一个有能力应付架构进化的组织。并且一开始就把这些期望和能力融入你的业务中去,不要让人和组织成为你网站瘫痪的原因。不要认为系统一开始就应该是完美的,一个好的系统是在解决真正的问题和担忧中成长起来的,期待改变,适应改变才是正确的态度。