伸缩性

对于热点业务或数据 当现有资源明显不足以应对可预期的流量需求 则需要进行伸缩

• 高伸缩性：增加资源就可应对处理需求的增长
• 伸缩性差：随需求增长需求变差、性能提升成本高

热点数据

行为热点 -> 链路热点 -> 数据热点 -> 热点压力 -> 达到瓶颈限制 -> 系统崩溃

热点很容易造成整个缓存击穿 进而导致击穿到数据库 所以需要将热点数据进行隔离 避免发生故障时故障扩散

热点预测

• 提前进行数据采集，依托现有数据推测
• 舆情、PV/UV

热点发现

日志监控 -> 聚合分析 -> 发布热点数据事件

热点预案

发现热点数据后，对相应组件进行扩容增配，但也要做好限流保护，避免被冲垮

在热点预测后，可以先进行缓存预热，另外一个就是对非热点降级，将资源分配大部给热点

热点逻辑

功能防御：在热点冲击的情况下，为了提高整体性能，某些逻辑不采取常用做法，而是通过异步、消息通知等方式来进行

热点分散

发现热点key

• 分库分表
• 平均负载到不同的机器

在架构设计中，为了实现热点分散这个目的，各个组件间需要做好隔离，通过全链路压测来探索热点的极限及范围等，通过统计与分散治理，并通过压测验证优化的正确性

无状态应用

• Serverless
• Kubernetes HPA
• Istio + Knative

负载均衡

• 高可用：当某个节点故障时，负载均衡器会将用户请求转发到另外的节点上，从而保证所有服务持续可用
• 伸缩性：根据系统整体负载情况，可以很容易地添加或移除节点

有状态应用

• 共享磁盘数据
  • 结构化的数据存数据库
  • 非结构化的数据用对象存储 搜索引擎
• Share Nothing架构
  • 集群节点之间没有共享资源 加节点很容易 需要注意的是可用性与一致性的权衡
  • 有状态应用的扩容需要一定时间 需要提前准备

session管理

Sticky Session

配置负载均衡器，使得一个用户的所有请求都路由到同一个服务器，这样就可以把用户的 Session 存放在该服务器中

当该节点宕机后，该节点的所有会话数据都将丢失

Session Replication

在服务器之间进行 Session 同步操作，每个服务器都有所有用户的 Session 信息

内存占用过多，且同步过程会影响性能

Session Server

使用一个单独的服务器存储 Session 数据，如可以使用mysql或者redis来实现

这可以使应用服务器保持无状态，但缺点是需要对session存取代码进行改造

消息解耦

对于长任务、非实时、基于发布订阅多下游同语义的业务场景，使用消息组件来不仅可以对各业务方进行解耦有利于各业务方独立伸缩，并且可以有效利用消息组件的可靠性