美团弹性伸缩系统的技术演进与落地实践

• 前言

• 一、弹性伸缩系统演进

• 二、挑战与应对之策

• 2.1 技术挑战

• 2.2 推广思路

• 2.3 运营难题

• 三、业务赋能场景

• 3.1 节假日扩缩容

• 3.2 日常高峰期扩容

• 3.3 应急资源保障

• 3.4 服务链路扩缩容

• 四、弹性伸缩未来规划

• 作者简介

• 招聘信息

前言

稳定、高效、可靠的基础设施是互联网企业应对业务高峰流量的底层基石。作为美团统一的基础技术平台，基础技术部一直致力于通过业内前沿技术的落地，保障公司内部所有业务在线生产系统所依赖的基础技术平台能稳定、安全、低成本、可持续地运行与发展。

弹性伸缩系统是基于Docker开发的自动弹性伸缩平台，在美团经历了多年的发展。

早在2016年，美团就在线上环境中尝试使用容器环境，推出了基于OpenStack的容器集群平台Hulk 1.0。随着容器的落地，弹性伸缩1.0版本应运而生，它解决了扩容实例慢、扩容上线慢、资源回收慢、计算资源冗余等问题。

结合前两年的探索和实践以及业界相关领域技术的成熟度，2018年至今，我们对容器集群平台进行了一次自底向上的的整体升级，也就是现在的Hulk 2.0平台。在底层，Hulk 2.0建设了自研的操作系统、容器引擎，并将OpenStack替换成了容器编排的事实标准Kubernetes；在上层弹性伸缩系统PaaS层面，推出了弹性伸缩系统2.0，解决了弹性伸缩1.0实践过程中面临的很多业务痛点，包括：

• 扩出的业务代码版本不一致：导致业务逻辑异常，造成资损。
• 部分服务高峰期资源不足：导致业务无法有效承载流量，引起资损，
• 平台维护成本高：北京、上海的业务各自一套弹性伸缩用户端管理平台、弹性逻辑（因为美团、大众点评合并前期，服务治理框架、CMDB系统、发布系统尚未标准化）。
• 配置使用灵活性低：业务集群每增/减一个IDC均需在平台做相匹配的配置操作，在资源的调控上无法和公司的流量调度体系包括单元化架构、同地域、同中心调用有效地进行匹配。

一、弹性伸缩系统演进

弹性伸缩1.0架构

我们首先看一下，产品演进路线和弹性伸缩1.0架构图。

产品演进路线

自左向右、自上而下进行模块介绍：

• 用户端Portal：OCTO管理端，OCTO是美团服务治理平台，出于北京业务操作服务节点习惯的考虑，在其上开发了对应的弹性伸缩管理页面；TTT管理端，TTT是上海侧（原大众点评侧）的CMDB管理平台，出于上海侧业务操作服务节点习惯的考虑，我们在其上开发了对应的弹性伸缩管理页面。
• Hulk-ApiServer：Hulk 1.0容器平台的网关服务。
• Hulk-Policy：弹性伸缩系统1.0的业务逻辑模块，其中涵盖了具体的指标聚合、扩缩容逻辑、策略等，主从架构模式，使用Zookeeper进行Master选举，从是冷备。
• Hulk数据源：OCTO，美团服务治理平台；CAT，美团服务端、移动端监控平台，主要负责应用层面；Falcon，基于开源Falcon定制化的系统监控平台，主要负责机器层面。
• Scheduler：Hulk 1.0容器平台的调度系统，基于OpenStack做了二次开发。

弹性伸缩2.0架构

弹性伸缩系统2.0主要在以下四个方面进行了架构演进：

1）调度系统-替换：将OpenStack替换成了容器编排的事实标准Kubernetes，并且在常驻资源池的基础上，新托管了专区资源池以及应急资源池。 

2）单体服务-微服务化。

a. API-Server：弹性伸缩-网关服务。

b. Engine：弹性伸缩-引擎，负责各服务实例扩缩的发起、终止，主从架构模式，使用Zookeeper进行Master选举，从是热备。

c. Metrics-Server、Metrics-Data：【新增】弹性伸缩指标服务，负责Raptor、OCTO等数据源的采集&聚合。

d. Resource-Server：【新增】弹性伸缩-库存管控服务，为各服务自动扩缩的资源需求保驾护航。 

3）服务画像-数据平台化：Portrait-Server、Portrait-Data，弹性伸缩系统内部自建的服务画像数据体系。 

4）可观测性：【新增】Alarm、Scanner，负责弹性伸缩的监控告警、运营治理等工作。

