高性能服务器 | 出家如初，成佛有余

distributed key-value store 杂思

Posted 九月 27, 2009

distributed key-value store是当下比较流行的话题，尤其在构建诸如搜索引擎、IM、P2P、游戏服务器、SNS等大型互联网应用以及提供云计算服务的时候，怎样保证系统在海量数据环境下的高性能、高可靠性、高扩展性、高可用性、低成本成为所有系统架构们挖苦心思考虑的重点，而怎样解决数据库服务器的性能瓶颈是最大的挑战。

按照分布式领域的CAP理论（Consistency、Availability、Tolerance to network Partitions这三部分在任何系统架构实现时只可能同时满足其中二点，没法三者兼顾）来衡量，传统的关系数据库的ACID只满足了Consistency、Availability，因此在Partition tolerance上就很难做得好。另外传统的关系数据库处理海量数据、分布式架构时候在Performance、Scalability、Availability等方面也存在很大的局限性。

而key-value store更加注重对海量数据存取的性能、分布式、扩展性支持上，并不需要传统关系数据库的一些特征，例如：Schema、事务、完整SQL查询支持等等，因此在分布式环境下的性能相对于传统的关系数据库有较大的提升。当然不同的key-value store根据应用需求的不同，在设计理念并不完全相同，例如以Google BigTable、Amazon Dynamo为例：

BigTable is a CA system; it is strongly consistent and highly available, but can be unavailable under network partitions. BigTable has no replication at the database level, rather replication is handled underneath by GFS.

Dynamo is an AP system; it is highly available, even under network partitions, but eventually consistent. Data is replicated within a single cluster, so even under partitions most data is available, however one node’s latest version might not match that of another, so every reader is only guaranteed to see every write eventually.

其实使用key-value store的历史已经很久了，以前在做电信计费时候的Radius服务器就采用Berkeley DB这样经典的key-value store作为用户数据库，只不过早期使用这样的key-value store关注的重点主要在性能上，对于分布式、海量数据的处理并非考虑的重点。

1、key-value store与RDBMS的区别

摘自:Is the Relational Database Doomed?

2、一些常用的key-value的开源项目

这些项目的设计思路大多是参考Google BigTable、Amazon Dynamo

除了以上罗列的产品外，还有如下一些产品

Flare

其中Tokyo cabinet、Redis、MongoDB各有特色，可以作为项目使用key-value store时候的重点评估对象。

3、与工作相关的一些可以使用key-value store的应用场合

Cache：Memcachedb、Tokyo Tyrant

网络通信：做IM、P2P时候做单点登录服务器、状态服务器；消息队列服务器（Tokyo Tyrant）

交易系统：计费系统cdr及预处理后的账单数据；交易系统风控系统（内存数据库,redis）

日志：服务器访问日志，用于web analytics使用；呼叫中心的呼叫数据；

爬虫及搜索引擎：爬取页面日志；爬取任务；索引库

SNS社区及CMS站点：可以大规模应用Tokyo Cabinet+Tokyo Tyrant，结合Solr/Lucene或这样的Sphinx搜索引擎搞定查询问题

云存储：

4、参考资料

Brewers CAP Theorem

Towards Robust Distributed Systems

CAP Theorem

Key Value Store List

Anti-RDBMS: A list of distributed key-value stores

Database Sharding at Netlog, with MySQL and PHP

Technorati 标签: cap theorem,key-value store,架构,高性能服务器,tokyo cabinet,redis,mongodb

图片服务器选型方案

Posted 四月 20, 2009

Comments(0)

各个web项目要共享各种图片素材、手机软件，同时也需要处理用户自助上传的图片、软件在各个项目间的共享。采用了独立的图片服务器来集中存储各种图片资源，其他应用服务器通过NFS方式存取图片资源（在linux下使用nfs及软链接解决图片文件共享问题）。起初觉得这种模式相对简单且容易实现，也不是很在意图片服务器的容灾问题，最近在部署应用时候没有按照步骤操作，直接把通过NFS方式共享的目录删除了（由于要在应用上传图片时候实时同步到图片服务器上，因此NFS目录是read、write的），这才意识到容灾的问题。

在当前的经济形势下，遵循“少花钱、多办事”的原则，采用纯Open Source的方案，不增加硬件及软件投入。简单整理了一下图片服务器的实现时候需要考虑的几个地方：

1、操作文件系统的选择：

非分布式文件系统方案：ReiserFS4、Ext3、JFS

分布式文件系统方案：Redhat GFS、Lustre、ZFS、NFS

2、数据同步

采用操作系统层分布式文件系统本身的同步功能

