关于美团:美团集群调度系统的云原生实践

本文介绍了美团在如何解决大规模集群治理的难题、设计优良且正当的集群调度零碎方面的实际，论述了美团在落地以 Kubernetes 为代表的云原生技术时，比较关心的问题、挑战以及对应的推动策略。同时本文也介绍了针对美团业务需要场景做的一些特色反对，心愿本文可能对云原生畛域感兴趣的同学有所帮忙或者启发。

导语

集群调度零碎在企业数据中心中占有无足轻重的位置，随着集群规模与利用数量的一直激增，开发者解决业务问题的复杂度也显著晋升。如何解决大规模集群治理的难题，设计优良且正当的集群调度零碎，做到保稳固，降老本，提效率？本文将会逐个进行解答。

| 备注：文章最早公布于《新程序员 003》云原生时代的开发者专栏。

集群调度零碎介绍

集群调度零碎，又被称为数据中心资源调度零碎，广泛用来解决数据中心的资源管理和任务调度问题，它的指标是做到数据中心资源的无效利用，晋升资源的利用率，并为业务方提供自动化的运维能力，升高服务的运维治理老本。工业界比拟出名的集群调度零碎，如开源的 OpenStack、YARN、Mesos 和 Kubernetes 等等，再如出名互联网公司 Google 的 Borg、微软的 Apollo、百度的 Matrix、阿里巴巴的 Fuxi 和 ASI。

集群调度零碎作为各互联网公司外围的 IaaS 基础设施，在近十几年经验了屡次架构演进。随同着业务从单体架构向 SOA（面向服务的架构）演进和微服务的倒退，底层的 IaaS 设施也从物理机裸机时代逐渐逾越到容器时代。尽管在演进过程中咱们要解决的外围问题没有扭转，但因为集群规模和利用数量的急剧收缩，问题的复杂度也成指数级增长。本文将论述大规模集群治理的挑战和集群调度零碎的设计思路，并以美团集群调度零碎落地实际为例，讲述通过打造多集群对立调度服务，继续晋升资源的利用率，提供 Kubernetes 引擎服务赋能 PaaS 组件，为业务提供更好的计算服务体验等一系列云原生实际。

大规模集群治理的难题

家喻户晓，业务快速增长带来的是服务器规模和数据中心数量的暴增。对于开发者而言，在大规模集群调度零碎的业务场景下，必须要解决的两个难题是：

1. 如何治理好 数据中心大规模集群部署调度，特地是在跨数据中心场景下，如何实现资源的弹性和调度能力，在保障利用服务质量的前提下尽可能地晋升资源的利用率，充沛升高数据中心老本。
2. 如何革新底层基础设施，为业务方 打造云原生操作系统，晋升计算服务体验，实现利用的自动化容灾响应和部署降级等，缩小业务方对底层资源管理的心智累赘，让业务方能够更专一于业务自身。

经营大规模集群的挑战

为了在实在的生产环境解决上述两个难题，具体又能够再拆分成以下四个大规模集群经营治理挑战：

1. 如何解决用户多样化需要并疾速响应。业务的调度需要和场景丰盛且动静多变，作为集群调度零碎这样的平台型服务，一方面须要可能疾速交付性能，及时满足业务需要；另一方面还须要把平台打造得足够通用，将业务个性化需要形象为可落地到平台的通用能力，并长期进行迭代。这十分考验平台服务团队的技术演进布局，因为一不小心，团队就会陷入无休止的业务性能开发中，尽管满足了业务需要，却会造成团队工作低水平反复的景象。
2. 如何进步在线利用数据中心的资源利用率且同时保障利用服务质量。资源调度始终是业界公认的难题，随着云计算市场疾速倒退，各云计算厂商一直加大对数据中心的投入。数据中心的资源使用率却非常低，更加剧了问题的严重性。Gartner 调研发现寰球数据中心服务器 CPU 利用率只有 6%～12%，即便是亚马逊弹性计算云平台（EC2，Elastic Compute Cloud）也只有 7%～17% 的资源利用率，可见资源节约有多重大。究其原因，在线利用对于资源利用率十分敏感，业界不得不预留额定资源以保障重要利用的服务质量（QoS，Qualityof Service）。集群调度零碎须要在多利用混合运行时打消利用间的烦扰，实现不同利用之间的资源隔离。
3. 如何为利用，特地是有状态利用提供实例异样主动解决，屏蔽机房差别，升高用户对底层的感知。随着服务利用规模的继续扩充，以及云计算市场的日趋成熟，分布式应用往往会配置在不同地区的数据中心，甚至是逾越不同的云环境，实现了多云或混合云部署。而集群调度零碎须要为业务方提供对立的基础设施，实现混合多云架构，屏蔽底层的异构环境。同时升高利用运维治理的复杂性，晋升利用的自动化水平，为业务提供更好的运维体验。
4. 如何解决单集群过大或集群数量过多，而带来的与集群治理相干的性能和稳定性危险。集群自身的生命周期治理复杂度会随同集群规模和数量的增多而增大。以美团为例，咱们所采取的两地多核心多集群计划，尽管在肯定水平上躲避了集群规模过大的隐患，解决了业务隔离性、地区提早等问题。随着边缘集群场景和数据库等 PaaS 组件上云需要的呈现，能够预感小集群数量将会有显著的上涨趋势。随之带来的是集群治理复杂度、监控配置老本、运维老本的明显增加，这时集群调度零碎须要提供更无效的操作标准，并保障操作安全性、报警自愈和变更效率。

