【转】大型网站架构系列之一-不得不考虑的问题

前言：这两天机器坏了，正在送修中，写个系列的大型网站架构的文章，希望对有志在互联网做出一番事业的站长朋友们一些帮助。

 

注意：这里的大型网站架构只包括高互动性高交互性的数据型大型网站，基于大家众所周知的原因，我们就不谈新闻类和一些依靠HTML静态化就可以实现的架构了，我们以高负载高数据交换高数据流动性的网站为例，比如海内，开心网等类似的web2.0系列架构。我们这里不讨论是PHP还是JSP或者.NET环境，我们从架构的方面去看问题，实现语言方面并不是问题，语言的优势在于实现而不是好坏，不论你选择任何语言，架构都是必须要面对的。

 

文入正题：

首先讨论一下大型网站需要注意和考虑的问题

A.     海量数据的处理。众所周知，对于一些相对小的站点来说，数据量并不是很大，select和update就可以解决我们面对的问题，本身负载量不是很大，最多再加几个索引就可以搞定。对于大型网站，每天的数据量可能就上百万，如果一个设计不好的多对多关系，在前期是没有任何问题的，但是随着用户的增长，数据量会是几何级的增长的。在这个时候我们对于一个表的select和update的时候(还不说多表联合查询)的成本的非常高的。

B.     数据并发的处理在一些时候，2.0的CTO都有个尚方宝剑，就是缓存。对于缓存，在高并发高处理的时候也是个大问题。在整个应用程序下，缓存是全局共享的，然而在我们进行修改的时候就，如果两个或者多个请求同时对缓存有更新的要求的情况下，应用程序会直接的死掉。这个时候，就需要一个好的数据并发处理策略以及缓存策略。
另外，就是数据库的死锁问题，也许平时我们感觉不到，死锁在高并发的情况下的出现的概率是非常高的，磁盘缓存就是一个大问题。

C.     文件存贮的问题对于一些支持文件上传的2.0的站点，在庆幸硬盘容量越来越大的时候我们更多的应该考虑的是文件应该如何被存储并且被有效的索引。常见的方案是对文件按照日期和类型进行存贮。但是当文件量是海量的数据的情况下，如果一块硬盘存贮了500个G的琐碎文件，那么维护的时候和使用的时候磁盘的Io就是一个巨大的问题，哪怕你的带宽足够，但是你的磁盘也未必响应过来。如果这个时候还涉及上传，磁盘很容易就over了。
也许用raid和专用存贮服务器能解决眼下的问题，但是还有个问题就是各地的访问问题，也许我们的服务器在北京，可能在云南或者新疆的访问速度如何解决？如果做分布式，那么我们的文件索引以及架构该如何规划。
所以我们不得不承认，文件存贮是个很不容易的问题

D.    数据关系的处理我们可以很容易的规划出一个符合第三范式的数据库，里面布满了多对多关系，还能用GUID来替换INDENTIFY COLUMN 但是，多对多关系充斥的2.0时代，第三范式是第一个应该被抛弃的。必须有效的把多表联合查询降到最低。

E.     数据索引的问题
众所周知，索引是提高数据库效率查询的最方面最廉价最容易实现的方案。但是，在高UPDATE的情况下，update和delete付出的成本会高的无法想想，笔者遇到过一个情况，在更新一个聚焦索引的时候需要10分钟来完成，那么对于站点来说，这些基本上是不可忍受的。
索引和更新是一对天生的冤家，问题A，D，E这些是我们在做架构的时候不得不考虑的问题，并且也可能是花费时间最多的问题，

F.     分布式处理
对于2.0网站由于其高互动性，CDN实现的效果基本上为0，内容是实时更新的，我们常规的处理。为了保证各地的访问速度，我们就需要面对一个绝大的问题，就是如何有效的实现数据同步和更新，实现各地服务器的实时通讯有是一个不得不需要考虑的问题。

G.    Ajax的利弊分析
成也AJAX，败也AJAX，AJAX成为了主流趋势，突然发现基于XMLHTTP的post和get是如此的容易。客户端get或者post到服务器数据，服务器接到数据请求之后返回来，这是一个很正常的AJAX请求。但是在AJAX处理的时候，如果我们使用一个抓包工具的话，对数据返回和处理是一目了然。对于一些计算量大的AJAX请求的话，我们可以构造一个发包机，很容易就可以把一个webserver干掉。

H.     数据安全性的分析
对于HTTP协议来说，数据包都是明文传输的，也许我们可以说我们可以用加密啊，但是对于G问题来说的话，加密的过程就可能是明文了（比如我们知道的 QQ，可以很容易的判断他的加密，并有效的写一个跟他一样的加密和解密方法出来的）。当你站点流量不是很大的时候没有人会在乎你，但是当你流量上来之后，那么所谓的外挂，所谓的群发就会接踵而来（从qq一开始的群发可见端倪）。也许我们可以很的意的说，我们可以采用更高级别的判断甚至HTTPS来实现，注意，当你做这些处理的时候付出的将是海量的database，io以及CPU的成本。对于一些群发，基本上是不可能的。笔者已经可以实现对于百度空间和 qq空间的群发了。大家愿意试试，实际上并不是很难。

I.      数据同步和集群的处理的问题

当我们的一台databaseserver不堪重负的时候，这个时候我们就需要做基于数据库的负载和集群了。而这个时候可能是最让人困扰的的问题了，数据基于网络传输根据数据库的设计的不同，数据延迟是很可怕的问题，也是不可避免的问题，这样的话，我们就需要通过另外的手段来保证在这延迟的几秒或者更长的几分钟时间内，实现有效的交互。比如数据散列，分割，内容处理等等问题

K．数据共享的渠道以及OPENAPI趋势

   Openapi已经成为一个不可避免的趋势，从google，facebook，myspace到海内校内，都在考虑这个问题，它可以更有效的留住用户并激发用户的更多的兴趣以及让更多的人帮助你做最有效的开发。这个时候一个有效的数据共享平台，数据开放平台就成为必不可少的途径了，而在开放的接口的情况保证数据的安全性和性能，又是一个我们必须要认真思考的问题了。

 

当然还有更多需要考虑的问题，我这里就写一个最需要考虑的问题，欢迎补充。

 

下一篇文章将针对问题A，提出具体的解决方案和思路

互联网系统架构的演进

多终端接入、开放平台给互联网带来了前所未有的用户量级和访问规模，SNS网站产生了海量的UGC（用户产生内容），而且这些内容依托关 系链扩散速度之快、传播范围之广是传统网站难以想象的，海量数据的计算存储也一直是近年互联网领域的热点。本文将从发展演进的层面探讨互联网的系统架构。

天下武功唯快不破

网站初期的架构一般采用“短平快”的架构思路，架构以简单清晰、容易开发为第一衡量指标。

互联网架构选型首先包括开发语言的选择，目前PHP、Java是主力语言。开发语言的选择一般从团队人员的知识储备、社区活跃度、商业应用的成熟度、招聘人才的人力成本等方面考量。

选择语言之后，一般会选择该语言的流行框架辅助研发，例如Java的SSH、Python的Django等。但这些框架并不是通常意义上的架构，架构一般可 分为物理架构、运行架构、逻辑架构、开发架构、数据架构等多个维度，框架往往只是代码架构的一部分。代码架构是指代码的组织形式、规范、设计模式等，框架 其实是常用设计模式的软件化。例如Struts是MVC模式的实现，Hibernate、iBATIS是ORM模式的实现。

在架构视图中，早期关注的主要是开发视图和数据视图，一般数据存储采用DB，初期数据的关注点主要是安全和备份，MySQL的Master-Slave模式可以满足该需求。

鸡蛋不要放在一个篮子里

采用“短平快”三板斧将网站开发出来之后，急需解决的是网站的可用性问题。可用性最基本的要求是不能有单点，对程序节点而言，前端可采用LVS、HAProxy、Nginx等负载均衡/反向代理设备。

DB的可用性就复杂了很多，数据库天然是有状态的，状态就是其中的数据，新增一个数据节点一般伴随着大量的数据复制和迁移。对金融行业而言，昂贵的商用存储是 解决之道，“IBM+Oracle+EMC”是该类系统的标配。互联网企业则一般采用较为廉价的方案，例如开源的DRDB+Heartbeat技术组合可 以在MySQL主库宕机时实现备机接管，接管时间可以控制在30秒内。

