大家好，又见面了，我是你们的朋友全栈君。

大型网站架构是一个系列文档，欢迎大家关注。本次分享主题：电商网站架构案例。从电商网站的需求，到单机架构，逐步演变为常用的，可供参考的分布式架构的原型。除具备功能需求外，还具备一定的高性能，高可用，可伸缩，可扩展等非功能质量需求（架构目标）。

根据实际需要，进行改造，扩展，支持千万PV，是没问题的。

本次分享大纲

1. 电商案例的原因
2. 电商网站需求
3. 网站初级架构
4. 系统容量估算
5. 网站架构分析
6. 网站架构优化
7. 架构总结

电商网站案例，一共有三篇本篇主要说明网站的需求，网站初始架构，系统容量估算方法。

一、电商案例的原因

分布式大型网站，目前看主要有几类1.大型门户，比如网易，新浪等；2.SNS网站，比如校内，开心网等；3.电商网站：比如阿里巴巴，京东商城，国美在线，汽车之家等。大型门户一般是新闻类信息，可以使用CDN，静态化等方式优化，开心网等交互性比较多，可能会引入更多的NOSQL，分布式缓存，使用高性能的通信框架等。电商网站具备以上两类的特点，比如产品详情可以采用CDN，静态化，交互性高的需要采用NOSQL等技术。因此，我们采用电商网站作为案例，进行分析。

二、电商网站需求

客户需求：

• 建立一个全品类的电子商务网站（B2C），用户可以在线购买商品，可以在线支付，也可以货到付款；
• 用户购买时可以在线与客服沟通；
• 用户收到商品后，可以给商品打分，评价；
• 目前有成熟的进销存系统；需要与网站对接；
• 希望能够支持3~5年，业务的发展；
• 预计3~5年用户数达到1000万；
• 定期举办双11，双12,三八男人节等活动；
• 其他的功能参考京东或国美在线等网站。

客户就是客户，不会告诉你具体要什么，只会告诉你他想要什么，我们很多时候要引导，挖掘客户的需求。好在提供了明确的参考网站。因此，下一步要进行大量的分析，结合行业，以及参考网站，给客户提供方案。

其他的略~~~~~

需求功能矩阵

需求管理传统的做法，会使用用例图或模块图（需求列表）进行需求的描述。这样做常常忽视掉一个很重要的需求（非功能需求），因此推荐大家使用需求功能矩阵，进行需求描述。

本电商网站的需求矩阵如下：

 

网站需求	功能需求	非功能需求
全品类的电子商务网站	分类管理，商品管理	方便进行多品类管理（灵活性）网站访问速度要快（高性能）

图片存储的要求（海量小图片）用户可以在线购买商品会员管理，购物车，结算功能良好购物体验（可用性，性能）在线支付或货到付款多种在线支付方式支付过程要安全，数据加密（安全性）多种支付接口灵活切换（灵活性，扩展性）可以在线与客服沟通在线客服功能可靠性：即时通讯商品打分评价商品评论 目前有成熟的进销存系统对接进销存属于约束条件对接时要考虑数据一致性，鲁棒性支持3~5年，业务的发展 属于约束条件伸缩性，可扩展性3~5年用户数达到1000万 约束条件举办双11，双12,三八男人节等活动活动管理，秒杀突增访问流量（可伸缩）实时性要求（高性能）参考京东或国美在线 参考条件

以上是对电商网站需求的简单举例，目的是说明（1）需求分析的时候，要全面，大型分布式系统重点考虑非功能需求；（2）描述一个简单的电商需求场景，使大家对下一步的分析设计有个依据。

三、网站初级架构

一般网站，刚开始的做法，是三台服务器，一台部署应用，一台部署数据库，一台部署NFS文件系统。

这是前几年比较传统的做法，之前见到一个网站10万多会员，垂直服装设计门户，N多图片。使用了一台服务器部署了应用，数据库以及图片存储。出现了很多性能问题。

如下图：

但是，目前主流的网站架构已经发生了翻天覆地的变化。一般都会采用集群的方式，进行高可用设计。至少是下面这个样子。

（1）       使用集群对应用服务器进行冗余，实现高可用；（负载均衡设备可与应用一块部署）

使用数据库主备模式，实现数据备份和高可用；

四、系统容量预估

预估步骤：

1. 注册用户数-日均UV量-每日的PV量-每天的并发量；
2. 峰值预估：平常量的2~3倍；
3. 根据并发量（并发，事务数），存储容量计算系统容量。