设计集群调度零碎时的取舍

为了解决上述挑战，一个好的集群调度器将施展关键作用。但事实中从来不存在一个完满的零碎，所以在设计集群调度零碎时，咱们须要依据理论场景在几个矛盾中做出取舍：

1. 集群调度零碎的零碎吞吐量和调度品质。零碎吞吐量是咱们通常评估一个零碎好坏很重要的规范，但在面向在线服务的集群调度零碎里更重要的是调度品质。因为每次调度后果的影响是长期的（数天、数周甚至数月），非异常情况不会调整。所以如果调度后果谬误，会间接导致服务时延增高。而调度品质越高则意味着须要思考的计算约束条件越多，而且调度性能越差的话，零碎吞吐量越低。
2. 集群调度零碎的架构复杂度和可扩展性。系统对下层 PaaS 用户凋谢的性能和配置越多，通过反对更多功能来晋升用户体验（比方反对利用资源抢占回收和利用实例异样自愈），也就意味着零碎复杂度越高，各子系统越容易发生冲突。
3. 集群调度零碎的可靠性和单集群规模。单集群规模越大，则可调度范畴则越大，但对集群的可靠性挑战也越大，因为爆炸半径会减少，呈现故障的影响也越大。单集群规模较小的状况下，尽管能够晋升调度并发度，但可调度范畴变小，调度失败概率变高，且集群治理复杂度变大。

目前，业内的集群调度零碎依照架构辨别，能够分为单体式调度器、两级调度器、共享状态调度器、散布式调度器和混合调度器这五种不同架构（见下图 1），都是依据各自的场景需要做了不同的抉择，没有相对的好与坏。

• 单体式调度器 应用简单的调度算法联合集群的全局信息，计算出高质量的搁置点，不过提早较高。如 Google 的 Borg 零碎、开源的 Kubernetes 零碎。
• 两级调度器 通过将资源调度和作业调度拆散，解决单体式调度器的局限性。两级调度器容许依据特定的利用做不同的作业调度逻辑，且同时放弃了不同作业之间共享集群资源的个性，可是无奈实现高优先级利用的抢占。具备代表性的零碎是 Apache Mesos 和 Hadoop YARN。
• 共享状态调度器 通过半分布式的形式来解决两级调度器的局限性，共享状态下的每个调度器都领有一份集群状态的正本，且调度器独立对集群状态正本进行更新。一旦本地的状态正本发生变化，整个集群的状态信息就会被更新，但继续资源争抢会导致调度器性能降落。具备代表性的零碎是 Google 的 Omega 和微软的 Apollo。
• 散布式调度器 应用较为简单的调度算法以实现针对大规模的高吞吐、低提早并行任务搁置，但因为调度算法较为简单并不足全局的资源应用视角，很难达到高质量的作业搁置成果，代表性零碎如加州大学的 Sparrow。
• 混合调度器 将工作负载扩散到集中式和分布式组件上，对长时间运行的工作应用简单算法，对短时间运行的工作则依赖于分布式布局。微软 Mercury 就采取了这种这种计划。

