伸缩性
对于热点业务或数据 当现有资源明显不足以应对可预期的流量需求 则需要进行伸缩
- 高伸缩性：增加资源就可应对处理需求的增长
- 伸缩性差：随需求增长需求变差、性能提升成本高
热点数据
行为热点 -> 链路热点 -> 数据热点 -> 热点压力 -> 达到瓶颈限制 -> 系统崩溃
热点很容易造成整个缓存击穿 进而导致击穿到数据库 所以需要将热点数据进行隔离 避免发生故障时故障扩散
热点预测
- 提前进行数据采集，依托现有数据推测
- 舆情、PV/UV
热点发现
日志监控 -> 聚合分析 -> 发布热点数据事件
热点预案
发现热点数据后，对相应组件进行扩容增配，但也要做好限流保护，避免被冲垮
在热点预测后，可以先进行缓存预热，另外一个就是对非热点降级，将资源分配大部给热点
热点逻辑
功能防御：在热点冲击的情况下，为了提高整体性能，某些逻辑不采取常用做法，而是通过异步、消息通知等方式来进行
热点分散
发现热点key
- 分库分表
- 平均负载到不同的机器
在架构设计中，为了实现热点分散这个目的，各个组件间需要做好隔离，通过全链路压测来探索热点的极限及范围等，通过统计与分散治理，并通过压测验证优化的正确性
无状态应用
- Serverless
- Kubernetes HPA
- Istio + Knative
负载均衡
- 高可用：当某个节点故障时，负载均衡器会将用户请求转发到另外的节点上，从而保证所有服务持续可用
- 伸缩性：根据系统整体负载情况，可以很容易地添加或移除节点
算法
- 轮询（Round Robin）
每个请求轮流发送到每个服务器上该算法笔记适合每个服务器性能差不多的场景
- 加权轮询（Weighted Round Robbin）
在轮询的基础上，根据服务器的性能差异，为服务器赋予一定的权值，性能高的服务器分配更高的权值权值更高的服务器接收更多的请求
- 最少连接（Least Connections）
将请求发送给当前最少连接数的服务器上
- 加权最少连接（Weighted Least Connection）
根据服务器的性能为每台服务器分配权重，再根据权重计算出每台服务器能处理的连接数
- 随机算法（Random）
把请求随机发送到服务器上
- 源地址哈希法 (IP Hash)
通过对客户端 IP 计算哈希值之后，再对服务器数量取模得到目标服务器的序号这样就可以保证同一ip的客户的请求都会转发到同一台服务器，这个算法可以解决分布式session问题
转发实现
HTTP重定向
负载均衡服务器使用某种负载均衡算法计算得到服务器的 IP 地址之后，将该地址写入 HTTP 重定向报文中，状态码为 302。客户端收到重定向报文之后，需要重新向服务器发起请求
这样客户端需要两次请求，性能会受到一定影响
DNS域名解析
DNS 解析域名的同时使用负载均衡算法计算服务器 IP 地址
优点是可以返回离用户地理位置更近的服务器缺点是DNS具有多级结构，DNS解析结果可能被各级缓存，修改DNS记录后，需要比较长的时间才能生效
大型网站基本使用了 DNS 做为第一级负载均衡手段，然后在内部使用其它方式做第二级负载均衡
反向代理服务器
位于源服务器前面，用户的请求需要先经过反向代理服务器才能到达源服务器
反向代理服务器可能会成为性能瓶颈
- 应用层转发
这种方式对于其它类型层的转发优点是可以得到更为详细的数据包信息
- 网络层转发
nginx之类的代理服务器是工作在应用层上的，网络层上的反向代理可以直接修改数据包目的IP地址，进行转发，但在服务器的响应还是需要经过负载均衡器
- 链路层转发
在链路层根据负载均衡算法计算源服务器的 MAC 地址，并修改请求数据包的目的 MAC 地址，并进行转发
通过配置源服务器的虚拟 IP 地址和负载均衡服务器的 IP 地址一致，源服务器的响应可以直接发送给客户端，不用经过负载均衡器
有状态应用
- 共享磁盘数据
- 结构化的数据存数据库
- 非结构化的数据用对象存储 搜索引擎
- Share Nothing架构
- 集群节点之间没有共享资源 加节点很容易 需要注意的是可用性与一致性的权衡
- 有状态应用的扩容需要一定时间 需要提前准备
session管理
Sticky Session
配置负载均衡器，使得一个用户的所有请求都路由到同一个服务器，这样就可以把用户的 Session 存放在该服务器中当该节点宕机后，该节点的所有会话数据都将丢失
Session Replication
在服务器之间进行 Session 同步操作，每个服务器都有所有用户的 Session 信息
内存占用过多，且同步过程会影响性能
Session Server
使用一个单独的服务器存储 Session 数据，如可以使用mysql或者redis来实现
这可以使应用服务器保持无状态，但缺点是需要对session存取代码进行改造
消息解耦
对于长任务、非实时、基于发布订阅多下游同语义的业务场景，使用消息组件来不仅可以对各业务方进行解耦有利于各业务方独立伸缩，并且可以有效利用消息组件的可靠性
性能规划
性能指标
- RT响应时间
- 吞吐量（QPS、TPS）
- 并发数
RT与吞吐量是正相关的，RT越短、吞吐量越高
业务性能优化
- 并行、异步化
- 存储优化
- 缓存
- 数据异构/冗余
- SQL调优
性能基线
时刻关注拐点 确保集成新功能后系统仍能保持原来的曲线
