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

Posted 2022-02-18 美团技术团队

总第487篇

2022年 第004篇

本文介绍了美团在如何解决大规模集群管理的难题、设计优秀且合理的集群调度系统方面的实践，阐述了美团在落地以Kubernetes为代表的云原生技术时，比较关心的问题、挑战以及对应的推进策略。同时本文也介绍了针对美团业务需求场景做的一些特色支持，希望本文能够对云原生领域感兴趣的同学有所帮助或者启发。

导语

集群调度系统介绍

大规模集群管理的难题

运营大规模集群的挑战

设计集群调度系统时的取舍

美团集群调度系统演变之路

多集群统一调度：提升数据中心资源利用率

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

未来展望：构建云原生操作系统

导语

集群调度系统在企业数据中心中占有举足轻重的地位，随着集群规模与应用数量的不断激增，开发者处理业务问题的复杂度也显著提升。如何解决大规模集群管理的难题，设计优秀且合理的集群调度系统，做到保稳定，降成本，提效率？本文将会逐一进行解答。

| 备注：文章最早发布于《新程序员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），都是根据各自的场景需求做了不同的选择，没有绝对的好与坏。

图1 集群调度系统架构分类（摘自Malte Schwarzkopf - The evolution of cluster scheduler architectures）

单体式调度器使用复杂的调度算法结合集群的全局信息，计算出高质量的放置点，不过延迟较高。如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 美团集群调度系统架构图

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

平台层负责业务接入，打通美团基础设施，封装原生接口和逻辑，提供容器管理接口（扩容、更新、重启、缩容）等功能。

策略层提供多集群统一调度能力，持续优化调度算法和策略，结合业务的服务等级和敏感资源等信息，通过服务分级提升CPU使用率和分配率。

引擎层提供Kubernetes服务，保障多个PaaS组件的云原生集群稳定性，并把通用能力下沉到编排引擎，降低业务云原生落地的接入成本。

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

多集群统一调度：提升数据中心资源利用率

评估考核集群调度系统的好坏，资源利用率是最重要的指标之一。因此，虽然我们在2019年完成了容器化，不过容器化不是目的，只是手段。我们的目标是通过从VM技术栈切换到容器技术栈，为用户带来更多的收益，比如全面降低用户的计算成本。

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

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

系统地建立了集群状态、宿主状态、服务状态的关联，并结合调度仿真平台，综合考虑了峰值利用率和平均利用率，实现了基于宿主历史负载和业务实时负载的预测和调度。

通过自研的动态负载调节系统和跨集群重调度系统，实现了集群调度和单机调度链路的联动，根据业务分级实现了不同资源池的服务质量保障策略。

经过三版迭代，实现了自有集群联邦服务，较好地解决了资源预占和状态数据同步问题，提升了集群间的调度并发度，实现了计算分离、集群映射、负载均衡和跨集群编排控制（见下图3）。

图3 集群联邦V3版本架构

集群联邦服务第三版本按照模块拆分为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，获得技术红利。

图4 美团Kubernetes引擎服务调度和编排框架

在我们推进云原生落地过程中，一个广泛被关注的问题是：基于Kubernetes云原生方式来管理有状态应用，相比于之前自己打造管理平台有什么区别？

对于这个问题，需要从问题根源——可运维性考虑：

基于Kubernetes意味着系统做到了闭环，不用担心两套系统经常出现的数据不一致问题。

异常响应可以做到毫秒级别，降低了系统的RTO（Recovery Time Objective，即恢复时间目标，主要指所能容忍的业务停止服务的最长时间，也是从灾难发生到业务系统恢复服务功能所需要的最短时间周期）。

系统运维复杂度也降低了，服务做到了自动化容灾。除了服务本身之外，服务依赖的配置和状态数据都可以一起恢复。

相比于之前各个PaaS组件“烟囱式”的管理平台，通用能力可以下沉到引擎服务，减少开发维护成本，而通过依托于引擎服务，可以屏蔽底层异构环境，实现跨数据中心和多云环境的服务管理。

未来展望：构建云原生操作系统

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