所以，如何评估一个调度零碎的好坏，次要取决于理论的调度场景。以业内应用最宽泛的 YARN 和 Kubernetes 为例，尽管两个零碎都是通用资源调度器，实际上 YARN 专一于离线批处理短工作，Kubernetes 专一于在线长时间运行的服务。除了架构设计和性能的不同（Kubernetes 是单体式调度器，YARN 是两级调度器），二者的设计理念和视角也不同。YARN 更专一工作，关注资源复用，防止近程数据屡次拷贝，指标是以更低成本、更高速度执行工作。Kubernetes 更专一服务状态，关注错峰、服务画像、资源隔离，指标是保障服务质量。

美团集群调度零碎演变之路

美团在落地容器化的过程中，依据业务场景需要，集群调度系统核心引擎由 OpenStack 转变为 Kubernetes，并在 2019 年底实现了在线业务容器化覆盖率超过了 98% 的既定目标。但仍然面临资源利用率低、运维老本低等问题：

• 集群整体的资源利用率不高。如 CPU 资源均匀利用率还处于业内平均水平，相较于其余一线互联网公司差距较大。
• 有状态服务的容器化率水平不够，特地是 MySQL、Elasticsearch 等产品没有应用容器，业务运维老本和资源老本存在较大的优化空间。
• 从业务需要思考，VM 产品会长期存在，VM 调度和容器调度是两套环境，导致团队虚拟化产品运维老本较高。

因而，咱们决定开始对集群调度零碎进行云原生革新。打造一个具备多集群治理和自动化运维能力、反对调度策略举荐和自助配置、提供云原生底层扩大能力，并在保障利用服务质量的前提下晋升资源使用率的大规模高可用调度零碎。外围工作围绕保稳固、降老本、提效率三大方向来构建调度零碎。

• 保稳固：晋升调度零碎的健壮性、可观测性；升高零碎各模块之间的耦合，缩小复杂度；晋升多集群治理平台的自动化运维能力；优化系统核心组件性能；确保大规模集群的可用性。
• 降老本：深度优化调度模型，买通集群调度和单机调度链路。从资源动态调度转向资源动静调度，引入离线业务容器，造成自由竞争与强控联合，在保障高优业务利用服务质量的前提下，晋升资源使用率，升高 IT 老本。
• 提效率：反对用户自助调整调度策略，满足业务个性化需要，踊跃拥抱云原生畛域，为 PaaS 组件提供包含编排、调度、跨集群、高可用等外围能力，晋升运维效率。

最终，美团集群调度零碎架构依照畛域划分为三层（见上图 2），调度平台层、调度策略层、调度引擎层：

• 平台层负责业务接入，买通美团基础设施，封装原生接口和逻辑，提供容器治理接口（扩容、更新、重启、缩容）等性能。
• 策略层提供多集群对立调度能力，继续优化调度算法和策略，联合业务的服务等级和敏感资源等信息，通过服务分级晋升 CPU 使用率和分配率。
• 引擎层提供 Kubernetes 服务，保障多个 PaaS 组件的云原生集群稳定性，并把通用能力下沉到编排引擎，升高业务云原生落地的接入老本。

通过精细化经营和产品性能打磨，咱们一方面对立纳管了美团近百万的容器 / 虚拟机实例，另一方面将资源利用率从业内平均水平晋升到了一流程度，同时还撑持了 PaaS 组件的容器化和云原生落地。

多集群对立调度：晋升数据中心资源利用率

评估考核集群调度零碎的好坏，资源利用率是最重要的指标之一。因而，尽管咱们在 2019 年实现了容器化，不过容器化不是目标，只是伎俩。咱们的指标是通过从 VM 技术栈切换到容器技术栈，为用户带来更多的收益，比方全面升高用户的计算成本。

而晋升资源利用率受限于集群的个别热点宿主，一旦扩容，业务容器就有可能扩容到热点宿主，业务的性能指标如 TP95 耗时会呈现稳定，以至于咱们只能像业界其余公司一样，通过减少资源冗余来保障服务质量。究其原因，Kubernetes 调度引擎的调配形式仅简略思考了 Request/Limit Quota（Kubernetes 为容器设定了申请值 Request 和束缚值 Limit，作为用户申请容器的资源配额），属于动态资源分配。导致不同宿主机尽管调配了同样多的资源，却因宿主机的服务差异性使得宿主机的资源利用率也存在较大的差别。