二、挑战与应对之策

在介绍前，有必要重点说明下2018年这个时间节点。如前言中所述，2018年以前弹性伸缩1.0这个PaaS平台存在的一些问题，以及整体Hulk 1.0容器平台落地过程中遇到的一些问题，在产品战略上我们提出了Hulk 2.0的计划，它涵盖调度系统、容器引擎、内核隔离增强、弹性伸缩增强等领域；在战术上，遵循自顶向下的设计原则、自底向上的实施原则。

在2018年4月前比较长的一段时间内，Hulk容器平台的研发主要聚焦在底层系统的升级上（优先打通Hulk 2.0容器编排Kubernetes、容器创建/销毁的流程），在弹性伸缩PaaS平台的投入约为0.5个人力，增量业务停止接入，存量业务继续维护。在Hulk 2.0底层系统基本成型后，容器平台团队一方面开始着手将未接入弹性伸缩平台的Hulk 1.0容器平滑迁移至Hulk 2.0容器。另外一方面，开始着手组建人力建设可对接Hulk 2.0容器平台编排能力的弹性伸缩2.0系统，为已接入弹性伸缩平台的Hulk 1.0容器平滑迁移过来做技术储备。

在弹性伸缩2.0系统的演进过程中遵循“技术”、“推广”、“运营”的演进策略。我们可以先来看下在搭建平台的过程中面临的一些挑战以及解法。

2.1 技术挑战

结合当下弹性伸缩系统面临的处境，并对业界弹性伸缩产品做过一番调研后，在平台搭建上确定了如下三期目标：

• 一期目标：弹性伸缩2.0系统MVP版本，简单来说是把底层OpenStack相关生态更换成Kubernetes周边生态，上层功能先维持不变。
• 二期目标：业务上，找同部门业务先行试点，基于反馈，小步快跑，快速迭代；技术上，对北京、上海服务治理平台，CMDB系统等相关业务逻辑进行融合。
• 三期目标：1.0系统的用户端融合为一套，减少业务侧的理解成本、研发侧的开发/维护成本。

在上述三期目标基本落地后，弹性伸缩2.0系统基本可以跑起来，处于一个不比弹性伸缩1.0系统差的阶段，接下来基于过往运维问题汇总以及业务访谈诉求，在后端架构上做了几个比较大的升级。

2.1.1 弹性调度

正如前言所述，和大部分弹性伸缩产品类似，早期启用弹性伸缩的过程如下：

• 创建弹性分组：弹性分组是弹性伸缩管理的基本单元，弹性分组用来管理同质化的业务实例，在美团的实践中，主要是同一个IDC中的实例。
• 创建弹性伸缩配置：用于确定扩容出来的弹性伸缩实例的机型配置，比如：CPU、内存、硬盘大小等。
• 创建弹性伸缩规则：具体来讲就是扩容几台、缩容几台。
• 创建弹性伸缩任务：监控任务、定时任务。

在美团的落地场景中，我们遇到如下问题：

• 该扩未扩，业务集群新部署一个IDC的实例时，不容易联想到需要给这个IDC实例创建弹性分组，导致的问题是高峰期其他IDC可正常扩容，这个IDC无法正常扩容。
• 不该扩却扩，业务集群不再使用某个IDC后，未联想到需要关停这个弹性分组，导致的问题是一些定时任务依旧扩容出这个IDC的实例，部分情况下会引发业务异常。
• IDC视角的扩缩局限性，未站在“上帝视角”做扩缩容决策，会导致部分IDC资源紧缺时，比较难以Fail-Fast。
• 业务在不同IDC的业务逻辑不一致，部分业务把具体的策略耦合在业务逻辑中，一个业务集群使用一套镜像弹性扩容，会引发业务异常。

基于以上种种原因，我们拉通了各PaaS方，梳理了流量分组、弹性分组、发布分组之间的关系，以保证弹性伸缩在美团私有云中的扩容准确性。

• 流量分组：划分来源于美团服务治理平台-OCTO、SET化平台-大禹，比如这个服务走的是SET化方式（类业界单元化架构），那么每一个SET就是一个流量分组；依次类推，设置的是无差别调用方式，那么全局就是一个流量分组；设置的是同地域（Region）调用方式，那么每个Region就是一个流量分组；设置的是同中心调用方式，那么每个中心就是一个流量分组；设置的是同IDC优先调用方式，那么每个IDC就是一个流量分组。
• 弹性分组：无需手动划分，一个流量分组就对应一个弹性分组，直接Mapping创建即可。
• 发布分组：划分来源于美团发布平台-Plus，对于未采用SET化架构的业务集群，则仅有一个Default-发布分组；针对采用SET化架构的集群，每个SET对应一个SET-发布分组，它们的代码/镜像可以不一样；基于同一个SET下又可能有多个地域、多个中心、多个IDC（目前美团的SET化架构以同IDC调用为主），所以和流量分组之间是1对N的关系。