采用应用层分布式文件系统同步方案：FastDFS、MogileFS、Hadoop HDFS

采用应用层第三方软件同步方案：csync2+inotify、rsync、unison、DRBD、tsync

3、Web服务器的选择：

采用轻量级的Lighttpd、Nginx，不采用apache

4、Cache及反向代理：

Squid

Lighttpd+mod_mem_cache

5、单独多个图片服务器、单独的图片服务器域名

6、数据压缩：

HTTP HEADER的Accept-Encoding

7、客户端缓存：

HTTP HEADER的Expires、Cache-Control、Etag、Last-Modified参数设置

8、应用层优化：

图片按需生成、图片预先生成、根据应用场景降低图片分辨率

采用ReiserFS4+csync2+inotify方案来满足当前需要，后续有空再测试一下FastDFS、MogileFS、Hadoop HDFS 的方案。

Technorati 标签: 图片服务器,高性能服务器,csync2,inotify,lighttpd,hadoop,分布式文件系统,选型

在linux下使用nfs及软链接解决图片文件共享问题

Posted 九月 13, 2008

Comments(4)

由于在门户社区中，诸如图片、下载软件这样的资源都较大，且在下载过程中，对带宽资源的占用也较大，因此为不影响正常业务应用，一般情况下都是将图片等资源部署到一台单独的服务器上以分配单独的带宽（在同一台服务器上也将这些资源存放在磁盘空间较大的地方），此种情况下图片等资源与应用不一定在同一台服务器上，即使在同一台服务器上也不一定部署在同一目录下。方案如下：

1、图片等资源部署在单独的另外一台服务器上

此种模式可以通过linux的nfs来把完成远程文件mount为本地的文件目录（类似于windows的网络共享），步骤如下：

下面以将192.168.1.199（NFS服务器端）上的目录/liang mount到192.168.1.202（NFS客户端）上为例，说明一下远程mount的实现

1) NFS服务端（192.168.1.199）执行如下操作

在NFS服务端（192.168.1.199）修改/etc/exports，内容如下

         /liang 192.168.1.0/255.255.255.0(ro,no_root_squash,sync)

格式如下：directory machine1(option11,option12)

       注意：好像采用很多文档所说的 /liang 192.168.1.*(ro,no_root_squash,sync)存在问题

在NFS服务器端启动NFS:

/etc/rc.d/init.d/portmap start

/etc/rc.d/init.d/nfs start

exportfs命令：

在启动了NFS之后又修改了/etc/exports后可以用exportfs命令来使改动立刻生效，命令格式如下：

exportfs [-aruv]

-a ：全部mount或者unmount /etc/exports中的内容

-r ：重新mount /etc/exports中分享出来的目录

-u ：umount 目录

-v ：在 export 的时候，将详细的信息输出到屏幕上。

2) 在NFS客户端(192.168.1.202)执行如下操作

mkdir /liang

mount 192.168.1.199:/liang /liang

修改/etc/fstab以在系统重启时候自动mount：

     # device       mountpoint     fs-type     options      dump fsckorder

     192.168.1.199:/liang  /liang    nfs          rw            0    0

showmout命令

-e ：显示指定的NFS SERVER上export出来的目录。

-a ：是用来显示已经mount上本机nfs目录的cline机器，一般在NFS SERVER上使用

2、图片等资源与应用部署在同一台服务器上，但资源目录与应用目录不在一处

此种情况，采用linux的软链接把图片等资源链接链接到应用的目录下。

ln -s /image /www/newwap/wap/image

由于安全上的考虑，tomcat及jboss缺省情况下都不允许访问软链接的文件，改动如下：

在conf/server.xml中或conf/Catalina/localhost（根据虚拟主机配置情况做相应改变）下的context中增加如下内容：

<Resources className=”org.apache.naming.resources.FileDirContext”

allowLinking=”true”/>

</Context>

3、参考资料

http://nfs.sourceforge.net/nfs-howto/ar01s04.html

Technorati Tags: nfs,ln,软链接,高性能服务器,mount,linux

无线增值业务门户建设技术思考

Posted 五月 25, 2008

Comments(1)

eSales这样的业务运营、支撑系统由于大部分内容都是动态的且由于并发用户数相对较少、压力也相对较低，在设计合理的情况下，性能并不是最大的瓶颈，因此此种情况下采用动态页面的方式是比较恰当。对于门户社区而言，高并发、高负载、高性能、高可用性是第一位的，需要采用各种手段来提高其性能。关于网站优化最好的方法论是Yahoo 的Best Practices for Speeding Up Your Web Site ，技术层面细节的优化策略参看Yahoo的方法论。