程序节点其实也可能存在状态，例如Web服务中常用的Session 就是保存在容器中的状态，这种状态保持要求所有相同用户的请求都在同一台机器上处理，无状态的程序节点才能水平扩展。无状态一般有两种设计思路，还以 Session为例，一种思路是把用户的状态保存在客户端Cookie，每次请求都把客户端的用户信息带到服务器端，淘宝的分布式Session就是该思 路的一种实现；另一种思路是状态保留在另外一个服务中，例如有些公司将Session放在分布式缓存中。

性能是生命线

去除单点之后的系统就可以水平扩展，架构如图1所示。但随着网站的推广运营，系统的规模开始扩大，此时可能会出现服务访问缓慢，甚至不可用的状况，如何提升系统性能就成了架构师的当务之急。

 

图1 去除单点之后进行水平扩展

存储架构和性能

互联网系统所有的性能瓶颈中，数据存储和访问速度往往是最重要也是最难解决的，选择合适的存储是系统的关键。存储的选择一般需要从多个方面考量，如成本、内容、用途和模型。目前主流的存储介质包括硬盘和内存两种。

对机械硬盘来说，1秒可以完成150次左右的随机I/O。而结合设计优良的Hash算法，内存查找可以每秒执行40万次左右。硬盘的随机读写能力决定了其读 写的最差性能，但操作系统在实现文件系统时会把最近读写过的数据缓存在内存中。由于磁盘访问和内存访问性能量级的差距，从操作系统的Cache命中率就可 以简单计算文件存储的性能，如果内存命中率可以达到80%，系统的I/O能力相较完全随机I/O将有5倍提升。

对于数据层服务器，大内存已成为标配（一般为100GB左右），如果DB中存储200GB的数据，根据8/2原则，Cache命中率应为87.5%，因此对MySQL而言，一般读写可以达到每秒1千次以上。

对于读写频率都很高、且可容忍数据丢失的场景，可以采用内存作为数据存储的介质。可靠的内存存储需要每次操作都记录Biglog，即使数据丢失也可以恢复，同时内存中的数据一般定期持久化到硬盘。

从功能角度考量，还可以分为持久化存储和Cache。持久化存储也可称为可靠存储，Cache是为了提升系统性能，在可靠存储的基础上建立的访问性能更加高效的数据读取节点，通常是内存存储，其架构一般如图2所示。

 

图2 持久化存储和Cache

存储的数据模型一般分为结构化存储和NoSQL存储。结构化存储以各种传统DB为代表，NoSQL技术的代表系统则有HBase、Memcached、 Redis等。各种NoSQL系统虽然特性各异，但相对传统DB而言，由于结构化信息的缺失，往往不能做各种关联查询，适用场景更多是主键查询，而且一般 是写少读多的系统。

对于大型互联网公司，为了某些场景下的性能优化，也会定制个性化的文件系统，例如为了适应大文件存储的场景，Google开发了GFS；为了更快读取海量商品的描述图片，TFS在阿里诞生。

虽然各类存储快速涌现，但DB作为结构化数据的传统存储设备，依然在架构中处于非常重要的地位。由于随机I/O的瓶颈，DB的性能天花板十分明显。在大型系 统中通常需要分库操作，分库一般有两个维度——水平切分和垂直切分。水平切分一般根据主键规则或某种规则将同类数据切分到不同的单元表中，原则是数据切分均匀，尤其是热点数据分布均匀。

垂直切分是把大表中的字段拆分到多张表。垂直切分一般按照数据访问频率的不同。逻辑关系的差别进行切分，例如将大字段、kv字段、计数等高频访问字段单独剥离存储都是常见的垂直切分方案。

除了切库之外， MySQL的分表也会有效减少单表大小，使数据变得更简单，甚至可以做到不下线变更，单表索引规模的下降也会带来性能的提升。

分库分表作为DB架构中重要的一环，使DB更加稳健，但它给业务代码带来了额外的复杂性，最好通过中间件来屏蔽DB的底层分布，对业务透明。

作为高性能网站必不可少的组件，Cache在各种主流架构中也起着重要的作用。

从部署模式上看，它可分为本地Cache和分布式Cache。本地Cache是指在应用进程中的Cache，通常的数据结构是一个MAP，其优点是结构简 单，效率较分布式Cache更高，缺点是一般应用程序服务器的内存有限，导致本地Cache容量受到局限，而且数据冗余度较高，每个应用服务器都需要一份 数据，更新比较烦琐，一般采用超时删除机制。

分布式Cache的容量较大，方便扩容和更新，其数据分布可采用一致性Hash算法，减少节点变化带来的数据迁移。

引入Cache不可避免的问题是服务器的宕机处理。Cache通常是一个集群，数据分布在多个节点，如果挂掉一个节点，只会影响部分数据，而且对于可靠性要求较高的系统，每个节点都可以有备份。

作为可靠存储的数据备份，Cache在架构设计上往往承担大部分读访问需求，其命中率尤为重要。Cache不命中有两种情况，一是数据在Cache中不存 在，二是在持久化存储中也不存在。对于后者的频繁访问会导致请求直接压在DB上，在设计时应尽量避免，可以通过维护Bitmap对持久化存储中没有的数据 进行拦截，直接返回，也可以简单地将这些数据对应空对象放进Cache。

Cache的存储一般是将索引和数据分离，对于索引数据可以全量缓存，对于体量较大的数据一般采用部分缓存的方式。

Cache的使用场景有一定的局限，对于较为静态的数据才有意义，这个临界值一般是5分钟。由于当前存储技术的进步，Cache也可以用其他高性能的存储介质代替，例如SSD的引入使得硬盘的随机读写能力提升数十倍，也会使得Cache的重要性有所下降。

程序架构和性能

对一般的系统而言，程序逻辑的主要作用是调用各种数据访问接口，该操作通常需要等待，所以除搜索等少数系统外，程序逻辑一般是非CPU密集型。该类系统中“线程”是稀缺资源，线程数和接口耗时构成了系统的QPS能力。

大型互联网系统的QPS可能为几万甚至峰值达到几十万，此时增加机器可以解决问题，但这些机器的利用率其实很低，因为大部分时间是在等待，此时引入异步变得非常重要，异步在同样的时间可以处理更多工作，拥有更好的性能。 

 

图3 同步调用和异步调用

利用Nio的多路复用方式可方便地实现异步系统，当然也可用协程令代码更加清晰。业界流行的SEDA技术可将一次请求拆分为粒度更细的Actor，每个 Actor使用独立队列，前一个的输出是后一个的输入。SEDA通过该方式将请求中等待和非等待的环节分离，提升了系统的吞吐量，这种方式在小米等互联网 公司有较多应用。

除了异步之外，并行对系统也很重要，它可以有效缩短请求的响应时间。批量接口也可以有效减少系统调用次数，使得系统线程消耗更少，从而提升系统吞吐量。

对线程而言，还有一个重要的参数是超时时间。响应快的服务，超时时间可以长一些，对于响应慢的服务，超时时间可以短一些，尽快失败是保护自己的有效手段。

网络架构和性能

大型网站的网络接入一般是“DNS+负载均衡层+CDN”这种模式。对于大型互联网公司，往往有多个IDC提供对外服务，中国互联网的南北不互通使得解决不 同地域不同运营商的接入速度问题成了难题，该问题的解决一般需要公司自己开发DNS服务器，结合IP测速平台，引流用户请求到访问速度最快的节点。

大系统小做

业务逻辑复杂多变，如何保证程序逻辑的代码稳定是架构师需要解决的问题，良好的模块划分和扩展性强的接口设计都是解决这个问题的利器。

模块是和领域模型相关的一个概念，其往往指系统中高内聚的一个数据访问单元。例如对电商系统而言，最大的两个领域模型分别是商品信息和交易信息，每个领域模 型对应一系列数据，商品会有商品的基本信息、类目信息等，交易会包括交易的订单，这些“领域模型+数据+业务方法”就构成了一个个的模块，高度内聚的模块 是数据的访问的入口。例如交易时也需要去获取商品信息，但一般不会被允许直接调用商品模块的数据表，而是通过商品模块提供的接口进行访问，这样做有下面一 些优点。

• 接口和数据分离，底层数据结构的变化不会影响到外围系统。
• 数据直接暴露给其他系统，增加了系统的不稳定性。
• 接口的收敛减少了重复开发，提高了系统可用性。

对较小规模的应用，模块可部署在一起，但对大型系统而言，模块一般是单独部署，通过RPC交互，这样可以减少彼此之间的系统层面影响。例如Amazon就倾向将所有服务器程序暴露为接口。

