有些东西必须动手做起来才能明白真正的含义，要不然只是空中楼阁。就像我高数反复看书，书上的题一看都能看懂，考试一做就Over，还是要做习题册才能理解，好吧，我穿越了。 

对于SOA，总是停在一个很浮的角度上，做了一些大东西，开始明白SOA真正的含义，对表现层、业务层、持久层的划分也有了更明白的认识，为什么要这么做。

持久层将类与数据库绑定在一起，提供一个代理，简单的说就是将数据库中的数据翻译存储到类中，这样到了业务层，类只要关心怎么处理业务流程即可，根本不需要关心类中的数据怎么从数据库获得，数据库也不用考虑怎么配合类，持久层会做好这个事。

业务层只负责处理业务流程，既不关心数据怎么来的，也不关心数据怎么显示，数据由持久层绑定好了，显示由表现层呈现。用例驱动整个业务流程。

表现层只负责把数据呈现出来，不需要关心数据的处理是怎么完成的，只需要把数据从表现层中获取出来，以合理的方式呈现出来即可，同时把交互的消息传达给业务层，业务层接受消息再处理业务。

通过这样的三层分割，系统中最重要的三个部分：数据、处理、显示，就完全的被分割开来，剥离了耦合，实现了内聚，软件工程中的高内聚、低耦合目标就达到了。数据库构架师负责持久层，程序员负责业务层，用户体验师负责表现层，层层分工。

然后SOA，实际上就是把“服务”当做“用户”来对待，一个用户想要进入一个系统，先要注册，然后系统知道了这个用户，给他分配一些资源，给他一些权限等等。

对于服务也是一样，在一个SOA系统中，想要加入一个服务，就把这个服务注册，系统为其分配权限和资源，服务利用这些权限和资源自给运行，处理自己的业务。当系统不需要这个服务的时候，就将其注销，从系统中去掉。这样服务业成为动态的了，跟业务不耦合，SOA核心系统只需要提供服务注册、服务接口、权限及资源分配即可。

但是说起来简单，想要把服务当成一个用户一样来处理，还是需要非常高的水平才能做到的，像我这种小菜鸟就不行。要通过企业服务总线ESB将所有服务连接起来，服务从ESB上获取数据，通过SOAP进行数据交互。

顺便说一句，XML很好很强大！

类似的文章

• 2009年05月1日 -- 小规模低性能低流量网站设计原则 (3)
• 2009年04月12日 -- eBay数据库构架方案分析 (0)

荣耀属于Fenng牛

到处都是什么大规模啊，高流量啊，高性能之类的网站架构设计，这类文章一是满足人们好奇心，但看过之后也就看过了，实际收益可能并不大；另外一个副作用是容易让人心潮澎湃，没学走先学跑，在很多条件仍不具备的情况下，过度设计、过度扩展(高德纳大爷也说过，”过早优化是万恶之源”)，所以，这里反弹琵琶，讨论一下小规模、低性能、低流量的网站该如何搞法。

如果站点起步阶段可能就是一台机器(或是一台虚拟机，比如 JobsDigg.com )，这个时候，去关注什么数据拆分啊，负载均衡啊，都是没影子的事情。很多大站点的经验绝不能照搬，辩证的参考才是硬道理。

拥抱熟知的技术
动手构建站点的时候，不要到处去问别人该用什么，什么熟悉用什么，如果用自己不擅长的技术手段来写网站，等你写完，黄花菜可能都凉了。所以，有现成的软件组件可用，就不要自己重新发明轮子。人家说 Python 牛，但自己只懂 PHP ，那就 PHP 好了，如果熟悉 .net ?，那也不错。用烂技术不是丢人的事情，把好技术用烂才丢人。

架构层次清晰化
起步的阶段应该清楚的确定下来架构的层次。如果都搅和在一起，业务一旦扩增开来，如果原有的一堆东西拆不开就是非常痛苦的事情。

Web Server <--> (AppServer)<-->Cache(eg. Memcached)<-->DB层次清晰化的一个体现是(以 LAMP 架构为例)：即使只有一台机器，也应该起个 Memcached 的实例，效果的确非常好–一般人儿我不告诉他…不要把什么都压到 DB 上，DB 一旦 I/O 压力走到磁盘上，问题要暴露出来是很快的。没错，DB 本身也会利用自己的 Cache，但 DB 的Cache 和 Memcached 设计出发点毕竟不一样。

数据冗余? 有必要
很多人并不是数据库设计专家，如果应用要自己设计表结构什么的，基本都是临时抱佛脚，但三个范式很多人倒是记得牢，这是大多数小型 Web 站点遇到的一个头疼事儿，一个小小的应用搞了几十个表… 忘掉范式这个玩意儿! 记住，尽可能的冗余数据，你在数据层陷入的时间越多，你在产品上投入的就会越少。用户更关心的是产品的设计。

