阿里云2020云原生编程挑战赛

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

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

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

enter image description here

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

赛题背景

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

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

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

静态布局

容器平台规模化建站

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

动态迁移

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

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

赛题准备

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

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

enter image description here

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

赛题内容

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

赛题挑战

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

静态布局

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

enter image description here

动态迁移

enter image description here

赛题数据

应用描述

  1. 集团中的应用信息实际以 “应用名 应用分组” 两个维度的形式呈现,同一个应用名下会有多个应用分组,不会出现一个应用分组对应多个应用名。对应关系是一对多的关系(appName:group=1:N)。
  2. 集团内部应用与应用、分组与分组之间有各种调度规则约束,如应用分时错峰、CPU/内存密集型应用交错布局,但本赛题简化问题描述,不增加这些复杂约束。
  3. 集团应用根据不同画像特性,cpu-model定义了cpu-share、cpu-set 两种类型,内存超卖技术还未规模化铺开,此处我们考量的是保证交易的稳定性的双11大促单元集群中的cpu-set模式、固定内存的核心应用。

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

问题背景

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

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

img

这里说明如下:

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

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

img 图1

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

img 图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调用多个函数,计算调度延迟和资源使用时间,按照一定规则对结果评测。


《大明王朝1566》王用汲 己溺己饥 给想注册公司的人泼个冷水 - v2ex