《大型网站技术架构》- 读书笔记

关键词

• 技术选型
• 架构设计
• 性能优化
• Web安全
• 系统发布
• 运维监控 .......

要点

1. 架构设计
2. 快速开发
3. 高效部署
4. 业务监控
5. 服务治理
6. 运维管理

核心技术

• 前端优化
• CDN
• 反向代理
• 缓存
• 消息队列
• 分布式存储
• 分布式服务
• NoSQL存储
• 搜索
• 监控
• 安全等

技术挑战类型：1. 功能性需求——传统网站中业务逻辑； 2. 非功能性需求——大型网站处理超大量的用户访问和海量的数据处理;
网站核心架构要素： 性能、可用性、伸缩性、扩展性、安全性几个网站核心架构要素切入

本书核心思想

阐述网站技术架构最基本的驱动力，基础的架构设计原理，以及架构方案选择的价值观。
希望软件工程师在解决问题之前，能够认真思考自己面对的真正问题究竟是什么，有哪些技术方案可以选择，其基本原理是什么？

大型网站架构演化

大型网站软件系统的特点

1. 高并发，大流量 2. 高可用 3. 海量数据 4. 用户分布广泛，网络情况复杂 5. 安全环境恶劣 6. 需求快速变更，发布频繁

没有一簇而就的大型网站，只有适应市场需求渐渐演化而来的，那么网站一开始设计时的可扩展性极其重要。

初始阶段网站架构

此时网站由于没有太多的人访问所以所有的资源包括应用程序、数据库、文件等所有的资源都是放在一台服务器上。

服务器分离

网站发展起来后，越来越多的用户访问导致性能越来越差，越来越多的数据导致存储空间不足。将应用和数据分离。
应用和数据分离后整个网站使用三台服务器： 应用服务器、文件服务器和数据库服务器
应用服务器： 需要处理大量业务逻辑需要强大的CPU
数据库服务器：需要快速磁盘检索和数据缓存因此需要更快的硬盘和更大的内存
文件服务器：需要存储用户上传的文件，因此需要更大的硬盘

使用缓存改善网站性能

根据二八定律，80%的业务访问集中在20%的数据上。可以将这些20%的数据换在的内存中减少对数据库的访问压力

两种缓存：

1. 缓存在应用服务器上的本地缓存。
2. 缓存在专门的分布式缓存服务器上的远程缓存。
   使用缓存后，数据访问压力得到有效缓解，但是单一应用服务器能够处理的请求连接有限，在网站访问高峰期，应用服务器成为整个网站的瓶颈。
   

使用应用服务器集群改善网站的并发处理能力

使用集群是网站解决高并发、海量数据问题的常用手段。
通过负载均衡器，可以将来自用户浏览器的访问请求分发到应用服务器集群中的任何一台服务器上，如果有更多的用户，就在集群中加入更多的应用服务器，使用应用服务器的负载压力不再成为整个网站的瓶颈！！！

数据库读写分离

网站使用缓存后，大部分数据读操作访问都可以不通过数据库就可完成，但是仍然有一部分读操作（缓存访问不命中、缓存过期）和全部的写操作需要访问数据库，在网站的用户达到一定规模后，数据库因为负载压力过高成为网站的瓶颈。
主流数据库服务器提供主从热备功能，通过配置两台数据库主从关系，可以将一台数据库服务器的数据更新同步到另一台服务器上。网站利用此功能实现数据库读写分离，改善数据库负载压力

应用服务器 ===》 写操作 =》 主数据库（Main DB Server)
主数据库=》 主从复制机制 ===》 数据库更新同步 ===》 从数据库
此时应用服务器读数据的时候，就可以通过从数据库获得数据。

为了便于应用程序访问读写分离后的数据库，通常在应用服务端使用专门的数据访问模块，使数据库读写分离对应用透明。

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

随着网站访问量递增，网站访问延迟愈发明显，为了提高用户的体验度（保证网站的访问量）可采用的手段有： CDN和反向代理

CDN和反向代理的基本原理：缓存
两者区别：
- CDN部署在分布式机房里，用户在请求网站服务时，可以从距离自己最近的网络提供商机房内获取数据；（CDN是整个网站服务的缓存，缓存的对象是整个网站核心服务)
- 反向代理部署在网站的中心机房，用户在请求网站服务时，如果反向代理服务器中缓存着用户请求的资源就将其直接返回给用户。（反向代理是所有指定用户的缓存，缓存的对象是用户缓存（即请求资源)