前端优化很重要
因为流量低，访客可能也不多，这时候值得注意的是页面不要太大，多数流量低的站点吃亏就在于一个页面动辄几兆(我前两天看到一个Startup的首页有4M之大,可谓惊人)，用户看个页面半分钟都打不开，你说咋发展? 先把基本的条件满足，再去研究前端优化。

功能增加要谨慎
不是有个 80/20 原则么? 把最重要的精力放在最能给你带来商业价值的地方。有些花里胡哨的功能带来很大的开销，反而收效甚微。记住，小站点，最有价值的是业务模式，而不是你的技术有多牛。技术是为业务服务的，不要炫技。

有些网站不停的添加功能，恰恰是把这些新功能变成了压死自己的稻草。

从开始考虑性能
这一点是可选的，但也重要。设计应用的时候在开始就应考虑 Profile 这件事情。一套应用能否在后期进行有效优化和扩展，很大的程度限制在是否有比较合适的 Profile 机制上。需要补充的是，对性能的考虑必然要把有关的历史数据考虑进来。另请参见网站运维之道的容量规划以及其它小帖子。

好架构不是设计出来的
这是最后要补充的一点。好的架构和最初的设计有关系，但最重要的是发展中的演化：

发展–>发现问题–>反馈–>解决问题(执行力)–> 改进->进化到下一阶段–新问题出现(循环)有些站点到了某个阶段停足不前，可能卡在执行力这个地方，来自用户的反馈意见上来了之后，没有驱动力去做改进。最后也是死猪不怕开水烫了。最怕听到的就是”业务不允许”的托词，试想如果不改进业务都没了，那业务还允许么? 其实就是一层心理障碍。

这篇文章有浓重的山寨风格，所以，你不要太认真。如果在用短、平、快的方式构建某些山寨网站的话，可参考其中对你有益的点，不赞同的地方可以直接忽视掉，就没必要费力留言进行争论了。

–EOF–

好的业务模式(产品) + 很好的技术 = 大赚钱
好的业务模式(产品) + 能用的技术 = 也赚钱
差的业务模式(产品) + 好的技术 = 赚吆喝(现在的SNS就差不多这样了)
差的业务模式(产品) + 差的技术 = 自己浪费资源

类似的文章

• 2009年08月20日 -- SOA构架与三层结构 (2)
• 2009年04月12日 -- eBay数据库构架方案分析 (0)

(荣耀属于Fenng和F5)

一、 eBay的数据量^[]

作为电子商务领头羊的eBay公司，数据量究竟有多大？eWeek的报道中，eBay的存储主管Paul Strong对数据量做了一些介绍，这些数据可以作为参考。

1. 站点处理能力

A. 平均每天的PV超过10亿

B. 每秒钟交易大约1700美元的商品

C. 每分钟卖出一辆车

D. 每秒钟卖出一件汽车饰品或者配件

E. 每两分钟卖出一件钻石首饰

F. 6亿商品，2亿多注册用户

G. 超过130万人把在eBay上做生意看作是生活的一部分

在这样高的压力下，可靠性达到了99.94%，也就是说每年只有5个小时多一点的时间服务不可用。从业界消息来看，核心业务的可用性要比这个还要高。

数据存储工程组控制着 eBay的2PB (1Petabyte=1000Terabytes) 可用空间。这是一个什么概念，对比一下 Google 的存储就知道了。每周就要分配 10T 数据出去，稍微算一下，一分钟大约使用 1G 的数据空间。

2. 计算能力

eBay使用一套传统的网格计算系统。该系统的一些特征数据：

A. 170 台 Win2000/Win2003 服务器；、

B. 170 台 Linux (RHES3) 服务器；、

C. 三个 Solaris 服务器：

为QA构建与部署 eBay.com；、

编译优化 Java / C++ 以及其他 Web 元素；、

D. Build整个站点的时间：

过去是10个小时，现在是30分钟；、

E. 在过去的2年半，有200万次Build，很可怕的数字

3. 存储硬件与软件

每个供货商都必须通过严格的测试才有被选中的可能，这些厂家或产品如下：

A. 交换机：Brocade

B. 网管软件：IBM Tivoli

C. NAS：Netapp（占总数据量的5%，2P*0.05，大约100T）

D. 阵列存储：HDS （95%，EMC在eBay是出局者）

E. 负载均衡与Failover：Resonate

F. 搜索功能：Thunderstone indexing system

G. 数据库软件：Oracle，大多数DB都有4份拷贝

H. 数据库服务器：Sun E10000

I. 数据备份：Share Plex，购买的全球Licence用于数据复制

4. 架构

A. 高分布式

