系统稳定性设计

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

一、稳定性设计

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

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),在开关配置发生变更后,资源管理中间件快速将变更信息通知所有应用节点,节点在收信息后更新本地缓存中的开关变量值,为了保持最终一致性,通常还需辅以定时轮询
  • 降级判断:一般是统计规定时间窗口内服务失败的次数和频率

你可能感兴趣的:(系统架构设计,java)