Compass-CI 架构揭秘：微服务设计与分布式集群实现原理-拓冰建站

Compass-CI 架构揭秘：微服务设计与分布式集群实现原理

【免费下载链接】compass-ciCompass-CI 是一个可持续集成的开源软件平台。为开发者提供针对上游开源软件（来自 Github, Gitee, Gitlab 等托管平台）的测试服务、登录服务、故障辅助定界服务和基于历史数据的分析服务。项目地址: https://gitcode.com/openeuler/compass-ci

前往项目官网免费下载：https://ar.openeuler.org/ar/

在开源软件持续集成领域，Compass-CI（Compass Continuous Integration）是一个功能强大的可持续集成平台。它为开发者提供了针对上游开源软件的自动化测试服务、登录服务、故障辅助定界服务和基于历史数据的分析服务。本文将深入解析Compass-CI的微服务架构设计和分布式集群实现原理，帮助您理解这个复杂系统的内部工作机制。

🏗️ 整体架构概览

Compass-CI采用了解耦架构设计，由几十个微服务和工具脚本组成。每个组件都是相对独立的小程序，便于理解和维护。系统主要分为服务端和客户端两个部分：

服务端代码：约1.1万行Ruby、6千行Crystal、6千行Shell
客户端代码：约3万行Shell、2万行Ruby（主要运行在测试机和客户端）

图1：Compass-CI整体架构图展示了系统的核心组件和交互关系

🔧 微服务架构设计

1. 微服务拆分原则

Compass-CI的微服务设计遵循单一职责原则，每个服务专注于特定的功能：

API代理服务：container/api-proxy/ - 处理API请求转发和负载均衡
数据API服务：container/data-api/ - 提供数据查询和存储接口
助手服务：container/assistant/ - 提供辅助功能如文件定位、邮件列表获取
账户分配服务：container/assign-account/ - 管理用户账户分配
结果处理服务：container/assist-result/ - 处理测试结果

2. 多语言技术栈选择

Compass-CI在语言选择上体现了实用主义原则：

Crystal语言：用于高性能、高安全性的服务组件
Ruby语言：用于便利性的小脚本和工具
Shell脚本：用于测试机上的框架代码，兼容内存受限系统

图2：Crystal与Go在微服务场景下的性能对比

3. 为什么选择Crystal而不是Go？

Compass-CI团队选择了Crystal作为主要的服务端语言，主要基于以下考虑：

动态数据结构处理：核心数据结构job.yaml具有动态性，Crystal的union类型特性使其能优雅处理动态YAML/JSON
ElasticSearch兼容性：核心数据库是ElasticSearch，Crystal完美支持动态JSON结构
Ruby生态继承：Crystal完美继承了Ruby语法和标准库，与现有Ruby代码协同性好
开发体验优秀：Crystal具有脚本语言的开发体验，但提供静态语言的性能和安全性

🌐 分布式集群实现

1. 集群架构设计

Compass-CI的分布式集群采用分层设计：

┌─────────────────────────────────────────────┐ │ 客户端层 (Client) │ │ • submit命令提交任务 │ │ • 本地job解析和预处理 │ └─────────────────┬───────────────────────────┘ │ ┌─────────────────▼───────────────────────────┐ │ 调度器层 (Scheduler) │ │ • 任务队列管理 │ │ • 资源分配和调度 │ │ • 负载均衡 │ └─────────────────┬───────────────────────────┘ │ ┌─────────────────▼───────────────────────────┐ │ 执行机层 (Testbox) │ │ • 容器测试机 (dc-*) │ │ • 虚拟机测试机 (vm-*) │ │ • 物理机测试机 (自定义) │ └─────────────────┬───────────────────────────┘ │ ┌─────────────────▼───────────────────────────┐ │ 存储层 (Storage) │ │ • ElasticSearch - 文档存储 │ │ • Redis - 缓存和队列 │ │ • 文件系统 - 测试结果存储 │ └─────────────────────────────────────────────┘