B. 拍卖站点是基于Java的，搜索的架构是用C++写的

C. 数百名工程师进行开发，所有的工作都在同样的代码环境下进行

5. 其他信息

A. 集中化存储应用程序日志

B. 全局计费：实时的与第三方应用集成（eBay的PayPal）

C. 业务事件流：使用统一的高效可靠消息队列，并且使用Cookie-cutter模式用于优化用户体验

二、 eBay 的应用服务器规模

从Oracle的一份白皮书《The eBay Global Platform and Oracle 10g JDBC》^[]中可以了解到，在2004年的时候，eBay的应用服务器采用了IBM Web Sphere，部署在WinNT上，硬件是Intel双CPU奔腾服务器。服务器数量是2400台。在第一部分中可以知道，eBay 的是集中式处理Log的，每天会有2T的Log数据产生，现在只会更多。这些应用服务器分成不同的组，通过一个统一的DAL(Database Access Layer)逻辑层访问135个数据库节点。

这篇白皮书已经发布了两年，相信在这两年的时间里，服务器规模又会扩大了许多。

eBay的SOA架构V3示意图如下：

三、 eBay的数据库分布扩展架构^[]

对于eBay这样超大规模的站点来说，瓶颈往往最容易在数据库服务器上产生，必定有一部分数据（比如交易记录这样不容易水平分割的数据）容易带来大量的读操作，而不管用什么存储，能承担的I/O能力是有限的。所以，如果有效的分散I/O的承载能力就是一个很有意义的事情。

大约为如下结构：

由F5公司设计的方案，通过Quest公司的Share Plex^[]近乎实时的复制数据到其他数据库节点，通过特定的模块检查数据库状态，并进行负载均衡，I/O 成功的做到了分布，读写分离，而且极大的提高了可用性。虽然整个方案技术并无高深之处，但方法巧妙，效果极好。

当然，这个技术架构不算便宜。Quest的Share Plex License很贵，而且对于每个结点来说，都需要数据库License与硬件费用。但优点也很多：节省了维护成本，数据库层面的访问也能做到SOA，高可用性。

国内的一些厂商比较喜欢给客户推存储级别的解决方案。通过存储底层复制来解决数据分布以及灾备问题。这个思路似乎太传统了，对于大型集群多少有点过时。

四、 Share Plex数据库负载均衡方案^[]

1. 需求及挑战

eBay拥有30套生产数据库，全部采用Oracle数据库：

A. 12个数据库支持“live”项目（Sun 480/4500）

B. 1个数据库支持存档项目（Sun 4800）

C. 4个数据库支持客户数据（Sun 4800）

D. 2个数据库支持eBay的反馈系统（Sun 480）

E. 1个数据库支持非正常的 “cache”数据（Sun 4800）

F. 10个其他的数据库（大部分Sun 480 class）

同时，采用Hitachi SAN建立存储架构，建立了两个远程备份数据库，并实施实时复制数据到远程数据库实现冗灾，同时每24小时实施针对数据块的数据备份。

因此，通过eBay数据库读写的比率分析，可以发现，eBay在数据库提供服务时，读和查询的操作达到530亿次，而数据库写和更新的操作达到2亿次。“读和查询”操作与“写和更新”的比率达到265:1。可见查询和数据库读的操作给数据库管理系统带来巨大的压力。而更为严峻的是，eBay年增长率达到50%，这意味着，来自读和查询的操作压力将持续增大，要保证数据库服务的响应能力和效率，稳定性和安全性，eBay 必须采用数据库服务器的负载均衡解决方案。

但是，由于系统庞大，出于投资保护等考虑，eBay对数据库服务器的负载均衡解决方案的需求有如下几个特点：

A. 不改变eBay的数据库体系结构

B. 可用性目标达到99.9%

C. 需承载eBay每年50%的高成长

D. 简单管理等等

这意味着在不对系统大动干戈的同时，却革命性地提高其性能，其挑战不言而喻。

2. 解决方案

针对eBay数据库服务器负载均衡的需求特点，eBay考虑了三种解决方案：

A. 将数据库垂直分割，划分成多层数据库处理，减轻原来单层数据库处理数据而形成的瓶颈与可用性问题。

问题：这种方案很难部署，而且也没有从根本上解决单点故障问题。

B. 采用Oracle OPS/RAC机群解决方案。

问题：要求给便数据库编程代码，非常难以管理与维护。

C. 采用F5与SharePlex 联合解决方案。

优点：简单管理，不需要改变整个体系结构。

在最初，eBay采用Oracle OPS/RAC解决问题。但是后来经过充分论证和探讨，最终eBay采用了基于F5/SharePlex的解决方案。

F5解决方案是应用类似OPS/RAC，但是却相对简单的解决方案，不用改变数据库体系结构，管理和维护简单得多。

