一共四道题，在此记录一下。原广告链接：https://tianchi.aliyun.com/specials/promotion/cloudnative

【赛道1】实现一个分布式统计和过滤的链路追踪

用户需要两个程序，一个是数量流（橙色标记）的处理程序，该机器可以获取数据源的http地址，拉取数据后进行处理，并与后端引擎（蓝色标记）通信， 最终数据结果在后端引擎机器上落盘。

【赛道2】实现规模化容器静态布局和动态迁移

赛题背景

阿里每年双11不断的创造奇迹的背后，是巨大的资源成本投入，用以支撑峰值流量。每年各种大促、基础设施的升级都有可能会涉及到单元、中心机房站点变化，而这些站点的迁移、变化，我们可能会短时间借助离线资源、云上资源等，也可能会评估采购物理机，无论是采用哪种方式，我们都期望控制成本用尽可能少的资源成本满足当下站点需求。

日常态，我们使用较少的资源满足业务流量需求，但备战各种大促态尤其是双11，容器平台会承担数十万容器扩容诉求，支撑0点峰值流量，满足用户买买买的需求，同时也使得机器资源成本大幅度提升。

在大促规模化场景下，我们希望通过合理容器静态布局及动态迁移能力，在保证业务稳定性前提下，用尽可能少的机器资源来满足大促资源成本的节省，因而集群规模化容器布局成为了我们的关注点。

静态布局

容器平台规模化建站

• 每年双11大促，阿里容器平台会提前规划多个机房单元流量、容量分布。此阶段各机房单元站点，可能经历从0到1的新建，也可能经历从1到N规模化的容器布局。使得交易流量从日常态倾于大促态。然后经受第一轮全链路建站压测。

动态迁移

集群变化后容器平台按诉求规模化容器迁移。

• 大促建站后，通过良好的资源运营方式，集群符合90%的大促态，但业务团队会通过全链路压测、特殊的业务大促活动补容/缩容诉求等，使得各个集群资源状态发生变化。
• 大促结束后，交易流量会从大促态倾于日常态，在此过程中，集群容器会缩容至日常态，同时集团的机器资源会退水并分时复用于其他团队。

赛题准备

根据下面的单元化集群描述，我们会抽取机房单元中容器、宿主机信息并结合站点集群的变化来准备赛题。

1. 多单元机房规模化容器布局
2. 单元机房集群站点变化

• 初始态: 基础设置环境准备，涉及内核、网络、中间件、存储、集群管理等等验证准备阶段，此时没有任何交易业务容器，涉及到跨bu多团队的协作。
• 站点火种: 较少的机器、业务容器，用于支撑极少交易流量(如每秒1k笔 / 全局1%%流量)，用于验证交易全链路的正确性，并为未来快速规模化扩容埋下火种。
• 中间态: 较多的机器、业务容器，用于支撑一定规模交易流量(如每秒万笔流量)，成为一个长期、平稳日常态单元集群，抑或通过建站使得集群规模化补容到濒临大促态。
• 大促态: 集团大面积封网、全链路压测稳定，迎接大促。
• 一个不够形象的串联解释: 当我们想要搬家时，购买了很多储物箱(初始态)，但还没到搬家的日期，空闲时先收拾了一部分衣物在部分储物柜中(站点火种)，当真正要搬家之前，此阶段可能还要补充储物柜、清理旧物品等，然后陆陆续续的整理好了一个个的储物柜(中间态)，，直到真正搬家时候(大促态)。

赛题内容

1. 规模化容器静态布局场景。我们准备了确定数量多规格机器资源，使得在满足调度约束条件下，确定数量、多种类的应用容器能在这些机器资源上满足扩容诉求，保证建站的确定性(赛题中我们会给出充足的机器，但真正建站场景我们会先通过计算预估机器)。
2. 规模化容器动态迁移场景。我们会准备一个集群容器静态布局数据，此时集群是一种碎片态。然后通过容器的迁移，按照规则要求尽可能腾空机器资源，过滤空机器，使得碎片态集群现状重新成为饱满态。

赛题挑战

一个单元集群，数万容器、数千主机、核心业务调度约束，综合起来资源碎片问题会更加放大，而这些单元机房可能根本不会有容器的新增，集群会成为我想象中的”饱和态”

静态布局

业界多数调度器均通过不同的策略打分通过queue以one-by-one的方式调度容器，设计上并不感知后续容器信息，串行扩容顺序会左右调度结果，进而极大地可能会导致资源的浪费。下面通过三个容器实例、三台宿主机举例:

动态迁移

赛题数据

应用描述

1. 集团中的应用信息实际以 “应用名

   应用分组” 两个维度的形式呈现，同一个应用名下会有多个应用分组，不会出现一个应用分组对应多个应用名。对应关系是一对多的关系(appName:group=1:N)。