分布式系统增加了系统交互的复杂性，也为系统引入了更多潜在的失败环节，但分布式系统可以带来的好处更明显。

• 有利于系统分级，针对不同服务提供不同的可用性。
• 大规模开发有了可能，每个模块可以单独开发和部署。
• 系统可重用性加强，避免重复制造轮子。
• 服务治理更加简单，一般RPC天然提供容灾，可以自动发现新增节点和剔除问题节点。

逻辑层的接口设计如何做到稳定呢？首先接口的设计不应该是产品驱动的，而应该由数据驱动，尽量考虑接口以后的发展，接口的参数尽量是对象，参数不要采用boolean这种难以扩展的数据类型。

逻辑层的接口设计，一般有粗粒度和细粒度两种模式。粗粒度接口的优点是交互少，一次调用基本可以满足需求，缺点是业务逻辑较多，所以不稳定性增加，这里的不稳定性不仅是系统稳定性，还包括业务逻辑的稳定性。细粒度接口交互较多，但更加有利于重用性。

细粒度接口多次交互是否会带来明显的性能损耗呢？目前服务器1秒可以执行近万次TCP连接，网络传输对于千兆网卡而言，一般也不会造成瓶颈，尤其RPC框架般都会保持长连接。因此，通常情况下我们可以忽略RPC调用带来的性能损耗。

逻辑层接口尽量采用大系统小做的原则，该原则是腾讯架构中重要的价值观。一个接口不做太多事情，只做关键路径，非关键逻辑可以用消息队列或事件通知等方式剥离出来，使得关键路径更加稳定。这也体现了服务分级的思想，把最大的精力花在最重要的接口上。

除了按重要性划分服务之外，也可以按接入方划分，避免不同终端的Bug影响。还可以按快慢划分，例如为上传文件等功能提供单独的服务，避免长时间占用线程，影响系统稳定性。

模块化是程序的水平切分，有时也会采用垂直切分，这种架构有以下好处。

• 系统规模更方便水平扩展，数据处理能力会显著增加。例如某个模块的容量不足，可以单独扩容该模块。
• 减少系统耦合，提升稳定性。例如将多变的Web层和稳定的数据层进行拆分，可以避免因为页面频繁发布导致的系统故障；将无线的接入层和Web接入层分离可以减少因为一个接入方引起的全局问题。

开放势不可挡

系统发展往往会带来平台化需求，例如微博的大多数服务除了满足PC访问，还要满足移动端及内外部平台，此时系统通常会抽象出一个接入层。

接入层设计

接入层一般分为：通信、协议和路由模块。

常用的通信方式有TCP、UDP和HTTP等，对开放平台等以外围接入为主的系统而言，HTTP因其简单方便是最合适的通信方式，而内部系统接入出于性能考量，可以直接用TCP或者UDP。

目前的主流协议有JSON、XML、Hessian等，对外部调用一般采用XML或者JSON，内部系统可以采用Hessian或其他自定义的二进制协议。

路由层是根据用户的信息将请求转发到后端服务层。LVS可看作是路由层，根据IP协议将不同来源的请求转发到不同IP Server，Nginx等具备反向代理的服务器也可以看作路由，根据不同URL转发到不同后端。我们经常会自定义路由层，通过用户调用的不同方法转发到 不同Server，或者根据用户的特征，将用户路由到我们的灰度测试机。

云平台概念

具有了平台化的接入功能，系统可以方便地接入内部或者外部系统，此时就具有了“云”的特征，对各种公有云或私有云来说，系统的隔离和自动扩容都十分重要，虚拟化等技术在该类系统中有了充分应用，例如阿里云等云平台都大量使用了虚拟化。

稳定压倒一切

代码稳定性

稳定性是系统架构中一以贯之的内容，可以从图4中理解它的含义。

正常情况下，图4左边系统的性能明显优于右边，但从架构角度考虑，右图要好于左图，因为突起的毛刺使得系统的容量骤降，很容易引发雪崩。性能考量不仅是系统的最优性能或者平均性能，最差性能往往也是系统出现问题的原因。

 

图4 两种稳定性对比

容灾

除了特别小型的系统，没有100%可用的系统。一般需要根据系统的情况制定合适的目标，该目标最通用的衡量维度是系统可用率。

系统可用率是可以提供服务的时间与总时间的比率，常用的系统可用率如表1所示。

 

而对于灾难，我们有下面几个环节可以介入。

• 预防：容量估算和接入方限流是常用的手段，以应对宕机或者突发流量。
• 发现：主要依赖监控和各种工具，可以分为系统、接口、公共组件、业务等方面。
• 解决：应对灾难需要我们事先做足功课，例如对外部的调用我们都有降级开关可以随时关闭；针对系统内部某个接口导致整个系统失去响应的场景，可以限制每个接口的并发量。

系统容量的冗余和可水平扩展也是容灾的必备要求，无状态的系统对于系统扩容更友好。

作者杨光辉，淘宝北京研发中心技术专家，花名三玄。曾在互动百科、腾讯科技等公司任职，对服务器端架构和开发等有一定研究。

从头到尾设计一个b2c系统——概念设计

收集了这么多需求，这一节我们准备画一幅图，抽象的概括b2c的业务需求和用户需求。

我们知道，电子商务有三流：物流、资金流和信息流。要上系统，是希望信息能完整的通过系统流转。而在信息流中，最核心的其实是商品信息。我们可以这样抽取b2c业务中的共性：

商品，在b2c企业中，首先是被用来销售的；

销售出去后我们要发货；

用户收到货不满意需要退回；

随着订单量提升，我们需要考虑正规化的业务处理方式：商品需要被采购、商品需要被储存在仓库。

因此，商品的子概念我们可以总结为：销售、发货、退回、采购、储存

1、对于销售，我们能够联想到的是

1）商品需要展示；

2）用户会过来咨询各种问题；

3）要销售就会搞促销；

4）要销售就会慢慢发展出自己的会员体系；

5）用户感兴趣了会下单，这时候就是交易了；

6）交易完毕，用户会做评价，反过来这些评价会形成口碑，影响更多的购买者；

2、对于发货，我们能够联想到的是

1）订单审核后，指派物流；

2）单证打印；

3）拣货；

4）验货；

5）包装；

6）称重；

7）配送等……

3、对于退回，我们能够联想到的是

1）退货

2）维修

3）换货

4）退款等……

4、对于采购，我们能够联想到的是

1）采购计划

2）供应商挑选和管理

3）价格管理

4）采购单

5）收货

6）质检

7）入库

8）结算等……

5、对于储存，我们能够联想到的是

1）入库

2）出库

3）盘点

4）调拨

5）仓库

6）库区

7）库位等……

说到这里，我们不得不根据这些概念和子概念联想到对应的系统，通过什么系统去满足这些业务和用户需求

1、我们可以设想一个最简单的b2c系统是这样的

1）发布了商品，展示给用户；

2）用户购买商品，形成订单并付款；

3）商家根据订单配货、发货

只需要能发布和管理商品、展示商品的系统、能付款并形成订单的交易功能即可，其它一切可以通过人工方式处理。

2、为了更好的吸引用户，你可能需要玩些花样，搞点促销，这个时候，你就要考虑上个促销系统了；

3、但随着客流量的提升，订单量也提升了，这个时候，用户会有各种各样的问题需要咨询你们，该搞点在线咨询的工具了，同时还需要配备更加强大的呼叫系统了；

4、同时，商品的数量需要管理起来了，这个时候需要有个简单的管理商品数量的系统，叫库存管理系统；

……

后面随着订单量不断增加，为了提升效率，提升体验，一切业务你都希望能够通过系统解决。

完成概念设计后，可以开始写一份完整的MRD文档了。

设计一个b2c系统6：产品架构

根据上一篇文章“概念设计”中为我们描绘的蓝图，我们可以理解，作为一家b2c网站，我们其实是在卖商品，商品要销售出去，我们需要涉足多个业务领域。这些领域，在不同的阶段，都需要通过系统来支撑或者通过系统提升效率。下面我们通过一幅图来更加具体的描述整个业务生态流程：

根据上面的业务逻辑，结合一定的规则，我们把可能用到的系统或者功能模块组合在一起，形成一张传说中的产品架构图（注意不是系统架构图），这张图不够严谨，目的仅仅是让你站以更高的高度看透一个网站的b2c系统中，各个子系统或者功能模块之间的重要程度、以及关系。

