微服务架构 | 实战常见数据

@

目录

• 压测参考值（180C）
• 线程池
• Qps/Tps
• JVM
• redis

压测参考值（180C）

	时长	TPS	TPS极限	TP性能	TP极限	并发	CPU负载
一般接口	5min	500	2000	50/100ms	120ms	1->10/30	40%
缓存接口	5min	5000	20000	7/20ms	10/25ms	1->2/4	40%
一般写接口
关键写接口

线程池

使用原则

• 尽量避免使用公共线程池：假设有两种任务 A/B 共用线程池，若 A 处理逻辑故障可能导致用尽线程池，最终影响了 B 任务
• 线程池监控覆盖不到位：线程池是系统运行时关键资源，应当对线程数、等待队列数等进行监控
• 正确设置线程池参数：线程池最大线程数、队列长度等参数需要经过多次压测并调整至核实的数值

最佳实践

• 通过线程池管理线程：避免频繁创灭线程造成系统开销
• 线程命名规范：指定具有业务含义的线程名（前缀），以方便排查问题
• 线程池参数设置：创建线程池时应手动显示指定如下关键参数，并经过多次压测
  • 初始线程数/最大线程数：
    • 通常根据压测数据指定，初步估计可用系统容量估算，或 \(\ge\frac{TPS*TP*1.2}{nodeCount}\)（TP换算成秒）
    • 估算后的数据需要经过压测验证
    • 通常情况下，初始线程数 == 最大线程数
  • 任务队列最大长度
    • 设置过小影响线程池可用度，设置过大则可能在异常时诱发频繁 GC
    • 可以考虑通过混沌演练找到合适的值
  • 任务队列满后拒绝策略：丢弃，并增加兜底逻辑
• 线程池隔离机制：频率较少并且稳定的任务，可以按强依赖/弱依赖、CPU密集/IO密集、长任务/短任务、高优先级/低优先级等划分各自的线程池
• 线程池监控机制：通常包括当前线程数、队列积压任务数、拒绝次数等，以便故障时快速定位
• 并发任务超时设置：妥善设置超时，并遵照漏斗法则
• 线程上下文使用风险：线程回归资源池时，清理线程使用的上下文，防止其他请求读到脏数据

Qps/Tps

• mysql：1500
• reids：10w+
• kafka：100w+

JVM

主要是降低 STW-time
Minor GC：< 200ms
Full GC：< 2s

redis

实验室理论极限数据

• 读：11w /s
• 写：8w /s