襄阳建设路21号创意园网站,做短视频网站用哪家cms,融通资源开发公司,wordpress获取文字首届云原生编程挑战赛正在报名中#xff0c;初赛共有三个赛道#xff0c;题目如下#xff1a;
赛道一#xff1a;实现一个分布式统计和过滤的链路追踪 赛道二#xff1a;实现规模化容器静态布局和动态迁移 赛道三#xff1a;服务网格控制面分治体系构建
立即报名#…首届云原生编程挑战赛正在报名中初赛共有三个赛道题目如下
赛道一实现一个分布式统计和过滤的链路追踪 赛道二实现规模化容器静态布局和动态迁移 赛道三服务网格控制面分治体系构建
立即报名报名时间即日起至06/29https://tianchi.aliyun.com/specials/promotion/cloudnative#problem-definition
本文主要针对赛道三题目做出剖析帮助选手更高效的解题。
背景知识
“服务网格” 是近年来非常火热的技术其全托管的思维非常适合云原生场景。“服务网格” 核心分为控制面与数据面数据面主要是一个名为 Sidecar 的代理组件它通过接收控制面发送的路由与控制信息来定向转发或处理数据。这样一些坐落在服务网格里的应用就将整个分布式逻辑交给了底层自己不用关心了。一旦与底层解耦灵活性大大增加更符合云原生的标准。
题目解析
本题的核心考查点还是如何让服务网格的控制面支撑大规模的 Sidecar 实例。为什么会产生这个问题呢因为在目前服务网格影响最广的实现 Istio 架构中控制平面 Pilot 负责整个系统的路由转译工作也就是说所有服务的实例信息都需要通过 Pilot 下发给每一个 Sidecar当然用户可以通过 SidecarScope 来设置个别 Sidecar 对于系统服务的可见性但这只会影响到 Sidecar 接受到的数据而已Pilot 仍然是全量从注册中心同步例如 ConsulK8s 的 CoreDNS 等如此一来随着接入应用的增加Pilot 不能横向扩容很快便会成为性能瓶颈内存不够用啊。 题目提出了分治的解法而选手们的任务就是优化分治逻辑使整体负载均衡。为了理解题目我们首先需要弄清楚什么是分治。所谓的分治就是将负载分成一个个独立的子系统然后分别处理他们这样就将问题化小了比如我们常见的合并排序就是分治的典型应用。按题目的解释控制面的分治是按应用维度进行划分的也就说坐落在服务网格中的应用将被划分到不同的子系统中。 上图中就被划分成了左右两个子系统。应用之间存在相互依赖即服务依赖在本题中一个应用只提供一个服务因此应用所连接的 Pilot 需要加载的数据就是其依服务。由于分治的存在每个 Pilot 不需要加载所有的服务了这样当更多的应用接入时我们就可以进行横向扩容解决容量问题。 上图中为什么每个分治组加载的数据不是完全隔离的呢这里的原因是应用的依赖是错综复杂的如果我们把每个应用一个点表示依赖用一条线表示那么实际生产中几乎是不可能形成孤岛的原因是每个应用依赖的服务是有重叠的而且很多。
这样我们便不能随意地划分应用因为如果我们将依赖相似度很高的应用划分到不同的 Pilot 上会导致同样的依赖在多个 Pilot 上加载造成内存消耗增加。反过来如果将所有应用都挂到同一个 Pilot 上那么加载的内存总量是最少的不过连接就极度不均匀了。
所以本题要求选手优化分治逻辑让分治系统均匀承压。我们先来看看一评分的公式 公式也不复杂分为三个评分项
Pilot 实际加载内存与理想内存的占比上文提到不同应用之间依赖的服务可能会有重叠因此最理想的状态就是所有服务依赖在整个 Pilot 系统中只加载一次简单来说就是将有相似依赖的应用都划分到同一个 Pilot 中Pilot 的内存标准差这个就比较直白了就是让 Pilot 加载的服务尽量均衡不要出现一个 Pilot 加载很多数据另一个空闲的状态Pilot 连接的标准差这个与上面的类似就是要求 Pilot 连接的 Sidecar 尽量均衡。
由于实际加载的内存肯定是大于等于理想状态内存因此最左边的分子式始终于大于 1 的也就是说这是一个倍率而标准差是大于等于 0 的显然想要两个标准差同时为 0 不现实。因此选手的任务就是分配应用让
每个 Pilot 加载的服务数相近每个 Pilot 连接的 Sidecar 相近尽量不要重复加载服务。
什么意思呢既然我们已经知道了分治就是让应用连接不同的 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获取大赛玩法解析包含参赛玩法和奇葩任务的玩法。
原文链接 本文为云栖社区原创内容未经允许不得转载。
