旁观者看eBay技术发展.docVIP

旁观者看eBay技术发展 几年以来，eBay在几个不同的大会上先后分享过几次关于eBay技术的PPT，在这篇blog中，就以这些PPT来以旁观者的角度分析下eBay的技术发展历程，不论eBay现在的业绩如何，不可否认，他们的技术还是挺强的，因此还是值得学习，eBay的整个技术发展历程从一定程度上来说可以认为是互联网公司的典型技术发展历程，基本上各家互联网公司都在走着类似的路线，只是各家选择的语言不同、具体的实现方案不同、细节不同，当然，思路是一方面，实现又是另外一方面，只有两者结合才能实现一个高可用、高性能和高并发的有海量数据的系统。本篇blog中涉及到的主要有eBay的以下三个PPT，先来阐述下这几个PPT，最后从一个旁观者的角度来总结下eBay的技术发展。ps: 以下提及的三个PPT均可在此下载：/BlueDavy/archive/2009/04/28/267970.html1、The eBay Architecture 2006????? 这个PPT非常经典，阐述了eBay从成立之初到2006年所经历的技术发展历程，这个过程一定程度上也是目前大多数网站从小到大时的一个发展过程。????? 在这个PPT中，eBay首先根据自己的经验，总结出了一些经验，这些经验包括：????? (1). 每一层都要支持水平伸缩，按功能划分；????? (2). 优选异步方式为系统间交互的方式；????? (3).?减少系统间物理依赖以及提升部署的灵活性；????? (4). 自动化的错误诊断和通知，业务功能的降级支持。?????即使现在看这些经验，可谓是金玉良言，想必eBay也是在一个快速发展的过程经历了很多次血的教训才得到上面这些经验的。?????在总结完经验后，PPT开始详细的阐述eBay从1995--2006的技术发展历程，从V 1.0到V 2.x，首先是将系统重构为3层结构，采用Oracle，业务服务器和数据库服务器分开，采用索引，这也就是2.0版本；进入2.1版本后，想必是数据库压力开始增大了，这有两方面原因，一是访问量的上涨，二是数据量的上涨，因此将数据库服务器进行了升级，换成了更好的服务器，同时给前端加上了负载均衡，这应该是为了前端应用更简单的实现水平扩展；进入2.3版本后，增加了第二台数据库服务器，以支持failover，提升可用性，同时其他的业务服务器在不断的增加中，到2.3版本运行的末阶段，数据库服务器已经达到了运行的极限；进入2.4版本阶段，专注解决数据库压力的问题，采用的方案为将数据库逻辑分区为多个实例；进入2.5版本阶段，开始进行水平分表，例如按类目将商品分解到多张表中，或者读写分等。在V 2.5阶段完成后，此时数据库部分压力的问题基本解决，但在eBay面前又出现了新的问题（画外音：所以说互联网公司到最后技术的比拼也非常重要），几百人维护同样的代码，甚至还达到了类允许的最大的方法数等问题，于是进入了eBay架构的V 3时代。V 3最重要的是将整个应用翻写为Java，并提升了代码的重用性和代码的职责分离，同时为开发人员提供了一个开发的框架（应该就是那篇著名的eclipse at eBay）。????? 在PPT的最后，eBay又详细的分享了他们对于构建可伸缩系统的一些经验，这些经验对多数人而言都会非常的有帮助，来看看。?????? (1). 数据层的伸缩???????主要是三种方法：分解压力，减少数据库做的事情，无事务等技巧。???????分解压力最主要的方法有按功能进行划分，功能范围内的则可进行水平划分，在PPT中eBay还分享了下按功能划分的一些例子，例如按用户、商品、评价等，水平划分方面同样列举了一些例子，例如读写分、hash分等。???????对于数据层的伸缩，eBay在PPT中提到了非常关键的一点，那就是应用无需关心分库、分表这些，这样的话，无论是要分库、合库、分表还是合表，对应用都是完全透明的，正是因为这个理念造就了eBay很早以前就拥有了令人骄傲的数据层，也就是DAL。?????? 减少数据库做的事情最主要的方法是不要在数据库中做业务逻辑的处理，将耗CPU的操作（包括joins、sorting等）放到应用中完成，使用Prepared statements和绑定变量。???????所谓的无事务等技巧是指没有分布式事务，而改为采用补偿等方式去保持数据一致性。?????? (2). 应用层的伸缩?????? 主要也是三种方法：分解压力，减少依赖和虚拟的数据操作。???????分解压力最主要的方法有按功能划分，水平则借助负载均衡来进行伸缩，关于这里面的具体的一些技巧，PPT中提到了应抛弃大部分Java EE的东西，保持应用层的无状态，尽可能的使用缓存。?????