客户需求：3~5年用户数达到1000万注册用户；

每秒并发数预估：

1. 每天的UV为200万（二八原则）；
2. 每日每天点击浏览30次；
3. PV量：200*30=6000万；
4. 集中访问量：24*0.2=4.8小时会有6000万*0.8=4800万（二八原则）；
5. 每分并发量：4.8*60=288分钟，每分钟访问4800/288=16.7万（约等于）；
6. 每秒并发量：16.7万/60=2780（约等于）；
7. 假设：高峰期为平常值的三倍，则每秒的并发数可以达到8340次。
8. 1毫秒=1.3次访问；

没好好学数学后悔了吧？！（不知道以上算是否有错误，呵呵~~）

服务器预估：（以tomcat服务器举例）

1. 按一台web服务器，支持每秒300个并发计算。平常需要10台服务器（约等于）；[tomcat默认配置是150]
2. 高峰期：需要30台服务器；

容量预估：70/90原则

系统CPU一般维持在70%左右的水平，高峰期达到90%的水平，是不浪费资源，并比较稳定的。内存，IO类似。

以上预估仅供参考，因为服务器配置，业务逻辑复杂度等都有影响。在此CPU，硬盘，网络等不再进行评估。

五、网站架构分析

根据以上预估，有几个问题：

• 需要部署大量的服务器，高峰期计算，可能要部署30台Web服务器。并且这三十台服务器，只有秒杀，活动时才会用到，存在大量的浪费。
• 所有的应用部署在同一台服务器，应用之间耦合严重。需要进行垂直切分和水平切分。
• 大量应用存在冗余代码
• 服务器SESSION同步耗费大量内存和网络带宽
• 数据需要频繁访问数据库，数据库访问压力巨大。

大型网站一般需要做以下架构优化（优化是架构设计时，就要考虑的，一般从架构/代码级别解决，调优主要是简单参数的调整，比如JVM调优；如果调优涉及大量代码改造，就不是调优了，属于重构）：

• 业务拆分
• 应用集群部署（分布式部署，集群部署和负载均衡）
• 多级缓存
• 单点登录（分布式Session）
• 数据库集群（读写分离，分库分表）
• 服务化
• 消息队列
• 其他技术

六、网站架构优化

6.1业务拆分

根据业务属性进行垂直切分，划分为产品子系统，购物子系统，支付子系统，评论子系统，客服子系统，接口子系统（对接如进销存，短信等外部系统）。

根据业务子系统进行等级定义，可分为核心系统和非核心系统。核心系统：产品子系统，购物子系统，支付子系统；非核心：评论子系统，客服子系统，接口子系统。

业务拆分作用：提升为子系统可由专门的团队和部门负责，专业的人做专业的事，解决模块之间耦合以及扩展性问题；每个子系统单独部署，避免集中部署导致一个应用挂了，全部应用不可用的问题。

等级定义作用：用于流量突发时，对关键应用进行保护，实现优雅降级；保护关键应用不受到影响。

拆分后的架构图：

参考部署方案2

1. 如上图每个应用单独部署
2. 核心系统和非核心系统组合部署

6.2应用集群部署（分布式，集群，负载均衡）

分布式部署：将业务拆分后的应用单独部署，应用直接通过RPC进行远程通信；

集群部署：电商网站的高可用要求，每个应用至少部署两台服务器进行集群部署；

负载均衡：是高可用系统必须的，一般应用通过负载均衡实现高可用，分布式服务通过内置的负载均衡实现高可用，关系型数据库通过主备方式实现高可用。

集群部署后架构图：

6.3 多级缓存

缓存按照存放的位置一般可分为两类本地缓存和分布式缓存。本案例采用二级缓存的方式，进行缓存的设计。一级缓存为本地缓存，二级缓存为分布式缓存。（还有页面缓存，片段缓存等，那是更细粒度的划分）

一级缓存，缓存数据字典，和常用热点数据等基本不可变/有规则变化的信息，二级缓存缓存需要的所有缓存。当一级缓存过期或不可用时，访问二级缓存的数据。如果二级缓存也没有，则访问数据库。

缓存的比例，一般1:4，即可考虑使用缓存。（理论上是1:2即可）。

根据业务特性可使用以下缓存过期策略：

1. 缓存自动过期；
2. 缓存触发过期；

6.4单点登录（分布式Session）

