大型Web网站的技术挑战主要来自于大量的用户，高并发的访问和海量的数据存储，任何简单的业务一旦需要处理TB级别的数据和面对数以亿计的用户，问题就会变得很棘手。那么如何打造一个高可用、高性能、易扩展、可伸缩且安全的网站？首先要从架构方面入手，以高性能架构为基础，辅以优化后的前端应用（如减少Http请求，终端缓存等等）和后台程序（如Jvm优化，操作系统优化等等）即可以构建一个高性能的Web网站。
首先我们来了解下构建一个高性能Web网站时，性能的瓶劲在哪里？如下图所示：

在这里插入图片描述

从上图可以分析出性能瓶劲主要表现在两个方面：
1、硬件资源层面，如不同运营上的网络，服务器的带宽限制，服务器的CPU、内存及磁盘IO等；
2、软件层面，Web应用程序的性能，数据库服务器的性能；
硬件资源的提升对性能的提升时逐级递减的直至趋于0，所以性能的提高不能通过无休止的增加硬件资源，所以我们就要考虑如何从软件架构的层面来提供性能，下图为高性能架构的主要思路：

在这里插入图片描述

架构思路的说明如下：
1、负载均衡，包括早期的使用DNS负载均衡，四层交换的负载均衡及七层交换的负载均衡；一般业界多采用硬件四层交换负载均衡和软件四层交换负载均衡，硬件四层交换负载均衡优势时稳定性高，功能强大，但价格较高，一般的公司难以承受，典型产品是F5、A10；软件四层交换负载均衡的优势是免费开源，通过热备等方式也可以构建一个稳定性高的负载均衡，所以我们的首选软件四层交换负载均衡（即LVS）
2、高可用性方面要考虑避免单点故障，需要引入热备（包括主从和主主两种方式），集群以及灾备；
3、 Web应用开发架构方面要选择合适的应用开发框架同时考虑将动态页面进行静态化并进行静态资源（图片，CSS，JS及页面）的缓存（此点建议使用Nginx或者Varnish进行缓存）；数据存储方面考虑使用分布式存储系统（需要根据所存储文件的大小选择合适的存储系统，比如一般的图片文件和视频文件选择的存储系统就会有所不同，前者一般可以选择FastDFS，后者选择HDFS）以及引入数据缓存(如Redis集群)和NoSql数据库（也叫内存数据库，比如：MongoDB）
4、数据库方面需要考虑进行读写分离，分库、分表、分区等；
5、网络方面引入CDN来解决不同网络服务商的接入速度问题并考虑在不同运营商机房部署服务器，通过镜像技术来实现不同网络服务商的接入速度问题。
Web应用架构的演化历程：

在这里插入图片描述

Web应用架构的特点如下图

在这里插入图片描述

微服务架构有其明显的优势，已经是目前及未来Web应用架构的首选，其缺点是：微服务过多，服务治理成本高，不利于系统维护；分布式系统开发的技术成本高（容错、分布式事务等），对团队挑战大；所以如果是一般初学者建议还是选择先从MVC架构开始。
综合以上的简单分析，我们可以大致得出高性能的架构如下图：

在这里插入图片描述

1、使用LVS作为软件四层交换负载均衡并使用Heartbeat实现双机热备；
2、使用反向代理软件来实现数据缓存（静态资源缓存），此处我们可以选择使用Nginx或者Varnish
3、 Web应用框架可以更加系统规模进行选择，小编建议初学者选择先从MVC架构开始；
4、数据持久化层使用MyBatis以提高性能，数据缓存使用Redis集群；
5、分布式存储选择HDFS并引入NoSql数据库，数据库方面实现读写分离和热备，必要的时候还需要分库分表等；

--------------------------------------------------------------------------------------------------------------------

高并发设计的技术方案

1.负载均衡
2.分布式微服务
3.缓存机制
4.分布式关系型数据库
4.1 垂直分表
4.2 水平分表
4.3 开源框架分类
4.4 实现方案
5.分布式消息队列
5.1 常见的消息队列
5.2 消息队列的场景
6.CDN 内容分发网络
7.其他
8.总结

————————————————

1.负载均衡

靠优化单台机器的内存、CPU、磁盘、网络带宽，使其发挥极致性能，已经不太现实。

负载均衡，它的职责是将网络请求 “均摊”到不同的机器上。避免集群中部分服务器压力过大，而另一些服务器比较空闲的情况

通过负载均衡，可以让每台服务器获取到适合自己处理能力的负载。在为高负载服务器分流的同时，还可以避免资源浪费，一举两得。

常见的负载算法：

随机算法
轮询算法
轮询权重算法
一致性哈希算法
最小连接
自适应算法

常用负载均衡工具：

LVS
Nginx
HAProxy

对于一些大型系统，一般会采用 DNS+四层负载+七层负载的方式进行多层次负载均衡。

————————————————

2.分布式微服务

每个微服务独立部署，服务和服务间采用轻量级的通信机制，如：标准的HTTP协议、或者私有的RPC协议。

微服务特点:

按照业务划分服务，单个服务代码量小，业务单一，容易维护
每个微服务都有独立的基础组件, 例如数据库
微服务之间的通信为Http 协议或者其他协议, 具有容错性
微服务有一定的治理方案, 服务之间不耦合, 可以随时加入和删除
单个微服务可以集群部署, 有负载均衡的能力
整个微服务有安全机制, 包括用户验证, 权限验证, 资源保护
整个微服务有链路跟踪的能力
有完整的实时日志系统
市面常用微服务框架有：Spring Cloud 、Dubbo 、kubernetes、gRPC、Thrift 等