在学术界和工业界中，有两种罕用的办法解决资源应用效率和利用服务质量之间的矛盾。第一种办法是通过高效的任务调度器在全局角度解决；第二种办法是通过单机资源管理伎俩来增强利用之间的资源隔离。不论是哪一种办法，都意味着咱们须要全面把握集群状态，所以咱们做了三件事：

• 系统地建设了集群状态、宿主状态、服务状态的关联，并联合调度仿真平台，综合思考了峰值利用率和均匀利用率，实现了基于宿主历史负载和业务实时负载的预测和调度。
• 通过自研的动静负载调节零碎和跨集群重调度零碎，实现了集群调度和单机调度链路的联动，依据业务分级实现了不同资源池的服务质量保障策略。
• 通过三版迭代，实现了自有集群联邦服务，较好地解决了资源预占和状态数据同步问题，晋升了集群间的调度并发度，实现了计算拆散、集群映射、负载平衡和跨集群编排管制（见下图 3）。

集群联邦服务第三版本（图 3）依照模块拆分为 Proxy 层和 Worker 层，独立部署：

• Proxy 层会综合集群状态的因子及权重抉择适合的集群进行调度，并抉择适合的 Worker 散发申请。Proxy 模块应用 etcd 做服务注册、选主和发现，Leader 节点负责调度时预占工作，所有节点都能负责查问工作。
• Worker 层对应解决一部分 Cluster 的查问申请，当某集群工作阻塞，能够疾速扩容一台对应的 Worker 实例缓解问题。当单集群规模较大时会对应多个 Worker 实例，Proxy 将调度申请分发给多个 Worker 实例解决，晋升调度并发度，并缩小每一个 Worker 的负载。

