赛题解析|初赛赛道三：服务网格控制面分治体系构建

首届云原生编程挑战赛正在报名中，初赛共有三个赛道，题目以下：

赛道一：实现一个分布式统计和过滤的链路追踪 赛道二：实现规模化容器静态布局和动态迁移 赛道三：服务网格控制面分治体系构建

当即报名（报名时间即日起至06/29）：https://tianchi.aliyun.com/specials/promotion/cloudnative#problem-definition

本文主要针对赛道三题目作出剖析，帮助选手更高效的解题。

背景知识

“服务网格” 是近年来很是火热的技术，其全托管的思惟很是适合云原生场景。“服务网格” 核心分为控制面与数据面：数据面主要是一个名为 Sidecar 的代理组件，它经过接收控制面发送的路由与控制信息来定向转发或处理数据。这样一些坐落在服务网格里的应用就将整个分布式逻辑交给了底层，本身不用关心了。一旦与底层解耦，灵活性大大增长，更符合云原生的标准。

题目解析

本题的核心考查点仍是如何让服务网格的控制面支撑大规模的 Sidecar 实例。为何会产生这个问题呢？由于在目前服务网格影响最广的实现 Istio 架构中，控制平面 Pilot 负责整个系统的路由转译工做，也就是说全部服务的实例信息都须要经过 Pilot 下发给每个 Sidecar，固然用户能够经过 SidecarScope 来设置个别 Sidecar 对于系统服务的可见性，但这只会影响到 Sidecar 接受到的数据而已，Pilot 仍然是全量从注册中心同步（例如 Consul，K8s 的 CoreDNS 等），如此一来随着接入应用的增长，Pilot 不能横向扩容，很快便会成为性能瓶颈（内存不够用啊）。

题目提出了分治的解法，而选手们的任务就是优化分治逻辑，使总体负载均衡。为了理解题目，咱们首先须要弄清楚什么是分治。所谓的分治就是将负载分红一个个独立的子系统，而后分别处理他们，这样就将问题化小了，好比咱们常见的合并排序，就是分治的典型应用。按题目的解释，控制面的分治是按应用维度进行划分的，也就说坐落在服务网格中的应用将被划分到不一样的子系统中。

上图中，就被划分红了左右两个子系统。应用之间存在相互依赖即服务依赖，在本题中一个应用只提供一个服务，所以应用所链接的 Pilot 须要加载的数据就是其依服务。因为分治的存在，每一个 Pilot 不须要加载全部的服务了，这样当更多的应用接入时，咱们就能够进行横向扩容解决容量问题。

上图中为何每一个分治组加载的数据不是彻底隔离的呢？这里的缘由是应用的依赖是错综复杂的，若是咱们把每一个应用一个点表示，依赖用一条线表示，那么实际生产中，几乎是不可能造成孤岛的，缘由是：每一个应用依赖的服务是有重叠的，并且不少。

这样咱们便不能随意地划分应用，由于若是咱们将依赖类似度很高的应用划分到不一样的 Pilot 上，会致使一样的依赖在多个 Pilot 上加载，形成内存消耗增长。反过来，若是将全部应用都挂到同一个 Pilot 上，那么加载的内存总量是最少的，不过链接就极度不均匀了。

因此本题要求选手优化分治逻辑，让分治系统均匀承压。咱们先来看看一评分的公式：

公式也不复杂，分为三个评分项：

1. Pilot 实际加载内存与理想内存的占比，上文提到，不一样应用之间依赖的服务可能会有重叠，所以最理想的状态就是全部服务依赖在整个 Pilot 系统中只加载一次，简单来讲就是将有类似依赖的应用都划分到同一个 Pilot 中；
2. Pilot 的内存标准差，这个就比较直白了，就是让 Pilot 加载的服务尽可能均衡，不要出现一个 Pilot 加载不少数据，另外一个空闲的状态；
3. Pilot 链接的标准差，这个与上面的相似，就是要求 Pilot 链接的 Sidecar 尽可能均衡。

因为实际加载的内存确定是大于等于理想状态内存，所以最左边的分子式始终于大于 1 的，也就是说，这是一个倍率；而标准差是大于等于 0 的，显然想要两个标准差同时为 0 不现实。所以选手的任务就是分配应用，让

1. 每一个 Pilot 加载的服务数相近；
2. 每一个 Pilot 链接的 Sidecar 相近；
3. 尽可能不要重复加载服务。

什么意思呢，既然咱们已经知道了分治就是让应用链接不一样的 Pilot ，那么每一个应用链接上 Pilot 后便会给其必定的压力。

链接的应用越多，压力越大，但因为服务存在重叠的现象，所以并不彻底是线性关系。例如上图中另外一个应用 E 连 接上来后，若是其依赖的服务是 [服务A，服务B，服务E]，那么 Pilot 加载的服务仅会增加 1。这就很好的节省了内存开销。

所以，如何分配应用至每一个 Pilot 上，使其知足公式所示条件，就是本题的操做空间与须要解决的问题。

须要特别注意的是，本题评分分为了 两个阶段，一个是静态的，选手能够一次性拿到一阶段全部数据，这样咱们就能够总体分析。二阶段数据都是实时分批给的，所以如何让动态的数据也具有良好的表现亦是解题的一个关键点。另外还须要注意的一点，Pilot 加载的数据是只境不减的，由于在实际生产环境中，不可能将一个应用瞬间迁移到另外一个 Pilot 上，所以已有的数据须要保留。

解题思路

既然咱们知道了得分的要点，那咱们就能够围绕这三个点来优化。如下给你们一些分析，以供解题。固然解法不少，下面只是一个列举。

仅量不要重复加载服务数据

固然是让依赖相同的应用出如今同一个 Pilot 上，所以咱们能够分析应用依赖的类似度，把类似度高的应用归组一块儿分配。由于依赖是一个列表，咱们能够将其视为一个基因片断或者字符串中的一个字符，问题便成了如何在海量字符串中找到类似的。

Pilot 链接的 Sidecar 相近

固然是每一个 Pilot 都同样为好，理想状态是均分。平均说到是简单，可是咱们可不能像切蛋糕那样作呀。每一个应用的实例有大有小，那么这里的问题就化为了有一串物品，N 个包他们的价值为 a1, a2, a3……，咱们如何放置才能使每一个包里物品的价值接近平均值，虽然咱们有两个要求相近的值（内存与链接），不过若是咱们再把物品的重量考虑进来，参数维度就增长了。

第二阶段动态部分

因为第二阶段的数据是不能一次性获得的，所以如何利用已有的数据便成了关键，这里一个方向是相似基于已排序数列进行插入再排序的思想，如何构造这样的一个状态即是关键。

如何拿好成绩

因为得分公式是一个总体，单单提高一个是得不到好成绩的，所以要想拿好结果，建模是须要的，这样咱们才能知道哪一个才是最大的影响因子，或者甚至可以消除一个变量，那就更好了。

以上内容来自赛道三的明星导师玄胤。

做者信息： 玄胤，阿里云高级技术专家，8 年专一软负载领域，从 0 到 1 写过服务百万实例的软负载产品，Nacos 奠定人，《Service Mesh 实战》做者，Istio 社区成员，3项国家发明专利。

挑战赛交流群

---

报名成功后，必定要记得加入我们的挑战赛交流群哦~

首届云原生编程挑战赛选手交流群（钉钉群）：

领取通关秘笈：关注“阿里巴巴中间件”公众号，回复：2020，获取大赛玩法解析（包含参赛玩法和奇葩任务的玩法）。