共计 6736 个字符，预计需要花费 17 分钟才能阅读完成。
前 言
刚刚过来的 2021 年，在寰球经济增长放缓、疫情时起时伏、中美关系摩擦一直、国家平台监管趋严等宏观趋势叠加影响下，很多互联网厂商都遭逢了显著的市值下滑以及亏损加大，裁员音讯时有耳闻，所以在 2022 年，降本增效无疑将进一步成为业界大势所趋。
在放弃业务状态和投入不变的前提下，降本增效一个不言而喻的办法是晋升现有资源利用率，而造成资源利用率不高的起因次要有如下几个：
粗放的资源评估：研发更关注如何疾速稳固的迭代产品需要，所以在服务部署时，个别依照最大流量来预计服务所需资源。但在线服务大都具备显著的潮汐特色，导致大部分时间段资源利用率都很低（10% 以下）从而造成节约。
集群资源整合度不高：服务器的资源占用经常出现非均衡状态，例如在线服务尤其是调用主链路上的扇出节点业务，高峰期往往呈现出 CPU 和带宽吃紧，但内存入不敷出的状况。这导致尽管内存有冗余，但仍然无奈聚合等比例的其它闲置资源去造成有意义的计算实体。
业务部署隔离：因为东西部机房老本差别较大和以及容量布局等问题，很多企业会将在线机房、离线机房齐全隔离开，这样不同 AZ 甚至不同地区间的在离线作业齐全无奈交融，资源池也无奈互通流转。
而在离线混部技术作为晋升资源利用率、降低成本的无效计划，受到业界的统一认可和举荐。
什么是在离线混部
企业的 IT 环境通常运行两大类过程，一类是在线服务，一类是离线作业。
在线服务：运行工夫长，服务流量及资源利用率有潮汐特色，时延敏感，对服务 SLA 要求极高，如音讯流 Feed 服务、电商交易服务等。
离线作业：运行工夫分区间，运行期间资源利用率较高，时延不敏感，容错率高，中断个别容许重运行，如 Hadoop 生态下的 MapReduce、Spark 作业。
因为在线服务资源利用率有更显著的的起伏特色，所以混部的次要场景是通过填充离线作业把在线服务各个时段的闲暇资源利用起来，缩小企业一劳永逸的老本开销。(注：离在线混部打算另文论述)
图 1 混部示意图
在离线混部的老本价值
为了更形象的理解在离线混部的老本价值，咱们来看一个中小型企业，4 核 8G 的机器一共有 1000 台，次要计算资源就是 4000 核，8000G。假如均匀每台机器的资源使用率是 10%，那么理论应用的计算资源是 400010% = 400 核，800010% = 800G。如果咱们能通过混部将资源利用率晋升到 20%，那么咱们只须要 500 台机器即可。假如 CPU 的平均价格是 300 元 / 核 / 年，内存的平均价格是 180 元 /G/ 年，就能够节俭 2000300 + 4000 180 = 132w 元 / 年。
由此可见，在离线混部的老本价值是清晰可计算且收益微小的。
业界实际来看，谷歌利用混部技术将资源利用率从 10% 晋升到 60%，每年节俭上亿美金。阿里等大厂也胜利借助混部将资源利用率晋升了 3 倍以上，老本节俭可观。
在离线混部的技术门槛
在离线混部尽管有显著的老本价值，但目前真正落地到生产环境的还是只有头部的一些大厂。究其原因，次要是在离线混部波及服务观测、调度部署、容灾治理等多方面底层技术难题，甚至还包含组织成本核算、跨部门协同等非技术问题，有较高的施行门槛。总结起来，大抵有以下几大挑战：
可观测性体系
可观测性简略来说是通过查看零碎输入来掂量零碎外部状态的能⼒。从具体输入项来看，个别包含 metric、trace、log 三种形式，是零碎衰弱运行的基石。在离线混部要谋求更高的资源利用率，必然须要借助实时指标的反馈做出决策。然而可观测性在分布式及云原生时代，遇到了以下阻碍:
云原生的体系，决定了服务能力和服务规模随时都在动静调整，所以端上数据收集、传输的老本大大增加，极其状况下甚至对服务自身性能造成侵扰。
可观测性输入要造成决策意义，须要基于一些维度进行归并、拟合、建模等操作，包含应用决策树到 AI 学习等一系列剖析动作。在大服务体量和实时变动的背景下，可观测性输入的剖析时延、准确性都面临很大挑战。
可观测性的可视化以及延展关联剖析 (BI 报表等)，须要依据业务状态和需要进行深度定制，复杂性较高，不足间接能用的工具和伎俩。
调度决策
在离线混部的调度决策是决定混部成果的外围，目前次要有几种决策形式：
整机分时复用：在固定的工夫点 (比方凌晨当前) 跑离线作业，白天让出资源给在线服务。这种以工夫维度切分的混部形式比较简单易了解，但整体资源利用率晋升无限。
资源局部共享：将单机的资源整体划分为在线资源、离线资源以及在离线共享资源，各资源之间隔离，提前划分预留。这种从单机资源维度切分的混部形式比分时复用绝对更精密一些，然而须要资源规格较大的机器切分才有意义。
资源齐全共享：通过及时精确的资源预测伎俩、疾速响应资源变动的能力，以及一套能够在资源水位发生变化时的服务保障措施，更高效自动化地实现机器资源复用。资源归属不预设，齐全根据实时指标决策。
前一种属于动态决策，相对来说对底层可观测性体系的要求、对调度零碎的高可用高性能的要求较低。后两种属于动静决策，在资源利用率的晋升上比动态决策更优，但对前述撑持零碎要求也更高。
调度执行
因为在线服务和离线作业工作模式的差别，往往须要采纳不同的调度器进行调度（比方 K8s 和 Yarn）。混部场景下，在线调度器和离线调度器同时部署在集群中，当资源比拟缓和的时候，调度器会产生资源抵触，只能重试，此时调度器的吞吐量和调度性能会受到较大影响，最终影响调度的 SLA。同时，对于大规模批量调度场景，原生的 K8s 只反对在线服务的调度，从而带来革新老本。
资源隔离
容器的实质是一个受限制的过程，过程之间通过 namespace 做隔离，cgroups 做资源限度。在云原生时代，大部分业务资源都是基于容器来隔离和限度，然而在资源超售叠加混部场景下，CPU、内存等方面仍然可能存在争抢。
例如在 CPU 方面，为了保障在线服务稳定性，广泛做法是进行绑核，将在线服务绑定在某个逻辑外围上防止其余业务占用。然而绑核对于有并行计算要求的服务并不敌对，核数间接决定并行效率。
在内存方面，离线作业往往会读取大量文件数据，导致操作系统会做 page cache，而原生操作系统对 page cache 的治理是全局的，不是容器维度的。
工作抵触时的资源保障
在线服务和离线作业属于不同的工作类型，将这两种负载部署在同一个节点上，会呈现资源烦扰，当资源缓和或者流量突发的时候，在线服务在资源应用上会受到离线作业的烦扰。在离线混部最重要的指标，就是在保障在线服务和离线作业的 SLA 的同时，最大限度进步单机资源利用率。
针对在线服务，须要尽量保障其服务在流量顶峰期间与混部之前的指标稳定管制在 5% 之内；
针对离线作业，不能因为优先级不如在线服务，就始终处于饥饿或者频繁驱赶状态，影响离线作业总的运行工夫和 SLA。
服务平行扩缩容能力
将多个业务混部到一台机器或容器，则宕机可能影响十几个甚至几十个服务，这时候就要求服务有平滑且疾速的扩缩容能力，实现分钟级的业务迁徙。尤其是存储类的有状态服务，甚至波及到存算拆散架构的革新，从而带来一系列包含数据一致性、响应延时的问题。
部门墙
在企业外部，机器的产品线个别是固定的，老本和利用率也是依照产品线计算，所以通常状况下机器是不会在不同部门之间自在流转的。引入在离线混部之后，势必须要突破部门墙，对老本和利用率计算有一个能交融能合成的调整，能力精确反映出混部的微小老本价值并继续精细化经营。以下是美团某部门精细化老本经营后的合成图：
图 2 老本指标合成图
业界在离线混部计划解析
计划拆分
通过对目前业界在离线计划计划的剖析，咱们能够形象出在离线混部计划的三个划分维度：
从在离线混部的 隔离类型 上，能够分为独占内核和共享内核，次要取决于混部的服务内核是否独立。如果服务是混部于同一台物理机上，属于共享内核；如分属于不同物理机，则属于独占内核。
从在离线混部的 部署底座 上，能够分为物理机部署和容器部署。
从在离线混部的 调度决策 上，能够分为动态决策和动静决策。判断规范是调度决策所依赖的元素是否依赖运行过程中的实时指标。如是则属于动静决策，反之则属于动态决策。动静决策资源利用率更高，然而要做好突发状况时的资源保障。
这三个维度的组合，目前理论利用中次要是独占内核 + 物理机 + 动态决策、独占内核 + 容器 + 动静决策、共享内核 + 容器 + 动静决策这三种模式。
独占内核 + 物理机 + 动态决策
这种组合属于入门级的在离线混部抉择，比方物理机运行服务且分时整机腾挪。
益处是可能疾速实现在离线混部，播种老本升高的红利。技术门槛上，这种形式躲避了后面说的简单的资源隔离问题，并且调度决策足够清晰，服务部署节奏有明确的预期，整个零碎能够设计得比较简单。
毛病是没有充分发挥出在离线混部的资源利用率后劲，目前次要是一些初创企业在利用。阿里晚期在大促期间，将所有离线作业节点下线换上在线服务，也能够看做这种状态的近似版本。
独占内核 + 容器 + 动静决策
在这种模型下，业务开发人员将服务部署在云原生部署平台，抉择某些指标（大部分随同着流量潮汐个性）来掂量服务负载，平台会依照业务指定规定对服务节点数量扩缩容。当流量低峰期来长期，随着业务节点数量的缩小，在线服务会有大量碎片资源开释，部署平台会整顿碎片资源，将碎片资源化零为整后，以整机的形式将资源租借给离线作业应用。
比拟典型的是字节跳动的计划，架构图如下所示:
图 4 字节跳动在离线混部架构图
字节跳动依靠于 K8s 与业务 quota 做整机腾挪的在离线混部，以集群转让节点的形式进步整体资源利用率，次要实现思路为：
当在线服务的波谷降临后，简直所有服务都会因为弹性缩容而导致正本数升高。从整体上看，集群里节点上的 Pod 会变得十分稠密，集群整体资源部署水位也随之升高。当集群的部署水位低于设置的阈值后，管制面会通过肯定规定选取局部在线节点，将该节点上的 Pod 驱赶到别的节点上，并标记该节点不可调度，最初通过某种机制将该节点加到离线的集群中实现资源的转让。同理，当在线服务的波峰降临后，会产生一个逆向的管制过程，管制面在告诉并确保离线工作撤退后，从新将节点加回到在线集群中设置为可调度状态，实现资源的回收。
字节跳动的计划基于公司本身的业务复杂度，应用自定义 quota 而没有应用 K8s 通用的 hpa；部署形式两阶段混部：白天离线作业机器给在线服务应用，早晨在线服务器转让给离线作业应用；仅反对容器部署，计划并未开源。
由此可见，在独占内核 + 容器 + 动静决策计划中，业务在部署服务的同时制订扩缩容规定，当流量低谷时，平台依照规定缩小服务节点数量，此时在线资源会开释碎片资源。当碎片资源达到阈值，会触发在线到离线的转让逻辑，转让逻辑中首先整合碎片资源，而后将碎片资源整合为物理机，最初将物理机整体租借给离线应用。当流量逐步复原后，会触发在线回收转让资源逻辑，在该逻辑下，会逐步驱赶离线工作，将资源回收。因为在线服务有很强的潮汐个性，能够通过定时定量的形式，比方晚顶峰 19 点 -23 点，将指定数量的离线资源转让给在线服务应用，当 0 点时将转让的资源返还给离线应用。
共享内核 + 容器 + 动静决策
与上述几种计划最大的不同在于，转让的资源规定是动静决策的。在一个大企业中，服务数量数以万计，要求所有在线服务制订扩缩容决策是很难做到的。同时，业务在部署服务时更关注服务稳定性，经常依照最大流量评估资源，这样就导致流量低峰期有大量的资源节约。
比拟典型的是百度、腾讯、快手的计划，这里以腾讯计划为例：
图 4 腾讯 Caelus 零碎架构图
腾讯在离线混部零碎 Caelus 以 K8s 为依靠，在 K8s 节点以容器的形式部署离线工作，实现在线服务节点转让资源给离线作业，反对个性包含：工作定级 / 调度加强 / 资源复用 / 资源画像 / 存算拆散 / 工作避让 / 烦扰检测等。腾讯的计划兼容 Hadoop 生态，但不反对离线作业转让资源给在线服务。该计划在腾讯外部曾经被大规模利用到广告、存储、大数据、机器学习等多个 业务，均匀晋升 30% 资源利用率，节俭了上亿老本。通过混部 Hadoop 类离线作业，大概进步了 60% 的 CPU 使用率。
共享内核 + 容器 + 动静决策的计划有两种资源视角:
在线服务资源视角，看到的是节点资源总体容量，比方以后物理机上总共有 126 核 CPU；
离线作业资源视角，看到的是节点的闲暇负载，比方以后物理机还有 64 核 CPU 是闲暇的；
服务部署时：
在线服务依照资源容量调度服务；
离线作业依照节点负载调度服务；
这类模型施行的难度在于资源隔离，如何防止或升高离线对在线的影响是混部计划是否胜利的要害。各大厂在资源隔离方面都做了很多致力，比方更全面的指标收集、更智能的负载预判、更正当的在线资源冗余度、更精密的 eBPF 等。即便在资源隔离方面做了十分多的致力，还是难以避免共享内核模型中离线对在线的影响，计划中个别都搭配着烦扰探测，当探测到在线服务受到影响时，及时止损。
一种开源在离线混部的疾速实现计划
从上述在离线混部计划的剖析中能够看出，如果有比拟强的研发实力，可能较好解决第三局部中讲到的简直所有技术门槛，就能够挑战共享内核 + 容器 + 动静决策组合的计划，以谋求极致的资源利用率和老本优化成果。如果公司研发团队在底层技术积攒比拟少，想疾速、平安、低成本地用上在离线混部，先享受局部混部的老本优化红利，则 独占内核 + 容器 + 动静决策组合的计划是首选。
联合业界绝大多数企业的理论场景，咱们推出了一套一站式在离线混部计划，由算力调度引擎 BridgX 和智能运维引擎 CudgX 两个外围组件形成，如下图所示：
图 5 一种开源高可用在离线混部计划架构图
BridgX：算力调度引擎，在算力层面为在离线混部提供根底的算力调度能力，包含跨云调度能力、K8s 容器及大规格裸金属服务器切割能力以及疾速弹性伸缩能力。
CudgX：智能运维引擎，为在离线混部提供自动化压测、服务指标度量、容量评估等能力，精准刻画在离线作业的资源应用画像。
整体的工作流程如下：
CudgX 负责收集服务指标，通过配置冗余度规定放弃服务和节点的冗余度。当流量低峰时，CudgX 对服务节点缩容，触发在离线整合模块转让逻辑。当流量顶峰时，CudgX 对服务节点扩容，触发在离线整合模块回收逻辑。
同时 CudgX 还会评估在线资源的冗余度，当在线资源冗余度过低时，CudgX 会触发 K8s 扩容逻辑，借助 BridgX 申请资源，实现在线资源扩容。当资源冗余度回归失常时则将资源退还，保障资源短缺的状况下老本可控。
离线整合模块负责实现转让和回收逻辑，当在离线整合模块发现在线资源有足够多的碎片资源能够回收时，会进行一次碎片资源整顿统计，将碎片资源整合为残缺物理机转让给离线作业应用。当在离线整合模块发现在线资源冗余度有余时，会触发资源回收逻辑，将转让给离线作业的资源回收，实现回收逻辑。
本计划通过内核进行资源隔离，长处是在离线服务彻底拆散，不存在离线作业影响在线服务的可能。
GitHub 链接：
Bridgx：https://github.com/galaxy-fut…
Cudgx：https://github.com/galaxy-fut…
总 结
在离线混部对资源利用率晋升、降低成本都有公认的显著作用，但在离线混部又是一个宏大而简单的工程，波及多个组件以及多个团队的协同单干。在离线混部也是一个继续优化的过程。各家大厂都投入了相当长的工夫钻研才开始放量铺开。咱们冀望通过借鉴业界成熟的混部计划，以云原生低门槛一站式的形式让在离线混部在更多企业落地，帮忙业务解脱老本懊恼，助力企业胜利！
作者介绍：
舒超，目前在星汉将来负责 CTO，负责公司整体研发工作。2010-2015 年在腾讯负责技术专家，负责微博微群、音讯流广告等我的项目；2015-2021 年在美团任根底研发团队负责人及存储核心架构师、资深技术专家，负责美团公司级的云原生服务治理体系研发与演进。
对于星汉将来：
星汉将来（Galaxy-Future）是一家云原生根底引擎提供商，提供三大算力引擎：算力调度引擎 BridgX、数据物流引擎 DTExpress、智能运维引擎 CudgX，基于三大引擎也提供了标准化智能运维产品 SchedulX 和运维可观测产品 ComandX，同时，也为企业提供解决方案和咨询服务，心愿能帮忙企业在上云过程中实现：云应用老本升高 50%-80%，同时，开发效率能晋升 10 倍。
相干产品 GitHub 地址：
算力调度引擎 BridgX：
GitHub 地址：
https://github.com/galaxy-fut…
智能运维引擎 CudgX：
GitHub 地址：
https://github.com/galaxy-fut…
标准化智能运维产品 SchedulX：
GitHub 地址：
https://github.com/galaxy-fut…