同时这是一个用户为中心(user centered)的年代，诸如“以用户为中心的设计”、“以用户为中心的系统”、“用户为中心的营销”等等。但是怎样才能够让门户设计中充分考虑用户体验，避免致命性的坏体验（bad smell）？这是门户建设需要重点考虑的问题，这一点上所谓的交互设计模式对于我们还是有所益处的。关于用户交互设计的模式：Yahoo Design Pattern Library 和Interaction Design Pattern Library

此处重点从技术层面谈一下在门户开发时候需要考虑的重点内容：

Web2.0化：除了充分使用诸如TAG、RSS、DIGG、SNS、UGC这些典型的Web2.0的元素外，“用户体验”是门户建设的重中之重，以用户体验为中心，把这些web2.0元素恰当地融入无线增值业务门户中，相信我们才会造就一个伟大的无线互联网门户，否则只是一堆与别人雷同的舶来品。

无线门户、互联网门户一体化：WAP门户及互联网门户采用同样的技术架构，在整个系统的基础架构仍然沿用目前的Struts2+Spring+Hibernate（ibatis）的架构，但在View层不使用JSP，而是采用Freemarker，充分利用Freemarker对模板支持及对xml较好支持，将对WML(WAP1.0)、XHTML（WAP2.0）、HTML（Internet）的处理都统一到同一架构下。

REST（Representational State Transfer）：遵循REST设计原则，尤其是无状态通信（statelessness）。

页面静态化：对门户社区页面都尽量采用页面静态化方案，这样能够充分利用cache机制及实现replication、load balance及镜像（例如南北电信部署）。为了实现页面静态化策略，采用Freemarker+FMPP方案来实现页面静态化的策略。

SEO：在设计时候一定要首先重点考虑搜索引擎友好及针对google、baidu搜索引擎进行优化，主要是Meta Tag部分内容及网站架构，所有的页面url遵循RSET模式，对无法遵循REST模式的，采用lighhttpd的mod_rewrite来实现。

爬虫：简单的垂直爬虫主要采用httpclient+htmlparser方案实现，复杂爬虫策略采用Heritrix(或Nutch)实现。

搜索引擎：采用Nutch+Lucene+Compass方案，对门户定时索引，提供全站搜索功能。

AJAX：在eSales后台的ajax主要采用struts2的dojo实现，可以充分利用struts2的标签，保持架构的统一。在门户实现时候，由于主要采用静态页面化方案，对于需要动态内容的地方，采用ajax来实现动态数据的状态。在ajax库选择上，不再采用dojo，采用jquery方案。

CSS：在eSales后台主要还是采用frame、table方式来实现页面布局，在门户开发时候完全采用CSS方案，以保证页面布局的灵活性及页面大小。

Cache：尽量使用诸如memcache和squid的cache机制，提高性能

镜像：采用rsync来实现对静态页面内容的镜像及同步，解决因不同运营商（移动（铁通）、电信、联通（网通）、教育网、有线网）及地域用户访问速度上差异。

其他的部署策略参看下图：

参考资料：

性能方面：

http://developer.yahoo.com/performance/rules.html

http://highscalability.com/

High Performance Web Sites

Building Scalable Web Sites

http://www.sitepoint.com/print/web-site-optimization-steps

用户体验方面

http://www.welie.com/patterns/index.php

http://developer.yahoo.com/ypatterns/atoz.php

http://en.wikipedia.org/wiki/Interaction_design_pattern

http://www.visi.com/~snowfall/InteractionPatterns.html

Technorati 标签: 高性能服务器,freemarker,performance,ajax,用户体验,无线互联网,增值业务,交互设计

业务平台部署方案思考

Posted 四月 17, 2008

Comments(1)

Technorati 标签: 高性能服务器,高可用性,lighttpd,lvs,heartbeat,squid,电子商务

ebay 电子商务平台研究（2）-ebay architecture

Posted 十月 21, 2007

Comments(3)

4、ebay系统架构

4.1、架构度量标准

搭建高扩展性的系统架构是每一个架构师的口号，又有几个实现了这样的承诺？什么叫架构的高扩展性，我自己一直也没有明确的答案，ebay的架构师Dan Pritchett在其blog上的一篇文章You Scaled Your What?，对架构的高扩展性的维度要素进行了较为精辟的阐述:

Transactional
Data
Operational
Deployability
Productivity
Feature TTM