系统分割为多个子系统，独立部署后，不可避免的会遇到会话管理的问题。一般可采用Session同步，Cookies，分布式Session方式。电商网站一般采用分布式Session实现。

再进一步可以根据分布式Session，建立完善的单点登录或账户管理系统。

流程说明

1. 用户第一次登录时，将会话信息（用户Id和用户信息），比如以用户Id为Key，写入分布式Session；
2. 用户再次登录时，获取分布式Session，是否有会话信息，如果没有则调到登录页；
3. 一般采用Cache中间件实现，建议使用Redis，因此它有持久化功能，方便分布式Session宕机后，可以从持久化存储中加载会话信息；
4. 存入会话时，可以设置会话保持的时间，比如15分钟，超过后自动超时；

结合Cache中间件，实现的分布式Session，可以很好的模拟Session会话。

6.5数据库集群（读写分离，分库分表）

大型网站需要存储海量的数据，为达到海量数据存储，高可用，高性能一般采用冗余的方式进行系统设计。一般有两种方式读写分离和分库分表。

读写分离：一般解决读比例远大于写比例的场景，可采用一主一备，一主多备或多主多备方式。

本案例在业务拆分的基础上，结合分库分表和读写分离。如下图：

1. 业务拆分后：每个子系统需要单独的库；
2. 如果单独的库太大，可以根据业务特性，进行再次分库，比如商品分类库，产品库；
3. 分库后，如果表中有数据量很大的，则进行分表，一般可以按照Id，时间等进行分表；（高级的用法是一致性Hash）
4. 在分库，分表的基础上，进行读写分离；

相关中间件可参考Cobar（阿里，目前已不在维护），TDDL（阿里），Atlas（奇虎360），MyCat（在Cobar基础上，国内很多牛人，号称国内第一开源项目）。

分库分表后序列的问题，JOIN，事务的问题，会在分库分表主题分享中，介绍。

6.6服务化

将多个子系统公用的功能/模块，进行抽取，作为公用服务使用。比如本案例的会员子系统就可以抽取为公用的服务。

6.7消息队列

消息队列可以解决子系统/模块之间的耦合，实现异步，高可用，高性能的系统。是分布式系统的标准配置。本案例中，消息队列主要应用在购物，配送环节。

1. 用户下单后，写入消息队列，后直接返回客户端；
2. 库存子系统：读取消息队列信息，完成减库存；
3. 配送子系统：读取消息队列信息，进行配送；

目前使用较多的MQ有Active MQ,Rabbit MQ,Zero MQ，MS MQ等，需要根据具体的业务场景进行选择。建议可以研究下Rabbit MQ。

6.8其他架构（技术）

除了以上介绍的业务拆分，应用集群，多级缓存，单点登录，数据库集群，服务化，消息队列外。还有CDN，反向代理，分布式文件系统，大数据处理等系统。

此处不详细介绍，大家可以问度娘/Google，有机会的话也可以分享给大家。

七、架构总结

以上是本次分享的架构总结，其中细节可参考前面分享的内容。其中还有很多可以优化和细化的地方，因为是案例分享，主要针对重要部分做了介绍，工作中需要大家根据具体的业务场景进行架构设计。

以上是电商网站架构案例的分享一共有三篇，从电商网站的需求，到单机架构，逐步演变为常用的，可供参考的分布式架构的原型。除具备功能需求外，还具备一定的高性能，高可用，可伸缩，可扩展等非功能质量需求（架构目标）。

2.网站技术架构示例

最近我在阅读 2 本关于大型网站架构的书：《大型网站技术架构——核心原理与案例分析》李智慧、《大型网站系统与 Java 中间件实践》曾宪杰。

　　我期望从这些书中学习到大型网站是如何做架构的，这个过程会遇到什么问题。当看完这 2 本书后，我总结出两个大问题：

　　1. 网站技术架构为什么会演进？换个说法就是为什么网站会变大？

　　2. 演进的过程会遇到什么问题？或者说为了演进，会遇到什么问题？

　　网站技术架构为什么会演进

　　我个人总结出来我们的技术架构演进的两种驱动力，驱动着我们为什么演进网站的技术架构：

　　1. 内在驱动力：我们期望把当前的业务做得更好，开发更多新业务

　　2. 外在驱动力：用户量的上升、用户种类的多样化

　　这两种驱动力不是独立的，更多时候是并行的。我想淘宝就是两种驱动力并行驱动的结果。