应用链路交付管理。随着业务规模和链路复杂度的增大，业务所依赖的PaaS组件和底层基础设施的运维复杂度早已超过普遍认知，对于刚接手项目的新人更是难上加难。所以我们需要支持业务通过声明式配置交付服务并实现自运维，给业务提供更好的运维体验，提升应用的可用性和可观测性，减少业务对底层资源管理的负担。

边缘计算解决方案。随着美团业务场景的不断丰富，业务对边缘计算节点的需求增长，比预期快很多。我们会参考业内最佳实践，形成适合在美团落地的边缘解决方案，尽快为有需求的服务提供边缘计算节点管理能力，实现云边端协同。

在离线混部能力建设。在线业务集群的资源利用率提升是有上限的，根据Google在论文《Borg: the Next Generation》中披露的2019年数据中心集群数据，刨去离线任务，在线任务的资源利用率仅为30%左右，这也说明了再往上提升风险较大，投入产出比不高。后续，美团集群调度系统将持续探索在离线混部，不过由于美团的离线机房相对独立，我们的实施路径会与业界的普遍方案有所不同，会先从在线服务和近实时任务的混部开始，完成底层能力的构建，再探索在线任务和离线任务的混部。

总结

美团集群调度系统在设计时，整体遵循合适原则，在满足业务基本需求的情况下，保证系统稳定后再逐步完善架构，提升性能和丰富功能。因此，我们选择了：

在系统吞吐量和调度质量中我们选择优先满足业务对系统的吞吐量需求，不过度追求单次调度质量，而是通过重调度调整完善。

在架构复杂度和可扩展性中我们选择降低系统各模块之间的耦合，减少系统复杂度，扩展功能必需可降级。

在可靠性和单集群规模中我们选择通过多集群统一调度来控制单集群规模，保障系统可靠性，减少爆炸半径。

未来，我们也会根据同样的逻辑持续优化迭代美团的集群调度系统，彻底转变为以应用为中心的云原生操作系统。

作者简介

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

----------  END  ----------

招聘信息

美团基础技术部/基础软件研发中心是负责美团基础技术体系中基础软件建设的团队，使命是为美团全公司提供稳定、高效、易扩展、成本合理的弹性计算、监控体系、安全设施等基础软件方案，有力支持业务研发、PaaS平台，屏蔽硬件差异，发挥软硬件红利。中心长期招聘操作系统、调度系统、弹性系统、监控系统、安全基础设施相关领域的专家，感兴趣的同学可以将简历发至：[e-mail]。

也许你还想看

  | 美团容器平台架构及容器技术实践

  | 美团容器平台HULK的调度系统

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

阅读更多

---

前端 |  算法 | 后端 | 数据

安全 | android | ios  | 运维 | 测试

宙斯盾 DDoS 防护系统“降本增效”的云原生实践

作者

tomdu，腾讯云高级工程师，主要负责宙斯盾安全防护系统管控中心架构设计和后台开发工作。

导语

宙斯盾 DDoS 防护系统作为公司级网络安全产品，为各类业务提供专业可靠的 DDoS/CC 攻击防护。在黑客攻防对抗日益激烈的环境下， DDoS 对抗不仅需要“降本”还需要“增效”。随着云原生的普及，宙斯盾团队持续投入云原生架构改造和优化，以提升系统的处理能力及效率。本文主要介绍宙斯盾防护调度平台上云过程实践与思考。

为什么上云？

云原生作为近年来相当热门的概念，无论在公司内各部门，还是公司外各大同行友商，都受到追捧。云原生涉及技术包括容器、微服务、 DevOps 、持续交付等，这些新的技术和理念能带来哪些收益？在我们看来，

资源共享，动态扩缩容——“降本”

以宙斯盾防护调度平台为例，因为以前申请的物理机资源还在服役期，所以当前大部分后台服务还是运行在物理机。申请时会适当预留 buffer （资源消耗跟外部攻击威胁有关，波峰波谷相差可达十倍）。这部分 buffer 虽然作为 backup ，但同时大部分时间处于空闲状态，物理机也不便于跨系统、项目共享。在资源上云阶段， CVM 已经对物理机做了虚拟化，一定程度上实现资源共享。随着容器化管理平台的出现，资源控制粒度更细。例如在 TKE 平台上，一个容器分配的资源可以精确到0.1核 CPU 、1 MB 内存，根据负载随时扩缩容。同时所有资源作为一个大池子来共享，减少资源浪费。

