转 -- ebay电子商务平台技术

转的这个，也是转的。可惜没有找到原出处。分成3篇，我就合在一起了啊。文章是3年前的。

转载的地址如下：

http://hi.baidu.com/wohiker/blog/item/19610f23772a28fad7cae206.html

ebay电子商务平台技术（转）

ebay搭建了高可用性（high availability））、高可靠性（high reliability）、高扩展性（high scaliability））、高安全性（high security）、高性能（high performance）的电子商务平台及paypal支付平台。

一、             ebay电子商务平台演进历史

版本	时间	核心系统技术框架 （Language,Web Server,DB,OS）	备注
V1.0	1995-1997/9	Perl,Apache,GDBM,FreeBSD	•在1995年，花费一个周末在皮埃尔Omidyar’s客厅建立 •系统硬件由在Fry购买的零件做成 •每个项目是一个单独的文件，用perl脚本语言写的 •没有查寻功能，只有浏览功能
V2.0	1997/9-1999/2	C++,IIS,Oracle(Solaris),NT,	• 有排列的概念性建筑学 • 有排列的物理实施(没有应用服务器) 跑在Windows的IIS的 C++图书馆(eBayISAPI.dll) •微软用于查寻的索引服务器 •使用 Oracle数据库
V2.1	1999/2-1999/11	C++,IIS,Oracle(Solaris),NT	•服务器被编组入pools (small soldiers) •共鸣使用为前端负载平衡和故障转移 •查寻功能移动了向Thunderstone索引系统 •后端Oracle数据库服务器加入一个更大的机器(Sun E10000)
V2.3	1999/6-1999/11	C++,IIS,Oracle(Solaris),NT	•增加了第二数据库 • CGI水池、目录、页和查寻继续水平标度 •在1999年11月前，数据库服务器接近了物理成长的极限
V2.4	1999/11-2001/4	C++,IIS,Oracle(Solaris),NT	•数据库“split”技术。 •分开数据库到分开的事例里。 •水平的可测量性通过2000年。
V2.5	2001/4–2002/12	C++,IIS,Oracle(Solaris),NT	•水平的可测量性通过数据库分裂• 项目按类别分裂了• SPOF排除
V3.0	2002/12-present	Java,Sun Java System Web Server,Oracle(Solaris),Solaris	•使用Java语言，SUN系统网络服务器， Oracle (Solaris) •在J2EE应用服务器框架替换C++/ISAPI用Java.Re写了整个应用 •支持表示层的MSXML框架 •实施了发展仁作为程序员的一个基础

ebay电子商务平台技术（转）（二）

一、             产品管理流程

从软件产品管理流程的一级流程而言，ebay的产品管理流程与大部分软件公司的研发管理流程倒没有太多的差别，都大致遵循标准软件工程或CMMI之类的模型定义的流程，也即：项目策划（需求收集、业务需求规格说明书、市场分析、盈利分析等）->项目立项（产品需求规格说明书、立项评审会议、项目计划等）->需求分析设计->开发->测试->上线及市场推广。在核心流程定义清楚的情况下，软件开发流程至关重要的是执行力以及流程的持续完善，对此ebay的产品管理流程倒有很多值得借鉴的地方。

ebay产品管理流程

产品的管理流程的核心要素是对于需求的管理（需求的收集、组织、跟踪、审查、确认、变更和验证），ebay使用了“需求漏斗”的概念来描述需求在产品管理流程各个阶段中状态的迁移变化过程。通过对需求层层筛选过滤，保证

二、             ebay系统架构

ebay的架构师Dan Pritchett对架构的高扩展性的维度要素进行了较为精辟的阐述:

Transactional 交易

Data 数据

Operational 可操作的

Deployability 可部署的

Productivity 生产力

Feature TTM 特点

架构目标

高可用性、高可靠性、高扩展性、高安全性：支撑系统无缝的增长，保证大容量数据库和代码的扩展性

高可维护性，更快的产品交付：以加速度交付高质量的功能，更进一步精简和优化ebay的开发模型

为未来而架构：支撑10倍速的增长,支撑快速的业务革新

架构图

Container容器 presentation tier介绍层 busines tier 商业层 integration tier 综合层

Service framework 服务框架

三、             数据层

4．1功能分段（Functional Segmentation）

通过对数据库数据按照功能进行分段（应该就是按照use case的领域模型或实体模型），可以将原来存储到一台数据库服务器的数据按照功能分布到不同数据库服务器上。例如User数据库、Item数据库、Account数据库等，ebay有多达70多种功能分类。 功能分段可以支持功能间的解耦和彼此独立性，在分段时候需要根据功能使用频率、扩展性等特征对不同数据进行分段。一个典型的例子就是应当把OLTP和OLAP的功能分段，分别在不同的服务器上进行处理。

值得注意的是：ebay在应用服务器、数据库数据分区上是基于use case进行划分的，很好的度量标准，只是在use case的粒度定义上需要经验和技巧。

