稳定、高效、可靠的基础设施是互联网企业应对业务高峰流量的底层基石。作为美团统一的基础技术平台,基础技术部一直致力于通过业内前沿技术的落地,保障公司内部所有业务在线生产系统所依赖的基础技术平台能稳定、安全、低成本、可持续地运行与发展。
弹性伸缩系统是基于 Docker 开发的自动弹性伸缩平台,在美团经历了多年的发展。
早在 2016 年,美团就在线上环境中尝试使用容器环境,推出了基于 OpenStack 的容器集群平台Hulk 1.0。随着容器的落地,弹性伸缩 1.0 版本应运而生,它解决了扩容实例慢、扩容上线慢、资源回收慢、计算资源冗余等问题。
结合前两年的探索和实践以及业界相关领域技术的成熟度,2018 年至今,我们对容器集群平台进行了一次自底向上的的整体升级,也就是现在的Hulk 2.0平台。在底层,Hulk 2.0 建设了自研的操作系统、容器引擎,并将 OpenStack 替换成了容器编排的事实标准Kubernetes;在上层弹性伸缩系统 PaaS 层面,推出了弹性伸缩系统 2.0,解决了弹性伸缩 1.0 实践过程中面临的很多业务痛点,包括:
我们首先看一下,产品演进路线和弹性伸缩 1.0 架构图。
产品演进路线
弹性伸缩 1.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,负责弹性伸缩的监控告警、运营治理等工作。
弹性伸缩 2.0 架构
在介绍前,有必要重点说明下 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.0 系统基本可以跑起来,处于一个不比弹性伸缩 1.0 系统差的阶段,接下来基于过往运维问题汇总以及业务访谈诉求,在后端架构上做了几个比较大的升级。
正如前言所述,和大部分弹性伸缩产品类似,早期启用弹性伸缩的过程如下:
在美团的落地场景中,我们遇到如下问题:
基于以上种种原因,我们拉通了各 PaaS 方,梳理了流量分组、弹性分组、发布分组之间的关系,以保证弹性伸缩在美团私有云中的扩容准确性。
分组关系图
同地域访问的方式比较有代表性,这里对同地域调用 &未 SET 化、同地域调用 &SET 化的业务集群自动扩容方式进行展开说明,其他组合可依次类推。
分组明细图
弹性伸缩系统如果只是单纯地提供一个 IaaS 资源的自动供给能力,这件事情并不难。然而实际情况下,弹性伸缩系统在落地过程中需要解决资源上面临的问题。
针对业务的这个关注点,目前业界公有云厂商的做法基本是不做 SLA 承诺或者说很难做到 SLA 承诺,因此也自然不会面临到组织的关注点问题。具体来说,在美团主要是通过以下几个措施来解决。
资源多租户图
平台给到每个业务线的资源并非无限,会给每个业务集群的弹性分组,设置一个默认的资源 Quota。如果业务觉得默认 Quota 不够,可通过工单的方式进行一轮评估调整(从实践来看,绝大部分情况无需调整)。针对这个资源 Quota,平台侧承诺的 SLA:99.9%的扩容成功率。
这里会有个问题:是不是给业务 Quota 后,这部分资源就直接划分给这个业务独占了?答案:不是的。这只是一个逻辑上的划分,资源本身是各业务混用的,平台需控制资源闲置率,本身会做些“超售”,但过程中需解决好“超售”可能面临的问题,这就是水位线监管机制。
常规-资源保障,指的是平日、小节假日下的资源供给机制,这部分的资源来源于常驻资源池(架构图所示),平台会对已接入平台的所有服务,进行小时粒度的资源重预估。具体示意图如下:
资源保障图
新增/更新服务的伸缩任务、伸缩规则时,会对当前变更对整体资源池水位的影响进行预估,如果在叠加时间点将超过整体资源池的水位,平台会拒绝执行变更操作,并给到用户和平台管理员消息推送,用户可通过工单方式进行资源请求说明(需保障存量服务的资源可靠性)。
库存 &实时用量
库存 &预估用量
常驻资源池的大小是有限的,应急-资源保障指的是业务拉新、大促、大节假日等非常态的资源供给机制,这部分的资源来源于常驻资源池+应急资源池(如架构图所示)。应急资源池简单来说就是,我们按用量计费模式购买的公有云资源,这是一种更灵活的资源池模式(具备一定的租约)。在此基础上,我们构建了更省成本的混合云弹性调度能力(在此之前仅在私有云的常驻资源池调度)。
以下示意图展示的是一个服务在大促期间(维持 T 天)需要 208 台容器实例,其中 8 台为常态下的资源诉求,200 台为应急资源诉求。
大促前:
大促后(T+1):
T+1 天后,这些应急资源池将被腾退回公有云厂商,公司无需为后续继续付费。多业务都应急的场景其实会偏复杂些;特殊情况下,需要采用重调度、治理。
在 2020 年之前,是弹性伸缩 2.0 系统的练内功阶段,并未大规模向业务推广 Hulk 2.0 弹性伸缩系统,主要原因归结为两方面:
截止 2020 年年底,共接入了约 500 个服务。这里主要以弹性伸缩 1.0 系统中平滑迁移过来的服务,同部门的服务(Eat Your Own Dog Food)为主。
在 2020 年-2021 年,是弹性伸缩 2.0 系统的规模化阶段。
经过以上这些工作,我们 80%+的服务接入了弹性,覆盖了公司 90%+的业务线。回到那句话,如果弹性伸缩系统只是单纯地提供一个 IaaS 资源的自动供给能力,这件事情并不难,而我们的定位是 PaaS 平台。
这部分主要介绍向业务交付弹性容器实例后,碰到的三类典型问题:配置、启动、性能。这些问题大部分不是弹性伸缩 2.0 这个 PaaS 平台本身领域内可直接闭环解决的事项,这往往取决于各 PaaS 平台是否已全量标准化、业务自身逻辑、以及基础设施层性能等因素,催化我们多去做这一步的原因只有一个:弹性扩容出的实例只有很好的帮助业务分担负载,才可真正帮助业务解决问题。
启动问题,大部分解决的是容器的这种开箱即用方式所面临的问题,而非过往的采用先申请机器、再在这上面发布代码包的方式。而且这里面会经常要面临着业务的质疑,为什么我手动发布的时候不存在这个问题,采用弹性扩容就出现了?
生产环境中,业务容器的性能问题其实是比较复杂的,可能涉及到重 IO 容器影响、宿主机 Load 过高、多个容器突发占用 CPU 过高导致影响某个业务容器问题。相对于不使用弹性时囤积算力的稳定场景,弹性扩缩容场景中,因对资源的频繁调配会更容易遇到资源性能的问题。为了保障使用效果,Hulk 项目组主要从三个角度对性能问题完整解决:
业务场景:有着明显的“七节二月”特性,就流量而言周末是工作日的 1.5 倍左右,节假日流量是周末的 3~5 倍左右。服务机器基本上是按照节假日的流量部署,平时机器使用率很低。
如何使用弹性伸缩:
接入效果:业务侧平均节约成本 20.4%。
业务场景:配送是外卖服务的下游,具有明显的午高峰特性。
如何使用弹性伸缩:
接入效果:接入弹性之前,为应对午高峰流量,该服务需要常驻机器 2420 台;接入弹性之后常驻机器释放了 365 台,高峰期弹性机器占总机器数的 15%。
业务场景:风控反爬服务,是公司业务的服务安全盾和数据安全盾。目前,已有上百个业务方接入反爬服务,每天处理百亿级重点流量,为各大业务方防控恶意流量,保障业务稳定、数据安全及统计数据的正确性。风控反爬相关服务,活动节假日期间,服务负载会受业务影响增长明显,需要活动节假日期间补充大量资源。
如何使用弹性策略:活动节假日期间,风控反爬业务,申请弹性应急资源(采购公有云宿主机),提升活动期间弹性扩容总量,提升服务稳定性。活动节假日过后,缩容应急资源,腾退公有云宿主机,节约资源。
服务 A
服务 B
接入效果:为风控业务支持了 5 次大规模线上活动,基于弹性伸缩的应急-资源保障机制,累计提供公有云资源 700+台高配容器,约 7000+CPU 资源。
业务场景:餐饮 SaaS 采取“火车模型发布的模式”交付功能,需要为 70+服务申请专用的灰度链路机器,用于云端功能的灰度验证。但机器每月仅需使用 2~3 个工作日,一直持有机器,造成机器资源浪费;最初团队是通过每月定时手动申请、释放机器来解决,耗费较大人力,一定程度上影响到了研发的效率。
如何使用弹性策略:
接入效果
随着弹性伸缩系统 2.0 在美团的规模化落地,我们未来会从稳定性、易用性、业务解决方案、新技术探索四个方面去做深、做广:
(1)稳定性:基础服务的稳定性是一切的基石,而这往往是不少研发同学容易忽视的一点,研发同学需“在晴天时修屋顶”。
(2)易用性
(3)业务解决方案
(4)新技术探索:借鉴 Knative、Keda 的设计理念,为云原生业务场景的弹性伸缩做技术储备。
领取专属 10元无门槛券
私享最新 技术干货