使用CDN和反向代理的目的是： 尽早返回数据给用户

1. 提供用户体验度(网站访问速度） 2.网站整体负载压力平均化

使用分布式文件系统和分布式数据库系统

分布式数据库是网站数据库拆分的最后手段，只有在单表数据规模非常庞大的时候才使用。（不到不得已时，网站更常用的数据库拆分手段时业务分库，将不同业务的数据库部署在不同的物理服务器上）

使用NoSQL和搜索引擎

随着网站业务越来越复杂，对数据存储和检索的需求也越来越复杂，网站需要采用一些非关系数据库技术eg: NoSQL和非数据库查询技术eg:搜索引擎

NoSQL和搜索引擎都是源自互联网的技术手段，对可伸缩的分布式特性具有更好的支持。应用服务器则通过一个统一数据访问模块访问各种数据，减轻应用程序管理诸多数据源麻烦。

业务拆分

任何应用开发均存在两种问题： 1.功能性问题（业务逻辑愈来愈复杂） 2.非功能性问题（网站并发量、数据量增大），通过使用分而治之的手段将整个网站业务分成不同的产品线路
eg: 大型购物交易网站会将首页、商铺、订单、卖家、买家、等拆分成不同的产品线，分归不同的业务团队负责。==》 随之微服务的概念来源于此
根据产品线划分，将一个网站拆分成不同的应用，每个应用独立部署维护。应用之间可以通过一个超链接建立关系（eg: 在首页上的导航链接🔗每个都指向不同的应用地址），也可以通过消息队列进行数据分发或者通过访问同一个数据存储系统来构成要给关联的完整系统。

分布式服务

业务拆分越来越小， 存储系统越来越庞大， 应用系统的整体复杂度呈指数级增加，部署维护愈发困难！！！
连接的数目是服务器规模的平方，导致存数据库资源不足，拒绝服务！！！

每个应用系统都需要执行许多相同的业务操作eg: 用户管理、商品管理等，可以将共同的业务抽取出来独立部署，可复用的业务连接数据库，提供共用业务服务，而应用系统只需要管理用户界面，通过
分布式服务调用共用业务服务完成具体业务操作。

小结

1. 应用服务器在于CPU快(处理程序逻辑）
2. 数据库重点在于内存大（缓存）还有检索数据块（磁盘IO）
3. 文件服务器在于硬盘大（存储用户文件）

• I/O性能： CPU缓存 > 内存 > 网络 > 硬盘。 缓存的数据量太大的情况下需要部署专门的缓存服务器

• 正向代理和反向代理是相对于客户端与服务器而言； 代理服务端是为反向， 代理客户端是为正向。

• PB指的是petabyte, 1PB = 1024TB

• 双机热备： 保持两个数据库的状态自动同步。 对任何一个数据库的操作都自动应用到另一个数据库，始终保持两个数据库数据一致
  好处：
  1. 可以做容灾处理（即一个宕机可以用另一个）
  2. 可以做负载均衡将请求分摊到其中任何一台，提高网站吞吐量，平均化网站负载压力。

• 微服务实现业务逻辑分离， 分布式数据库实现业务数据分离（打个照面）

• 拆分的业务之间建立联系的方法
  1. 超链接
  2. 消息队列进行数据分发
  3. 访问同一个数据存储系统

• 大型网站架构演化进程
  - 第二阶段：使用缓存 1. 前端静态缓存 2. 服务端本地缓存 3. 缓存服务器
  - 第三阶段：应用服务器集群化： 解决应用服务器单点问题
  - 第四阶段：数据库读写分离：解决应用服务集群化之后的数据库单点读写问题

大型网站架构演化的价值观

大型网站都是从小型网站发展而来的。网站的价值在于它能为用户提供什么价值，网站在用户的关注点里是能做什么，在开发者眼里是怎么做。
小型网站需要做的就是为用户提供好的服务来创造价值，得到用户的认可，活下去，野蛮生长！！！

驱动大型网站技术发展的主要力量是 网站的业务发展

再厉害的网站都是一行一行代码累积而成，再厉害的工程师也是一点一点积累出来的，一口吃不成胖子，最快到达山顶的诀窍是： 慢慢来
思考在工作中得到了什么，从业务、技术、人发展思考！！！

技术是用来解决业务问题的，而业务问题也可以通过业务的手段去解决

★★★ 开发者真正核心竞争力不是掌握了多少技术而是能够解决问题的能力

网站架构模式

高性能、高可用、易伸缩、可扩展、安全等

分层 - 【横向切分】

分层将系统在横向维度上切成几个部分，每个部分负责一部分相对比较单一的职责（单一职责），上层调用下层--下层对上层负责构成一个完整系统

• 网站分层架构
  | DESC | URL |
  | ---- | ----|
  | 应用层 | 负责具体业务和视图展示，如网站首页以及搜索输入和结果展示 |
  | 服务层 | 为应用层提供服务支持，如用户管理服务，购物车服务等 |
  | 数据层 | 提供数据存储访问服务，eg: 数据库、缓存、文件、搜索引擎等|

分层后各个模块相互独立统一向外提供私有接口进行访问。在维持原有调用接口不变的情况，各个模块可以独立进行迭代发展！！！

分层注意项：各层次之间要依赖于规划层次的边界和接口，禁止🈲跨层次的调用(应用层直接调用服务层）以及逆向调用（数据层调用服务层，服务层调用应用层）

分割 - 【纵向切分】

分层将软件在横向方面进行切面，那么分割就是在纵向方面对软件进行切分。
网站越大，功能越复杂，服务和数据处理的种类也越多，将不同的功能和服务分割开来，包装成高内聚低耦合的模块单元。

1. 有助于软件的开发和维护。
2. 有助于不同模块的分布式部署，提高网站的并发能力和功能扩展能力。

大型网站的分割的粒度可能会很小，比如在应用层，将不同业务进行分割，eg: 将购物、论坛、搜索、广告分割成不同的应用，由独立的团队负责，部署在不同的服务器上；
在同一个应用内部，如果规模庞大业务复杂，会继续分割，比如购物业务，可以进一步分割成机票酒店业务、3C业务，小商品业务等更细小的粒度。即使在粒度上可以继续分割成首页、搜索列表
、商品详情等模块。

分布式

分层和分割的一个主要目的是： 为了切分后的模块便于分布式部署(即将不同模块部署在不同的服务器上，通过远程调用协同工作)。

分布式意味着可以使用更多的计算机完成同样的功能，计算机越多，CPU、内存、存储资源也就越多，能够处理的并发访问和数据量就越大，进而能够为更多的用户提供服务。

• 存在的缺点
  - 分布式调用必须通过网络，这可能会对性能造成比较严重的影响；
  - 服务器越多，服务器宕机的概率也就越大，一台服务器宕机造成的服务不可用可能会导致很多应用不可访问，使网站可用性降低；
  - 数据在分布式的环境中保持数据一致性非常困难，分布式事务难以保证，这对网站业务正确性和业务流程有可能造成很大影响；
  - 分布式导致网站依赖错综复杂，开发管理维护困难。
  分布式要量力而行，切不可为了分布式而分布式！！！

常用的分布式方案类型：

1. 分布式应用和服务： 将分层和分割后的应用和服务模块分布式部署；
2. 分布式静态资源：网站的静态资源eg: JS、CSS、Logo图片等资源独立分布式部署，并采用独立的域名，即动态分离。

静态资源分布式部署可以减轻应用服务器的负载压力；通过使用独立域名加快浏览器并发加载的速度；由负责用户体验的团队进行开发维护有利于网站分工合作，使不同技术术业有专攻！！！

3. 分布式数据和存储： 大型网站需要处理以P为单位的海量数据，单台计算机无法提供如此大的存储空间需要将数据分布式存储（为网站而生的各种NoSQL产品几乎都是分布式存储的）。
4. 分布式计算：应用、服务、实时数据处理都是计算，网站除了要处理这些在线业务，还有一部分用户没有直观感受的后台业务要处理包括搜索引擎的索引构建、数据仓库的数据分析统计等

业务的计算规模非常庞大，普遍使用Hadoop以及MapReduce分布式计算框架进行此类批处理计算将计算程序分发到数据所在的位置以加速计算和分布式计算。
支持网站线上服务器配置实时更新的分布式配置；分布式环境下实现并发和协同的分布式锁；支持云存储的分布式文件系统等；

集群

使用分布式将分层和分割后的模块独立部署，但是对于用户访问集中的模块（eg: 网站的首页），需要将独立部署的服务器集群化，即多台服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务。
服务器集群有更多服务器提供相同服务，因此提供更好的并发性，当有更多用户访问的时候，只需要向集群中加入新的机器即可。同时因为一个应用由多台服务器提供，当某台服务器发生故障时，负载均衡设备或者系统的失效转移机制会将请求转发到集群中其他服务器上，使服务器故障不影响用户使用。在网络应用中即使访问量很小的分布式应用和服务，也至少要部署两台服务器构成一个小的集群，目的是提高系统的可用性。

缓存

缓存： 将数据存放在距离计算最近的位置以加快处理速度。(缓存是改善软件性能的第一手段)

CDN(Content Delivery Network)内容分发网络——后端缓存，部署在距离终端用户最近的网络服务商，用户的网络请求总是先到达他的网络服务商哪里，在缓存网站的一些静态资源（较少变化的数据），可以就近以最快速度返回给用户。eg: 视频网站和门户网站将用户访问量大的热点内容缓存在CDN。

反向代理：——前端缓存，部署在网络的前端，当用户请求到达网站的数据中心时，最先访问的是反向代理服务器，这里缓存网站的静态资源，无需将请求继续转发给应用服务器就能返回给用户。

本地缓存：在应用服务器本地缓存着热点数据，应用程序可以在本机内存中直接访问数据，而无需访问数据库。

分布式缓存： 大型网站的数据量非常庞大，即使只缓存一小部分，需要的内存空间也不是单机能承受的，所以除了本地缓存，还需要分布式缓存，将数据缓存在一个专门的分布式缓存集群中，应用程序通过网络通信访问缓存数据。

• 使用缓存的两个前提条件：
  - 1. 数据访问热点不均衡，某些数据会被更频繁的访问，这些数据应该放在缓存中；
  - 2. 数据在某个时间段内有效，不会很快过期，否则缓存的数据就会因已经失效而产生脏读，影响结果的正确性；

网站应用中，缓存既可以加快数据访问速度也可以减轻后端应用和数据存储的负载压力🍐。

异步

计算机软件发展的一个重要目标和驱动力是降低软件耦合性。事务之间直接关系越少，就越少被彼此影响，越可以独立发展。
大型网站架构中，系统解耦合的手段除了分层、分割、分布还有异步，业务之间的消息传递不是同步调用而是将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方式异步执行进行协作。
异步架构是典型的生产者消费者模式，两者不存在直接调用，只要保持数据结构不变，彼此功能实现可以随意变化不相互影响。

• 异步消息队列的特性：
  - 提供系统可用性

消费者服务器发生故障，数据会在消息队列服务器中存储堆积，生产者服务器可以继续处理业务请求，系统整体表现无故障。消费者服务器恢复正常后，继续处理消息队列中的数据。
- 加快网站响应速度
处在业务处理前端的生产者服务器在处理完业务请求后，将数据写入消息队列，不需要等待消费者服务器处理就可以返回，响应延迟减少。
- 消除并发访问高峰。
用户访问网站是随机的，存在访问高峰和低谷，即使网站按照一般访问高峰进行规划和部署，也依然会出现突发事件，比如购物网站的促销活动、微博上的热点事件都会造成网站并发访问突然增大会造成整个网站访问突然增大，会造成整个网站负载过重，响应延迟，严重时甚至会出现服务宕机的情况。使用消息队列将突然增加的访问请求数据放入消息队列中，等待消费者服务器依次处理，就不会对整个网站负载造成太大压力。
- 冗余
网站是7x24连续运行单服务器随时可能出现故障，如果服务器规模较大，出现某台服务器宕机是必然事件。要保证服务器宕机的情况下网站依然可以继续服务，不丢失数据，就需要一定程度的服务器冗余运行，数据冗余备份，当某台服务器宕机时，可以将其上的服务和数据访问转移到其他机器上。
访问和负载很小的服务必须部署至少两台服务器构成一个集群，目的在于通过冗余实现服务高可用。数据库除了定期备份，存档保存，实现冷备份外，为了保证在线业务高可用，需要对数据库进行主从分离，实时同步实现热备份

• 灾备数据中心
  为了抵御地震、海啸等不可抗力导致的网站完全瘫痪，某些大型网站会对整个数据中心进行备份，全球范围部署灾备数据中心。网站程序和数据实时同步到多个灾备数据中心。

自动化

在无人值守的情况下网站可以正常运行，一切都可以自动化时网站的理想状态

DESC	URL
发布过程自动化	有效减少故障
自动化代码管理	代码版本控制、代码分支创建合并等过程自动化
自动化测试	代码开发完成，提交测试后，系统自动将代码部署到测试环境，启动自动化测试用例进行测试，向相关人员发送测试报告，向系统反馈测试结果
自动化安全检测	安全检测工具通过对代码继续宁静态安全扫描以及部署到安全测试环境进行安全攻击测试、评估其安全性
自动化部署	将工程代码自动部署到线上生产环境
自动化监控	监控各种问题: 服务器宕机、程序Bug、存储空间不足、突然爆发对线上生产环境进行自动化监控
自动化报警	对服务器进行心跳检测，并监控其各项性能指标和应用程序的关键数据指标。
自动化失效转移	检测到故障，系统自动失效转移，将失效的服务器从集群中移出去，不再处理系统中的应用请求。等到故障消除后系统自动化失效恢复，重新启动服务
自动化降级	拒绝部分请求以及关闭部分不重要的服务将系统负载降至一个安全的水平
自动化分配资源	将空闲资源分配给重要的服务，扩展其部署规模

安全

通过密码和手机校验码进行身份认证； 登录、交易等操作需要对网络通信进行加密，网站服务器上存储的敏感数据如用户信息等也进行加密处理；
为了防止机器人滥用网络资源攻击网站，网站使用验证码进行识别；
对于常见的用于攻击网站的XSS攻击、SQL注入、进行编码转换等响应处理；
对垃圾信息、敏感信息进行过滤；
对交易转账等重要操作根据交易模式和交易信息进行风险控制；

小结

• 集群： 多台处理相同业务的机器 ~ 构成集群。

• 分布式：多台分别处理不同业务的机器 ~ 构成分布式。

• 缓存的数据：一般都是更新修改不频繁的数据eg: 电商网站商品信息

• 缓存： 主要目的是实现计算在哪数据在哪。（1. 减少请求处理事件提高用户体验度 2. 减轻后端系统整体负载能力）

• xss(CSS-Cross-SiteScripting): 跨站脚本攻击。恶意攻击者往Web页面里插入恶意HTML代码，当用户浏览该页之时，嵌入其中Web里面的html代码会执行。

• 网站技术模式9个： 分层、分割、分布式、集群、缓存、异步、冗余、自动化和安全
  - 分层：将应用按照MVC或更细分。
  - 分割：将应用根据不同的功能进行模块分割。

架构模式在新浪微博的应用

简单的架构无法支持快速发展的业务需求，随着访问用户的逐渐增加，系统不堪重负。

系统分为三个层次：
最上层： API和新浪微博的业务层，各种客户端（Web网站）和第三方应用，通过调用API集成到新浪微博的系统中，共同组成一个生态系统。

中间层: 平台服务和应用服务层，新浪微博的核心服务是微博关系和用户，服务被分割为独立的服务模块，通过依赖调用和共享基础数据构成基础业务。

最下层： 基础服务层，提供数据库、缓存、存储、搜索等数据服务以及其他基础技术服务（海量数据和高并发访问是整个系统的技术基础）。

被分层和分割后的业务模块和基础技术模块分布式部署，每个模块都部署在一组独立的服务器集群上，通过远程调用的方式进行依赖访问。改善服务的负载均衡和可用性。

在微博的早期架构中，微博发布使用同步推模式，用户发表微博后系统会立即将这条微博插入数据库所有粉丝的订阅列表中，当用户量比较大时候，特别是明星用户发布微博时，会引起大量的数据写操作，超出数据库负载，系统性能急剧下降，用户响应延迟加剧。为了解决此类问题，微博采用异步推拉结合的模式，用户发表微博后系统将用户发表的新动态内容写入消息队列之中立即返回，用户响应迅速，消息队列消费者任务将微博推送给所有当前在线粉丝的订阅列表中，非在线用户登录后根据关注列表拉取微博定于列表。

微博需要频繁更新，使用多级缓存策略，热门微博和明星用户的微博缓存在所有的微博服务器上，在线用户的微博和近期微博缓存在分布式缓存集群上，对于“刷微博”操作，几乎全部都是缓存访问操作，可以获得很好的系统性能。

提供系统的整体可用性和性能，微博启用多个数据中心，数据中心即是地区用户访问中心，用户可以就近访问最近的数据中心以加快访问速度，改善系统性能；同时也是数据冗余复制的灾备中心，所有的用户和微博数据通过远程消息系统在不同的数据中心之间同步，提高系统可用性。

小结

• “推模式” -> 事件触发后广播给所有粉丝，如果粉丝数过多，后台压力增大浪费存储空间， “拉模式” -> 在用户登录后，根据关注的实体生成timeline内容。用户一旦登录就需要被内容读取出来，读取压力会比较大。新浪采用“推拉结合”，活跃用户在线推送，其他用户拉取，既可以降低存储空间也可以大多数用户的读取需求。

• 好的设计绝对不是模仿，不是生搬硬套某个模式，而是对问题深刻理解之上的创造与创新，即使是“微创新”也是让人耳目一新的似曾相识，山寨和创新的最大区别： 对问题和需求是否真正理解和把握！！！

• 综合分析业务场景和诉求，达到业务诉求和技术复杂平衡，不过分追求技术，技术为业务量身定制。（结合需求和业务，选择合适的架构，不要为了选择架构而改变)

好的艺术家模仿皮毛，伟大的艺术家窃取灵魂 -- 毕加索

大型网站核心架构要素

架构通俗说法： “最高层次的规划，难以改变的决定” ， 规划和决定奠定了事物未来发展的方向（脉络）和最终的蓝图!!!

人生规划也是一种架构。选什么学校、学什么专业、进什么公司、找什么对象，过什么样的生活，都是自己的人生架构！！！

Software Architecture： 软件架构是系统的草图。软件架构描述的对象是最直接构成系统的抽象组件。各个组件之间的连接🔗则明确和相对细致地描述组件之间地通讯。 在实现阶段，抽象组件被细化为实际地组件。eg: 某个具体地类或对象。 在OO中组件之间的连接通常用接口来实现。

软件架构： 有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计！！！

软件架构关注点： 性能（响应事件）、可用性（724）、伸缩性（分布式、集群）、扩展性（功能易扩展）和安全性*

• 性能

  优化性能的手段
  1. 在浏览器端： 通过浏览器缓存、使用页面压缩、合理布局页面、减少Cookie传输等手段改善性能。使用CDN，将网站静态内容分发至距离用户最近的网络服务商机房，使用户通过最短访问路径获取数据，可以在网站机房部署反向代理服务器，缓存热点文件，加快请求响应速度，减轻应用服务器负载压力
  2. 在应用服务器端： 可以使用服务器本地缓存和分布式缓存，通过缓存在内容中的热点数据处理用户请求，加快请求处理过程，减轻数据库负载压力。通过异步操作将用户请求发送至消息队列等待后续任务处理，而当前请求直接返回响应给用户。
  3. 在代码层面： 使用多线程、改善内存管理等手段
  4. 在数据库服务器端： 索引、缓存、SQL优化等性能优化手段都已经较为成熟

• 衡量网站性能指标
  响应的事件、TPS(Transaction Per Second)、系统性能计数器等（必须要考察系统在高并发访问情况下，超出负载设计能力的情况下可能出现的性能问题）。

小结

• 前端的优化方式： 添加CDN静态资源缓存、添加反向代理服务器；
• 后端的优化方式： 添加分布式缓存和本地内存缓存，通过异步方式处理请求；

如何提高响应速度（性能）？ 要从数据流转过程起进行分析可优化的手段

1. 打开浏览器，需要一小部分的数据通过Cookie进行缓存，起到改善性能帮助。
2. 当浏览器缓存不了了，可采用运营商提供的CDN结点缓存静态资源。
3. 当前两者都未找到缓存数据，请求才刚到服务端，可以先做反向代理，达到分流，减轻服务器压力，再进行异步处理，减小DB与CPU的压力，不管是响应速度还是性能都得到了提升！！！

性能优化贯穿整个系统的各个层面：

• 前端浏览器开始（Cookie、页面布局...）
• 网络运行商（CDN）
• 服务端（本地缓存，远程分布式缓存）
• 代码层面（多线程、异步处理、合理的数据结构）
• 数据库层面（sql优化...)

可用性

网站可能出现的问题： 网站服务器宕机（服务器硬件故障）、服务不可用

网站高可用架构设计的前提是必然会出现服务器宕机，
而高可用设计的目标： 当服务器宕机的时候，服务或应用依然可用.

网站高可用的主要手段： 冗余， 应用部署再多台服务器商同时提供访问，数据存储在多台服务器上互相备份，任何一台服务器宕机都不会影响应用的整体可用，也不会导致数据丢失。

多台应用服务器通过负载均衡设备组成一个集群共同对外提供服务，任何一台服务器宕机，只需把请求切换到其他服务器就可以实现应用的高可用（即在某一台服务器宕机的前提下，应用服务器集群任何能够对外提供可用的服务），切换到其他服务器的过程中无法保存请求的会话信息。

网站高可用需要软件开发过程的质量保证。通过预发布验证、自动化测试、自动化发布、灰度发布等手段，减少将故障引入线上环境的可能，避免故障范围扩大。

伸缩性

网站通过集群的方式将多台服务器组成一个整体共同提供服务。伸缩性是指： 不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求。

衡量架构伸缩性： 1. 是否可以用多台服务器构建集群 2. 是否容易向集群中添加新的服务器 3. 加入的新服务器时候可以提供和原来的服务器无差别的服务。 4. 集群中可容纳的总的服务器数目是否有限制。

扩展性

衡量网站架构扩展好坏的主要标准就是在网站增加新的业务产品时候，是否可以实现对现有产品透明无影响，不需要任何改动或者很少改动既有业务功能就可以上线新产品。

不同产品之间是否低耦合，一个产品改动对其他产品无影响，其他产品和功能不受牵连进行改动。

网站可伸缩架构的主要手段： 事件驱动架构和分布式架构

事件驱动架构在网站通常利用消息队列实现，将用户请求和其他业务事件构造成消息发布到消息队列中，消息的处理者作为消费者从消息队列中获取消息进行处理。通过这种方式将消息产生和消息处理分离开来，可以透明增加新的消息生产者任务或新的消息消费者任务。

分布式服务是将业务和可复用服务分离开来，通过分布式服务框架调用。（新增产品通过调用可复用的服务实现自身的业务逻辑，而对现有产品没有任何影响）。

网站性能测试

性能测试是性能优化的前提和基础，也是性能优化结果的检查和度量标准。不同视角下的网站性能有不同的标准，也有不同的优化手段。

不同视角下的网站性能：

1. 用户视角的网站性能： 用户在浏览器上直观感受到的网站响应速度块还是慢。用户感受到的时间包括用户计算机和网站服务器通信的时间、网站服务器处理的时间、用户计算机浏览器构造请求解析响应数据的时间。
2. 开发人员视角的网站性能： 应用程序本身以及子系统的性能（响应延迟、系统吞吐量、并发处理能力、系统稳定性等技术指标）主要的优化手段： ①使用缓存加速数据读取，使用集群提高吞吐能力，②使用异步消息加快请求响应以及实现③使用代码优化手段改善程序性能。
3. 运维人员视角的网站性能： 基础设施性能和资源利用率，eg：网络运营商的带宽能力、服务器硬件的配置、数据中心网络架构、服务器和网络带宽资源利用率

性能测试指标

1. 响应时间（应用执行一个操作需要的时间，发出请求到接收响应数据所需时间）
2. 并发数（系统能够同时处理请求的数目，反映系统负载特性，对于网站而言，并发数即网站并发用户数，指的是同时提交请求的用户数目）。网站系统用户数 >> 网站在线用户数 >> 网站并发用户数

当并发用户数超过网站最大负载而响应缓慢，急性子的用户不停刷新浏览器，导致系统并发数更高，最后以服务器系统崩溃，用户浏览器现实“Service is too busy"而告终。（网站技术准备不充分导致）

3. 吞吐量（单位时间内系统处理的请求量，体现系统的整体处理能力）

• TPS(每秒事务数） HPS(每秒HTTP请求数) QPS(每秒查询数）等