4．2水平切割（Horizontal Split）

按照所谓的主要存取路径“primary access path”进行水平切割。在模式上有多种。例如：写操作读取master数据库，读操作读取slave库；或者按照数据分段访问（按key、按Map to data location）

4．3逻辑数据库主机（Logical Database Hosts）

    逻辑数据库主机应该是类似数据库中间件或统一的数据存取层以隔离数据的实际物理存储库。在自己实现时候最为简单的方案就是在应用层面各Use Case的DAO层应当能够使用不同的数据源（多个数据库），而不是只能使用统一的数据源配置信息。

降低数据库资源占用（Minimize DB Resources）

   不在数据库服务器处理具有业务逻辑的操作：无存储过程，只采用简单的触发器

   将CPU占用较大的操作移到应用程序来处理：包括对依赖完整性、Join、排序等操作都放到应用程序来处理。这也对，毕竟大部分应用数据库是瓶颈，而且应用服务器还是比数据库服务器配置低，成本也低。

   大量使用prepared statements 和绑定变量（bind variables）

4．4减少数据库事务处理（Minimize DB Transactions）

避免死锁情况，降低耦合性，并发更新，无缝处理切割数据的访问

对于大部分的数据库操作采用Auto Commit方式。

完全没有使用客户端事务（程序代码）：单数据库的事务采用数据库服务器端匿名的PL/SQL块来进行事务管理

较少使用XA分布式事务。

ebay电子商务平台技术（转）（三）

一、             Application Tier (应用层)

5.1、最大限度地扩展J2EE

没有使用大部分的J2EE特性，主要使用了JDBC、servlet和rewrite过得connection pool

保持应用层无状态性：在应用层没有session状态，状态迁移在cookie或数据库存取。

Cache所有能够cache的：Cache公用的metadata，采用复杂的cache刷新机制；Cache从本地存储重新装载（memory db？）；Cache数据采用ThreadLocal模式，保证线程安全；

5.2、分层架构模型

严格按照J2EE规范，把应用画风华展现层（Presentation）、业务层（Business）、集成层（Integration）

应用服务器将不相互通信，不采用cluster方案。

5.3、数据访问层（Data Access Layer ）

采用了ebay内部的存Java OR mapping方案（类Hibernate）

所有的CRUD (Create Read Update Delete)操作都通过DAL的数据接口层操作。

在不变更代码的情况下支撑数据层的水平扩展（应该要修改配置文件吧？）

大量使用JDBC的Prepared Statements
动态的数据路由：Dynamic Data Routing（DDR） hides the physical location of data from developers by providing a mapping from logical names to physical tables and database servers on which they reside. eBay uses some scalability patterns to reduce complexity/latency. For example, on any given day, there are roughly 40 million distinct items for sale on eBay. These items are split amongst 20 different database servers. These details are hidden from developers-they access an Item object using its id (ItemID)-the exact server from which it is fetched is computed by DDR and queries are routed to that host+table at runtime.

DAL的failover机制：可以通过自动或手动方式监控数据源的可用性，在数据源不可用情况下能够自动按照预设的规则把数据源切换到备用主机，据说是在切换过程中用户的操作不会有中断。DAL的failover机制应该有点类似HA或Clsuter的功能（是F5？），只是其实时性、动态性怎样实现的，值得学习。

5.4、代码垂直分区（Vertical Code Partitioning）

按功能对代码进行分区：应用细粒度化，只操作单一区的数据（例如Selling，Buying等）；Domain包含了扩应用的公用业务逻辑（应该就是公用组件）

严格限定应用间的相互依赖性：应用最多只能依赖Domain，而不能依赖其他的应用；在公用的Domain间没有相互依赖关系

5.5、功能分段（Functional Segmentation ）

将功能切分层独立的应用池

降低或隔离DB的依赖性

允许平行的开发、部署和监控

5.6、平台解耦（Platform Decoupling）

将无事务操作的Domain从有事务的流程中解耦出来。

通过异步的EDA和同步的SOA模式对应用进行集成

采用JMS实现子系统之间和与数据库的松耦合。

二、搜索优化（Scaling Search）

eBay的搜索引擎系统原来使用的是Thunderstone的系统，但到2002年时候就遇到了性能瓶颈，当时更新一次索引需要9个小时，使用了最高档的设备也满足不了需求。eBay对全文检索的要求很高，产品列表、竞标等信息要求实时更新、很多查询要求返回所有结果、存储有按关键字、分类和结构化属性组织等多种形式。由于没有现成产品能满足所有需求，eBay开发了自己的全文检索系统。

实时供给器平台负责将更新从主数据库可靠广播到多个检索节点，索引支持实时更新，支持内存索引。

索引系统是高度分布式的，索引机有多组副本，一组又包含多台机器。

缓存技术也被应用于搜索系统中，主要是缓存常用搜索或非常耗资源的搜索的结果。