单点登录SSO

一、什么是单点登录SSO（Single Sign-On）

　　SSO是一种统一认证和授权机制，指访问同一服务器不同应用中的受保护资源的同一用户，只需要登录一次，即通过一个应用中的安全验证后，再访问其他应用中的受保护资源时，不再需要重新登录验证。

二、单点登录解决了什么问题

　　解决了用户只需要登录一次就可以访问所有相互信任的应用系统，而不用重复登录。

三、单点登录的技术实现机制

　　如下图所示：

　　

　　　　当用户第一次访问应用系统1的时候，因为还没有登录，会被引导到认证系统中进行登录；根据用户提供的登录信息，认证系统进行身份效验，如果通过效验，应该返回给用户一个认证的凭据－－ticket；用户再访问别的应用的时候，就会将这个ticket带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行效验，检查ticket的合法性（4,6）。如果通过效验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。

从上图可以看出sso的实现技术点：

　　1）所有应用系统共享一个身份认证系统。

　　　　统一的认证系统是SSO的前提之一。认证系统的主要功能是将用户的登录信息和用户信息库相比较，对用户进行登录认证；认证成功后，认证系统应该生成统一的认证标志（ticket），返还给用户。另外，认证系统还应该对ticket进行效验，判断其有效性。

　　2）所有应用系统能够识别和提取ticket信息

　　　　要实现SSO的功能，让用户只登录一次，就必须让应用系统能够识别已经登录过的用户。应用系统应该能对ticket进行识别和提取，通过与认证系统的通讯，能自动判断当前用户是否登录过，从而完成单点登录的功能。

关于统一身份认证机制：如下图

　   ①用户请求访问业务系统。

　　②业务系统在系统中查看是否有对应请求的有效令牌，若有，则读取对应的身份信息，允许其访问；若没有或令牌无效，则把用户重定向到统一身份认证平台，并携带业务系统地址，进入第③步。

　　③在统一身份认证平台提供的页面中，用户输入身份凭证信息，平台验证此身份凭证信息，若有效，则生成一个有效的令牌给用户，进入第④步；若无效，则继续进行认证，直到认证成功或退出为止。

　　④用户携带第③步获取的令牌，再次访问业务系统。

　　⑤业务系统获取用户携带的令牌，提交到认证平台进行有效性检查和身份信息获取。

　　⑥若令牌通过有效性检查，则认证平台会把令牌对应的用户身份信息返回给业务系统，业务系统把身份信息和有效令牌写入会话状态中，允许用户以此身份信息进行业务系统的各种操作；若令牌未通过有效性检查，则会再次重定向到认证平台，返回第③步。

　　通过统一身份认证平台获取的有效令牌，可以在各个业务系统之间实现应用漫游。

四、单点登录的优点

　　1）提高用户的效率。

　　　　用户不再被多次登录困扰，也不需要记住多个 ID 和密码。另外，用户忘记密码并求助于支持人员的情况也会减少。 

　　2）提高开发人员的效率。

　　　　SSO 为开发人员提供了一个通用的身份验证框架。实际上，如果 SSO 机制是独立的，那么开发人员就完全不需要为身份验证操心。他们可以假设，只要对应用程序的请求附带一个用户名，身份验证就已经完成了。 

　　3）简化管理。

　　　　如果应用程序加入了单点登录协议，管理用户帐号的负担就会减轻。简化的程度取决于应用程序，因为 SSO 只处理身份验证。所以，应用程序可能仍然需要设置用户的属性（比如访问特权）。

五、单点登录的缺点

　　1）不利于重构

　　　　因为涉及到的系统很多，要重构必须要兼容所有的系统，可能很耗时

　　2） 无人看守桌面

　　　　因为只需要登录一次，所有的授权的应用系统都可以访问，可能导致一些很重要的信息泄露。

从头到尾设计一个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(business to customer)。B2C的B是Business，意思是企业，2则是to的谐音，C是Customer，意思是消费者，所以B2C是企业对消费者的电子商务模式。这种形式的电子商务一般以网络零售业为主，主要借助于Internet开展在线销售活动。B2C模式是我国最早产生的电子商务模式，以8848网上商城正式运营为标志。

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系统，真是一个大工程啊。