常用的注册中心有：Zookeeper、etcd、Eureka、Nacos、Consul

需要注意一些很复杂的问题

分布式事务
限流机制
熔断机制
网关
服务链路跟踪

————————————————

3.缓存机制

性能不够，缓存来凑。要想快速提升性能，缓存肯定少不了

缓存能够带来性能的大幅提升，以 Memcache 为例，单台 Memcache 服务器简单的 key-value 查询能够达到 TPS 50000 以上；Redis性能数据是10W+ QPS

常见的缓存分为本地缓存和分布式缓存，区别在与是否要走网络通讯。

本地缓存是部署在应用服务器中，而我们应用服务器通常会部署多台，当数据更新时，我们不能确定哪台服务器本地中了缓存，更新或者删除所有服务器的缓存不是一个好的选择，所以我们通常会等待缓存过期。因此，这种缓存的有效期很短，通常为分钟或者秒级别，以避免返回前端脏数据。
分布式缓存采用集群化管理，支持水平扩容，并提供客户端路由数据，数据一致性维护更好。虽然有不到 1ms 的网络开销，但比起其优势，这点损耗微不足道。

缓存更新常用策略:

Cache aside，通常会先更新数据库，然后再删除缓存，为了兜底还会设置缓存时间。
Read/Write through，一般是由一个 Cache Provider 对外提供读写操作，应用程序不用感知操作的是缓存还是数据库。
Write behind，延迟写入，Cache Provider 每隔一段时间会批量写入数据库，大大提升写的效率。像操作系统的page cache也是类似机制。

————————————————

4.分布式关系型数据库

MySQL数据库采用B+数索引，三层结构，为了保证IO性能，一般建议单表存储千万条数据.

分表又可以细分为垂直分表和水平分表两种形式。

4.1 垂直分表
数据表垂直拆分就是纵向地把一张表中的列拆分到多个表，表由“宽”变“窄”，简单来讲，就是将大表拆成多张小表，一般会遵循以下几个原则：

冷热分离，把常用的列放在一个表，不常用的放在一个表。
字段更新、查询频次拆分
大字段列独立存放
关系紧密的列放在一起
4.2 水平分表
表结构维持不变，对数据行进行切分，将表中的某些行切分到一张表中，而另外的某些行又切分到其他的表中，也就是说拆分后数据集的并集等于拆分前的数据集。

SQl组合。因为是逻辑表名，需要按分表键计算对应的物理表编号，根据逻辑重新组装动态的SQL
数据库路由。如果采用分库，需要根据逻辑的分表编号计算数据库的编号
结果合并。如果查询没有传入指定的分表键，会全库执行，此时需要将结果合并再输出。
4.3 开源框架分类
Proxy模式。SQL 组合、数据库路由、执行结果合并等功能全部存放在一个代理服务中，业务方可以当做。
支持多语言, 但是引入一个中间件, 会形成流量瓶颈, 安全风险高, 运维成本高
Client 模式。常见是 sharding-jdbc，业务端系统只需要引入一个jar包即可，按照规范配置路由规则。jar 中处理 SQL 组合、数据库路由、执行结果合并等相关功能。
简单, 轻便, 减少了流量瓶颈与运维成本, 但是单语言, 升级不方便
4.4 实现方案
如何选择分表键。

数据尽量均匀分布在不同表或库、跨库查询操作尽可能少、这个字段的值不会变。比如电商订单采用user_id。

基因分库分表
数据存储中，相互关系的表，尽量分库时落到同一个库中，避免遍历多个库查询，而且还能避免分布式事务。
一般分库或者分表我们采用取余操作，余数相同的id落到相同的库中，或分表规则一致。
分片策略。

根据范围分片、根据 hash 值分片、根据 hash 值及范围混合分片

历史数据迁移

增量数据监听 binlog，然后通过 canal 通知迁移程序开始增量数据迁移
开启任务，全量数据迁移
开启双写，并关闭增量迁移任务
读业务切换到新库
线上运行一段时间，确认没有问题后，下线老库的写操作
数据量大，就分表；并发高，就分库

在实际的业务开发中，要做好数据量的增长预测，做好技术方案选型。另外，在引入分表方案后，要考虑数据倾斜问题，这个跟分表键有很大关系，避免数据分布不均衡影响系统性能

————————————————

5.分布式消息队列

并不是所有的调用都要走同步形式，对于时间要求不高、或者非核心逻辑，我们可以采用异步处理机制。

消息队列主要有三种角色：生产者、消息队列、消费者。两者之间通过消息中间件完成了解耦，系统的扩展性非常高。

5.1 常见的消息队列
ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaQ，RocketMQ、Pulsar 等

5.2 消息队列的场景
异步处理。将一个请求链路中的非核心流程，拆分出来，异步处理，减少主流程链路的处理逻辑，缩短RT，提升吞吐量。如：注册新用户发短信通知。
削峰填谷。避免流量暴涨，打垮下游系统，前面会加个消息队列，平滑流量冲击。比如：秒杀活动。生活中像电源适配器也是这个原理。
应用解耦。两个应用，通过消息系统间接建立关系，避免一个系统宕机后对另一个系统的影响，提升系统的可用性。如：下单异步扣减库存
消息通讯。内置了高效的通信机制，可用于消息通讯。如：点对点消息队列、聊天室。

————————————————