瓜分60万现金大奖，云原生编程挑战赛等你来挑战！

作者 | 项升

2021 年第二届云原生编程挑战赛目前正在火热招募中。本次大赛由阿里云、Intel 主办，阿里云云原生、阿里云天池承办。自 2015 年开始，大赛已经成功举办了六届，并从 2020 年开始升级为云原生编程挑战赛，共吸引超过 23000 支队伍，覆盖 10 余个国家和地区。

本届大赛将继续深度探索 RocketMQ、Dubbo3、Serverless 三大热门技术领域，为热爱技术的年轻人提供一个挑战世界级技术问题的舞台，希望选手用技术为全社会创造更大价值。初赛我们共准备了三个赛道供选手选择，你准备好了吗？

本文主要解密赛道二：实现一个柔性集群调度机制，希望给选手们提供一些思路。

瓜分60万现金大奖，三大赛道任意选择，

更有奇葩任务定义拿奖新姿势，快快点击报名吧！👇

https://tianchi.aliyun.com/competition/entrance/531923/introduction?spm=5176.12281925.0.0.58987137KRXtxf

1、赛题背景

云原生带来了技术标准化的重大变革，如何让应用在云上更简单地创建和运行，并具备可弹性扩展的能力，是所有云原生基础组件的核心目标。借助云原生技术带来的弹性能力，应用可以在极短时间内扩容出一大批机器以支撑业务需要。

比如为了应对零点秒杀场景或者突发事件，应用本身往往需要数千甚至数万的机器数来提升性能以满足用户的需要，但是在扩容的同时也带来了诸如集群节点极多导致的节点异常频发、服务容量受多种客观因素影响导致节点服务能力不均等一系列的在云原生场景下集群大规模部署的问题。

Dubbo 期待基于一种柔性的集群调度机制来解决这些问题。这种机制主要解决的问题有两个方面：一是在节点异常的情况下，分布式服务能够保持稳定，不出现雪崩等问题；二是对于大规模的应用，能够以最佳态运行，提供较高的吞吐量和性能。
从单一服务视角看，Dubbo 期望的目标是对外提供一种压不垮的服务，即在请求数特别高的情况下，可以通过选择性地拒绝一些请求来保证总体业务的正确性、时效性。

从分布式视角看，要尽可能降低因为复杂的拓扑、不同节点性能不一导致总体性能的下降，柔性调度机制能够以最优的方式动态分配流量，使异构系统能够根据运行时的准确服务容量合理分配请求，从而达到性能最优。

2、赛题解析

集群的柔性调度正是指 Dubbo 能够从全局的角度合理分配请求，达到集群的自适应。具体来说使消费者能够快速地感知服务端节点性能的随机变化，通过调节发送往不同服务端节点的请求数比例分配变得更加合理，让 Dubbo 即使遇到集群大规模部署带来的问题，也可以提供最优的性能。

柔性调度机制主要解决的场景有以下这些：

• 多机房异地部署，网络丢包严重
  

随着业务不断地发展，当前业务触达的用户越来越多，服务端所需的计算容量也越来越大。另外由于应用不断庞大，在微服务架构拆分的体系下依赖的上游应用也在变多。而对于单一机房来说所能提供的机器容量是有限的，因此不论是为了解决机器需求数大的问题、亦或者是为了保证业务高可用做的异地多活的，多机房异地部署的场景对于业务方来说多机房异地部署的情况变得越来越普遍。

涉及到多机房异地部署，对于同城部署，机房之间的网络尚且可以使用租用裸光纤等方式保障网络的稳定，但是一旦多个机房部署在不同的城市、甚至是不同的国家，网络丢包严重等问题会越来越严重。

本次赛题通过模拟服务端随机丢弃部分请求来模拟这种情况，旨在期望看到有一种自动基于延时学习，快速对调用进行失败返回的机制，不论是及时将失败的结果返回给调用端或者是发起重试来保证服务的总体可用性的提高。

• 服务端处理性能有限，并发越大处理越慢
  

