■月均活跃用户达1.3亿，B站高可用架构实践

流量洪峰下要做好高服务质量的架构是一件具备挑战的事情，本文详细阐述了从 Google SRE 的系统方法论以及实际业务的应对过程中出发，一些体系化的可用性设计。对我们了解系统的全貌、上下游的联防有更进一步的帮助。

本文插图
本文来自公众号云加社区(ID：QcloudCommunity)
负载均衡
负载均衡具体分成两个方向，一个是前端负载均衡，另一个是数据中心内部的负载均衡。

本文插图
前端负载均衡方面，一般而言用户流量访问层面主要依据 DNS ，希望做到最小化用户请求延迟。
将用户流量最优地分布在多个网络链路上、多个数据中心、多台服务器上，通过动态 CDN 的方案达到最小延迟。
以上图为例，用户流量会先流入 BFE 的前端接入层，第一层的 BFE 实际上起到一个路由的作用，尽可能选择跟接入节点比较近的一个机房，用来加速用户请求。
然后通过 API 网关转发到下游的服务层，可能是内部的一些微服务或者业务的聚合层等，最终构成一个完整的流量模式。
基于此，前端服务器的负载均衡主要考虑几个逻辑：

尽量选择最近节点
基于带宽策略调度选择 API 进入机房
基于可用服务容量平衡流量

本文插图
数据中心内部的负载均衡方面，理想情况下会像上图右边显示那样，最忙和最不忙的节点所消耗的 CPU 相差幅度较小。
但如果负载均衡没做好，情况可能就像上图左边一样相差甚远。由此可能导致资源调度、编排的困难，无法合理分配容器资源。
因此，数据中心内部负载均衡主要考虑：

均衡流量分发
可靠识别异常节点
scale-out ，增加同质节点以扩容
减少错误，提高可用性

本文插图
我们此前通过同质节点来扩容就发现，内网服务出现 CPU 占用率过高的异常，通过排查发现背后 RPC 点到点通信间的 Health Check 成本过高，产生了一些问题。
另外一方面，底层的服务如果只有单套集群，当出现抖动的时候故障面会比较大，因此需要引入多集群来解决问题。
通过实现 Client 到 Backend 的子集连接，我们做到了将后端平均分配给客户端，同时可以处理节点变更，持续不断均衡连接，避免大幅变动。
多集群下，则需要考虑集群迁移的运维成本，同时集群之间业务的数据存在较小的交集。

本文插图
【■月均活跃用户达1.3亿，B站高可用架构实践】
回到 CPU 忙时、闲时占用率过大的问题，我们会发现这背后跟负载均衡算法有关。
第一个问题：对于每一个 QPS ，实际上就是每一个 query、查询、API 请求，它们的成本是不同的。
节点与节点之间差异非常大，即便你做了均衡的流量分发，但是从负载的角度来看，实际上还是不均匀的。
第二个问题：存在物理机环境上的差异。因为我们通常都是分年采购服务器，新买的服务器通常主频 CPU 会更强一些，所以服务器本质上很难做到强同质。