小红书近线服务统一调度平台建设实践
随着公司的发展，技术架构逐步演进为在线、近线、离线三位一体架构。近线服务介于在线和离线之间，一般采用异步计算的方式，并不要求立即返回结果，但是计算的执行却和在线服务类似。容器架构团队设计了一套基于容器的近线服务统一调度平台，支持数十万核近线服务接近0计算成本运行。
以下内容，整理自 SACC 2022中国系统架构师大会上的演讲：
本期分享嘉宾是小红书基础架构部容器架构负责人高会军，他本次的分享侧重于近线服务统一调度平台 从0到1的建设实践之路的思考，其要点是关于整体解决方案，以及服务资源保障模型和落地的典型案例。
分享概要：
一、为什么要建设一个近线服务统一调度平台
二、整体解决方案和架构剖析
三、收益
四、未来规划
为何要建设一个近线服务统一调度平台
1、了解何为近线服务
在2013年 Netflix 公布了自己推荐系统的架构，首次将计算分为在线、近线和离线三种类型。
对于推荐系统来说，在线计算需要快速响应事件并且使用最新的数据。在线计算在可用性和响应时间上都有较高的SLA要求，通常来说在线计算依赖的数据源也是需要在线提供的。
离线计算允许在算法方法中有更多选择，例如复杂的算法，并且对使用的数据量的限制更少。比如定期汇总数百万电影播放事件的统计数据，以计算 baseline 的流行度指标。
近线计算可以看做前两种模式的折中。近线计算的执行与在线情况完全相同。但是，取消了在计算结果后立即提供结果的要求，而是可以存储它们，从而使其成为异步的。
其实延展到所有的计算场景中，根据不同的服务特征（主要是对响应延迟的敏感程序），都可以将计算服务分为在线、近线和离线。从资源侧来看，不同类型的服务对于计算资源的保障能力要求是不同的。
2、近线服务现状和存在的问题
在建设近线服务统一调度平台之前，我们梳理了所有近线服务的实际情况，发现主要存在的问题，有以下几点：
- 成本不是最优：没有将计算服务按照服务特征进行服务分级，导致近线服务和在线服务一样使用保障能力最高的算力资源，进而成本上不是最优的。
- 缺乏统一的调度入口：不同的团队各自为战，出于稳定性和弹性的考虑，导致每个集群都冗余一定量的闲置资源。缺乏一个近线服务统一调度入口，无法站在整个公司的视角管理资源。
3、为何要建设一个近线服务统一调度平台？
在整个互联网行业的整体形式不乐观的背景下，降本增效成为所有公司的必须要做的事情。此外小红书自身业务的快速蓬勃发展，对计算资源的需求成倍的增长。如何以最少的资源支撑更多的业务，是小红书云原生团队不得不思考的一个问题，也是义无反顾需要承担的责任。
结合近线服务存在的问题，建设一个近线服务统一调度平台 是降本增效行之有效的路径。
近线服务统一调度平台，站在整个公司计算资源的视角，统一管理和调度所有的近线服务。并且提供差异化的云原生能力，在降低成本的同时，增强近线服务的容错能力。
整体解决方案和架构剖析
1、算力来源和服务QoS资源保障模型
对于算力，小红书按照算力生命周期、资源成本、普适性三个维度，对不同算力（独占资源池机器、buffer池闲置资源、潮汐分时算力、混部算力、公有云容器实例）进行打分。
对于服务，我们目前将服务划分为强隔离要求在线服务、普通在线服务、近线服务、离线服务4个QoS级别。
服务 QoS 资源保障模型，本质上就是按照服务的 QoS 级别，给予不同的算力保障。
对于近线服务，调度优先级为：独占资源池机器 > 在线集群闲置算力 > 混部算力 > 公有云容器实例服务。目前公有云容器实例服务，只是作为一种特殊场景的资源兜底算力。
2、整体架构
近线服务统一调度平台架构如下图所示，整体包括三部分，自上而下分别为运维面、控制面、负载面。接下来，我逐一展开说下。
- 运维面，即近线服务统一部署平台（内部代号：RedCloud），用户无需感知 k8s 相关知识和底层资源，一键部署业务。
- 控制面，包含元数据管理集群，核心组件包括调度器（包含统一资源视图）、弹性控制器、Virtual Kubelet （简称VK）等。
- 负载面，由多个在线工作负载集群组成。核心组件包括二次调度器。
通常场景，控制面集群，不会运行真正的工作负载。控制面和负载面集群通过 VK 连接。
在介绍整体架构后，接下来着重介绍一下核心组件和核心能力。
1）近线服务统一部署平台
近线服务统一部署平台，作为所有近线服务的统一入口。抽象了近线服务的应用模型和可视化云原生支持能力，将可用、可伸缩等需求交由基础设施实现，使用户仅需关注业务逻辑 而无需关注具体部署和运行，极大地提高了应用开发效率。
同时提供了发布管控能力，支持多种服务升级灰度策略，比如分批次发布和多机房灰度等，并且对接了内部的风险变更平台，最大程度上保证了近线服务的稳定性。
2）VK
VK 是一个开源的 k8s kubelet 实现，它将自己伪装成一个 kubelet，将 pod 资源转换为其他形式的资源，供 k8s 集群使用。
在小红书内部已对开源的 VK，做了大量的特性增强和 bug 修复，相关优化均已贡献给社区。另外，使用 VK 作为联通多个集群的管道，实现了多个集群之间资源互联互通。
近线服务下发到控制面元数据集群的 Pod，需要 VK 在中间做一层转换 才能映射到在线集群，因为在线集群在资源、标签、namespace 等方面的差异，需要属性转换才能运行到在线集群。
同时负责可用资源的计算，通过资源视图模块计算可以实际分配的套餐资源。
3）调度
调度是整个平台的核心部分，相当于大脑。调度需要考虑成本、稳定性、部署速度等因素。
在上面讲到的近线服务对于不同算力的调度优先级，主要依靠 RedScheduler 优先级和抢占两个策略实现。
同时部署在负载面在线集群的二次调度器，主要负责近线服务实例的退场工作。比如当在线业务实例存在 pending 的时候，二次调度器需要在2分钟内将近线实例驱逐，最终将资源归还给在线服务。
4）弹性
弹性作为云原生的核心能力，主要体现在增强服务的按需使用能力和故障容错能力。 按需使用，意味着对成本优化。故障容错能力，意味着可以提升服务面对流量高峰的处理能力。
目前支持多种弹性策略，包括 1）cpu 和 mem 等资源指标；2）cron 定时；3）基于业务自定义指标，比如 qps 或事件堆积数；4）智能 HPA。通过算法预测未来的流量洪峰提前扩容，避免扩容不及时导致的雪崩和服务稳定性故障。
由于同一个近线服务实例会被分发到多个集群，所以自研了联邦HPA控制器，支持多集群场景。
对于近线服务，弹性也是实现近线计算实例在不同算力资源流转的前提。
收益
截止目前，小红书近线服务统一调度平台已经覆盖了全部的近线服务和部分离线服务。目前实现了近 10wc+ 的近线服务 0 计算成本运行的目标。同时，也提升了近线服务的处理能力。
此外，沉淀了上述的服务QoS资源保障模型，并基于该调度模型建设了小红书三级调度体系。该体系在未来整个提升计算资源效能中发挥重要的作用。
（一）一级调度体系，主要是策略调度。 策略调度实现了服务QoS资源保障模型，按照服务的QoS级别，给予不同的算力保障。
（二）二级调度体系，集群调度。集群调度也是小红书建设的多集群 k8s 管理系统的核心模块。通过用户输入的调度需求、统一的全局资源视图，根据不同的调度策略产生对应的集群调度结果，满足不同应用对于跨集群调度的需求。目前我们的二级调度器支持的调度策略包括：
- 强指定类型，用户直接指定目标集群以及副本分布；
- 资源优先（单集群模式），优先将应用分发至资源最充足的单个集群；
- 资源优先（多集群模式），按资源余量，将应用分发至多个符合条件的候选集群；
- 节点优先，将应用优先分发至符合条件节点最多的候选集群；
- 均分模式，将应用同步分发至符合条件的所有集群。
（三）节点调度。主要用于集群内节点调度。主要包含了red-scheduler 和 descheduler。其中red-scheduler，基于原生 k8s 调度器，增加了基于真实负载感知调度，抢占等策略。
未来规划
未来小红书需要统一在离线调度器，在调度层融合现在的在线服务以及支持剩余的离线服务，最终支持在线、近线、离线三位一体超融合场景，从而建设一个具备全局最优资源效率，能够统一管理底层资源的调度平台。
本期分享嘉宾
高会军
小红书 基础架构部容器架构负责人
【嘉宾介绍】9年互联网后端开发和架构设计经验，在Kubernetes、网关、可观察性、服务网格、DevOps等方向有一定的实践经验。目前在小红书负责云原生技术的推广和落地。
