架构通用核心指标
- 延迟（Latency）√
- 吞吐（Throughput）√
- 成本（Cost）√
- 可用性（Availability）
- 其他（可扩展性、可维护性、可测性、可运维性...）
延迟
延迟 ~ 速度 ~ 响应时间
延迟的度量
- 均值（整体）√
- 分布
- 分布曲线
- 50分位值（中位值）
- 90分位值
- 99分位值（长尾）√
- 超时率（失败率）√
延迟常用的SLA
- 均值 < ? ms
- 90分位值 < ? ms
- 99 分位值 < ? ms
- 超时率 < ? % （超时时间 == ? ms）
如何做到低延迟？
Cache就是万金油，有它速度不用愁
并行：
- 多机
- 单机多CPU
- 单CPU多core
- （单core超线程）
2:8原则，优化热点
- 确定热点：日志（分阶段的耗时记录）、监控数据（系统+业务）、借助工具进行profiling
- 如果IO是热点：
- Disk换成SSD -> 更小的IO延迟，更强的IO能力
- Bloom filter -> 减少不必要的读
- 数据分片 + 分布式 + 更多内存 -> 减少/避免IO
- Cache（系统层或应用层） -> 减少重复IO
- 如果网络是热点：
- 打包访问
- 压缩（推荐lzo，snappy等高效算法）
- 减少跨机房网络
还有些更简单有效的
- 升级一下编译器（比如GCC）
- 开一下O3（指GCC的O3优化）
- 换一下技术（比如用HHVM替换PHP官方实现）
- 换一下硬件
- 关注一下系统配置
- 选择适合应用场景的系统
延迟=等待时间+处理时间 -> 少排队或不排队
- 除非资源到了瓶颈，否则不排队：
- 合适的并发模型
- 队伍要均衡
- 过长的队伍，及时柔性处理
- 需要权衡：吞吐、利用率、成本
总结
- 度量方法要精确且合理
- 常用优化方法：
- 单机层面：Cache、并行、热点优化、排队论、基础软件、硬件、技术选型...
- 分布式层面：抗波动、调度策略、优先级机制、柔性架构、在线转离线...
吞吐
吞吐 ~ 流量
定义：满足服务SLA要求的前提下，单位时间内整个系统的处理能力
优化吞吐
- 提高资源利用率：
- 任何资源都还没到瓶颈，但吞吐上不去：不合适的并发模型、过多锁、过大粒度的锁
- 吞吐的克星：等
- 优化瓶颈：CPU瓶颈、IO瓶颈、网络瓶颈
- 转移瓶颈问题：
- IO瓶颈：比如利用压缩 -> CPU换IO量
- CPU瓶颈：比如利用预计算+Cache -> 内存换CPU
- 网络瓶颈：比如利用数据压缩 -> CPU换带宽
- 合适的并发模型：
- 同步多线程不一定适合所有场景：吞吐=线程数/延迟
- 多个线程组（分阶段或分组）
- 局部异步化 VS 全异步化：需考虑代码可维护性
- 避免过多的overhead比例：尤其是细粒度任务
- 策略折中/有损优化/柔性策略
- 简单有效的手段：升级编译器、O3优化、结合硬件特性、开启超线程、合适的系统配置（网络、文件系统等）
成本
度量：
- 投入产出比
- 简单度量：机器数，或者云环境下的资源池需求等
- 可控（可预估、可扩展）
- 人力成本也是成本，避免过度复杂的系统，或者维护成本过高的系统设计
第一原则：为业务选择合适的技术和硬件
兼顾成本的延迟吞吐优化：
- 编译优化
- 热点优化
- 瓶颈优化
- 提高利用率
- Cache
- ...
一些最佳实践
- 设计阶段就得想好（想好 != 过度设计）
- 2:8原则：优化在刀刃上
- 不要死磕：权衡、折中、局部妥协、另辟蹊径，有时更有效
- 简单好用的基础机制，不用白不用，简单有效
- 基础一定要先做（可以考虑公有云服务）：指标量化、数据收集、监控统计、有目的地优化
- 为业务负责，满足重要、紧急的需求，适当做技术预判