旁观者看eBay技术发展

几年以来，eBay在几个不同的大会上先后分享过几次关于eBay技术的PPT，在这篇blog中，就以这些PPT来以旁观者的角度分析下eBay的技术 发展历程，不论eBay现在的业绩如何，不可否认，他们的技术还是挺强的，因此还是值得学习，eBay的整个技术发展历程从一定程度上来说可以认为是互联 网公司的典型技术发展历程，基本上各家互联网公司都在走着类似的路线，只是各家选择的语言不同、具体的实现方案不同、细节不同，当然，思路是一方面，实现 又是另外一方面，只有两者结合才能实现一个高可用、高性能和高并发的有海量数据的系统。

本篇blog中涉及到的主要有eBay的以下三个PPT，先来阐述下这几个PPT，最后从一个旁观者的角度来总结下eBay的技术发展。
ps: 以下提及的三个PPT均可在此下载：http://www.blogjava.net/BlueDavy/archive/2009/04/28/267970.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等。