一个b2c网站，首要的是商品展示及自助下单购买功能；同时商家要能看到用户所下订单，以便实现发货；而作为一个动态的网站，如果商品不是一成不变，则需要一个对商品进行管理的操作。

上面3个系统或功能实现了，一个b2c网站的雏形就形成，因此它们是最核心的。

但随着业务量的增大，网站越来越正规，为了提升效率，提升用户的体验，我们需要同时配备其它一些系统如：会员系统、促销系统、配送管理和控制，采购、wms、商品评价等等，这算是目前电商的标配了。

当业务继续不断持续攀升，又会有更加多的需求需要去满足，类似联盟、分析、站内广告评估管理等系统就用得上了。

不管怎么样，作为非业务系统的Bi系统（最初期是各类统计报表，现在其实很少称得上是所谓bi系统的）和财务系统，需要通过抽取底层的一些数据，如会员数据、商品数据、各类单据（如订单、采购单、出入库单等）进行分析和计算。以便给业务决策提供数据参考。

挑战空中加油——1号店B2C电商系统演进之路

一、 面临的挑战

• 发展速度快：每年近十倍的业务增长。既要及时响应业务发展的新需求，又要对系统平滑地进行技术升级重构，其难度堪比飞机空中加油。
• 系统越来越复杂：
  1. 多渠道: 1号店、掌上商城、第三方商城、多个分站
  2. 产品多样: 既有各类百货，也有各种虚拟票劵，还有机票充值等
  3. 多种经营模式: 有自营也有代售，有自配送也有第三方配送
  4. 多部门协同：采购、市场、销售、仓储、配送、客服等多部门需高效协同。
  5. 更智能化：随着业务和系统的复杂，各部门完全人工的运营决策变得十分低效，需要系统更加智能化。
• 流量越来越大：流量每年增长10倍。

二、演进的策略

• 新旧兼容，平滑升级：我们在实施任何技术升级时，首要强调的就是新系统要尽量兼容旧系统，以支持平滑升级。完全新的架构看似很吸引人，比较容易开发，但是不兼容原来的系统可能使得新系统风险非常大。所以1号店采用兼容的方式，滚动开发，把架构从原来的合成一团的小系统方式逐步改变为子系统独立，多数据库的模式。这好比一边高速飞行，一边加油。
• 系统拆分：解决系统复杂性的唯一方法是分解。同时拆分后系统也使各自进行新的技术改造变得相对平滑。我们从终端渠道、业务逻辑、使用部门等多个维度进行了系统拆分。 例如:
  

  相关厂商内容

  送给光棍节的促销，电子商务的背后—《架构师》11月刊免费下载!
• 适当放弃一致性：在一些实时性要求不高的场合，我们适当放弃一致性要求。这样就可以充分利用多种手段来提高系统吞吐量，例如页面缓存、分布式数据缓存、数据库读写分离、查询数据搜索索引化。
• 系统共用组件Service化：随着系统的分拆，各子系统间的重复代码越来越多，增加了很多不必要的维护成本。为提高代码的复用，降低维护成本，我们将多个子系统都需要用到的业务组件，进行了Service化。例如：
  
• 中间件的研发使用：随着子系统和Service的增多，面临很多共同的技术性挑战。为降低应用系统人员的开发难度，我们在一些开源系统的基础上，研发了多个适应我们的中间件系统。例如：ESB平台(支持远程服务、异步消息)、分布式缓存、数据访问层等。大大简化了应用系统的开发。使用中间件后的总体示意图如下：
  
• 系统自动化：为进一步提高运营效率，我们采用了很多自动化的设计理念，尽量减少人工配置的需要。例如：根据比价系统和策略自动调整商品价格，根据投放效果和策略自动调整广告投放，根据库存和销售预测自动安排采购等。

三、 经典案例：数据访问层YhdDAL 1.0设计与实施

1) 实施前旧系统状态与结构：

• 整体已拆分有多个子系统和多个数据库。
• 每个应用系统与多个数据库直连，使用iBatis进行O/R Mapping。
• 各应用系统代码中，使用MemCached服务器进行数据缓存。
  

2) 旧系统面临的问题：

• 数据库连接数大，数据库服务器负担重。
• Cache代码繁琐: 本来一行代码的事需要写四五行。下面是典型的示例伪代码：

  result = getFromMemCached(key);
  if (result != null) return result;
  result = getFromDatabase(...);
  writeMemCached(key, timeout);
  return result;
  

• Cache 管理困难: 失效时间代码分散，不便管理。不同系统还容易key冲突。
• 数据分库和读写分离代码繁琐，某库故障时无法自动切换到可用库上。
• 系统Service化改造困难: 原Web层与Dao层代码耦合度高，不易实现Service化。拆分粒度太细连接数上升和故障概率增加，粒度太粗又效果不佳。
• 无法充分发挥Cache潜能：某个Cache项失效时，因前端的并发性会导致多次数据库请求。到期Cache无法延期使用，数据库故障时应用系统就立即故障。

3) 备选方案的优缺点：

• 基于iBatis本地扩展: 优点是工作量小。缺点是连接数和Service化等问题无法很好解决。
• 基于jdbc驱动的DAL：优点是客户端代码兼容性好，原代码改动工作量小。缺点是实现一个完整的jdbc驱动本身代价很高。
• DAL服务化，接口自定义： 优点是代码可控性高，各项需求特性易实现。缺点是有一定的迁移成本。

4) YhdDAL 1.0设计方案：

• 引入DAL服务器。应用系统仅访问DAL服务器，DAL才连接数据库。
• 客户端与DAL采用成熟的远程调用协议，接口简化为一个:
• Object execute(functionName, parameters...)
• 参数和返回值一律采用Map或基本类型，必要时可在客户端转换为Java Bean
• 支持iBatis格式的sql脚本定义和字段映射，以降低iBatis代码迁移成本。
• DAL层支持JavaScript脚本语言编写的类似存储过程的计算代码，简化业务层数据处理代码实现。
• 因DAL服务器数量明显小于应用服务器数量，可有效减少数据库连接总数。
• DAL层封装Cache处理机制，一方面简化应用层代码。另一方面可采取缓存主动更新，失效延期等机制，充分发挥Cache潜能。
• DAL层封装分库和读写分离处理机制，简化应用层代码。
• 参考数据库存储过程的设计思想，客户端仅传入过程名称和参数，DAL层计算完成后返回结果。有利于实现Service化。
• 大量简化应用层代码，很多简单的Sevice/Dao类可以完全省略。
• 1.0的缓存和负载均衡采用相对成熟简单方案，以降低风险。结构图如下:
  

5) 实施与升级过渡步骤：

• 实现DAL核心功能。进行压力测试，评估系统性能。
• 先对一个风险相对较小的应用系统进行改造，评估系统稳定性和改造成本。
• 采用iBatis兼容模式，直接转换迁移旧代码。以快速将原有系统升级至新平台。
• 采用新平台的设计理念，如读写分离、Service化，进行旧代码改造。
• 扩展DAL附加功能，如日志记录、权限控制、缓存优化、连接分组等。

通过一系列的方法与手段，1号店基本实现了从小系统向大系统演变，使得1号店的系统能够支撑大量高并发的访问，同时满足了业务的需要。

关于作者

韩军,1967年出生。1989年毕业于上海交通大学计算机系, Monash MBA

• 1号店的第一个员工，CTO, 设计并开发了1号店所有的系统
• 2004年，设计了 美国著名的比较购物系统 smarter.com
• 1999年加入51job，设计并开发了中国最为成功的工作网站与系统

架设大型高并发高负载网站的系统架构

随着中国大型IT企业信息化速度的加快，大部分应用的数据量和访问量都急剧增加，大型企业网站正面临性能和高数据访问量的压力，而且对存储、安全以及信息检索等等方面都提出了更高的要求……

本文中，我想通过几个国外大型IT企业及网站的成功案例，从Web技术人员角度探讨如何积极地应对国内大型网站即将面临的扩展（主要是技术方面，而较少涉及管理及营销等方面）矛盾。

一、 国外大型IT网站的成功之道

(一) MySpace

今天，MySpace已经成为全球众口皆碑的社区网站之王。尽管一流和营销和管理经验自然是每个IT企业取得成功的首要因素，但是本节中我们却抛弃这一点，而主要着眼于探讨在数次面临系统扩张的紧急关头MySpace是如何从技术方面采取应对策略的。

第一代架构—添置更多的Web服务器

MySpace最初的系统很小，只有两台Web服务器（分担处理用户请求的工作量）和一个数据库服务器（所有数据都存储在这一个地方）。那时使用