2. 集团内部应用与应用、分组与分组之间有各种调度规则约束，如应用分时错峰、CPU/内存密集型应用交错布局，但本赛题简化问题描述，不增加这些复杂约束。
3. 集团应用根据不同画像特性，cpu-model定义了cpu-share、cpu-set 两种类型，内存超卖技术还未规模化铺开，此处我们考量的是保证交易的稳定性的双11大促单元集群中的cpu-set模式、固定内存的核心应用。

【赛道3】服务网格控制面分治体系构建

问题背景

阿里拥有百万级别的服务实例。虽然通过 Nacos 可以解决超大规模服务发现问题，但服务网格的先行者 Istio 却一直是单体全量数据，不能横向扩容。因此我们找个办法，通过让不同的 Pilot 实例负责不同的 Sidecar 即分治方式来支撑超大规模的系统。然而这里的一个挑战是：如何分配 Sidecar 才能让 Pilot 集群整体负载均衡 ？

为了更好地说明问题，我们先将问题简化成以下模型：

这里说明如下：

• 三个部分，从上至下分别是：注册中心、Pilot 集群以及应用；
• 每个应用中 Sidecar 依赖的服务都是一样的，不同应用依赖的服务可能有重叠；
• 应用可能随时增减、应用的 Sidecar 也可能随时增减；
• 每个 Pilot 依据连接上来的 Sidecar 实例需要的全部服务，向注册中心发起服务订阅，将结果存于内存中并推送给他们。

由此可见，Pilot 单个实例承压为：Sidecar 连接量 + 服务数据。服务数据越大，意味着推送前处理的数据越多；连接数越多，意味着需要推送的数据越多。因此，这里的性能优化便成了设法降低这两个值，这体现在 Pilot 集群里便是让 Sidecar 连接更均匀，以及减少 Pilot 服务加载的重复度。但这并不简单，因为我们尝试优化一个时，另一个就会变差。例如，如果我们采取随机连接的方式，那么 Sidecar 连接将会比较平均，单个实例的连接数便较小，但每个 Pilot 加载的服务量增加，因为加载的是 Sidecar 依赖的并集；

图1

如果我们采用散列函数按服务依赖映射至 Pilot，单个实例加载的服务会减少，但是多个应用可能会映射到同一 Pilot，连接数又会增加，造成不均匀问题（如图2所示）。

图2

所以，我们需要寻找一个最优解。

问题描述

首先我们简化问题，只在应用维度进行 Sidecar 分配，同时为了更好的地理解问题，我们进行以下抽象：

• 已知：
  • 提供一个应用列表 A，以及每个应用对应的 Sidecar 数量 n；
  • 对于每个应用 a，提供一个服务依赖列表 D；
  • 已知一个 Pilot 集群，并有 m 个实例。
• 条件：
  • 为了保障 Sidecar 由访问的顺畅，防止惊群，在整个过程中 Pilot 的加载的服务只增不减（即使应用迁移到其它 Pilot 上，加载的数据依然存在），请谨慎调整应用连接的 Pilot；
  • 需要支持应用增减，Sidecar 扩容、缩容，变化后每个 Sidecar 需要的服务需要在对应的 Pilot 上找到，不得缺失。
• 求：
  • 每个 Pilot 实例需要挂载的应用列表 P(L)（i ∈ [0, m-1]）。

【复赛预览】实现一个 Serverless 计算服务调度系统

赛题背景

Serverless 计算服务（如函数计算）根据实际代码执行时间和资源规格收费，让使用者无需为闲置资源付费，背后是服务方采用各种手段优化服务端资源利用率。在优化的过程中，一个关键的问题是平衡请求响应时间和资源利用率，即如何在响应延迟可接受范围内使用尽可能少的资源。Serverless计算服务支撑场景的多样性以及不同应用对于响应延迟的不同要求，也给优化带来了一些额外的空间。本题目是关于如何设计和实现一个 Serverless 计算服务的调度系统。

赛题设置

• 系统分为APIServer，Scheduler和ResourceManager 3个组件，其中APIServer和ResourceManager由平台提供，Scheduler由选手实现。
• APIServer提供了Invoke API，该API接受函数名称和event，返回执行结果。
• ResourceManager提供了ReserveNode API获得Node和ReleaseNode API释放Node，该Node上有容器管理服务，选手可以调用管理服务在Node上为函数创建和销毁容器。其中函数实现已提供，选手无需关注。
• 当APIServer接收到Invoke请求后会调用Scheduler的AquireContainer API获得执行函数需要的容器，在该容器上执行函数，执行成功后调用ReturnContainer API归还容器。

指标定义

• 资源使用时间：获得Node成功后开始计时，同一Node释放成功后结束计时，其差值为资源使用时间。
• 调度延迟：调用AquireContainer所需时间。

赛题描述

评测程序会以不同QPS调用多个函数，计算调度延迟和资源使用时间，按照一定规则对结果评测。