B站-毛剑-海量用户下的微服务可用性设计.pdfVIP

海量用户下的微服务可用性设计 毛剑 目录 • 隔离 • 超时控制 • 过载保护 • 限流 • 降级 • 重试 • 负载均衡 • 最佳实践 • References 隔离 隔离，本质上是对系统或资源进 行分割，从而实现当系统发生故 障时能限定传播范围和影响范围， 即发生故障后只有出问题的服务 不可用，保证其他服务仍然可用。 服务隔离 • 动静分离、读写分离 轻重隔离 • 核心、快慢、热点 物理隔离 • 线程、进程、集群、机房 隔离 • 动静隔离: 小到 CPU 的 cacheline false sharing 、 数据库 mysql 表设计中避免 bufferpool 频繁过期，隔离动静表， 大到架构设计中的图片、静态资 源等缓存加速。 本质上都体现的一样的思路，即 加速/缓存访问变换频次小的。比 如 CDN 场景中，将静态资源和动 态 API 分离，也是体现了隔离的 思路: • 降低应用服务器负载，静态文件 访问负载全部通过CDN。 • 对象存储存储费用最低。 • 海量存储空间，无需考虑存储架 构升级。 • 静态CDN带宽加速，延迟低。 隔离 archive: 稿件表，存储稿件的名称、作 者、分类、tag 、状态等信息，表示稿件 的基本信息。 在一个投稿流程中，一旦稿件创建改动的频 率比较低。 archive_stat: 稿件统计表，表示稿件的 播放、点赞、收藏、投币数量，比较高 频的更新。 随着稿件获取流量，稿件被用户所消费，各 类计数信息更新比较频繁。 MySQL Buff erPool 是用于缓存 DataPage 的， DataPage 可以理解为缓存了表的行，那么如 果频繁更新 DataPage 不断会置换，会导致 命中率下降的问题，所以我们在表设计中， 仍然可以沿用类似的思路，其主表基本更新， 在上游 Cache 未命中，透穿到 MySQL，仍然 有 Buff erPool 的缓存。 • 读写分离：主从、Replicaset 、CQRS 。 隔离 • 核心隔离 业务按照 Level 进行资源池划分 (L0/ L1/ L2)。 • 核心/ 非核心的故障域的差异隔离(机 器资源、依赖资源) 。 • 多集群，通过冗余资源来提升吞吐和 容灾能力。 隔离 • 快慢隔离 我们可以把服务的吞吐想象为一个 池，当突然洪流进来时，池子需要 一定时间才能排放完，这时候其他 支流在池子里待的时间取决于前面 的排放能力，耗时就会增高，对小 请求产生影响。 日志传输体系的架构设计中，整个流都 会投放到一个 kaf ka topic 中(早期设计目 的: 更好的顺序 IO) ，流内会区分不同的 logid，logid 会有不同的 sink 端，它们之 前会出现差速，比如 HDFS 抖动吞吐下 降，ES 正常水位，全局数据就会整体反 压。 • 按照各种纬度隔离：sink、部门、业 务、logid、重要性(S/A/ B/ C) 。 业务日志也属于某个 logid，日志等级就 可以作为隔离通道。 隔离 • 热点隔离 何为热点？热点即经常访问的数据。 很多时候我们希望统计某个热点数 据中访问频次最高的 Top K 数据，并 对其访问进行缓存。比如： • 小表广播: 从 remotecache 提升为 localcache，app 定时更新，甚至可以 让运营平台支持广播刷新 localcache， 例如 atomic.Value。 • 主动预热: 比如直播房间页高在线情 况下bypass 监控主动防御。 • 自适应热点防御：每个节点自己计算。 隔离 • 线程隔离 主要通过线程池进行隔离，也是实现服务 隔离的基础。把业务进行分类并交给不同 的线程池进行处理，当某个线程池处理一 种业务请求发生问题时，不会讲故障扩散 和影响到其他线程池，保