尤其值得注意的是他把系统的运营性、易部署作为架构扩展的重要指标提出，很好的实践性经验总结。对于大部分的互联网公司而言，“以软件作为服务”，运营效率、运营成本是核心的竞争力之一；在需求变更频繁、迭代时间较短、需要部署服务器众多的情况下，怎样在不影响生产系统业务运行的前提下，实现代码快速、安全的上线部署，直接影响能否及时响应需求变更和服务质量。因此在架构搭建、程序开发过程中一定要考虑系统的可维护性、可运营性以及部署上线的要求。

4.2、架构目标

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

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

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

4.3、架构

4.4、软件设计模式实践

http://au.sun.com/events/dev_forum/files/best_practices.pdf

http://gceclub.sun.com.cn/java_one_online/2003/TS-3264CHI(USA,2003)/ts3264ch.pdf

http://blog.spiralarm.com/richard/2006/12/billion-hits-a-day-ebay-javaone.pdf

5、架构最佳实践

• Scale Out, Not Up
– Horizontal scaling at every tier.
– Functional decomposition.
• Prefer Asynchronous Integration
– Minimize availability coupling.
– Improve scaling options.
• Virtualize Components
– Reduce physical dependencies.
– Improve deployment flexibility.
• Design for Failure
– Automated failure detection and notification.
– “Limp mode” operation of business feature

5.1、Data Tier(数据层)

5.1.1、功能分段（Functional Segmentation）

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

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

5.1.2、水平切割（Horizontal Split）

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

5.1.3、逻辑数据库主机（Logical Database Hosts）

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

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

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

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

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

5.1.5、减少数据库事务处理（Minimize DB Transactions）

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

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

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

较少使用XA分布式事务。

5.2、Application Tier (应用层)

5.2.1、最大限度地扩展J2EE

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

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

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

5.2.2、分层架构模型

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

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

5.2.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.2.4、代码垂直分区（Vertical Code Partitioning）

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

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

5.2.5、功能分段（Functional Segmentation ）

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

降低或隔离DB的依赖性

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

5.2.6、平台解耦（Platform Decoupling）

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

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

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

6、运营最佳实践

6.1、系统部署

• Demanding Requirements
– Entire site rolled every 2 weeks
– All deployments require staged rollout with immediate rollback if necessary.
– More than 100 WAR configurations.
– Dependencies exist between pools during some deployment operations.
– More than 15,000 instances across eight physical data centers.
• Rollout Plan
– Custom application that works from dependencies provided by projects.
– Creates transitive closure of dependencies.
– Generates rollout plan for Turbo Roller.
• Automated Rollout Tool (“Turbo Roller”)
– Manages full deployment cycle onto all application servers.
– Executes rollout plan.
– Built in checkpoints during rollout, including approvals.
– Optimized rollback, including full rollback of dependent pool

6.2、网管监控

Centralized Activity Logging (CAL)
– Transaction oriented logging per application server
• Transaction boundary starts at request. Nested transactions supported.
• Detailed logging of all application activity, especially database and other external
resources.
• Application generated information and exceptions can be reported.
– Logging streams gathered and broadcast on a message bus.
• Subscriber to log to files (1.5TB/day)
• Subscriber to capture exceptions and generate operational alerts.
• Subscriber for real time application state monitoring.
– Extensive Reporting
• Reports on transactions (page and database) per pool.
• Relationships between URL’s and external resources.
• Inverted relationships between databases and pools/URL’s.
• Data cube reporting on several key metrics available in near real time.

7、搜索优化（Scaling Search）

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

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

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

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

8、平台开发接口

9、网络解决方案

http://www.sinogrid.com/shownews.asp?news_id=72

http://www.sinogrid.com/show_solution.asp?solution_id=43&cat_id=15

10、参考资料

http://pages.ebay.com/community/chatter/2005december/insideebay.html

http://www.lukew.com/ff/entry.asp?318

http://www.slideshare.net/lukew/design-patterns-defining-and-sharing-web-design-languages

http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf

http://www.addsimplicity.com/adding_simplicity_an_engi/2006/11/you_scaled_your.html

http://www.eweek.com/article2/0,1759,2041437,00.asp

http://highscalability.com/ebay-architecture

http://www.infoq.com/interviews/dan-pritchett-ebay-architecture

http://glinden.blogspot.com/2006/12/talk-on-ebay-architecture.html

http://www.ddj.com/blog/architectblog/archives/2007/08/ad_2007_the_eba.html

http://blogs.zdnet.com/service-oriented/?p=675

http://itmanagement.earthweb.com/service/article.php/3531291

http://article.pchome.net/content-123538.html

http://pages.ebay.com/community/chatter/2005november/insideebay.html

http://designcult.typepad.com/designcult/files/Design_Patterns_IA_Summit_public.pdf

