OPPO的弹性伸缩实践：框架设计

原创 Jia Zhu 安第斯智能云

背景

近几年，OPPO 构建并不断完善基于 kubernetes 的混合云平台，统一了之前公有云、自有机房裸机部署的方式，积极推动业务迁移上云，使得在简化运维、降低成本等方面取得了一定的成果。但是初尝喜悦之后，我们发现不（ke）合（you）理（hua）的地方：

宏观上看：整个云看起来像个“会跳舞的胖子”，所有的服务单纯堆在云上，显得很臃肿；
微观上看：应对突发、峰谷等状况没有为业务提供很好的弹性手段；

从平台的角度看，要做的就是一件事：“把资源盘活、盘好、盘细”，我们内部把他们分成不同的方向在探索，比如统一算力、智能调度，而我们这里要谈的就是弹性伸缩，希望通过它做到的是节省空余资源，提高分时利用率。

我们从不同的维度，挖掘了OPPO云实际业务的一些配对特征（下图所示）：

按实时性分：

在线业务，实时要求高，不可重试，不太能接受被抢占；
离线业务，可以接受排队，被抢占重试任务即可；

按职能分：

基础设施，包括云上的一些paas产品，或者保护平台基本运作的设施；
对外服务，主要是对外业务的服务；

按部署形态分：

单集群部署，不具备跨集群部署能力的业务；
可用区部署，跨集群业务，但这里想表达的是包括但不限于serverless化；

按状态分：

有状态业务：各种rds、中间件、甚至大数据处理的集群等；
无状态业务：一些高并发服务；

按实现方式分：

传统方式实现：传统技术实现的服务直接上云；
云原生方式实现：operator 化的业务，有些本身实现了k8s scale能力，有些则没有；

其实有很多是具备“逻辑可弹”的属性（即逻辑上可以设置多副本，组成集群或者组的概念），比如“持续部署”是一个 PAAS 产品，他里面的“分组”就是用来管理业务节点副本的，同时又包装了诸多比如rds授权、服务发现、对接监控等能力，我们把持续部署打造为一款弹性资源，那只要接入了持续部署的所有业务，就变成了弹性资源的实例化对象。我们这里希望做的不仅仅是通过“弹性伸缩”解决典型的场景问题，更想要统一的管理和挖掘弹性资源，输出标准。

综上所述，我们打算做个统一管理弹性资源的平台，提供弹性伸缩能力。

原则和选型

▎2.1 原则

在上述背景下，对于弹性平台的设计，我们设立了一些基本原则：

丰富：提供丰富的弹性策略，支持多种触发能力；
安全：伸缩执行时要有严格的兜底管控能力；同时具备详细的观测、审计能力可以追溯；
统一：设定资源弹性化标准，需要弹性化的资源方只需做一些对接，即可自动化接入；
复用：公司内部已经有非常完备的监控、告警、调用链等系统，我们的弹性产品希望能够做良好的集成，把整个产品链起来；
框架：通用能力尽量下沉，同时又具备充分的扩展能力。比如对接公司产品，我们不希望做强耦合，而是通过实现接口将产品能力安置在扩展包中，保留框架的抽象层。

▎2.2 选型

基于 kubernetes 的弹性开源方案并不太多，像原生的 HPA 或者 keda，本质都是利用了 hpa controller 对各种metrics server做轮询。

而又鉴于以下几点，我们觉得 kubernetes 已有的方案并不适合我们：

我们决定自己去实现一款弹性平台，吸收了现有方案的优势，择善而从，在包含了 hpa 能力的同时又增加了一些实用的功能，项目代号为“burrfish”。

设计

本节主要介绍在平台开发中的一些设计理念和架构组件。

▎3.1 理念设计

对于弹性平台的设计：

首先得具备丰富的弹性功能，这是本职工作；
其次我们想要实现的是相对通用的、又能结合公司产品的框架，所以在主流程的关键步骤上都是由抽象的接口层实现，接口层之上又分为标准层和扩展层，对于标准层我们制定协议、结构，让有需要的调用方按照标准接入；对于扩展层，则是我们主动适配对方接口来实现功能，但又因为扩展层的规划，我们在适配时不需要敛手束脚地担心对框架的侵入，用直白的话说，就是“直接拿掉扩展层（蓝色阴影），框架照样可以运行”。

对于弹性资源的设计：

前文提到可以设置多副本、多worker、多成员的对象，其实都具备逻辑可弹性，一般实现来说，即使没有用 kubernetes 里原生的工作负载比如 deployment、statefulset，也会去构造“组”的概念，对组设置副本。而我们则做了个取（chou）巧（xiang），设计了弹性资源的概念，这样我在控制面上不需要关心你用什么去承载多副本，你在我这就是注册的一种弹性资源。
然后我们在弹性资源的设计上严格遵守框架的理念，推出资源弹性化标准。其中弹性化标准层是让弹性资源方来适配框架，而http接口标准则是为了让传统服务更简单的接入框架；弹性化扩展层则是框架去主动适配某一种弹性资源。

进一步的，我们把公司的多个 PAAS 产品对接成了弹性资源。这种多样化的对接方式是有必要的，同时我们又想让这个过程变得平滑，不强求资源方为了接入弹性框架，而让他们按照统一云原生的方式改造自己。

梳理完思路后，我们提出了一个分层构想：

▎3.2 架构设计

如下图所示，我们架构包括5个组件，guarder、trigger、scaler、hooker、tracer。其中：

guarder：守卫模块，职能包括：

保存弹性策略完整的伸缩配置；
根据触发器的不同类型，决定是否要到指标源进行必要注册；
管理策略的状态，只有正常的且打开的才能顺利流转；

trigger：触发器模块，他是一类可以扩展的组件。只要实现了逻辑语义“拿到一个指标，格式化发给后续组件”都可以认为是触发器，即使有业务逻辑比较重的触发规则，也可以归类到扩展层中。它的分类如下：

定时触发：基本需求；
k8s metrics server：主要就是一些开源的指标采集方式，可以无缝支持，但实际对我们来说不是很用得上；
云监控告警：绝大部分策略采用的触发方式。我们有完备的监控体系，他集成了系统负载（cpu/memory等）、消息中间件、rds、log日志、自定义业务指标等监控，它同时支持轮询（分钟级）、流式（秒级）告警，所以我们并不需要造太多的触发器轮子；
sidecar触发：这是 FAAS 对接衍生出的一种触发方式，可以满足其需求；