F5解决方案得主要思路是：通过应用将数据库“读与查询”的操作与”写和更新”的操作导向到分开的 “逻辑” 数据库，这些数据库服务器都单独配备数据存储，而没有采用共享存储的方式。这样，F5 应用交换机动态的将所有的数据库”读与查询”请求导向到查询数据库服务器群中，并智能负载均衡到最佳的数据库服务器上。所有的”写和更新”请求都指向到一个单一的数据库服务器上，由Share Plex动态实时将数据记录复制到”读与查询”数据库服务器群的数据库中。

这样，一方面，数据库服务器群被F5应用交换机虚拟化和集群，变成了一个“池”；另一方面，“读与查询”的操作，可以根据需要，选择更高效率得数据库服务器，从而使“读与查询”的操作压力得到解决。同时，随着业务的增长，还可以随时根据客户业务的压力在线扩展新的服务器在这个群之中。

由于根据以上分析，数据库读写的比例超过260倍，采用这样的方法，有效解决了数据库性能和高可用性要求。

3. 方案特点

F5解决方案具有以下特点：

A. 运用分离读和写操作，使读和写操作进入分别的逻辑数据库 而不是共享磁盘

B. 数据库服务器均衡可以使所有的读操作交叉分配到Available Hosts，所有的写操作都指定到单一的DOR(Database-Of-Record)

C. 应用类似OPS/RAC，但是却相对简单的的解决方案

D. 发挥F5产品灵敏的量测性和显著的增强可用性。

采用F5的BIG-IP负载均衡器后，对于eBay应用系统有独到的优势：

A. 高可用性：BIG-IP动态分配每一个流量请求到后台的四台Oracle 9i Database数据库服务器，并动态检查各个服务器的健康状态，将下一个请求分配给最有效率的服务器，任何服务起死机时，BIG-IP即刻将流量请求分配给其他的三台服务器，从而达到99.999%系统有效性。特别是针对Oracle 9i 数据库服务器，F5公司专门为Oracle 9i数据库开发了专用的健康检查模块，通过调用F5专有的扩展应用校验（EAV）进程，F5能够随时得到Oracle 9i数据库的应用层服务能力而不是其他的负载均衡设备所采用的ICMP/TCP层进行健康检查。

B. 高安全性： BIG-IP支持地址翻译技术和安全地址翻译，这样一来客户不可能知道真正提供服务的服务器的IP地址与端口，从而保护数据库服务器不受到诸如SYN Flood、DOS及DDOS进攻。

C. 高效率：采用BIG-IP 负载均衡之后。BIG-IP可以智能寻找最佳状态的数据库服务器从而保证客户得到响应最快的数据库服务器以提供最佳的查询数据库服务。

D. 高可扩展性：BIG-IP可以支持动态增加或删除其负载均衡的数据库服务器群组的任何数量的服务器,而不需要对前端或后台做任何改变从而使得系统扩展轻松方便、透明。

E. 高可管理性：BIG-IP有专门的管理软件可以实时监控整个数据库服务器群组的流量状态,并分析发展趋势帮助客户及时根据流量增长增加服务器。

4. 客户价值

F5解决方案具有低成本、低维修，以及保护投资，高效率的特点，并方便在线拓展，面向未来。在2001年第二季度，F5公司与Quest公司合作成功帮助客户实现了以上解决方案，初期布署了两台”读与查询”数据库服务器和一台”写和更新”数据库服务器。在2001年第三季度成功通过了99.9%高可用性。并真正实现了在线高可扩展性，在2002年增加另外两台读与查询”数据库服务器，并于2002年第三季度增加部署了冗灾备份的功能。

F5提供的eBay数据库服务器负载均衡解决方案对行业也具有相当的借鉴意义。电子商务应用同样有着数据库查询的压力，如果能够有效将查询的压力分解到单独的服务器群来处理，将有效提高电子商务的应用效率。 对于电子商务类应用系统数据库扩展解决方案，只需要在Web Portal上将数据库请求分成两个不同模块，问题便迎刃而解。

对于公众服务行业类的数据库服务器的负载均衡，如银行，电信，税务等系统，每月和每季度的都会有报表生成汇总，这些报表既包括用户的月结单数据信息，也需要产生总体业务的业绩报告。这样就必须对数据库系统进行检索和查询。如果这些业务工作与实际生产环境是一个数据库的情况下，将造成系统的巨大压力。采用F5类似方法，同样能够有效达到高可用性预告可扩展性能的需要。

类似的文章

• 2009年08月20日 -- 关于VS2008与一些数据源配置的问题 (0)
• 2009年07月24日 -- 数据库中的一些概念——集群技术及数据仓库 (0)
• 2009年07月9日 -- Oracle 最近的一些记录 (0)