01 背景介绍

B站的 CDN 下行边缘节点过去是非集群化架构。这种架构下有几个弊端：

1. 增加调度逻辑复杂性；
2. 同机房流量/负载难以均衡；
3. 暴露过多的公网IP，增加安全隐患 (盗链等)；
4. 灰度流量比例分配粒度大；

针对以上问题，我们调研了常见的四层负载均衡器， 传统的 SLB，LVS，DPVS 这类四层负载均衡器，在功能上也能满足我们现有的需求。但是以上几个负载均衡器均需要独占机器，进而造成成本升高，资源浪费。

有没有一种既不增加成本，又能解决边缘节点四层负载需求的方案呢？由 Cloudflare 提出的基于 Express Data Path (XDP) 的高性能四层负载均衡器 Unimog[1]性能优异，并且可以和后端服务同机部署，在性能上也完全满足我们边缘场景的要求。所以我们参考 Cloudflare Unimog 的思想，在其基础上自研了适用于B站的边缘四层负载均衡器 Nickel (以下简称 Ni) 。

• 与业务服务同机部署，更划算；
• 只保留业务需要功能，更轻量；
• 可针对业务特点优化，更灵活；

目前已部署在自建动态加速，及自建点直播 CDN 集群化生产环境中。其支持与后端服务同机部署，底层使用 XDP、Traffic Control (TC) 进行包粒度转发，支持 Direct Server Return (DSR) 模式，支持根据 CPU/QPS (或其他业务维度) 动态调整流量分配。

下面左图为传统 DSR 模式，右图为自研负载均衡器 Ni 的 DSR 模式，不需独占资源，支持与服务同机部署，更符合边缘场景。

02 架构设计

2.1 总体设计

四层负载均衡器 Ni 由两部分组成，控制面和数据面。控制面主要负责服务发现、配置管理、数据上报，及LB规则的动态维护等。数据面主要由 LoadBalance (XDP) , Redirect (TC Traffic Control) 等模块组成，主要用来负责数据包的转发。控制面和数据面根据预定义的接口传输数据。

图片

开始介绍之前先明确几个下文中用的到名词及其意义：

• VIP (virtual IP) ：用于统一接受用户请求，代表当前集群流量入口，下文中VIP指LB所在机器的IP（目前边缘没有支持真正虚拟IP的建设）。
• DIP (direct IP) ：业务服务所在机器的 IP。

2.2 控制面

控制面基于开源框架 kglb[2] 结合边缘网络特点做的改造和开发，其核心为生成和维护供数据面使用的转发表。为了保证转发表的数据的正确性、实时性、高效性，控制面使用以下几个功能和模块更新信息：

• 服务发现、管理

Ni 控制面需要维护同集群边缘节点的所有服务器信息 (VIP，DIP，Hostname，运营商，权重等)，以及需要感知当前边缘机房内机器或者服务的状态变化，如标记为下线的机器不再接受新的连接请求，但是需要维护当前已经建立的连接直至其主动断开；

• 健康检查

处于异常状态的服务在确认其不可用后应该尽快从转发表中删除，避免影响范围扩大。因此机房内需要有服务器级别的健康状态检查。目前 Ni 提供多种协议类型的健康检查方式，如 Http、Tcp 等。以下为 Http 健康检查的相关配置字段：

{
    "checker": {
        "http": {
            "scheme": "http",
            "uri": "/",
            "check_port": 9080,
            "codes": [
                200
            ]
        }
    },
    "fall_count": 2,
    "interval_ms": 2000,
    "rise_count": 2
}