eBay是目前世界上最大的电子商务网站（Am I right?），目前已有2亿多注册用户，每天PV超过10亿，执行260多亿次SQL操作，在这么高的负载下仍然能提供非常稳定的服务（可用性达 99.94%），其架构设计一定有很多过人之外。Bay的技术人员Dan Pritchett和Randy Shoup前段时间在SD Forum上介绍了eBay的架构设计，现简述如下。
除最基本的Web服务器和数据库服务器之外，eBay的网站完全使用自主开发的软件，开发人员达几百人。从1995年eBay成立以来， eBay网站的架构经历了多次演变。最初的V1.0版本开发只用了一个周末，使用Perl，应用各层都部署在一台机器上，数据存储采用文件系统+GDBM （动态哈希表）相结合的方式。1.0用了两年，到了1997年系统中的条件达到5万时就顶不住了，于是开发的2.0，在逻辑上是三层架构，物理上是二层， 应用层使用C++编写的内嵌于ISS的dll实现，数据库也独立出来使用Oracle。各系统都只使用一台服务器（Web服务器是有多台，但是不同的 Web服务器提供不同的服务）。再过了两年，99年升级到2.1，其中部分前台服务器使用集群，并将搜索功能独立出来，同时升级了数据库服务器的硬件。好 景不长，一年还没用下来又不行了，于是升级到2.3，所有前台服务器都使用了集群，数据库加了个Standby。结果发现还是不行，二个月之后立马升级到 2.4，数据库按业务划分了一下，使用多台服务器了（终于跨出了关键性的一步啊）。接下来的V2.5按数据库划分得更细了。02年之后又升级到3.0，使 用Java技术重写整个应用。
eBay在架构设计上主要关心三个可伸缩性：数据库存储可伸缩性、应用层可伸缩性和搜索服务可伸缩性，现一一道来。
数据库存储的可伸缩性实现的第一招是根据功能将数据库服务器加以分组，分为用户、条目、账号、反馈、事务等70多个类别。组内可伸缩性实现 则有两种方式：master/slave或数据分区，数据分区有使用取模实现，也有使用映射数据库实现。为减少数据库的负载，数据库层不包含业务逻辑，没 有存储过程，参照完全性检查、联接、排序等占CPU的工作移到应用中去作。同时很少使用事务，绝大部分操作都用auto commit模式。为减少对事务的依赖，应用程序需要非常仔细的安排数据库操作的顺序，对于部分不可避免的数据不一致则使用异步的故障处理脚本来处理。要求不使用事务增加了开发的难度，但也避免了数据库死锁和提高的数据库的并发度。
应用层主要涉及负载的分布和依赖关系最小化两个方面。eBay不使用大部分的J2EE特性，只使用servlet和一个定制的连接池，应 用层完全不维护状态信息（session使用cookie或scratch数据库维护），并尽可能的对常用的metadata等信息做了缓存。应用程序严 格的分为呈现层、业务层和集成层。其中集成层即数据访问层（Data Access Layer），实际上是eBay自己实现的一个Java ORM组件，负责所有CRUD操作，并支持动态数据路由服务（即逻辑数据库服务器->物理数据库服务器动态映射关系管理）。
为减少应用之间的依赖关系，应用代码按功能区划分为买出、购买等多个独立模块，共享的模块如用户认证、个性化等组织成Domain，应用 只依赖于Domain，不依赖于其它应用，Domain中各模块之间也无相关依赖关系。应用服务器和数据库服务器也根据业务类型划分为多个集群，不同集群 的开发、部署可并行进行。
eBay的全文检索系统原来使用的是第三方开发的一个系统，但到2002年就遇到了性能瓶颈，当时更新一次索引需要9个小时，使用了最高 档的设备也满足不了需求。eBay对全文检索的要求很高，产品列表、竞标等信息要求实时更新、很多查询要求返回所有结果、存储有按关键字、分类和结构化属 性组织等多种形式。由于没有现成产品能满足所有需求，eBay开发了自己的全文检索系统，其中有很多创新性的功能。实时供给器平台负责将更新从主数据库可 靠广播到多个检索节点，索引支持实时更新，支持内存索引。索引系统是高度分布式的，索引机有多组副本，一组又包含多台机器。缓存技术也被应用于搜索系统 中，主要是缓存常用搜索或非常耗资源的搜索的结果。
由此可见即使强大如eBay，最初的系统都是很菜的，后来一步步走向分布式才解决了一个又一个瓶颈，可见分布式是大势所趋。也可以看到功能 分解或面向对象中的CRC原则在网站架构设计中的重要性，若是功能划分不清晰，业务单元之间的依赖关系过于复杂，要设计一个好的架构是难上加难。
