51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 648|回复: 0
打印 上一主题 下一主题

[原创] 大厂的工程效能CI/CD之流水线引擎的建设实践(下)

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2022-10-27 15:56:15 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
本帖最后由 草帽路飞UU 于 2022-10-27 15:57 编辑

4.2 资源池划分设计

1)整体方案

  我们采用多队列的设计,结合标签建立作业队列与资源池的匹配关系,以保障不同队列资源的有效划分,在出现队列积压、资源池故障、无可扩资源等情况时,最大限度地降低影响范围,避免所有作业全

局排队等待的现象。




图9 资源池架构

2)模型关系



图10 资源池模型对象

作业队列与标签的关系:队列与标签采用1对1的关系,降低业务理解和运维成本。


  当队列积压时,能快速定位到某个标签没资源了。


  标签资源不足时,也能快速判断影响的具体队列情况。


  标签与资源池的关系:标签和资源池采用多对多的关系,主要从资源整体利用率和对核心队列的资源可用性保障考虑。


  对于一些作业量较少的队列,单独分配一个资源池会造成大部分时间资源是空闲状态,资源利用率低。我们通过给资源池打多标签的方式,既保证了队列有一定的资源配额,同时也能处理其他标签的作


业,提高资源的利用率。

  对于核心场景的队列,通常标签资源会分配到多个资源池上,保证资源的一定冗余,同时也降低单个资源池整体故障带来的影响。


  3)标签设计


标签的目的是建立资源(池)与作业(队列)的匹配关系。在设计上,为便于标签管理和后期维护,我们采用二维标签的形式,通过组件和流水线两个维度,共同决定一个作业所属标签及对应的资源。

  第一维度:组件维度,对资源做通用划分。结合组件的业务覆盖情况、作业执行量、对机器和环境的特殊要求(如SSD、Dev环境等),对需要独立资源的组件进行打标,划分出不同的公共资源池(每个


公共资源池执行一类或多类组件作业),在引擎层面统一分配,保证所有作业都有可正常运行。

  第二维度:流水线维度,根据业务场景进行划分。结合业务对资源隔离/作业积压敏感度的诉求,按需进行划分。有些希望资源完全独立的业务,会从所有的公共资源池进行切分;有些仅对部分核心场景


下的资源需要保障,根据链路上涉及的组件,选择性地从部分公共资源池进行划分,实现业务隔离和资源利用率的平衡。

  注:每个维度都会设一个other的默认值用来兜底,用于处理无资源划分需求的场景。



图11 标签设计

4)队列拆分设计


根据作业所属标签不同拆分出多个队列,保证每个队列的独立性,降低作业积压的影响范围。整个拆分过程可以分为入队和出队两部分:

  入队过程:通过计算作业在组件和流水线两个维度的属性值,来确定作业对应的标签。结合模型关系中标签与队列(1对1)的关系,为每个标签按需创建一个队列,存储该标签作业,不同队列间作业做排


他处理,简化出队的实现复杂度。

  出队过程:队列拆分后,因为标签和资源池(多对多)的关系,资源池的一次作业拉取请求往往会涉及多个队列。出于拉取效率的考虑,采用轮询的方式依次对单队列进行出队操作,直到达到该次请求的


作业数上限或所有可选队列为空时返回结果。该方式可以避免同时对多个队列加锁,并且在前置环节会对多标签进行随机排序,降低多个请求同时操作一个队列的竞争概率。


图12 队列拉取设计

4.3 组件分层设计


  1)分层架构


图13 组件架构设计

业务层:引入适配层,满足组件开发中多样化的需求场景,同时避免上层差异污染到下层。


  系统交互层:设立统一的流程标准,保证引擎和组件交互过程的一致性,便于统一处理非功能性的系统优化。


  执行资源层:提供多种资源策略,向上层屏蔽不同资源类型的差异。


 2)标准的交互流程设计


  在系统交互层,组件与引擎交互的过程中,有两个环节是确定的,①组件作业的状态机流转,这涉及到组件执行的整个生命周期管理,若允许存在不同的状态流转关系,整个管理过程会十分混乱;②引擎

对外提供的接口范围,从服务间解耦的角度,对外提供的接口主要是组件作业维度的接口操作,不应该耦合任何组件内部的实现细节。

  结合作业状态机 + 引擎提供的接口,确定了组件执行基本的系统交互流程。利用模版模式,抽象出init()、run()、queryResult()、uploadArtifacts() 等必要方法供业务实现,整个交互流程则由系统统一


处理,业务无需关心。


图14 组件标准流程设计

3)扩展基础能力


 组件执行除了正常的执行流程外,随着业务场景的丰富,还会涉及组件中止、回调(人工审批场景)等操作,这些操作的引入势必会改变原先的交互流程。为了不增加额外的交互复杂度,在拉取作业环

节,增加作业的事件类型(运行、中止、回调等事件),Worker根据拉取到的不同事件,执行相应的扩展逻辑。同时,引入新的扩展也不会影响到已有的交互流程。


图15 组件扩展能力设计

基于上述扩展,我们可能更好地将一些通用能力下沉到Daemon Thread层。如结果查询流程,通过守护线程的方式,取消了原先同步等待的查询限制,这对于需要异步化处理的场景(如组件作业逻辑已执行


完,仅在等待外部平台接口返回结果)可以提前释放资源,提高资源执行的利用率。并且,当执行资源故障重启后,结果查询线程会自动恢复待处理异步作业。这部分能力的支持在业务层是透明的,不改变整

个交互流程。

 4)引入适配器


业务虽可以通过必要方法完成自定义组件,但这些方法过于基础,业务在一些特定场景下实现成本较高。如对于组件支持Shell的脚本化调用,业务其实仅需提供可执行的Shell即可,通用约定的方式,其

他必要方法的实现都可以交由系统完成。

  针对业务个性化的处理,采用适配器模式,通用引入不同Command(ShellCommand、xxCommand)来默认实现特定场景下的必要方法,降低业务的开发成本。同时,保持系统侧流程的一致性,通过


动态注入 Command的方式,防止对业务个性化处理的耦合。


图16 组件适配器设计

5)效果


  目前已支持Shell组件、服务组件、容器组件等多种接入方式,平台上已提供数百个组件,组件开发方涉及数十个业务线。组件库覆盖源码域、构建域、测试域、部署域、人工审批域等多个环

节,打通了研发过程所涉及的各个基础工具。


图17 组件库

5. 后续规划


       借助Serverless等云原生技术,探索更轻量、高效的资源管理方案,提供更精细化的资源策略,从资源的弹性、启动加速、环境隔离三个方面为业务提供更优的资源托管能力。

  面向组件开发者,提供从开发、上线到运营的一站式开发管理平台,降低组件开发、运营成本,使更多工具方、个人开发者能参与其中,共同打造丰富多样的业务场景,形成良性的组件运营生态。













本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

x
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-9-27 06:11 , Processed in 0.067080 second(s), 25 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表