假设你对项目管理、系统架构有兴趣，请加微信订阅号“softjg”，增加这个PM、架构师的大家庭

近期在infoq上面看到 ebay介绍其系统架构变迁以及系统设计分享方面的讲座，当中陈述了ebay从1995年到2006年之间系统架构的变化过程。从这里，我们能够学习到很多宝贵的经验来设计一个大容量，高并发，分布式的系统。

ebay的系统架构的变迁主要经历了4个阶段。以下一幅图展现了ebay系统架构变迁的时间表

在ebay的V1版本号，ebay採用的是FREEBSD + APACHE + PERL +DGBM。这是一个比較原始的模型，并且相对照较简单。操作系统，应用server，webserver 以及 数据库server都是在同一台机器中，网络结构在物理上仅仅有一层。

整个站点有四个域名。每一个域名相应不同的应用。每组应用相应一台server。

图表 1 ebayV1系统架构

随着业务量以及訪问量的不断上升。ebay在1999年開始对架构进行升级，技术架构发生了较大的变化，这期间主要是从1999-2004年。而架构的版本则从V2.0到V2.5 。以下我们来看看Ebay V2.0技术架构

• V2.0

² 開始採用ORACLEserver。数据库server和webserver分开。数据库独立部署到一台新的机器上面

² 程序逻辑上面已经開始分层。也就是我们常说的mvc3层结构：显示层、业务逻辑层、数据訪问层，而在物理上面还是两层结构 webserver 以及 数据库server

² 编程语言採用C++。那个时候java刚兴起，预计也没有其它好的语言选择了。

• V2.1

² 每组应用相应多台server，而多台server组成一个 servler pool(服务池)，通过一个负载均衡server来分别转发请求到不同的server

² 数据库部署到性能更加好的server上面

• V2.2

² 添加了一台数据库server作为 备份server。防止失败

• V2.3

这个版本号仅仅是对每一个应用添加了很多其它的服务器，不断的进行server pool

• V2.4

这个版本号最大且最重要的改变就是对数据库进行垂直拆分，即把数据库依照不同的功能模块进行划分，比如交易库，会员库，帐务库

• V2.5

这个版本号在2.4的版本号上面，对部分数据库进行读写分离，同一时候对Item(物品条目)数据库进行水平拆分。把Items依照不同的Categoty分配到不同的Categoty商品库里面，。这样大大的扩展了对Items数据库的訪问性能。

图表 2 ebayV2系统架构

从上能够看出ebay V2的架构变迁，主要是通过server的加入。数据库的垂直拆分以及水平拆分，数据库的读写分离操作 来提高整个站点的性能。在web层，通过加入server来进行水平扩展，同一时候相应用服务功能进行垂直拆分，依照不同的业务功能划分到不同的系统。

在数据库层面。进行了读写分离尝试，对数据库进行垂直拆分，同一时候把Items库依照Category进行水平拆分，这样做。分散了对产品库items的集中訪问，只是须要在DAL层提供透明的訪问机制，ebays这里貌似还并没有这个成熟的框架，同一时候不知道 分布式事务ebay在这个阶段是怎样实现的。

• V3

整个应用程序开发平台所有替换为j2ee平台。用java改写了整个站点。看来是一次比較大的工作。目的是为模块解耦 以及模块复用。从这里。我们能够看出java在开发复杂企业应用的优势。

V3版本号在数据库层面上面做了更加优化的设计。ebay继续在数据库上面进行优化

垂直拆分数据库，依照 功能模块 拆分为很多其它的子库

水平拆分数据库，对同一类数据。依照key值的不同数据分配到不同的数据库中（详细水平分库的方式有多种。这里就不再介绍了。）在进行水平拆分数据库的时候，ebay也必须建立一套透明的DAL訪问方式，必须提供透明的数据库訪问机制以及透明的数据库路由功能，数据库的物理结构变更不会影响到代码的逻辑变动。

在这里，ebay也在数据库层给出了最佳实践：

² 尽量降低数据库CPU的消耗，比如不使用存储过程，仅仅使用少量的触发器

² 降低数据库层面的逻辑功能。比如数据转化。组合，这些都放在逻辑层

² 降低动态SQL。主要是SQL中參数的动态生成功能，这一点，公司的DBA也在强调

² 尽可能的缩短数据库的事务时间，尽可能早的结束事物

² 尽可能的採用异步更新数据库方式，分散数据库的压力，比如消耗数据库时间的操作要放在夜间处理。

² 不使用分布式事务，看来分布式事务的确不使用高并发性的系统

在应用逻辑层面。ebay把系统依照功能划分成很多不同的模块。每一个模块作为一个子系统，同一时候通过水平扩展子系统server数量来提高整个系统的伸缩性。

以下看看ebay在应用层面给出的最佳实践

² 保持应用层子系统全然是无状态的，能够水平进行无限扩展以提高伸缩性，通过负载均衡server均等分配到各个子系统的实例池里面。

² 尽可能的使用缓存，缓存可以降低数据库的压力，使用空间来换时间

² 严格划分系统的各个层面。表现层，业务逻辑层，服务集成层。DAO层，基础设施层。

在应用层的设计上面，ebay通过不同的功能划分了非常多domain,每一个domain仅仅负责自己的功能的业务逻辑，domain与domain之间是不会依赖的，同一时候还会提供common domain 提供各个 domain之间的交互以及依赖，见下图：

因为ebay的数据库依照逻辑划分了非常多不同的字库。那么ebay必须提供透明的訪问数据库的能力，举个样例：ebay把Items依照categoray分成了非常多sub items库。假如须要查询出来某一个用户所购买的全部Items。那么必须要查询全部的sub items库,把数据库组合出来，那么DAL层必须屏蔽数据库的物理结构。一次性的把全部的sub items库中相应的数据查询出来。而这个訪问。相应用来说是透明的。应用不须要关注究竟items有多少个子库。

总结：在大规模，高并发系统的设计中，最经常使用的技术就是分层和缓存，把一个业务流程垂直分解成几个系统，每一个系统提供不同类型的服务，一个业务流程通过不同的服务组装起来，这就是SOA设计的思路吧。每一个系统能够进行水平集群，提供无状态的服务，能够水平无线扩展，数据库层面，主要就是用到垂直分库。水平分库。读写分离，热备份等技术，提高数据库的读写能力。在应用层能够考虑使用集中式缓存或者分布式缓存来降低数据库的訪问压力。

假设你对项目管理、系统架构有兴趣，请加微信订阅号“softjg”，增加这个PM、架构师的大家庭