　　演进的原因很简单。但是在什么时机我们就应该演进网站的技术架构了，以及如何演进？面对这些问题，说实话，我没有任何经验，再说现实中每家企业当时都面临的问题都不一样，所以，我很难从经验中总结出什么是演进的时机。

　　但是我可以从另一个角度切入这个问题：研究网站内外结构，找到这些结构可能出现的问题点，知道或者预见到问题点了，你当然就知道应该怎么演进了。类似于你了解了 PC 机的结构，你也就知道什么时候要加内存了，什么时候要加硬盘了。

　　那么我们先看看网站的外部结构：

　　外部结构中，我们可以看由以下几个部分构成：

　　U：代表用户群。当用户群变了，我们的网站如何演进？用户群的分析，我目前能知道的维度有：数量，种类，地理位置（区域）。

　　N：代表网络环境。网络环境在每个地区都不同。你可以想像我们为什么需要 CDN。当我们期望每个区域的用户都能得到好的体验，我们的网站如何演进？

　　S：代表安全。就是我们要安全到什么程度？这与网站当前所处阶段及你网站的性质有关。

　　C：代表我们的网站。属于内部结构

　　网站的内部结构：

　　内部结构的组成：

　　A：应用服务。

　　D：数据服务

　　总结下来就是我们在考虑网站是否应该演进了或者如何演进时，这些组成部分为我们提供了考虑问题的基准。

　　那么我们为什么不一开始就把网站设计成“大型”的。李智慧在后记里写到：“不要企图去设计一个大型网站”，“原因是互联网发展运行有其自己的规律，短暂的互联网历史已经一再证明这种企图行不通”。还说了：“大型网站不是设计出来的，而是逐步演化出来的”。对于最后这句话，我需要提醒下：“不是设计出来的”并不代表“随意设计”。

　　对于“大型网站的设计”，我个人的看法是现在我们的有“云”了，计算是可以买的，只要我们的设计能适应“云”，我是不是就可以一开始就设计大型网站了？

　　演进的过程会遇到什么问题

　　- 最初

　　从一个小网站说起。一台服务器也就足够了。

　　- 数据服务与应用服务分离

　　越来越多的用户代表着越来越多的数据，一台服务器已经满足不了。我们将数据服务和应用服务分离，给应用服务器配置更好的 CPU，内存。而给数据服务器配置更好更大的硬盘。

　　- 使用缓存

　　因为 80% 的业务访问都集中在 20% 的数据上，如果我们能将这部分数据缓存下来，性能一下子就上来了。而缓存又分为两种：本地缓存和远程分布式缓存。具体使用哪种？还是两种都用，我目前不知道。

　　这里有一个问题，书没有提到：应该缓存哪些数据？应该有一些原则的吧。

　　- 使用服务器集群

　　当这台服务器的处理能力达到上限时，它就会成为瓶颈。虽然你是可以通过购买更强大的硬件，但总会有上限。这时，我们就需要服务器的集群。这时，就必须加个新东西：负载均衡调度服务器。

　　但是，使用服务器集群时，需要考虑一个问题：Session 的管理问题。Session 的管理有以下几种方式：

　　Session Sticky：打个比方就是如果我们每次吃饭都要保证我们用的是自己的碗筷，而只要我们在一家饭店里存着我们的碗筷，只要我们每次去这家饭店吃饭就好了。

　　这种方式的问题：

　　1. 一台服务器重启，上面的 session 都没了

　　2. 负载均衡器成了有状态的机器，要实现容灾会有麻烦

　　Session 复制：就像我们在所有的饭店里都存一份自己的碗筷。不适合做大规模集群，适合机器不多的情况

　　这种方案的问题：

　　1. 应用服务器间带宽问题

　　2. 大量用户在线时，占用内存过多

　　基于 Cookie：类似于每次吃饭都把自己的碗筷带上

　　这种方案的问题：

　　1. Cookie 的长度限制

　　2. 安全性

　　3. 数据中心外部带宽的消耗

　　4. 性能影响，服务器处理每次的请求的内容又多了

　　Session 服务器：同样可以是集群的。这种方式适用于 session 数量及 web 服务器数量大的情况

　　这种方案需要考虑的是：

　　1. 保证 session 服务器的可用性

　　2. 我们在写应用时需要做调整，我目前不知道应用服务器能否将这部分逻辑透明化

　　- 数据库读写分离