最终通过多集群对立调度，咱们实现了从动态资源调度模型转向动静资源调度模型，从而升高了热点宿主比例，缩小了资源碎片比例，保障了高优业务利用的服务质量，将在线业务集群的服务器 CPU 利用率均值晋升了 10 个百分点。集群资源利用率均值计算形式：Sum(nodeA.cpu. 以后应用核数 + nodeB.cpu. 以后应用核数 + xxx) / Sum(nodeA.cpu. 总核数 + nodeB.cpu. 总核数 + xxx），一分钟一个点，当天所有值取均匀。

调度引擎服务：赋能 PaaS 服务云原生落地

集群调度零碎除了解决资源调度的问题之外，还解决服务应用计算资源的问题。正如《Software Engineering at Google》一书中提到的，集群调度零碎作为 Compute as a Service 中要害组件之一，既要解决资源调度（从物理机拆解到 CPU/Mem 这样的资源维度）和资源竞争（解决“吵闹街坊”），还须要解决利用治理（实例自动化部署、环境监控、异样解决、保障服务实例数、确定业务需要资源量、不同服务品种等）。而且从某种程度上来说利用治理比资源调度更重要，因为这会间接影响业务的开发运维效率和服务容灾成果，毕竟互联网的人力老本比机器老本更高。

简单的有状态利用的容器化始终是业界难题，因为这些不同场景下的分布式系统中通常保护了本人的状态机。当利用零碎产生扩缩容或降级时，如何保障以后已有实例服务的可用性，以及如何保障它们之间的可连通性，是相较无状态利用简单许多的辣手问题。尽管咱们曾经把无状态服务都容器化了，但咱们还没有充分发挥出一个良好的集群调度零碎的全副价值。如果要想管好计算资源，必须治理好服务的状态，做到资源和服务拆散，晋升服务韧性，而这也是 Kubernetes 引擎所善于的。

咱们基于美团优化定制的 Kubernetes 版本，打造了美团 Kubernetes 引擎服务 MKE：

• 增强集群运维能力，欠缺了集群的自动化运维能力建设，包含集群自愈、报警体系、Event 日志剖析等，继续晋升集群的可观测性。
• 竖立重点业务标杆，与几个重要的 PaaS 组件深刻单干，针对用户的痛点如 Sidecar 降级治理、Operator 灰度迭代、报警拆散做疾速优化，满足用户的诉求。
• 继续改良产品体验，继续优化 Kubernetes 引擎，除了反对用户应用自定义 Operator 之外，也提供了通用的调度和编排框架（见图 4），帮忙用户以更低的老本接入 MKE，取得技术红利。

在咱们推动云原生落地过程中，一个宽泛被关注的问题是：基于 Kubernetes 云原生形式来治理有状态利用，相比于之前本人打造治理平台有什么区别？

对于这个问题，须要从问题本源——可运维性思考：

• 基于 Kubernetes 意味着零碎做到了闭环，不必放心两套零碎经常出现的数据不统一问题。
• 异样响应能够做到毫秒级别，升高了零碎的 RTO（Recovery Time Objective，即复原工夫指标，次要指所能容忍的业务进行服务的最长工夫，也是从劫难产生到业务零碎复原服务性能所须要的最短时间周期）。
• 零碎运维复杂度也升高了，服务做到了自动化容灾。除了服务自身之外，服务依赖的配置和状态数据都能够一起复原。
• 相比于之前各个 PaaS 组件“烟囱式”的治理平台，通用能力能够下沉到引擎服务，缩小开发保护老本，而通过依靠于引擎服务，能够屏蔽底层异构环境，实现跨数据中心和多云环境的服务治理。

将来瞻望：构建云原生操作系统

咱们认为，云原生时代的集群治理，会从之前的治理硬件、资源等职能全面转变为以利用为核心的云原生操作系统。以此为指标，美团集群调度零碎还需从以下几方面发力：

• 利用链路交付治理。随着业务规模和链路复杂度的增大，业务所依赖的 PaaS 组件和底层基础设施的运维复杂度早已超过广泛认知，对于刚接手我的项目的新人更是难上加难。所以咱们须要反对业务通过申明式配置交付服务并实现自运维，给业务提供更好的运维体验，晋升利用的可用性和可观测性，缩小业务对底层资源管理的累赘。
• 边缘计算解决方案。随着美团业务场景的不断丰富，业务对边缘计算节点的需要增长，比预期快很多。咱们会参考业内最佳实际，造成适宜在美团落地的边缘解决方案，尽快为有需要的服务提供边缘计算节点治理能力，实现云边端协同。
• 在离线混部能力建设。在线业务集群的资源利用率晋升是有下限的，依据 Google 在论文《Borg: the Next Generation》中披露的 2019 年数据中心集群数据，刨去离线工作，在线工作的资源利用率仅为 30% 左右，这也阐明了再往上晋升危险较大，投入产出比不高。后续，美团集群调度零碎将继续摸索在离线混部，不过因为美团的离线机房绝对独立，咱们的施行门路会与业界的广泛计划有所不同，会先从在线服务和近实时工作的混部开始，实现底层能力的构建，再摸索在线工作和离线工作的混部。

总结

美团集群调度零碎在设计时，整体遵循适合准则，在满足业务根本需要的状况下，保证系统稳固后再逐步完善架构，晋升性能和丰盛性能。因而，咱们抉择了：

• 在零碎吞吐量和调度品质中咱们抉择优先满足业务对系统的吞吐量需要，不适度谋求单次调度品质，而是通过重调度调整欠缺。
• 在架构复杂度和可扩展性中咱们抉择升高零碎各模块之间的耦合，缩小零碎复杂度，扩大性能必须可降级。
• 在可靠性和单集群规模中咱们抉择通过多集群对立调度来管制单集群规模，保障系统可靠性，缩小爆炸半径。

将来，咱们也会依据同样的逻辑继续优化迭代美团的集群调度零碎，彻底转变为以利用为核心的云原生操作系统。

作者简介

谭霖，来自美团根底研发平台 / 根底技术部。

浏览美团技术团队更多技术文章合集

前端 | 算法 | 后端 | 数据 | 平安 | 运维 | iOS | Android | 测试

| 在公众号菜单栏对话框回复【2021 年货】、【2020 年货】、【2019 年货】、【2018 年货】、【2017 年货】等关键词，可查看美团技术团队历年技术文章合集。

| 本文系美团技术团队出品，著作权归属美团。欢送出于分享和交换等非商业目标转载或应用本文内容，敬请注明“内容转载自美团技术团队”。本文未经许可，不得进行商业性转载或者应用。任何商用行为，请发送邮件至 tech@meituan.com 申请受权。