同地域访问的方式比较有代表性，这里对同地域调用&未SET化、同地域调用&SET化的业务集群自动扩容方式进行展开说明，其他组合可依次类推。

2.1.2 库存管控

弹性伸缩系统如果只是单纯地提供一个IaaS资源的自动供给能力，这件事情并不难。然而实际情况下，弹性伸缩系统在落地过程中需要解决资源上面临的问题。

• 业务关注点：资源如何保障？过往在弹性伸缩系统1.0遇到过多次扩不出资源的情况。
• 组织关注点：弹性资源池该划分为多大合适？如果储备大量的资源，却无法较好的进行分时复用，作为PaaS平台本身会造成资源闲置。

针对业务的这个关注点，目前业界公有云厂商的做法基本是不做SLA承诺或者说很难做到SLA承诺，因此也自然不会面临到组织的关注点问题。具体来说，在美团主要是通过以下几个措施来解决。

2.1.2.1 多租户管理

平台给到每个业务线的资源并非无限，会给每个业务集群的弹性分组，设置一个默认的资源Quota。如果业务觉得默认Quota不够，可通过工单的方式进行一轮评估调整（从实践来看，绝大部分情况无需调整）。针对这个资源Quota，平台侧承诺的SLA：99.9%的扩容成功率。

这里会有个问题：是不是给业务Quota后，这部分资源就直接划分给这个业务独占了？答案：不是的。这只是一个逻辑上的划分，资源本身是各业务混用的，平台需控制资源闲置率，本身会做些“超售”，但过程中需解决好“超售”可能面临的问题，这就是水位线监管机制。

2.1.2.2 常态-资源保障

常规-资源保障，指的是平日、小节假日下的资源供给机制，这部分的资源来源于常驻资源池（架构图所示），平台会对已接入平台的所有服务，进行小时粒度的资源重预估。具体示意图如下：

新增/更新服务的伸缩任务、伸缩规则时，会对当前变更对整体资源池水位的影响进行预估，如果在叠加时间点将超过整体资源池的水位，平台会拒绝执行变更操作，并给到用户和平台管理员消息推送，用户可通过工单方式进行资源请求说明（需保障存量服务的资源可靠性）。

2.1.2.3 应急-资源保障

常驻资源池的大小是有限的，应急-资源保障指的是业务拉新、大促、大节假日等非常态的资源供给机制，这部分的资源来源于常驻资源池+应急资源池（如架构图所示）。应急资源池简单来说就是，我们按用量计费模式购买的公有云资源，这是一种更灵活的资源池模式（具备一定的租约）。在此基础上，我们构建了更省成本的混合云弹性调度能力（在此之前仅在私有云的常驻资源池调度）。

• 弹性扩容：常驻资源池实例优先占用，应急资源池实例次之。
• 弹性缩容：应急资源池实例先缩容，常驻资源池实例次之。

以下示意图展示的是一个服务在大促期间（维持T天）需要208台容器实例，其中8台为常态下的资源诉求，200台为应急资源诉求。

大促前：

大促后（T+1）：

T+1天后，这些应急资源池将被腾退回公有云厂商，公司无需为后续继续付费。多业务都应急的场景其实会偏复杂些；特殊情况下，需要采用重调度、治理。

2.2 推广思路

在2020年之前，是弹性伸缩2.0系统的练内功阶段，并未大规模向业务推广Hulk 2.0弹性伸缩系统，主要原因归结为两方面：

• 公司还处在从虚拟机、Hulk 1.0容器迁移至Hulk 2.0容器阶段，Hulk 2.0容器实例还处于打磨以及逐步赢得业务信任的过程中，推广弹性弹性伸缩2.0系统，容器化是第一步。
• Hulk 2.0系统在基础功能上不足以满足相对复杂的业务场景，比如SET化架构的业务。

截止2020年年底，共接入了约500个服务。这里主要以弹性伸缩1.0系统中平滑迁移过来的服务，同部门的服务（Eat Your Own Dog Food）为主。

在2020年-2021年，是弹性伸缩2.0系统的规模化阶段。

