系统稳定性设计

《服务器开发技术、方法与实用解决方案》

一、稳定性设计

稳定性是指系统在干扰、异常等破坏性事件的影响下持续、正确地提供服务或功能的能力

1. 容量评估

容量评估的常用技术指标：QPS、TPS
通过容量评估可以分析得到应用和接口维度的容量需求，其中最常见的稳定性风险是高并发风险

分析流量时可以采用业务漏斗模型和调用链路模型

2. 压测摸底

1）压测目标：

• 系统水位评估：系统濒临阈值时系统可承载的QPS、TPS以及对应的RT数据
• 系统容量验证：在给定QPS或TPS下是否存在性能瓶颈，核心业务链路是否正常运行

2）压测粒度：
接口压测、核心链路压测、全链路压测

3. 风险识别

稳定性风险主要有两类：高并发风险和远程调用风险

高并发场景常用的稳定性提升措施：

• 性能优化：如使用缓存、优化SQL、减少IO、优化代码等
• 异步化：即削峰策略，对于不需要实时返回结果的业务，可以通过异步线程、消息队列等进行异步处理，保证核心链路稳定
• 降级和限流：降级部分非核心业务，释放资源；或设置限流保护系统

远程调用风险在于其结果存在不确定性，如网络抖动、依赖的下游系统重启、响应超时等。处理措施：

• 如果返回明确的结果，可以记录日志返回错误信息等
• 对于未知调用结果，一般只能通过重试解决。同时需要根据具体场景分析重试策略（阶梯延时重试、定时调度重试）、幂等、重试顺序等

4. 限流方案

1）限流粒度：

• 单机限流：算法主要有令牌桶、漏桶、计数器算法，可以使用Guava的RateLimiter实现。但是该方式已不再适用于互联网的分布式架构了
• 分布式限流：从全局视角实现整体限流

2）限流手段：

• 客户端限流：避免单个客户端对服务的过度使用。如通过浏览器端的JS代码监控点击频率、统计点击次数、或者通过客户端包中的限流逻辑让访问快速失败并返回。缺点是对全局流量无感知，客户端触发限流时，服务端的实际荷载可能还很小，不需要限流
• 接入层限流：客户端的请求一般会通过接入层（一般为Nginx集群）分发到服务器应用集群上，接入层负责负载均衡、流量转发等能力。Nginx通过漏桶算法实现了限流能力，主要提供两种限流方式：访问频率限制和并发连接数限制。但是接入层限流无法实现接口维度的流量管控
• 应用层限流：在业务代码层面实现精细控制的限流，如Sentinel就可以实现接口级的流量控制。
• Mesh限流：Service Mesh是一个基础设施层，用于处理服务间通信，通常由一系列轻量级的网络代理组成，与应用程序部署在一起，但对应用无感知。Service Mesh可以看做是微服务间的TCP/IP，负责服务之间的网络调用、限流、熔断和监控，所有应用程序间的流量都会通过它。实现如蚂蚁的MSON，大型企业的限流一般都实现配置化

3. 降级方案

需要降级的场景：因资源不足而降级、因链路异常而降级

1）执行方式

• 手动降级：通过手动配置（通常是开关变量，通过修改其至来改变执行逻辑）启动降级链路。根据业务场景的需要，降级链路都是提前设计好的，如直接返回错误提示，或使用缓存
• 自动降级：一般有两种策略，所有失败均自动降级走兜底链路，或当频次触发降级阈值时采降级

2）常用方案

• 延迟服务：将非核心服务异步化，如存入消息队列或HBase中，待流量平稳后通过消费消息或定时任务执行
• 关闭/拒绝服务：在流量高峰时关闭低优先级服务
• 有损服务：如为减轻数据库压力而直接读缓存，可能会存在数据不一致问题

3）降级设计

• 开关设计：在分布式架构中使用分布式资源管理中间件（如蚂蚁DRM），在开关配置发生变更后，资源管理中间件快速将变更信息通知所有应用节点，节点在收信息后更新本地缓存中的开关变量值，为了保持最终一致性，通常还需辅以定时轮询
• 降级判断：一般是统计规定时间窗口内服务失败的次数和频率