容器化管理，快速部署——“增效”

要提升迭代速度，除了开发环节，测试、发布、运维都需要做优化。原来物理机部署时，需要运维同学手工或者通过专门的运维发布平台来完成发布，期间还可能因为机器环境的差异出现发布失败或者异常，需要人工处理。现在通过容器化部署，可以保证服务的运行环境一致性，避免“雪花服务器”。同时借助容器管理平台，可以实现一键发布、快速扩缩容，通用的容器容灾策略为服务的稳定性提供了基本保证。

怎么上云？

当前架构

如上图所示， DDoS 防护流程包括攻击检测（发现攻击）和攻击防护（攻击流量清洗及正常流量回源）。

在这个过程中，还需要一个主控“大脑”来协调检测系统和防护系统，以实现全流程的自动化处理——这个“大脑”就是防护调度平台。在检测到 DDoS/CC 攻击时，防护调度平台会自动化决策需要调用的防护设备机房、数量、以及需要下发的防护策略，遇上强对抗时还需要实时调整防护设备上的防护策略，其重要程度可见一斑。

当前防护调度平台整体架构如下图所示。

• 防护设备：分为 ADS （ Anti-DDoS System ）、 HTTP CC 、 HTTPS CC 三大类，结合多年来团队在 DDoS/CC 攻防对抗上的积累，分别集成了各种协议/场景下的自研防护算法。防护设备部署在全球各地机房入口，在触发攻击告警后牵引并清洗攻击流量，然后回源。其上部署有管控 agent ，负责与后台通信、并管理防护设备。
• 接入层：多点接入，内网、公网接入。管控 agent 启动后随机选择一个可用接入进行 TCP 连接。
• 后台服务：多主/主备部署，向接入注册心跳，所有后台请求通过接入分发、负载均衡，所有 agent 请求通过接入转发。

如果按照当前架构直接部署到 TKE 上，系统是可以运行起来，但是由于机器部署和容器部署的特性不同，直接部署总会有些冲突、别扭的地方。考虑方案时，我们觉得当前架构不适应 TKE 部署的主要地方有：

• 服务发现：后台服务根据预配置的接入 IP 列表注册心跳，容器化部署后 IP 切换频繁，通过配置的方式加载接入已经不适用。
• 无状态：容器化部署可以做到根据负载快速扩容，但需要服务做到完全无状态才能达到完全水平扩展。当前多主部署的服务都是无状态的，可以直接迁移，但主备部署的服务则需要改造。
• 配置管理：当前按机器维度管理，与运行环境相关/无关的配置混在一起。

同时，借着这次上云的机会，我们也希望对系统架构做一次大的优化，接入公司成熟的公共服务如北极星名字服务、七彩石配置中心、智研，提升研效。

上云架构

基于当前架构，除了把服务做镜像打包、迁移到 TKE 上部署，同时对不适应的地方做改造、优化。改造后的大致架构及流程如下：

• 服务发现：后台服务全部接入北极星名字服务，向北极星注册实例、定期发送心跳，接入从北极星获取各类服务健康实例来分发请求。
• 无状态：当前系统存在状态的场景主要有两类。
  • 文件下载：主要是防护设备的策略文件下载，无状态化改造涉及待下载文件在多个文件服务实例间同步。解决方案是选择使用 CFS 来同步文件。
  • 策略分包下发：策略太大时应用层做了分包，同一请求哈希到同一后台策略服务实例。解决方案是请求中带上当前分包状态信息，任一策略服务实例可以处理且结果一致。
• 配置管理：与运行环境无关的配置，接入七彩石配置中心，保证同一类型部署的实例配置一致。
• 日志监控：迁移到智研日志汇、监控宝。

两大“拦路虎”

如何平滑迁移

当前物理机环境稳定运行，计划逐步灰度、切量到TKE环境，因此会有一段时间是物理机+ TKE 混跑的状态。管控接入、后台服务迁移 TKE ，对于防护设备 agent 是透明的。因为防护设备 agent 只会选择一个可用接入建立连接，即 agent 只会连到物理机环境或 TKE 环境，因此后台服务与 agent 交互时，混跑状态下涉及物理机环境和 TKE 环境互访的情况。这种情况 TKE 提供了灵活的配置支持。