• 数据驱动：从数万个服务中，通过自建的服务画像数据体系挖掘出数千个美团适合接入弹性伸缩的服务，主要是参考高低峰、是否有状态、实例配置、业务集群规模等因素，并将其下钻到各业务部门，共建设30+运营大盘，锁定了平台侧希望去赋能的业务群体。
• 价值量化：这里面经历了一些认知迭代的过程，最后提炼出来主要是三方面：“应突发”、“省成本”、“自动化”。
• 深入业务：在前面500多个服务相对比较稳定之后，大概花了两三个月，和美团的各个业务线负责人去聊，主要围绕业务介绍（只有了解它，才有可能为它赋能），弹性伸缩价值介绍（横向拉通其他业务的最佳实践），业务今年的OKR是哪几块（评估弹性伸缩三方面的价值是否可以帮助业务更好的达成业绩、合作共赢），一起讨论当前业务接入后可能看到的收益。
• 技术培训：根据前期深入业务，获得的反馈。业务比较关注技术原理、接入成本、系统健壮性、最佳实践、有哪些潜在的坑。团队同学把这些进行了提炼总结，输出了弹性伸缩白皮书（技术原理、FAQ手册、最佳实践等）、避坑指南，并在有需要的业务部门进行VIP式的技术分享，一次不够、可以来两次，大大小小的业务团队、公司级的分享，我们做了十几二十次。
• 渠道闭环：公司层面上要做一些大促活动，如“安心复苏计划”、“517吃货节”、“1001夜直播”，这些活动只要我们知道了，我们就主动加入进去看看能帮助哪些，从结果来看，效果还是挺好的。我们还在公司的COE系统（故障复盘分析工具）去搜“负载”、“秒杀”、“暴涨”、“扩容”之类的关键字，学习问题的处理过程以及待办事项，评估后发现能帮上的，我们就主动联系业务去沟通。
• 业务回访：虽然我们会在技术支持群内会做答疑，且每周会进行值班问题的汇总Review，但相对来说会偏零散些。我们开始是采用问卷调查的方式去获取反馈，但是践行下来效果比较一般。因此，我们还是采用比较原始的方式——“促膝长谈”，我们主动从业务侧去拉取接入后遇到的问题，在评估优先级后快速迭代系统本身。

经过以上这些工作，我们80%+的服务接入了弹性，覆盖了公司90%+的业务线。回到那句话，如果弹性伸缩系统只是单纯地提供一个IaaS资源的自动供给能力，这件事情并不难，而我们的定位是PaaS平台。

2.3 运营难题

这部分主要介绍向业务交付弹性容器实例后，碰到的三类典型问题：配置、启动、性能。这些问题大部分不是弹性伸缩2.0这个PaaS平台本身领域内可直接闭环解决的事项，这往往取决于各PaaS平台是否已全量标准化、业务自身逻辑、以及基础设施层性能等因素，催化我们多去做这一步的原因只有一个：弹性扩容出的实例只有很好的帮助业务分担负载，才可真正帮助业务解决问题。

2.3.1 配置问题

2.3.2 启动问题

启动问题，大部分解决的是容器的这种开箱即用方式所面临的问题，而非过往的采用先申请机器、再在这上面发布代码包的方式。而且这里面会经常要面临着业务的质疑，为什么我手动发布的时候不存在这个问题，采用弹性扩容就出现了？

2.3.3 性能问题

生产环境中，业务容器的性能问题其实是比较复杂的，可能涉及到重IO容器影响、宿主机Load过高、多个容器突发占用CPU过高导致影响某个业务容器问题。相对于不使用弹性时囤积算力的稳定场景，弹性扩缩容场景中，因对资源的频繁调配会更容易遇到资源性能的问题。为了保障使用效果，Hulk项目组主要从三个角度对性能问题完整解决：

• 事前：服务粒度配置个性化调度策略。
• 事中：基于服务画像数据平台提供服务时序特征、宿主机时序特征，建设多维度资源打散能力的调度算法。
• 事后：针对存量Node上的重IO、重CPU等容器进行重调度。

三、业务赋能场景

3.1 节假日扩缩容

业务场景：有着明显的“七节二月”特性，就流量而言周末是工作日的1.5倍左右，节假日流量是周末的3~5倍左右。服务机器基本上是按照节假日的流量部署，平时机器使用率很低。

如何使用弹性伸缩：

• 接入弹性伸缩定时任务，节假日期间弹性扩容，应对节假日流量高峰；非节假日高峰，弹性缩容，减少服务器资源开销。
• 任务配置示例：节前配置定时任务扩容；节后配置定时任务缩容；监控扩容任务作为托底。