2. 测试机类型管理

Compass-CI支持多种类型的测试机，通过testbox字段进行标识：

容器测试机：以dc-开头，如dc-8g
虚拟机测试机：以vm-开头，如vm-2p8g
物理机测试机：自定义名称，如taishan200-2280-2s64p-256g

测试机配置文件存储在以下位置：

$CCI_REPOS/lab-$lab/hosts/- 实验室特定配置
$LKP_SRC/hosts/- 全局默认配置

3. 任务调度机制

任务调度是Compass-CI的核心功能，主要流程如下：

任务提交：用户通过submit命令提交job.yaml文件
任务解析：调度器解析job文件，处理依赖和参数
资源匹配：根据testbox、os、arch等参数匹配可用资源
队列管理：任务进入相应的队列等待执行
执行分配：调度器将任务分配给合适的测试机
状态监控：实时监控任务执行状态

📊 数据流与通信机制

1. 任务数据流

# 典型的job.yaml文件结构 suite: iperf category: benchmark runtime: 300s cluster: cs-localhost if role server: iperf-server: if role client: iperf: protocol: - tcp - udp

2. 微服务间通信

Compass-CI微服务间采用多种通信方式：

HTTP/REST API：用于服务间同步通信
消息队列：用于异步任务处理
文件系统：用于大文件传输和共享
数据库：用于状态共享和数据持久化

3. 弹性扩展设计

系统支持水平扩展，关键组件都可以独立部署和扩展：

无状态服务：API服务、助手服务等可以多实例部署
有状态服务：数据库、消息队列等需要特殊处理
负载均衡：通过API代理实现请求分发

🔄 核心工作流程

1. 任务提交流程

客户端预处理：解析job.yaml，加载配置文件
调度器接收：接收任务，进行必要检查
资源分配：根据testbox等参数分配测试机
任务执行：在测试机上执行测试脚本
结果收集：收集测试结果并存储
状态更新：更新任务状态，通知用户

2. 错误处理机制

Compass-CI实现了完善的错误处理：

自动重试：对可重试错误进行自动重试
故障转移：当某个组件失败时自动切换到备用组件
日志记录：详细的日志记录便于问题排查
告警通知：关键错误通过邮件等方式通知相关人员

🚀 性能优化策略

1. 并发处理

图3：Crystal与Go在并行处理场景下的性能对比

2. 缓存策略

Redis缓存：用于频繁访问的数据缓存
内存缓存：用于热点数据的内存缓存
CDN缓存：用于静态资源的CDN缓存

3. 数据库优化

ElasticSearch索引优化：合理设计索引结构
查询优化：使用高效的查询语句
分片策略：合理的数据分片策略

🔧 部署与运维

1. 容器化部署

所有微服务都采用Docker容器化部署：

# 示例：数据API服务的Dockerfile FROM debian:bookworm COPY />
图4：Crystal与Go在JSON解析场景下的性能对比
该架构的主要优势包括：
高可用性：微服务架构提高了系统的可用性
易扩展性：可以独立扩展各个组件
技术多样性：根据需求选择最合适的技术栈
维护便利：小规模的微服务便于理解和维护
随着开源软件的快速发展，Compass-CI的架构设计为大规模、高效率的持续集成提供了可靠的技术支撑。无论是对于开源项目的自动化测试，还是对于企业级的CI/CD流水线，Compass-CI都提供了值得借鉴的架构实践经验。
了解更多关于Compass-CI的技术细节，请参考项目文档：doc/development/why-crystal.md 和 doc/job/job_workflow.md
【免费下载链接】compass-ciCompass-CI 是一个可持续集成的开源软件平台。为开发者提供针对上游开源软件（来自 Github, Gitee, Gitlab 等托管平台）的测试服务、登录服务、故障辅助定界服务和基于历史数据的分析服务。项目地址: https://gitcode.com/openeuler/compass-ci