http://au.sun.com/events/dev_forum/files/best_practices.pdf

http://gceclub.sun.com.cn/java_one_online/2003/TS-3264CHI(USA,2003)/ts3264ch.pdf

http://download.oracle.com/oowsf2004/1235_wp.pdf

Technorati 标签: 电子商务 , architecture , 高性能服务器 , 电子支付 , ebay

ebay 电子商务平台研究（1）-ebay 产品研发流程

Posted 十月 21, 2007

Comments(0)

需要好好学习研究一下ebay的电子商务平台及paypal支付平台的开发方法论、系统架构模式，为搭建高可用性（high availability））、高可靠性（high reliability）、高扩展性（high scaliability））、高安全性（high security）、高性能（high performance）的电子支付及电子商务平台积累经验。

研究重点集中在两个方面：

ebay的产品研发管理
软件架构

1、ebay业务情况

http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf

212 million registered users, 1 billion photos

eBay users worldwide trade more than $1590 worth of goods every second

eBay averages over 1 billion page views per day

At any given time, there are approximately 105 million listings on the site

eBay stores over 2 Petabytes of data – over 200 times the size of the Library of Congress!

The eBay platform handles 3 billion API calls per month

26 Billion SQL executions/day!

On an average day, it runs through 26 billion SQL queries and keeps tabs on 100 million items available for purchase.

In 33 countries, in seven languages, 24×7

300+ features per quarter，Roll 100,000+ lines of code every two weeks

99.94% availability, measured as “all parts of site functional to everybody” vs. at least one part of a site not functional to some users somewhere

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

版本	时间	核心系统技术框架（Language,Web Server,DB,OS）	备注
V1.0	1995-1997/9	Perl,Apache,GDBM,FreeBSD	• Built over a weekend in Pierre Omidyar’s living room in 1995 • System hardware was made up of parts that could be bought at Fry’s • Every item was a separate file, generated by a Perl script • No search functionality, only category browsing
V2.0	1997/9-1999/2	C++,IIS,Oracle(Solaris),NT,	• 3-tiered conceptual architecture (separation of bus/pres and db access tiers) • 2-tiered physical implementation (no application server) • C++ Library (eBayISAPI.dll) running on IIS on Windows • Microsoft index server used for search • Items migrated from GDBM to an Oracle database on Solaris
V2.1	1999/2-1999/11	C++,IIS,Oracle(Solaris),NT	• Servers grouped into pools (small soldiers) • Resonate used for front end load balancing and failover • Search functionality moved to the Thunderstone indexing system • Back-end Oracle database server scaled vertically to a larger machine (Sun E10000)
V2.3	1999/6-1999/11	C++,IIS,Oracle(Solaris),NT	• Second Database added for failover • CGI pools, Listings, Pages, and Search continued to scale horizontally • By November 1999, the database servers approached their limits of physical growth.
V2.4	1999/11-2001/4	C++,IIS,Oracle(Solaris),NT	• Database “split” technology. • Logically partition database into separate instances. • Horizontal scalability through 2000, but not beyond
V2.5	2001/4–2002/12	C++,IIS,Oracle(Solaris),NT	• Horizontal scalability through database splits • Items split by category • SPOF elimination
V3.0	2002/12-present	Java,Sun Java System Web Server,Oracle(Solaris),Solaris	• Replace C++/ISAPI with Java.Re-wrote the entire application in J2EE application server framework • Leveraged the MSXML framework for the presentation layer • Implemented a development kernel as a foundation for programmers

3、ebay产品研发方法论

3.1、产品管理流程

http://pages.ebay.com/community/chatter/2005november/insideebay.html

http://pages.ebay.com/community/chatter/2005december/insideebay.html

http://pages.ebay.com/community/chatter/2003Apr/InsideeBay.html

http://pages.ebay.com/community/chatter/2005February/homevisits.html

http://creativityandinnovation.blogspot.com/2007/05/innovation-and-leadership-lessons-from.html

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

ebay产品管理流程

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

ebay需求收集渠道

Strategic Analysis：

Community：除了通常的邮件、电话、社区论坛等沟通方式外，eBay’s “Voices” program类似于用户座谈会这样的重要的沟通形式

Visits program：主要是侧重用户体验部分。

3.2、软件开发方法论

Our site is our product. We change it incrementally through implementing new features.
• Very predictable development process – trains leave on-time at regular intervals (weekly).
• Parallel development process with significant output — 100,000 LOC per release.
• Always on – over 99.94% available.

以此看来，ebay在开发方法上应该是采用了敏捷软件开发过程或RUP，采用迭代和增量开发方式。

3.3、用户体验设计