在 TKE 上部署服务时，提供了两种网络模块：

• Global Route ： VPC 内私有 IP ，无法从集群外访问，不可以注册到 CMDB 。开启随机端口映射后可从集群外访问，并可绑定 CLB 和北极星。
• ENI IP ：公司内可路由 IP ，可从集群外访问，可以注册 CMDB 、 CLB 和北极星。

在混跑灰度期间，接入部署选择 ENI IP 的方式，物理机后台服务访问 TKE 接入跟访问普通内网服务无异。迁移完成后，后台服务改用 Global Route 的方式，仅允许集群内互访。后台服务间通过原生的 service 访问，对外只通过 CLB 暴露服务。

不断变化的 IP

由于 DDoS 攻防对抗的业务特性，我们长期跟 IP 打交道，对 IP 有一种特殊的情节。在内部交流中，我们发现大家在迁移 TKE 过程中都会遇到一些共性问题。其中，跟 IP 相关的问题就会经常被提及。

在物理机部署环境，机器 IP 是固定的且变化频率较低（几年一次的机器裁撤）。但是在 TKE 环境，重启一次服务，分配到的容器 IP 、节点就可能变了，导致系统中依赖 IP 实现的功能无法很好适应 TKE 环境。

访问鉴权

比较简单的鉴权是基于源 IP 加白，如接口访问、 DB 访问。对于接口访问，我们定义了一套基于 JWT 的接口鉴权规范，所有对外接口不再使用源 IP 加白的方式。对于 DB 访问，当前是使用不限源的独立 DB 账号，并对权限做更细的划分（精确到表）。后续 DB 权限支持实时申请，当容器起来以后通过接口申请当前容器所在节点的访问权限。

服务发现

原来的架构中，管控接入层实现了简单的服务注册、服务发现功能，后台服务通过 IP 配置来注册、上报心跳。如果接入层不迁移到 TKE 、继续保持相对固定，那么这套方案还是可行的。但是，接入层迁移到 TKE 后，自身的部署节点也在不断变化，因此需要一个独立与接入、相对固定的服务注册与发现模块。集群内部署的服务可以使用 K8s / TKE 原生的 service ，对于物理机和 TKE 混跑的情况则可以考虑北极星名字服务。

服务暴露

这里包含两层含义，一个是该暴露给外部的服务如何保持稳定，另一个是不该暴露给外部的服务如何隐藏起来。

（1）暴露服务给外部

在物理机环境，机器裁撤导致服务IP变化就是经常出现的问题，通过域名、 VIP 都可以解决。在 TKE 上，通过 CLB 来实现。

（2）隐藏内部服务

通过 VPC 内私有 IP ，就能保证服务无法从集群外访问，实现隔离。

我们系统的最终目标是：所有对外服务通过接入层暴露出去，做好鉴权；内部的后台服务都隐藏起来，保证安全性。

上云效果

防护调度平台上云之后，

(1)在降低成本方面，预计资源使用率可以达到50%以上。之前为了保证 DDoS 攻击峰值时能正常运行而预留的一大部分资源，闲时放到整个大资源池里共享，忙时动态扩容。

(2)在部署效率方面，部署、扩容耗时从天降到分钟。原来需要运维同学专人专职完成发布，上 TKE 后只需开发同学简单配置即可完成。同时，随着业务场景的快速变化，通过 TKE 满足了我们对高防、网关、第三方云等场景的快速部署和扩容。

随着公司内云上服务越来越丰富，通过上云和接入公共服务，优化宙斯盾防护调度平台的架构，从而提升系统扩展性和迭代效率。
另外，宙斯盾的核心能力是 DDoS 、 CC 防护，除了管控上云，我们也正在探索防护能力虚拟化的可能性，为云上各种业务、场景提供灵活、弹性的防护能力。

关于我们

更多关于云原生的案例和知识，可关注同名【腾讯云原生】公众号~

福利：

   ①公众号后台回复【手册】，可获得《腾讯云原生路线图手册》&《腾讯云原生最佳实践》~

   ②公众号后台回复【系列】，可获得《15个系列100+篇超实用云原生原创干货合集》，包含Kubernetes 降本增效、K8s 性能优化实践、最佳实践等系列。