的是Dell双CPU、4G内存的系统。在早期阶段，MySpace基本是通过添置更多Web服务器来对付用户暴增问题的。但到在2004年早期，在

MySpace用户数增长到五十万后，其数据库服务器已经开始疲于奔命了。

第二代架构—增加数据库服务器

与增加Web服务器不同，增加数据库并没那么简单。如果一个站点由多个数据库支持，设计者必须考虑的是，如何在保证数据一致性的前提下让多个数据库分担压力。

MySpace运行在三个SQL

Server数据库服务器上—一个为主，所有的新数据都向它提交，然后由它复制到其它两个；另两个数据库服务器全力向用户供给数据，用以在博客和个人资料

栏显示。这种方式在一段时间内效果很好——只要增加数据库服务器，加大硬盘，就可以应对用户数和访问量的增加。

这一次的数据库架构按照垂直分割模式设计，不同的数据库服务于站点的不同功能，如登录、用户资料和博客。垂直分割策略利于多个数据库分担访问压

力，当用户要求增加新功能时，MySpace只需要投入新的数据库加以支持。在账户到达二百万后，MySpace还从存储设备与数据库服务器直接交互的方

式切换到SAN（存储区域网络）—用高带宽、专门设计的网络将大量磁盘存储设备连接在一起，而数据库连接到SAN。这项措施极大提升了系统性能、正常运行

时间和可靠性。然而，当用户继续增加到三百万后，垂直分割策略也变得难以维持下去。第三代架构—转到分布式计算架构

几经折腾，最终，MySpace将目光移到分布式计算架构——它在物理上分布的众多服务器，整体必须逻辑上等同于单台机器。拿数据库来说，就不能

再像过去那样将应用拆分，再以不同数据库分别支持，而必须将整个站点看作一个应用。现在，数据库模型里只有一个用户表，支持博客、个人资料和其他核心功能

的数据都存储在相同数据库。

既然所有的核心数据逻辑上都组织到一个数据库，那么MySpace必须找到新的办法以分担负荷——显然，运行在普通硬件上的单个数据库服务器是无

能为力的。这次，不再按站点功能和应用分割数据库，MySpace开始将它的用户按每百万一组分割，然后将各组的全部数据分别存入独立的SQL

Server实例。目前，MySpace的每台数据库服务器实际运行两个SQL

Server实例，也就是说每台服务器服务大约二百万用户。据MySpace的技术人员说，以后还可以按照这种模式以更小粒度划分架构，从而优化负荷分

担。

第四代架构—求助于微软方案

2005年早期，账户达到九百万，MySpace开始用微软的C#编写ASP.NET程序。在收到一定成效后，MySpace开始大规模迁移到ASP.NET。

账户达到一千万时，MySpace再次遭遇存储瓶颈问题。SAN的引入解决了早期一些性能问题，但站点目前的要求已经开始周期性超越SAN的I/O容量——即它从磁盘存储系统读写数据的极限速度。

第五代架构—增加数据缓存层并转到支持64位处理器的SQL Server 2005

2005年春天，MySpace账户达到一千七百万，MySpace又启用了新的策略以减轻存储系统压力，即增加数据缓存层——位于Web服务器

和数据库服务器之间，其唯一职能是在内存中建立被频繁请求数据对象的副本，如此一来，不访问数据库也可以向Web应用供给数据。

2005年中期，服务账户数达到两千六百万时，MySpace因为我们对内存的渴求而切换到了还处于beta测试的支持64位处理器的SQL

Server 2005。升级到SQL Server 2005和64位Windows Server

2003后，MySpace每台服务器配备了32G内存，后于2006年再次将配置标准提升到64G。

事实上，MySpace的Web服务器和数据库仍然经常发生超负荷，其用户频繁遭遇“意外错误”和“站点离线维护”等告示，他们不得不在论坛抱怨不停……

MySpace正是在这样不断重构站点软件、数据库和存储系统中，才一步步走到今天。事实上，MySpace已经成功解决了很多系统扩展性问题，

其中存在相当的经验值得我们借鉴。MySpace系统架构到目前为止保持了相对稳定，但其技术人员仍然在为SQL

Server支持的同时连接数等方面继续攻坚，尽可能把事情做到最好。

(二) Amazon

亚马逊书店无疑是电子商务发展的里程碑。2000年到现在，世界网络业腥风血雨。Amazon曾经成为网络泡沫的头号代表。如今，当这个“最大的泡沫”用几经易改的数字把自己变成了坚实的IT巨人。

历览Amazon发展过程，其成功经验在于，它创造性地进行了电子商务中每一环节的探索，包括系统平台的建设，程序编写、网站设立、配送系统等等

方面。用Amazon当家人贝索斯的话说就是，“在现实世界的商店最有力的武器就是地段，地段，地段，而对于我们来说最重要的三件事就是技术，技术，技

术。”

(三) eBay

eBay是世界闻名的拍卖网站，eBay公司通信部主管凯文?帕斯格拉夫认为，“eBay成功的最重要原因在于公司管理和服务。”

其成功的奥秘可以列举为以下几点：

①敢为天下先—在网络尚不普及的时代，eBay率先进入网络拍卖领域；

②依托虚拟商场所产生的特有的“零库存”是eBay公司取得成功的另一个重要原因。该公司的核心业务没有任何库存风险，所有的商品都是由客户提

供，它只需要负责提供虚拟的拍卖平台—网络和软件。所以，eBay公司的财务报表上不会出现“库存费用”和“保管费用”等。

③自eBay公司成立开始，它就一直遵循两条“黄金原则”：建设虚拟社区，给网民以家的感觉；保证网站稳定安全地运行。

二、 国内大型网站开发时的几点建议

从本节开始，我们将结合国内外大型IT网站在技术扩展方面的沉痛教训和成功经验，探讨在如今刚刚开始的Web 2.0时代如何应对国内网站即将面临的数据访问量增加（甚至是急剧膨胀）的问题，并提出一些供参考的策略和建议。

(四) 搭建科学的系统架构

构建大型的商业网站绝对不可能像构建普通的小型网站一样一蹴而就，需要从严格的软件工程管理的角度进行认真规划，有步骤有逻辑地进行开发。对于大

型网站来说，所采用的技术涉及面极其广泛，从硬件到软件、编程语言、数据库、Web服务器、防火墙等各个领域都有了很高的要求，已经不是原来简单的

html静态网站所能比拟的。以著名的Yahoo!为例，他们的每一个大型网站工程都需要大量相应专业人员的参与。

(五) 页面静态化

可不要小看纯静态化的HTML页面！其实在很多情况下，HTML往往意味着“效率最高、消耗最小”，所以我们尽可能使我们的网站上的页面采用静态

页面来实现。但是，对于大量内容并且频繁更新的网站，我们无法全部手动实现，因此可以开发相应的自动化更新工具，例如我们常见的信息发布系统CMS。像我

们经常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的。信息发布系统可以实现最简单的信息录入自动生成静态页

面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。

(六) 存储问题

存储也是一个大问题，一种是小文件的存储，比如图片这类；另一种是大文件的存储，比如搜索引擎的索引。

大家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，图片是最消耗资源的，于是我们有必要将图片与页面进行分离，这是基本上大型网

站都会采用的策略，他们都有独立的图片服务器，甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图

片问题而崩溃，在应用服务器和图片服务器上，可以进行不同的配置优化以保证更高的系统消耗和执行效率。

(七) 数据库技术—集群和库表散列

对于大型网站而言，使用大型的数据库服务器是必须的事情。但是，在面对大量访问的时候，数据库的瓶颈仍然会显现出来，这时一台数据库将很快无法满足应用，于是我们需要借助于数据库集群或者库表散列技术。

在数据库集群方面，很多数据库厂商都有自己的解决方案，Oracle、Sybase、SQL Server等都有很好的方案，常用的MySQL提供的Master/Slave也是类似的方案。因此，你使用了什么样的数据库，就参考相应的解决方案来实施即可。

上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用数据库类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，其中，库

表散列是常用并且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略

对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。在这一方面一个现

成的例子就是搜狐。它的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，

最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。

(八) 缓存策略

这绝对不单指低级的缓存技术相关的编程，应从整个架构角度着眼，深入研究Web服务器、数据库服务器的各层级的缓冲策略，最后才是低级的缓冲技术

的编程。不同的Web服务器、数据库服务器及Web编程语言都有自己不同的缓冲策略。例如数据库存储方面，SQL Serve