对于一般业务场景，单一服务往往不是单机的操作，更多的是需要连接如数据库等三方组件，这些组件很多对于总体并发数是有上限的，也即是当请求并发量达到一定值时，剩下的请求会进行排队，这将加大总体的处理延时。换个角度说，即使是在单机的视角来看，由于单机的 CPU 核心数是远小于并发线程数的，在并发数特别高的情况下，会花费较多的资源用于上下文切换上。而且如果服务的并发数过大，亦很容易造成服务单点过热的问题，进而演进为单点服务被压垮，这可能导致整个集群出现服务雪崩的现象。

下图是以指数函数（评测时不应依赖此模型）模拟并发数和延时之间关系时，服务总吞吐量的对比图。

可以看到，单位时间内能处理的请求数并不是并发数越大就越高的。本次赛题希望看到有一种机制能够自动分析出上游服务的最佳请求并发数，依次来达到单位时间内成功请求的服务数更大。

• 宿主机性能超配，服务端性能不稳定
  

随着云原生时代的到来，越来越多的应用被部署在容器之中，不管是容器本身还是说普通用户上云使用的类似阿里云 ECS 等 IaaS 设施，都是运行在虚拟化环境之中的。但是在一个虚拟化环境中，宿主机的资源（包括CPU cache 和内存带宽）都是共享的。如果有一个消耗 CPU cache 的应用快速消耗了 L3 缓存，或者一个应用消耗了系统大量内存带宽，都会对运行在同一台宿主机上的其他“邻居”造成干扰。而往往应用部署的时候很难预测到具体哪台机器会出现这种情况，因此我们期待 RPC 服务框架可以主动去适配这种波动，动态调配机器间的调用比例，最终达到尽可能高的服务容量。

3、解题思路

• 容量评估
  

本题的设计目标就是基于容量的自动化调度机制，评估服务最佳容量是完成本题的前提，基于最大服务容量以及预期调用延迟可以为整体流量调度提供宏观的数据基础。一般集群的容量评估都是通过线上实际压测来确定的，而关于运行时的动态计算可以基于如接口响应的平均耗时，P999 耗时、错误率等数据进行容量评估。同时应该尽可能多地去评估各种情况下的容量，避免陷入局部最优解。

基于不同服务端的容量信息，消费端可以控制对服务端请求的并发量，达到总体请求数最高的目标。

• 快速失败
  

当一个请求被服务端丢弃或者是网络传输过程中丢弃时，通常消费端需要一段较长的时间（超时时间配置）来发现这种情况。比如一个预期请求延时是 10ms 的，等到 5000ms 的超时时间才进行报错重试的话会浪费大量的时间在等待上面。如果可以基于预期的实际延时对具体的接口进行快速失败处理可以大大节约无效的等待时间。

• 自动探测
  

由于服务端性能是实时在进行变化的，因此对服务端的调用并发数不能一直固定在一个值上面，需要动态地在一定范围内进行试探，如果发现有更优的容量则需要自动调节调用参数，最终尽可能达到所有时间的最优解。

4、总结

本文从赛题背景、赛题解析和解题思路的角度，对本届比赛题目进行了分析，介绍了柔性集群调度算法的基本设计思路，希望对即将参加比赛的同学们能有所帮助。在此预祝各位参赛选手能取得优异的成绩，进军复赛和总决赛，我们在决赛答辩等你。

5、报名方式

【赛道1】针对冷热读写场景的 RocketMQ 存储系统设计

https://tianchi.aliyun.com/competition/entrance/531922/introduction?spm=5176.12281925.0.0.58987137KRXtxf
【赛道2】实现一个柔性集群调度机制
https://tianchi.aliyun.com/competition/entrance/531923/introduction?spm=5176.12281925.0.0.58987137KRXtxf
【赛道3】Less is more - Serverless创新应用赛
https://tianchi.aliyun.com/competition/entrance/531924/introduction?spm=5176.12281925.0.0.58987137KRXtxf

戳👇立刻报名参赛：

https://tianchi.aliyun.com/competition/entrance/531923/introduction?spm=5176.12281925.0.0.58987137KRXtxf