　　数据库的一部分读（未缓存、缓存过期）及所有的写操作都还需要经过数据库。当用户量达到一定量，数据库将会成为瓶颈。这边我们使用数据库提供的热备功能，将所有的读操作引入 slave 服务器。注意：读写分离解决的是读压力大的问题。

　　因为数据库的读写分离了，所以，我们的应用程序也得做相应的变化。我们实现一个数据访问模块使上层写代码的人不知道读写分离的存在。这里，我很想知道如果我使用 ORM 模型时，如何实现读写的分离？

　　数据库读写分离会遇到如下问题：

1. 数据复制问题： 考虑时延、数据库的支持、复制条件支持。不要忘了，分机房后，这个更是问题。
2. 应用对于数据源的路由问题

　　- 使用反向代理和 CDN 加速网站响应

　　使用 CDN 可以很好的解决不同的地区的访问速度问题，反向代理则在服务器机房中缓存用户资源：

　　- 使用分布式文件系统

　　- 数据库专库专用：数据垂直拆分。

　　这样可以解决部分数据写的问题

　　垂直拆分数据库时，会遇到的问题：

1. 跨业务的事务
2. 应用的配置项多了

　　关于事务的问题，有两种办法：

1. 使用分布式事务
2. 去掉事务或不追求强事务

　　- 某个业务的数据表的数据量或者更新量达到了单个数据库的瓶颈：数据水平拆分

　　将同一个表的数据拆分到两个数据库中

　　数据水平拆分会遇到的问题：

1. SQL 的路由问题，需要知道某个 User 在哪个数据库上。
2. 主键的策略会有不同。
3. 查询时的性能问题，如分页问题

 

• 使用搜索引擎：解决数据查询问题
• 部分场景可使用 NoSQL 提高性能
• 开发数据统一访问模块：解决上层应用开发的数据源问题

　　- 业务拆分及应用拆分

　　网站的业务日益复杂，建立一个独立的大型应用来完成这所有的业务变得不实际。从管理角度来，也不方便管理。然而，业务的拆分很难找到一种通用的模式，这是一个企业管理问题和技术问题的混合问题。同时和每个企业的具体情况有关。

　　但是从这两本书来看，最终架构都走向服务化，也就是 SOA。而如何实现 SOA，是另一个很大的话题，不是本篇文章的范畴。

　　我从程立 08 年的演讲中截个图来说明 SOA 后的架构大概是怎样的：

　　- 非功能性问题

　　   – 安全性问题、监控问题

　　– 发布问题：新的架构意味着新的发布方式

　　– 分机房

　– 这两本书都没有说分机房的问题。我没有经验，可是也可以猜到如果要分机房了，所有上面的问题都可能要重新考虑。

　　– 组织架构的变化 

　　我们的技术架构的变化，势必会引起我们的组织架构的变化，反之亦然。

　　这部分看似不应该由我们来管，但是，我觉得，我们技术人员也要参与一部分的组织架构的设计。举个例子，组织架构的设计会涉及绩效，而绩效有时很像一个国家的法律。如果一个国家的法律不健全，会发生什么？你懂的。

　　同时，我们还必须考虑人员对新架构的学习成本。

　　这部分我目前在看相关的书籍，还没有一个系统的认识。

　　总结：

　　- 关于演进的顺序

　　在现实中，技术架构的演进不一定就是按文章从头到尾这样列下来的，所以，要视具体情况来下决定。

　　- 关于传统演进与现代有“云”环境下的演进

　　很可惜，只有李智慧谈到云，而且只点了一下——“现在越来越多人的网站从建立之初就是搭建在大型网站提供的云计算服务基础之上，所需的一切资源：计算、存储、网络都可以按需购买线性伸缩，不需要自己一点一点地拼凑各种资源，综合使用各种技术方案逐步去完善自己的网站架构”。

　　因为我用“云”的时间也不长，还不能总结出有云架构与传统的无云架构在演进的时候有什么不同。

　　说回传统的架构演进，我自己总结和思考的结果是：

　　在对网站进行架构调整时，可以从两大的维度考虑：数据服务和应用服务。而这个调整的过程中，需要分清当前哪个点是瓶颈，需要知道哪个点优化的优先级最高。同时，最重要的一点：我们虽然作为技术人员，也应该去学习业务知识，这样我们在考虑问题时分清哪些是业务问题，哪些是技术问题，分清后才能对症下药。你要知道有些问题用技术手段并不比用业务手段更有效。12306 的分时卖票就是一个典型例子。