2005中的主动式缓存机制，Oracle数据的cache

group技术，Hibernate的缓存包括Session的缓存和SessionFactory的缓存；Web服务器方面，Apache提供了自己的

缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力，IIS缓冲器技术；至于web开发语言，所

用缓存技术更存在很大不同，例如ASP.NET

2.0中提出了两种缓存应用程序数据和缓存服务页输出的策略，这两种缓存技术相互独立但不相互排斥，PHP有Pear的Cache模块，等等。

(九) 镜像

镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异。在镜像的细节技术方面，这

里不阐述太深，有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路，比如Linux上的rsync等工具。

(十) 负载均衡

负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。

负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择，基于LAMP解决方案的Lighttped+Squid是相当不错的解决负载均衡和加速系统的有效方式。

(十一) 硬件四层交换

第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。第四层交换功能

就象是虚IP，指向物理服务器。它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上，需

要复杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口

共同决定。

在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。

(十二) 软件四层交换

大家知道了硬件四层交换机的原理后，基于OSI模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理一致，不过性能稍差。但是满足一定量的压力还是游刃有余的。

一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易。

(十三) 软件投资问题

据报导，目前国内除了一些上市企业和特别大知名大公司以外，很少有企业在成本中考虑正版软件的购置费用。这种思维极有可能给中国互联网带来噩梦。

如果一些公司真正面临软件资金方面的困难，完全可以考虑使用开源世界的LAMP解决方案（Linux＋Apache＋MySQL＋Perl、PHP或者

Python Web编程语言）；否则，随着我国加入WTO范围的不断扩大，盗版打击必然越来越严。因此，“苟且偷生”必将自食其果。

另外，随着网络带宽日渐提升，WEB 2.0技术必将影响到网络世界的几乎每一个角落。因此，如何积聚技术人员进行技术攻关并进一步加强安全防范也成为一个日益严峻的问题，宜尽早纳入到公司的议事日程。

四、 总结

中国电子商务真正理性发展的一个标志，是大量的传统企业实实在在地开始用互联网来处理商务、做生意，而现在这样的浪潮已经开始。北京发行集团，联合SINA、6688.com等单位共同推出的网上虚拟书店—新新书店就是这样的一个标志。

随着网络带宽日渐提升，随着网络理念和WEB

2.0技术的断深入人心，各种B2B、B2C、C2C等电子商务模式很可能以立体交叉方式整合到各种大型商务网站中来。因此，作为公司的技术人员，作为临

危救驾的“白衣骑士”，如何应对海量存储、海量访问问题，海量信息检索的问题，日益严峻的安全问题，等等，已经刻不容缓。

此条目由 charly 发表在 网站技术 分类目录，并贴了 架构、网站

B2C电子商务基础系统架构解析

运营B2C日久，越来越深刻的意识到IT系统对确保规范化业务流转，支撑消费者端的均一服务有着决定性的作用。于是，一直想好好整理下相关的系统架构，怎奈俗务缠身，一直拖到今日，猛然发现下周娃很可能就要出生，拖无可拖，快马加笔，居然整出来了。本文的重点是理清系统的逻辑关系，详细的功能模块请参见结尾附上的系统架构图。

首先，聊下对系统逻辑架构的看法；我个人始终坚持认为，系统的开发与演化，前台严格follow消费者的购买流程，后台则盯牢订单流转，牢牢抓住这两条主线，才能高屋建瓴的看清B2C的逻辑链和数据流，更深刻的规划功能模块，从而更有效支撑实际业务的流转。

前台系统包括：商品展示，内容展示，订单确认，支付系统，用户中心四大模块

一，商品展示

按照Ebay的内部分类，任何将商品以单个或批量的方式展示给消费者的功能均应归入此系统。因此，该系统至少包括：

A，站内搜索（搜索提示，搜索规则，搜索成功页，搜索不成功页，相似推荐）

B，导航（频道导航，其他导航如销售排行，广告位，推荐位，文字链，Also buy等）

C，商品分类（品牌分类，品类分类，属性分类如剪裁形式）

D， 登陆页（商品列表页，商品详细页，商品活动页）

这里的访问逻辑是：A /B/C分流消费者去往相对个性化的页面，由登陆页体现商家的核心诉求和价值传递，完成call-to-action的第一步。

二，内容展示

内容展示较为简单，对纯购物品牌而言包括：

A，公告区

B，帮助中心

C，论坛（如需商城与论坛发生交互，则需自行开发，否则可集成discuz做同步登陆即可）

大家都知道，就不多说了。

三，订单确认

订单确认，就是帮助消费者正确提交订单信息的环节，看似简单，实则非常复杂，需要对很多信息逻辑判断和处理，一般由2个部分组成：

A，购物车（购物车浮层，购物车页面，无注册购买）

无注册购买是需要慎用的功能，除非刻意追求用户的短平快下单，如团购/换购，一般不推荐使用，会造成系统异常复杂，开发量也很大。

B，订单提交（返回购物车，收货地址&地址薄，支付方式判断，配送方式，发票，订单标记，实付金额计算等等）

值得一提的是，几乎大多数的促销逻辑运算在这个环节完成，充分考虑各种促销方式之间的互斥与重叠是系统设计的核心，需要充分考虑各种情况，避免出现逻辑漏洞。

四，支付系统

与一般的想象不同，支付系统其实并不简单等于第三方支付工具接入：

A，外部支付系统（支付宝将接口，财付通接口，网银直联端口，信用ka分期端口）

B，内部支付系统（账户余额，积分，礼品卡，优惠券）

支付系统的逻辑设计不但需要考虑到各种极端情况的发生（如一张订单先用礼品卡，再用积分，最后网银支付），还要预留财务做账所需的相关字段，并充分考虑订单取消之后如何回滚各类内部账户。

五，用户中心

用户中心的实质是用户自助功能的dashboard，一般4个部分组成：

A，注册&登陆（快速注册，完整注册，注册有礼，推荐注册，密码找回，主站id登陆，open-id登陆如QQ，新浪微博等）

B，订单中心（历史订单状态，中间状态订单修改，物流追踪）

C，服务中心（各类自助服务如退款申请，退换货申请，建议与投诉等）

D， 信息管理（用户基本信息管理和账户信息管理）

用户中心的价值在于：尽可能引导用户自行获取所需的信息并提交所需的服务，在提升服务准确率，及时性的同时降低对人工成本。

后台系统包括：商品&促销，CRM，订单处理，WMS，采购管理，财务管理，报表管理，系统设置，WA系统9大模块

一， 商品&促销商品&促销模块的核心在于确保消费者下单之前，前台内容所见即所得

A， 商品管理（品类管理，品牌管理，单品管理）

B， 促销管理（活动管理和自定义活动模板管理）

在上述模块中，最重要的是2个部分：单品管理中的批量产品生成的自动程序和活动管理中“共享与互斥”管理。前者用于大幅提升上新速度，后者避免促销活动失控。

二， CRM

CRM是对B2C核心资源—会员的管理，服务与再营销系统，包括如下部分：

A，会员管理（会员信息的增删改查和到其他系统的链接）

B，用户关怀（条件触发和人工触发相关EDM & 短信 & OB）

C，定向营销（会员分组和营销活动管理）

D， 客服管理（内容非常多，集成所有需前台与后台交互的功能，详情还是看图吧）

E， 呼叫中心（IVR，坐席管理，统计报表，参数传递与窗口嵌入）

值得注意的，EDM和短信通道市面上已经有成熟的外包服务商，一般都会外包；呼叫中心和在线客服自行开发成本太高，特别是呼叫中心系统，业务初期也都是外包的。

三， 订单处理

订单处理是在订单未正式进入仓储部门处理之前，对订单的前置性处理环节。

A，订单录入（电话订购，网上下单，外部团购订单，无金额订单录入如礼品单）

B，订单审核（自动审核和人工审核）

C，RMA处理（RMA申请单和RMA处理单）

RMA的逻辑也异常复杂，需要在效率和成本之间找平衡，确保在不拖垮仓储部门的正常出入库的前提下对消费者端快速有效close工单；对内部则需要控制成本，货损不能超过预算上限。

四， WMS（Warehouse Management system仓库管理系统）

WMS的流程很长，功能模块也很多，大致分为入库管理，库存管理，出库管理和票据管理4个模块四个模块，细细道来就是另外一篇文章了，各位可以参考我这篇文章：庖丁解牛—B2C仓储内部运作解密（上，中，下）http://blog.sina.com.cn/wangxida0855

五， 采购管理

