大型网站架构

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

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

本次分享大纲 电商案例的缘由 电商网站需求 网站初级架构 系统容量估算 网站架构分析 网站架构优化 架构总结 电商网站案例，一共有三篇本篇主要说明网站的需求，网站初始架构，系统容量估算方法。

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

2、电商网站需求 客户需求：

创建一个全品类的电子商务网站（B2C），用户能够在线购买商品，能够在线支付，也能够货到付款； 用户购买时能够在线与客服沟通； 用户收到商品后，能够给商品打分，评价； 目前有成熟的进销存系统；须要与网站对接； 但愿可以支持3~5年，业务的发展； 预计3~5年用户数达到1000万； 按期举办双11，双12,三八男人节等活动； 其余的功能参考京东或国美在线等网站。 客户就是客户，不会告诉你具体要什么，只会告诉你他想要什么，咱们不少时候要引导，挖掘客户的需求。好在提供了明确的参考网站。所以，下一步要进行大量的分析，结合行业，以及参考网站，给客户提供方案。

其余的略~~~~~

需求功能矩阵

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

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

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

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

3、网站初级架构 通常网站，刚开始的作法，是三台服务器，一台部署应用，一台部署数据库，一台部署NFS文件系统。

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

以下图：

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

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

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

4、系统容量预估 预估步骤：

注册用户数-日均UV量-每日的PV量-天天的并发量； 峰值预估：日常量的2~3倍； 根据并发量（并发，事务数），存储容量计算系统容量。 客户需求：3~5年用户数达到1000万注册用户；

每秒并发数预估：

天天的UV为200万（二八原则）； 每日天天点击浏览30次； PV量：20030=6000万； 集中访问量：240.2=4.8小时会有6000万0.8=4800万（二八原则）； 每分并发量：4.860=288分钟，每分钟访问4800/288=16.7万（约等于）； 每秒并发量：16.7万/60=2780（约等于）； 假设：高峰期为日常值的三倍，则每秒的并发数能够达到8340次。 1毫秒=1.3次访问； 没好好学数学后悔了吧？！（不知道以上算是否有错误，呵呵~~）

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

按一台web服务器，支持每秒300个并发计算。日常须要10台服务器（约等于）；[tomcat默认配置是150] 高峰期：须要30台服务器； 容量预估：70/90原则

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

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

5、网站架构分析

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

须要部署大量的服务器，高峰期计算，可能要部署30台Web服务器。而且这三十台服务器，只有秒杀，活动时才会用到，存在大量的浪费。 全部的应用部署在同一台服务器，应用之间耦合严重。须要进行垂直切分和水平切分。 大量应用存在冗余代码 服务器SESSION同步耗费大量内存和网络带宽 数据须要频繁访问数据库，数据库访问压力巨大。 大型网站通常须要作如下架构优化（优化是架构设计时，就要考虑的，通常从架构/代码级别解决，调优主要是简单参数的调整，好比JVM调优；若是调优涉及大量代码改造，就不是调优了，属于重构）：

业务拆分 应用集群部署（分布式部署，集群部署和负载均衡） 多级缓存 单点登陆（分布式Session） 数据库集群（读写分离，分库分表） 服务化 消息队列 其余技术 6、网站架构优化 6.1业务拆分

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

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

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

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

拆分后的架构图：

参考部署方案2

如上图每一个应用单独部署 核心系统和非核心系统组合部署 6.2应用集群部署（分布式，集群，负载均衡）

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

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

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

集群部署后架构图：

6.3 多级缓存

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

一级缓存，缓存数据字典，和经常使用热点数据等基本不可变/有规则变化的信息，二级缓存缓存须要的全部缓存。当一级缓存过时或不可用时，访问二级缓存的数据。若是二级缓存也没有，则访问数据库。

缓存的比例，通常1:4，便可考虑使用缓存。（理论上是1:2便可）。

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

缓存自动过时； 缓存触发过时； 6.4单点登陆（分布式Session）

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

再进一步能够根据分布式Session，创建完善的单点登陆或帐户管理系统。

流程说明

用户第一次登陆时，将会话信息（用户Id和用户信息），好比以用户Id为Key，写入分布式Session； 用户再次登陆时，获取分布式Session，是否有会话信息，若是没有则调到登陆页； 通常采用Cache中间件实现，建议使用Redis，所以它有持久化功能，方便分布式Session宕机后，能够从持久化存储中加载会话信息； 存入会话时，能够设置会话保持的时间，好比15分钟，超事后自动超时； 结合Cache中间件，实现的分布式Session，能够很好的模拟Session会话。

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

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

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

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

业务拆分后：每一个子系统须要单独的库； 若是单独的库太大，能够根据业务特性，进行再次分库，好比商品分类库，产品库； 分库后，若是表中有数据量很大的，则进行分表，通常能够按照Id，时间等进行分表；（高级的用法是一致性Hash） 在分库，分表的基础上，进行读写分离； 相关中间件可参考Cobar（阿里，目前已不在维护），TDDL（阿里），Atlas（奇虎360），MyCat（在Cobar基础上，国内不少牛人，号称国内第一开源项目）。

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

6.6服务化

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

6.7消息队列

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

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

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

6.8其余架构（技术）

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

此处不详细介绍，你们能够问度娘/Google，有机会的话也能够分享给你们。

7、架构总结

以上是本次分享的架构总结，其中细节可参考前面分享的内容。其中还有不少能够优化和细化的地方，由于是案例分享，主要针对重要部分作了介绍，工做中须要你们根据具体的业务场景进行架构设计。

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

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 模型时，如何实现读写的分离？

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

数据复制问题： 考虑时延、数据库的支持、复制条件支持。不要忘了，分机房后，这个更是问题。 应用对于数据源的路由问题 　　- 使用反向代理和 CDN 加速网站响应

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

- 使用分布式文件系统

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

这样能够解决部分数据写的问题

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

跨业务的事务 应用的配置项多了 　　关于事务的问题，有两种办法：

使用分布式事务 去掉事务或不追求强事务 　　- 某个业务的数据表的数据量或者更新量达到了单个数据库的瓶颈：数据水平拆分

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

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

SQL 的路由问题，须要知道某个 User 在哪一个数据库上。 主键的策略会有不一样。 查询时的性能问题，如分页问题

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

- 业务拆分及应用拆分

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

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

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

- 非功能性问题

– 安全性问题、监控问题

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

– 分机房

– 这两本书都没有说分机房的问题。我没有经验，但是也能够猜到若是要分机房了，全部上面的问题均可能要从新考虑。

– 组织架构的变化

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

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

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

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

总结：

- 关于演进的顺序

在现实中，技术架构的演进不必定就是按文章从头至尾这样列下来的，因此，要视具体状况来下决定。

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

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

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

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

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