接入效果：业务侧平均节约成本20.4%。

3.2 日常高峰期扩容

业务场景：配送是外卖服务的下游，具有明显的午高峰特性。

如何使用弹性伸缩：

• 设置定时任务：在午高峰来临前扩容出足量的机器，在午高峰结束后缩掉富余的机器，如示例，分组【global - banner-east - 无swimlane】绑定了2个定时任务，每天09:55扩容125台机器；每天14:00缩容125台机器。

接入效果：接入弹性之前，为应对午高峰流量，该服务需要常驻机器2420台；接入弹性之后常驻机器释放了365台，高峰期弹性机器占总机器数的15%。

3.3 应急资源保障

业务场景：风控反爬服务，是公司业务的服务安全盾和数据安全盾。目前，已有上百个业务方接入反爬服务，每天处理百亿级重点流量，为各大业务方防控恶意流量，保障业务稳定、数据安全及统计数据的正确性。风控反爬相关服务，活动节假日期间，服务负载会受业务影响增长明显，需要活动节假日期间补充大量资源。

如何使用弹性策略：活动节假日期间，风控反爬业务，申请弹性应急资源（采购公有云宿主机），提升活动期间弹性扩容总量，提升服务稳定性。活动节假日过后，缩容应急资源，腾退公有云宿主机，节约资源。

接入效果：为风控业务支持了5次大规模线上活动，基于弹性伸缩的应急-资源保障机制，累计提供公有云资源700+台高配容器，约7000+CPU资源。

3.4 服务链路扩缩容

业务场景：餐饮SaaS采取“火车模型发布的模式”交付功能，需要为70+服务申请专用的灰度链路机器，用于云端功能的灰度验证。但机器每月仅需使用2~3个工作日，一直持有机器，造成机器资源浪费；最初团队是通过每月定时手动申请、释放机器来解决，耗费较大人力，一定程度上影响到了研发的效率。

如何使用弹性策略：

• 配置链路拓扑。
• 每月活动开始前，配置链路任务，设置：扩缩容时间、机器SET/LiteSet标识、链路服务扩容机器数量。
• 到达设定时间，自动扩容、缩容机器。

接入效果

• 使用前：火车发版涉及70+服务，每月需要70+服务负责人各自在发版前扩容机器，验证完成后缩容机器。
• 使用后：首次配置链路拓扑后，此后每月仅需一名RD同学，统一配置一个链路任务，达到预设时间，自动扩、缩容，大大提高效率。

四、弹性伸缩未来规划

随着弹性伸缩系统2.0在美团的规模化落地，我们未来会从稳定性、易用性、业务解决方案、新技术探索四个方面去做深、做广：

1）稳定性：基础服务的稳定性是一切的基石，而这往往是不少研发同学容易忽视的一点，研发同学需“在晴天时修屋顶”。

• 系统自身的健壮性：集群全链路拆分（缩爆炸半径）、池化、资源QoS保障能力建设。
• 弹性实例的稳定性：加固发现能力，持续完善异常检测工具（区别于常规的健康检测，会从异构算力的宿主机、不同内核参数、各系统指标层面进行综合决策），自动进行异常实例的替换；加强数据运营，提升反馈能力，持续协同调度算法进行演进。

2）易用性

• 强化预演模式：可以预测当前的弹性伸缩规则，服务接下来24小时的扩缩是怎么样的。这块我们目前做了个MVP版本，接下来除了会进一步提升用户触达率，另外也计划在用户端为接入的用户呈现使用后收益数据。
• 自动任务配置：基于阈值的配置方式不小程度上取决于工程师经验，可能会因为工程师过于“年轻”而没有做正确的配置，导致一些异常；目前在接入侧已经对部分业务放开了任务推荐的功能；计划基于运营数据进一步打磨工具后，会周期性的自动帮助业务调整配置。

3）业务解决方案

• 链路伸缩：目前已经实现了基于链路拓扑批量配置、对各服务伸缩规则进行拆分的能力；接下来会将服务与服务之间，服务与中间件、存储之间的背压反馈作用于弹性决策中。
• 专区弹性伸缩：目前已在金融业务线、美团七层负载均衡服务网关Oceanus中发挥弹性伸缩系统的“应突发”价值，未来计划为更多有专区场景的业务提供弹性伸缩支持。

4）新技术探索：借鉴Knative、Keda的设计理念，为云原生业务场景的弹性伸缩做技术储备。

作者简介