采购管理的核心是有效跟进采购合同/发票的状态，大货的采购入库/退库，财务结算和在仓库存查询和处理。

A，供应商管理（供应商信息管理，合同发票管理）

B，采购单管理（PO单管理，负PO单管理）

C，库存管理（库存查询，库存占用单，库存变动log）

六， 财务管理

B2C的财务管理，主要是对供应商，渠道和内部费用支出的成本控制。

A，供应商结算

B，渠道结算

C，配送结算

D， 内部结算

说实在的，哥对财务这块也不算很了解，大家将就看看，图片上有明细。

七， 报表管理

报表是B2C业务的宏观表现，理论上说，每个部门的KPI都应该从中找到。

A，搜索报表（站内搜索量查询）

B，销售报表（多个维度销量查询，优惠券使用情况，报表导出）

C，财务报表

D， 客服报表（客服日报和坐席报表）

前者反映与消费者发生的日常交互（包括正常与异常），后者考核客服的工作绩效

E， 仓储物流报表

这几块报表，是业务运作的核心，涉及到公司机密，就不能写的太细了，见谅。

八， 系统设置

这块大家都知道是干嘛的，也就不多说了，分成三块。

A，基础设置（和业务有关的一些字段值）

B，权限设置（不同账号的操作权限和操作记录）

C，其他设置

九， WA系统（Web Analytcis）

网站分析系统，几乎全是外购，很少有能够自建的，即使自建，最多做几个简单的模块。用于实战的，要么是免费的GA（Google Analytics），要么是昂贵的Omniture。这块的知识，细细说来也是另外一篇文章了，有兴趣的同学可以看我这篇科普文章：揭秘—我所知道的网站分析（上，下） http://blog.sina.com.cn/wangxida0855

最后，上全系统大图，再感慨一句，B2C系统，真是一个大工程啊。

淘宝 。CDN技术简介

背景

Internet的高速发展，给人们的工作和生活带来了极大的便利，对Internet的服务品质和访问速度要求越来越 高，虽然带宽不断增加，用户数量也在不断增加，受Web服务器的负荷和传输距离等因数的影响，响应速度慢还是经常抱怨和困扰。解决方案就是在网络传输上利 用缓存技术使得Web服务数据流能就近访问，是优化网络数据传输非常有效的技术，从而获得高速的体验和品质保 证。

网络缓存技术，其目的就是减少网络中冗余数据的重复传输，使之最小化，将广域传输转为本地或就近访问。互联网上传递的内容，大部分为重复的Web/FTP数据，Cache服 务器及应用Caching技术的网络设备，可大大优化数据链路性能，消除数据峰值访问造成的结点设备阻塞。Cache服务器具有缓存功能，所以大部分网页 对象(Web page object)，如html， htm， php等页面文件，gif，tif，png，bmp等图片文件，以及其他格式的文件，在有效期(TTL)内，对于重复的访问，不必从原始网站重新传送文件 实体， 只需通过简单的认证(Freshness Validation)- 传送几十字节的Header，即可将本地的副本直接传送给访问者。由于缓存服务器通常部署在靠近用户端，所以能获得近似局域网的响应速度，并有效减少广域 带宽的消耗。据统计，Internet上超过80%的用户重复访问20%的信息资源，给缓存技术的应用提供了先决的条件。缓存服务器的体系结构与Web服 务器不同，缓存服务器能比Web服务器获得更高的性能，缓存服务器不仅能提高响应速度，节约带宽，对于加速Web服务器，有效减轻源服务器的负荷是非常有 效的。

高速缓存服务器(Cache Server)是软硬件高度集成的专业功能服务器，主要做高速缓存加速服务，一般部署在网络边缘。根据加速对象不同，分为客户端加速和服务器加速，客户端 加速Cache部署在网络出口处，把常访问的内容缓存在本地，提高响应速度和节约带宽;服务器加速，Cache部署在服务器前端，作为Web服务器的前置 机，提高Web服务器的性能，加速访问速度。如果多台Cache加速服务器且分布在不同地域，需要通过有效地机制管理Cache网络，引导用户就近访问， 全局负载均衡流量，这就是CDN内容传输网络的基本思想。

什么是CDN?

CDN的全称是Content Delivery Network，即内容分发网络。其目的是通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络”边缘”，使用户可 以就近取得所需的内容，解决Internet网络拥塞状况，提高用户访问网站的响应速度。从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等 原因，解决用户访问网站的响应速度慢的根本原因。

狭义地讲，内容分发布网络(CDN)是一种新型的网络构建方式，它是为能在传统的IP 网发布宽带丰富媒体而特别优化的网络覆盖层;而从广义的角度，CDN代表了一种基于质量与秩序的网络服务模式。简单地说，内容发布网(CDN)是一个经策 略性部署的整体系统，包括分布式存储、负载均衡、网络请求的重定向和内容管理4个要件，而内容管理和全局的网络流量管理(Traffic Management)是CDN的核心所在。通过用户就近性和服务器负载的判断，CDN确保内容以一种极为高效的方式为用户的请求提供服务。总的来说，内 容服务基于缓存服务器，也称作代理缓存(Surrogate)，它位于网络的边缘，距用户仅有”一跳”(Single Hop)之遥。同时，代理缓存是内容提供商源服务器(通常位于CDN服务提供商的数据中心)的一个透明镜像。这样的架构使得CDN服务提供商能够代表他们 客户，即内容供应商，向最终用户提供尽可能好的体验，而这些用户是不能容忍请求响应时间有任何延迟的。据统计，采用CDN技术，能处理整个网站页面的 70%～95%的内容访问量，减轻服务器的压力，提升了网站的性能和可扩展性。

与目前现有的内容发布模式相比较，CDN强调了网络在内 容发布中的重要性。通过引入主动的内容管理层的和全局负载均衡，CDN从根本上区别于传统的内容发布模式。在传统的内容发布模式中，内容的发布由ICP的 应用服务器完成，而网络只表现为一个透明的数据传输通道，这种透明性表现在网络的质量保证仅仅停留在数据包的层面，而不能根据内容对象的不同区分服务质 量。此外，由于IP网的”尽力而为”的特性使得其质量保证是依靠在用户和应用服务器之间端到端地提供充分的、远大于实际所需的带宽通量来实现的。在这样的 内容发布模式下，不仅大量宝贵的骨干带宽被占用，同时ICP的应用服务器的负载也变得非常重，而且不可预计。当发生一些热点事件和出现浪涌流量时，会产生 局部热点效应，从而使应用服务器过载退出服务。这种基于中心的应用服务器的内容发布模式的另外一个缺陷在于个性化服务的缺失和对宽带服务价值链的扭曲，内 容提供商承担了他们不该干也干不好的内容发布服务。

纵观整个宽带服务的价值链，内容提供商和用户位于整个价值链的两端，中间依靠网络服务提供商将其串接起来。随着互联网工业的成熟和商业模式的变革， 在这条价值链上的角色越来越多也越来越细分。比如内容/应用的运营商、托管服务提供商、骨干网络服务提供商、接入服务提供商等等。在这一条价值链上的每一 个角色都要分工合作、各司其职才能为客户提供良好的服务，从而带来多赢的局面。从内容与网络的结合模式上看，内容的发布已经走过了ICP的内容(应用)服 务器和IDC这两个阶段。IDC的热潮也催生了托管服务提供商这一角色。但是，IDC并不能解决内容的有效发布问题。内容位于网络的中心并不能解决骨干带 宽的占用和建立IP网络上的流量秩序。因此将内容推到网络的边缘，为用户提供就近性的边缘服务，从而保证服务的质量和整个网络上的访问秩序就成了一种显而 易见的选择。而这就是内容发布网(CDN)服务模式。CDN的建立解决了困扰内容运营商的内容”集中与分散”的两难选择。无疑对于构建良好的互联网价值链 是有价值的，也是不可或缺的。

CDN新应用和客户

目前的CDN服务主要应用于证券、金融保险、ISP、ICP、 网上交易、门户网站、大中型公司、网络教学等领域。另外在行业专网、互联网中都可以用到，甚至可以对局域网进行网络优化。利用CDN，这些网站无需投资昂 贵的各类服务器、设立分站点，特别是流媒体信息的广泛应用、远程教学课件等消耗带宽资源多的媒体信息，应用CDN网络，把内容复制到网络的最边缘，使内容 请求点和交付点之间的距离缩至最小，从而促进Web站点性能的提高，具有重要的意义。CDN网络的建设主要有企业建设的CDN网络，为企业服务;IDC的 CDN网络，主要服务于IDC和增值服务;网络运营上主建的CDN网络，主要提供内容推送服务;CDN网络服务商，专门建设的CDN用于做服务，用户通过 与CDN机构进行合作，CDN负责信息传递工作，保证信息正常传输，维护传送网络，而网站只需要内容维护，不再需要考虑流量问题。

