旁观者看eBay的技术发展
几年以来，eBay在几个不同的大会上先后分享过几次关于eBay技术的PPT，在这篇blog中，就以这些PPT来以旁观者的角度分析下eBay的技术发展历程，不论eBay现在的业绩如何，不可否认，他们的技术还是挺强的，因此还是值得学习，eBay的整个技术发展历程从一定程度上来说可以认为是互联网公司的典型技术发展历程，基本上各家互联网公司都在走着类似的路线，只是各家选择的语言不同、具体的实现方案不同、细节不同，当然，思路是一方面，实现又是另外一方面，只有两者结合才能实现一个高可用、高性能和高并发的有海量数据的系统。
本篇blog中涉及到的主要有eBay的以下三个PPT，先来阐述下这几个PPT，最后从一个旁观者的角度来总结下eBay的技术发展。
ps: 以下提及的三个PPT均可在此下载：http://www.macd11.com/760.html
1、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的东西，保持应用层的无状态，尽可能的使用缓存。
减少依赖最主要的方法有将代码也按功能进行划分，各功能之间需要共享的东西则放入domain中，所有的应用都只能依赖domain，不能依赖其他的应用，而domain之间也不能有依赖，另外PPT中还提及到的有平台解耦，对于这点eBay的做法是经典的EDA以及同步的SOA。
虚拟的数据操作指的就是(1)中提及到的数据层了，不过在这里还值得注意的是它有提到它们可以做到从数据路由方面来达到优雅降级，所谓优雅降级的概念就是当系统压力大时，只保核心功能可用，而其他非核心的功能则不可用。
(3).搜索的伸缩
对这部分不是很感兴趣，大概提下主要就是做了实时索引，水平划分以及缓存。
(4).操作的伸缩
eBay在当时就能考虑这块，真的很不容易，这里包含的主要是两点：代码部署以及监测。
由于当时的eBay基本每两星期就要做全站部署，不过现在的eBay已经不会这么频繁部署了，部署时的依赖关系、部署后失败的回滚操作、众多的配置以及需要部署到众多的机器，这些都烦恼着当时的eBay，因此eBay做了一个部署系统，该部署系统可做到的是根据需要的部署的功能，分析出其依赖关系，按依赖关系进行部署，部署时自动进行检测和校验，并可选择性的进行回滚或全部回滚，不得不感叹，真够强大的。
监测方面基于消息机制实现，对日志进行广播、记录（记录至文件(当时的eBay记录的操作日志文件就已经有1.5TB每天了)、捕捉异常进行告警或实时的系统状态的监测）以及分析（报表、挖掘等）。
从上面的对PPT的分析来看，尽管这个PPT并不厚，但它的价值真的非常的高，并且也充分的展现了eBay的技术实力。
2、eBay Architectural Principles 2008
在2008年的QCon London会议上，eBay分享了这个PPT，这个PPT的内容不像上面的PPT讲解eBay的架构演变过程，而是直接根据eBay的经验总结了一些构建大型可伸缩系统的架构原则，有点像设计模式，将之前应对场景需求的一些技巧都总结成了模式，因此这些原则对于构建大型系统的同学而言都非常有帮助，来具体的看看。
PPT首先提到了架构关注的重点：可伸缩性、可用性、延时、可管理性以及成本，然后就提交到四点架构模式，来具体看看。
(1). 能分则分
在这点上eBay提出了一个观点：”If you can’t split it,you can’t scale it”，因此eBay建议将系统按数据、压力或使用情况来进行分解，分解的模式为按功能以及水平拆分。
在PPT中eBay继续提及了数据库的垂直以及水平拆分方法、无事务、应用层的垂直以及水平拆分方法、应用层的无状态、搜索的垂直以及水平拆分，这些方法在第一个PPT中也有详细分享。
(2). 能异步则异步
在这点上，eBay认为，只要能异步就应该异步，异步的实现模式为消息机制以及定时批量操作机制。
消息机制的方式通常为功能核心部分完成后发出消息，然后订阅消息的应用异步的进行一些处理，例如创建商品在创建完毕后，发出消息，图像处理的应用在接到消息后则能对此商品进行相应的处理，在PPT中还举到的一个例子为发出消息，用于更新搜索中的索引信息，这其实也就是eBay的实时索引的实现方式了。
定时批量操作适用于导入三方数据、生成推荐等。
(3). 能自动化则自动化
在这点上，eBay认为，能自动化的就尽量自动化，避免人工操作，实现的模式为自适应配置以及机器学习。
自适应配置方面eBay举了个例子，给一个事件的订阅者定义了SLA，例如为99%的事件应在15秒内处理完，那么所谓的自适应配置就是系统应能根据配置的SLA自动的调整，以最小的资源去满足SLA，例如调整处理的线程数、队列的大小、弹出的频率等，是不是有那么点云计算的前兆，:)。
机器学习方面eBay主要提及到的为给用户提供最匹配的页面布局、推荐等。
(4). 记住所有失败的事
这里的需求是所有的系统都应能容错，主要目的是为了保证可用性，实现的模式为失败检测、回滚以及优雅降级。
失败检测上eBay采取的方法为通过发送消息，由消息订阅者来进行记录、告警、分析或挖掘。
在回滚方面主要指的是代码的部署和回滚，就是之前第一个PPT中提及的部署系统。
优雅降级指的是系统功能的动态打开和动态关闭，eBay采取的方法为一个集中的配置来管理功能的打开或关闭。
PPT中还举了个例子来更好的说明，首先应用检测到了某个资源不可用或很慢，此时为了保证可用性，可做的有这么几件事：应用停止对此资源的操作并发出警告、关闭非核心的功能、核心功能退化（基于failover切换至其他资源或转为异步处理模式）。
这个PPT同样也不厚，但总结的非常好，这些模式对于构建大型系统（尤其是互联网系统）而言基本都是必须的，在2009 QCon北京大会上，eBay分享的也是这方面的话题，大体都是相同的，因此就不再去分析那个PPT了。
3、Teaching Machines To Fish
在QCon San Francisco上，eBay分享了这个PPT，这个PPT重点在于分享了eBay的智能化方面的工作，包括智能的推荐、用户请求的智能回答等，实现的策略方面主要是基于对用户数据的收集和分析，这个部分由于主要是用户数据分析的模型，在PPT中没有做过多的介绍，但从PPT中也可以看出，eBay为了改进搜索的效果付出了很大的努力，以尽可能的达到让用户最快的搜到自己想要的东西，这其实很难做到，例如同样一个用户搜索同样一个单词，期待的结果有可能是不同的。
eBay的这三个PPT都非常的经典，不得不说，这种分享精神也是值得敬佩的，毕竟这都是eBay的发展历程中摸索出来的，分享出来必然能让很多碰到类似问题的网站少走很多的弯路，来说说我自己从旁观者的角度看eBay的发展历程。
从eBay的这几个PPT来看，我觉得可以看出，eBay的技术其实在2006年就已经基本成型，而其发展过程也可以看做是互联网行业技术发展的一个缩影。
随着访问量的增长、数据量的增长以及功能的不断增长，”分”基本成为了第一招救命招，而这招要做到其实不如想象中简单，通常涉及到缓存技术、应用的拆分、 eBay提及的同步SOA和异步EDA、数据库的拆分（分库、分表）、文件存储的拆分、负载均衡等，这些对技术的要求都很高，网站发展到了这一步后通常就逐步显示出技术的重要性了。
eBay在进行”分”的同时以及之后，在自动化以及可用性的提升方面也做出了很大的努力，这包括了部署系统、优雅降级、监测、系统容错、自适应配置等的动作。
到了后面的阶段，eBay开始投入了更多的精力在智能化的领域。
从上面这三个阶段来看，可以认为”分”–>自动化–>智能化是互联网技术发展的一个常见发展模式，当然，这其中涉及到了非常多的技术，eBay的PPT确实为我们分享了很多这方面的技术，而我同时觉得除了智能化以外，虚拟化或者云计算、节能技术也将成为后续互联网技术的重点，也许在后面各类大会上我们会更多的看到这方面的知识，当然，目前也有一些在这方面领先的公司，例如Google、Amazon等。
继续观看eBay的技术发展
在HPTS大会上，Randy Shoup放出的eBay的PPT有所改变，在原有的5个Architectural Lessons上又增加了5个lesson，从这也可以一定程度的看出当访问量、数据量、功能不断上涨后，碰到的技术问题也将继续发展，想必这也是eBay增加5个lessons的原因，eBay在技术方面的发展对很多互联网公司都有一些参考意义，毕竟它已经经历过了国内很多网站目前的阶段甚至是几年后的阶段，在本篇blog中就完整的来看看eBay的这10个lessons、eBay的应对策略以及我个人的一些推测。
1、 Partition Everything
这点是现在各家互联网都使用的招，说白了也很正常，毕竟一个网站通常要提供很多功能，如果都部署在同一台机器上，随着水平伸缩，后端的资源肯定会呈现不够用的现象，这个时候能采用的方法自然是分，分开后自然一台能够支撑的量也会更高，同时后端资源的压力也会减小。
当然，要做到这点其实并不容易，eBay应对的策略为：按功能水平划分应用、按功能水平划分数据库、按其他原则垂直划分表，涉及到的技术有：划分之后应用的交互的解决以及数据访问层（DAL）。
这点基本是现在互联网公司的必备技能。
2、 Asynchrony Everywhere
同步的交互会带来强耦合，可用性方面保障就比较困难了，因此尽可能的采用异步。
在这点上，eBay的应对策略为：事件驱动和pipeline、多播消息，涉及的技术为：消息中间件（无序、至少一次到达）、基于SRM技术的可靠多播。
这点基本也是现在互联网公司的必备技能。
3、 Automate Everything
这点eBay比较强，中国的互联网公司不知道有几家能做到，J，其中有一点和twitter那个PPT提到的差不多，就是配置信息的动态化，这个确实非常重要。
要做到这些方面，会涉及的技术有：配置发布/订阅机制的实现、机器学习。
有些其他强大的东西eBay在这里也没提，例如部署系统。
4、 Remember Everything Fails
这点很多公司都做，但从PPT来看，估计很少有公司能做到eBay这个地步，J，尤其是eBay的优雅降级，twitter公布的PPT中也有类似的内容，国内公司还得努力，呵呵。
eBay的应对策略为：异常后发消息、有相应的消息订阅者接收这些报警信息、按功能实现降级，保障核心功能的可用性，涉及的技术有：消息中间件、如何实现按功能降级。
5、 Embrace Inconsistency
这点对于互联网公司来说非常重要，事务过多，性能就狂降了，尤其是Partition everything后，分布式事务需求产生，就更要注意了，因此eBay的应对策略为最终一致，涉及的技术有：消息中间件、CAP等。
以上5个lesson是很早以前eBay PPT中就一直有的，而以下5点则是第一次出现在eBay的PPT中，从中也可以一窥随着网站的发展带来的技术挑战。
6、 Expect (R)evolution
这里eBay讲到的主要是如何更好的应对变化，这包括了功能演变、架构演变，eBay的应对策略为：灵活的schema、可插拔的处理流程以及增量的系统发布，这方面的技术还是相当复杂的，eBay采用的是：配置化处理流程、系统发布过程支持多版本共存。
这点要做到真的不容易，看来eBay已经碰到了发布必须增量发的问题了。
7、 Dependencies Matter
这点随着Partition everything和Asynchrony everywhere执行，以及功能的不断增加后，就会变得比较明显，想必eBay也是如此。
他们的应对策略：服务拓扑管理、设计上的控制（只允许依赖…）、客户端承担责任。
说到这点，不得不说下，客户端承担责任这点其实真的很重要，现在很多架构都喜欢放在服务端上解决N多问题，但很多场合确实有必要放到客户端去做，当然，这也会带来一些问题，例如升级等。
8、 Be Authoritative
这点没看明白。
9、 Never Enough Data
看的也不是很明白，我理解下来意思也许是数据肯定是会一直增长的，因此要考虑可伸缩的内存保存以及持久存储产品，英文写的就是large-scale distributed storage。
10、 Custom Infrastructure
同样没看明白，感觉就是要做到充分发挥机器资源，从eBay有SLA来看，莫非是要开始做云计算了。
总结来说，eBay也是首先解决如何做到基于水平伸缩支撑大访问量、大数据量的问题，然后则是开始步入如何管理以及保障好如此大的应用的关系、可用性等。
作者：BlueDavy
