一、背景

       陌陌经过十几年的高速发展，衍生出了庞大的技术生态体系，生产服务的资源用量也随之居高不下，我们基于云平台监控数据，对生产服务资源进行盘点盘点，发现 30%生产服务存在资源闲置情况，我们希望建立一套自动化的流程机制，把生产环境上的资源浪费维持在一个合理水位，以最小化成本的方式推进下线操作流程。帮助我们更好地全局掌握资源利用情况，有效避免资源浪费。

二、 用户故事

• 作为技术管理者，希望有一套资源巡检机制，帮助我全局的了解生产服务的资源配给情况

• 作为技术管理者，希望有一套自动化流程机制，对存在资源浪费的服务能自动化的进行 成本洞察->成本优化-> 成本运营，将生产环境上的资源浪费「长期有效」的维持在一个很低水位

• 作为业务负责人，希望在尽量少的改动情况下，对低 QPS、低 cpu、内存占用的服务进行资源合并，降低技术维护成本和机器成本

三、 目标

方案设计目标

在保证业务稳定性的前提下，针对以上问题场景，建立资源成本管理机制：

1. 建立全局资源成本洞察机制 定期（每周）对生产所有服务进行资源用量数据的实时监测。获取进程资源（cpu&内存 &磁盘）的申请用量和实际用量，根据用量合理性规则配置，如 进程实际使用内存量/申请内存量<=40%，分析资源浪费情况，推送资产闲置报表 &用量浪费黑名单。

2. 建立云平台资源自动优化流程 通过用量分析、浪费告警，业务对资源用量进行确认，云平台支持用户提交资源降配或者缩容操作。

3. 低资源用量服务自动合并机制 对低 QPS、低 cpu、内存占用的服务进行资源合并。通过优化资源配给，提高服务整体效率，从而实现降低成本的目的。

借鉴 Finosp 的思想，通过这样周期性的成本巡检优化机制，实现长期有效地减少服务资源用量的浪费，下面会将流程逐个拆解落地。

• 成本洞察（Inform）：提供多维度的成本和资源数据可视化，应用容器和混部场景的成本分摊，产出资源闲置报表。

• 成本优化（Optimize）：提供可靠便利的智能成本优化方案，降低用户实施成本控制的门槛。

• 成本运营（Operate）：从组织，意识以及流程上建设一套系统的成本运营平台。

定义收益关键目标

• 线上服务资源用量减少 20%，服务器成本减少 xx 万

• 线上服务数减少 10%，系统维护成本降低 xx 人天

四、实施方案

方案流程概览

技术架构图

成本可视化和优化评估

• 由监控系统提供应用的资源用量数据，例如容器和物理机的 CPU、内存历史使用率

• 多维度的成本洞察，优化评估

推荐框架

提供了一个可扩展的推荐框架以支持基于历史峰值用量和 K8s 事件的资源分析，支持多种推荐器：资源推荐，副本推荐，HPA 推荐。

基于历史用量的自动 scale

基于云平台的 HPA、VPA 能力底座的弹性控制，在保障服务质量的同时，让降本更加高效

负载感知的调度器

根据实际的节点利用率构建了一个简单但高效的模型，并过滤掉那些负载高的节点来平衡集群。

全局资源配成本洞察

资源用量数据采集

数据来源陌陌统一的监控系统，数据格式：

• 环境    

• 服务类型    

• 近一个月 qpm 峰值    cpu 使用峰值（单位：核数）    

• 内存使用量峰值（单位：GB）    

• 内存申请 Request G    

• 部门    

• 负责人    

• 最近一次发布时间

覆盖服务

覆盖类型：有明确的请求量和 CPU、内存用量等黄金指标

覆盖范围：

• K8s docker 全覆盖

• 必要条件：服务上线时间超过 30 天，不满 30 天的服务将不发送通知。

策略规则

指标：

1.  请求量

2. cpu 利用率

3. 内存利用率

4. Java 服务：使用 Jvm 的 内存 heapSize 和 GC 前堆大小

   非 Java 服务：使用 docker 申请内存和使用内存

资源用量合理性规则配置

建议评估下线：近一个月峰值 QPS 为 0，且 CPU 峰值为<=0.01

建议评估降配：request 内存量/实际内存使用量<=30%，且历史 OOM 告警次数<=0

建议评估缩容：容器内存利用率最近一个月峰值小于 0.03 AND 容器 CPU 抑制率峰值小于 0.01 AND 常驻实例数大于等于 3

资源用量自动优化流程

优化手段：

• 下线退租：即机器无人使用、业务无人接手；

• 弹性降配策略：可以有效缓解业务使用量具有明显的波峰波谷的问题。包括 HPA 水平伸缩，VPA 垂直伸缩。

• 智能资源推荐：可以用于解决资源配置不当的问题。通过分析历史数据，推荐合理的 request 数值，以及副本数。其推荐值可以对 VPA 等对应用进行动态扩缩容带来指导意义。

• 混布：CPU 密集但内存消耗少的服务，可以与内存密集但 CPU 消耗少的服务进行混布，提高资源利用率；

• 迁移：将闲置资源转移给其他业务，变更机器所属服务树，盘活闲置资源。关于闲置率，并非关注节约多少成本，而是关注每种资源都实现其应用价值。

低资源用量服务自动合并技术方案

设计目标：

• 业务尽量小的改动

• 低流量低资源占用的服务合并到一个进程

行业解决方案调研

蚂蚁金融：多 Web 应用进程合并部署

将多个应用进程合并到一个 JVM 进程中，多个应用共用网络容器（netty、Tomcat、jetty）实例，使用不同的类加载器加载不同的 Biz，其中 Master Biz 为 LaunchedURLClassLoader 加载，非 Master Biz 有其专属的 BizClassLoader 加载。对于每个 Web Biz，也会使用其类加载器完成上述原生 web 容器的启动。

两种合并部署模式

流程交互设计

规则管理

• 全局默认规则 （管理员可见）

• 个别服务自定义规则 （弹窗编辑）

用户处理流程

用户接受通知 -> 阅读通知、查看报告 -> 提交工单、审批 -> 查看优化效果

通知详情

• 发送方式：钉钉通知

• 发送周期：每周发送一次

• 发送内容：

  效果：

  【环境】陌陌生产

  【appKey】

  【检测时间】2024-01-11 ~ 2024-01-17

  【内容】 CPU 峰值利用率低于 10%，建议缩容 （ 给出不同类型的建议）

  【业务负责人】XXX

  【报告详情】 wemomo.com/detail/121213

  建议类型：

  CPU 峰值利用率低于 10%，建议降配

  请求量为 0，CPU 峰值利用率低于 0.01，建议下线

  内存峰值利用率低于 40%，建议降配

报告详情

用户在发出的钉钉提醒中点击报告链接，报告包含 服务基本信息，统计周期内指标详情，指标利用率统计描述及优化建议。

治理总览

主要内容：

1. 统计近 1 月服务的利用率

   过滤：appkey、cpu、内存、请求量

2. 各个指标利用率分布饼图

3. 消息处理量统计和工单状态统计

五、 总结

本着自己先吃狗粮的原则，先在本部门内部推广，根据检测结果，共检测出 9%服务存在低利用率问题，这意味着在这些服务中，有一部分资源没有得到充分利用，可能导致效率低下和资源浪费。根据算法推荐值的估算，预期可以获得 6555C 和 31173G 的收益。长效的低利用率洞察机制为未来挖掘了更多的潜在收益。通过优化这些服务的利用率，可以释放出更多的计算和存储资源，提高资源利用效率，并为组织带来更大的经济收益。