CDN能够为网络的快速、安全、稳定、可扩展等方面提供保障。

IDC建立CDN网络，IDC运营商一般需要有分部各地的多个 IDC中心，服务对象是托管在IDC中心的客户，利用现有的网络资源，投资较少，容易建设。例如某IDC全国有10个机房，加入IDC的CDN网络，托管 在一个节点的Web服务器，相当于有了10个镜像服务器，就近供客户访问。宽带城域网，域内网络速度很快，出城带宽一般就会瓶颈，为了体现城域网的高速体 验，解决方案就是将Internet网上内容高速缓存到本地，将Cache部署在城域网各POP点上，这样形成高效有序的网络，用户仅一跳就能访问大部分 的内容，这也是一种加速所有网站CDN的应用。

CDN 的工作原理

在描述CDN的实现原理，让我们先看传统的未加缓存服务的访问过程，以便了解CDN缓存访问方式与未加缓存访问方式的差别:

由上图可见，用户访问未使用CDN缓存网站的过程为:

1. 用户向浏览器提供要访问的域名;
2. 浏览器调用域名解析函数库对域名进行解析，以得到此域名对应的IP地址;
3. 浏览器使用所得到的IP地址，域名的服务主机发出数据访问请求;
4. 浏览器根据域名主机返回的数据显示网页的内容。

通过以上四个步骤，浏览器完成从用户处接收用户要访问的域名到从域名服务主机处获取数据的整个过程。CDN网络是在用户和服务器之间增加Cache层， 如何将用户的请求引导到Cache上获得源服务器的数据，主要是通过接管DNS实现，下面让我们看看访问使用CDN缓存后的网站的过程:

通过上图，我们可以了解到，使用了CDN缓存后的网站的访问过程变为:

1. 用户向浏览器提供要访问的域名;
2. 浏览器调用域名解析库对域名进行解析，由于CDN对域名解析过程进行了调整，所以解析函数库一般得到的是该域名对应的CNAME记录，为了得到实 际IP地址，浏览器需要再次对获得的CNAME域名进行解析以得到实际的IP地址;在此过程中，使用的全局负载均衡DNS解析，如根据地理位置信息解析对 应的IP地址，使得用户能就近访问。
3. 此次解析得到CDN缓存服务器的IP地址，浏览器在得到实际的IP地址以后，向缓存服务器发出访问请求;
4. 缓存服务器根据浏览器提供的要访问的域名，通过Cache内部专用DNS解析得到此域名的实际IP地址，再由缓存服务器向此实际IP地址提交访问请求;
5. 缓存服务器从实际IP地址得得到内容以后，一方面在本地进行保存，以备以后使用，二方面把获取的数据返回给客户端，完成数据服务过程;
6. 客户端得到由缓存服务器返回的数据以后显示出来并完成整个浏览的数据请求过程。

通过以上的分析我们可以得到，为了实现既要对普通用户透明(即加入缓存以后用户客户端无需进行任何设置，直接使用被加速网站原有的域名即可访问)，又要 在为指定的网站提供加速服务的同时降低对ICP的影响，只要修改整个访问过程中的域名解析部分，以实现透明的加速服务，下面是CDN网络实现的具体操作过程。

1. 作为ICP，只需要把域名解释权交给CDN运营商，其他方面不需要进行任何的修改;操作时，ICP修改自己域名的解析记录，一般用cname方式指向CDN网络Cache服务器的地址。
2. 作为CDN运营商，首先需要为ICP的域名提供公开的解析，为了实现sortlist，一般是把ICP的域名解释结果指向一个CNAME记录;
3. 当需要进行sorlist时，CDN运营商可以利用DNS对CNAME指向的域名解析过程进行特殊处理，使DNS服务器在接收到客户端请求时可以根据客户端的IP地址，返回相同域名的不同IP地址;
4. 由于从cname获得的IP地址，并且带有hostname信息，请求到达Cache之后，Cache必须知道源服务器的IP地址，所以在CDN运营商内部维护一个内部DNS服务器，用于解释用户所访问的域名的真实IP地址;
5. 在维护内部DNS服务器时，还需要维护一台授权服务器，控制哪些域名可以进行缓存，而哪些又不进行缓存，以免发生开放代理的情况。

CDN的技术手段

实现CDN的主要技术手段是高速缓存、镜像服务器。可工作于DNS解析或HTTP重定向两种方式，通过Cache服务器，或异地的镜像站点 完成内容的传送与同步更新。DNS方式用户位置判断准确率大于85%，HTTP方式准确率为99%以上;一般情况，各Cache服务器群的用户访问流入数 据量与Cache服务器到原始网站取内容的数据量之比在2:1到3:1之间，即分担50%到70%的到原始网站重复访问数据量(主要是图片，流媒体文件等 内容);对于镜像，除数据同步的流量，其余均在本地完成，不访问原始服务器。

镜像站点(Mirror Site)服务器是我们经常可以看到的，它让内容直截了当地进行分布，适用于静态和准动态的数据同步。但是购买和维护新服务器的费用较高，另外还必须在各 个地区设置镜像服务器，配备专业技术人员进行管理与维护。大型网站在随时更新各地服务器的同时，对带宽的需求也会显著增加，因此一般的互联网公司不会建立 太多的镜像服务器。

高速缓存手段的成本较低，适用于静态内容。Internet的统计表明，超过80%的用户经常访问的是20%的网站 的内容，在这个规律下，缓存服务器可以处理大部分客户的静态请求，而原始的WWW服务器只需处理约20%左右的非缓存请求和动态请求，于是大大加快了客户 请求的响应时间，并降低了原始WWW服务器的负载。根据美国IDC公司的调查，作为CDN的一项重要指标-缓存的市场正在以每年近100%的速度增长，全 球的营业额在2004年将达到45亿美元。网络流媒体的发展还将剌激这个市场的需求。

CDN的网络架构

CDN网络架构主要由两大部分，分为中心和边缘两部分，中心指CDN网管中心和DNS重定向解析中心，负责全局负载均衡，设备系统安装在管理中心机房，边缘主要指异地节点，CDN分发的载体，主要由Cache和负载均衡器等组成。

当用户访问加入CDN服务的网站时，域名解析请求将最终交给全局负载均衡DNS进行处理。全局负载均衡DNS通过一组预先定义好的策略，将当时最接近用 户的节点地址提供给用户，使用户能够得到快速的服务。同时，它还与分布在世界各地的所有CDNC节点保持通信，搜集各节点的通信状态，确保不将用户的请求 分配到不可用的CDN节点上，实际上是通过DNS做全局负载均衡。

对于普通的Internet用户来讲，每个CDN节点就相当于一个放置在它周围的WEB。通过全局负载均衡DNS的控制，用户的请求被透明地指向离他最近的节点，节点中CDN服务器会像网站的原始服务器一样，响应用户的请求。由于它离用户更近，因而响应时间必然更快。

每个CDN节点由两部分组成:负载均衡设备和高速缓存服务器

负载均衡设备负责每个节点中各个Cache的负载均衡，保证节点的工作效率;同时，负载均衡设备还负责收集节点与周围环境的信息，保持与全局负载DNS的通信，实现整个系统的负载均衡。

高速缓存服务器(Cache)负责存储客户网站的大量信息，就像一个靠近用户的网站服务器一样响应本地用户的访问请求。

CDN的管理系统是整个系统能够正常运转的保证。它不仅能对系统中的各个子系统和设备进行实时监控，对各种故障产生相应的告警，还可以实时监测到系统中 总的流量和各节点的流量，并保存在系统的数据库中，使网管人员能够方便地进行进一步分析。通过完善的网管系统，用户可以对系统配置进行修改。

理论上，最简单的CDN网络有一个负责全局负载均衡的DNS和各节点一台Cache，即可运行。DNS支持根据用户源IP地址解析不同的IP，实现 就近访问。为了保证高可用性等，需要监视各节点的流量、健康状况等。一个节点的单台Cache承载数量不够时，才需要多台Cache，多台Cache同时 工作，才需要负载均衡器，使Cache群协同工作。

from：http://rdc.taobao.com/blog/cs/?p=106

No comments