Go语言进阶(十八)微服务可靠性-隔离

隔离

隔离,本质上是对系统或资源进行分割,从而实现当系统发生故障时能限定传播范围和影响范围,即发生故障后只有出问题的服务不可用,保证其他服务仍然可用。

服务隔离

动静隔离

小到 CPUcacheline false sharing、数据库 mysql 表设计中避免 bufferpool 频繁过期,隔离动静表,大到架构设计中的图片、静态资源等缓存加速。本质上都体现的一样的思路,即加速/缓存访问变换频次小的。比如 CDN 场景中,将静态资源和动态 API 分离,也是体现了隔离的思路:

  • 降低应用服务器负载,静态文件访问负载全部通过CDN。
  • 对象存储存储费用最低。
  • 海量存储空间,无需考虑存储架构升级。
  • 静态 CDN 带宽加速,延迟低。

image-20211213204524270

数据隔离

archive: 稿件表,存储稿件的名称、作者、分类、tag、状态等信息,表示稿件的基本信息。在一个投稿流程中,一旦稿件创建改动的频率比较低。

archive_stat:稿件统计表,表示稿件的播放、点赞、收藏、投币数量,比较高频的更新。随着稿件获取流量,稿件被用户所消费,各类计数信息更新比较频繁。

image-20211213205614458

MySQL BufferPool 是用于缓存 DataPage 的,DataPage 可以理解为缓存了表的行,那么如果频繁更新 DataPage 不断会置换,会导致命中率下降的问题,所以我们在表设计中,仍然可以沿用类似的思路,其主表基本更新,在上游 Cache 未命中,透穿到 MySQL,仍然有 BufferPool 的缓存。

读写分离

主从、ReplicasetCQRS

核心隔离

业务按照 Level 进行资源池划分(L0/L1/L2)。

  • 核心/非核心的故障域的差异隔离(机器资源、依赖资源)
  • 多集群,通过冗余资源来提升吞吐和容灾能力。

image-20211213210311590

快慢隔离

我们可以把服务的吞吐想象为一个池,当突然洪流进来时,池子需要一定时间才能排放完,这时候其他支流在池子里待的时间取决于前面的排放能力,耗时就会增高,对小请求产生影响。

日志传输体系的架构设计中,整个流都会投放到一个 kafka topic 中(早期设计目的: 更好的顺序 IO),流内会区分不同的 logidlogid 会有不同的 sink 端,它们之前会出现差速,比如 HDFS 抖动吞吐下降,ES 正常水位,全局数据就会整体反压。

  • 按照各种纬度隔离:sink、部门、业务、logid、重要性(S/A/B/C)。

业务日志也属于某个 logid,日志等级就可以作为隔离通道。

image-20211213210543289

热点隔离

何为热点?热点即经常访问的数据。很多时候我们希望统计某个热点数据中访问频次最高的 Top K 数据,并对其访问进行缓存。比如:

  • 小表广播: 从 remotecache 提升为 localcacheapp 定时更新,甚至可以让运营平台支持广播刷新 localcache
  • 主动预热: 比如直播房间页高在线情况下 bypass 监控主动防御。

image-20211213210826037

image-20211213210837572

物理隔离

线程隔离

主要通过线程池进行隔离,也是实现服务隔离的基础。把业务进行分类并交给不同的线程池进行处理,当某个线程池处理一种业务请求发生问题时,不会讲故障扩散和影响到其他线程池,保证服务可用。

image-20211213211445302

对于 Go 来说,所有 IO 都是 Nonblocking,且托管给了 Runtime,只会阻塞 Goroutine,不阻塞 M,我们只需要考虑 Goroutine 总量的控制,不需要线程模型语言的线程隔离。

image-20211213211658628

Java 除了线程池隔离,也有基于信号量的做法。

image-20211213212009483

当信号量达到 maxConcurrentRequests 后,再请求会触发 fallback

image-20211213212040011

当线程池到达 maxSize 后,再请求会触发 fallback 接口进行熔断。

进程隔离

容器化(docker),容器编排引擎(k8s)。B站15年在 KVM 上部署服务;16年使用 Docker Swarm;17年迁移到 Kubernetes,到年底在线应用就全托管了,之后很快在线应用弹性公有云上线;20年离线 Yarn 和 在线 K8s 做了在离线混部(错峰使用),之后计划弹性公有云配合自建 IDC 做到离线的混合云架构。

集群隔离

回顾 gRPC,我们介绍过多集群方案,即逻辑上是一个应用,物理上部署多套应用,通过 cluster 区分。

多活建设完毕后,我们应用可以划分为:region.zone.cluster.appid

image-20211213212234988

Case Study

  • 早期转码集群被超大视频攻击,导致转码大量延迟。
  • 缩略图服务,被大图实时缩略吃完所有 CPU,导致正常的小图缩略被丢弃,大量503。
  • 数据库实例 cgroup 未隔离,导致大 SQL 引起的集体故障。
  • INFO 日志量过大,导致异常 ERROR 日志采集延迟。