GitLab 25,000用户参考架构设计与部署指南

GitLab 25,000用户参考架构设计与部署指南

gitlabhq GitLab CE Mirror | Please open new issues in our issue tracker on GitLab.com 项目地址: https://gitcode.com/gh_mirrors/gi/gitlabhq

前言

本文详细介绍了GitLab自托管版支持25,000用户或500请求/秒(RPS)的参考架构设计方案。该架构基于真实用户场景设计，经过严格性能测试验证，适用于中大型企业级部署场景。

架构概览

核心设计指标

• 目标负载能力：
  • API请求：500 RPS
  • Web请求：50 RPS
  • Git拉取操作：50 RPS
  • Git推送操作：10 RPS
• 高可用性：全组件高可用设计（Praefect PostgreSQL需第三方方案实现HA）
• 混合架构支持：支持传统部署与云原生混合部署模式

组件规格矩阵

| 服务组件 | 节点数 | 推荐配置 | GCP示例机型 | AWS示例机型 | Azure示例机型 | |-------------------------|--------|-------------------|-------------------|-----------------|----------------| | 外部负载均衡器 | 1 | 8 vCPU, 7.2GB内存 | n1-highcpu-8 | c5n.2xlarge | F8s v2 | | Consul集群 | 3 | 2 vCPU, 1.8GB内存 | n1-highcpu-2 | c5.large | F2s v2 | | PostgreSQL数据库 | 3 | 16 vCPU, 60GB内存 | n1-standard-16 | m5.4xlarge | D16s v3 | | PgBouncer连接池 | 3 | 2 vCPU, 1.8GB内存 | n1-highcpu-2 | c5.large | F2s v2 | | 内部负载均衡器 | 1 | 8 vCPU, 7.2GB内存 | n1-highcpu-8 | c5n.2xlarge | F8s v2 | | Redis缓存集群 | 3 | 4 vCPU, 15GB内存 | n1-standard-4 | m5.xlarge | D4s v3 | | Redis持久化集群 | 3 | 4 vCPU, 15GB内存 | n1-standard-4 | m5.xlarge | D4s v3 | | Gitaly存储服务 | 3 | 32 vCPU, 120GB内存| n1-standard-32 | m5.8xlarge | D32s v3 | | Praefect代理层 | 3 | 4 vCPU, 3.6GB内存 | n1-highcpu-4 | c5.xlarge | F4s v2 | | Sidekiq后台任务 | 4 | 4 vCPU, 15GB内存 | n1-standard-4 | m5.xlarge | D4s v3 | | GitLab Rails应用 | 5 | 32 vCPU, 28.8GB内存| n1-highcpu-32 | c5.9xlarge | F32s v2 | | 监控节点 | 1 | 4 vCPU, 3.6GB内存 | n1-highcpu-4 | c5.xlarge | F4s v2 |

架构详解

网络拓扑设计

整个架构采用分层设计模式，主要分为以下几个层次：

1. 接入层：外部负载均衡器处理用户请求
2. 应用层：GitLab Rails和Sidekiq组成无状态服务集群
3. 数据层：
   • PostgreSQL数据库集群
   • Redis缓存/持久化集群
   • Gitaly存储集群
4. 控制层：Consul服务发现和监控组件

关键设计考量

1. Redis分离设计：

   • 独立缓存和持久化实例
   • Redis单线程特性，增加核心数不会显著提升性能
   • 分离设计可避免不同类型操作相互干扰

2. Gitaly集群：

   • 提供存储容错能力
   • 需注意大型单体仓库(monorepo)的性能影响
   • 建议仓库大小控制在GB级别以内

3. 自动扩展能力：

   • Sidekiq和GitLab Rails节点支持自动扩展
   • 状态化数据节点不建议自动扩展

部署实施指南

前置准备

1. 确保所有节点位于同一私有网络(10.6.0.0/24)
2. 准备SSL证书（如需HTTPS）
3. 配置对象存储服务

组件配置步骤

1. 负载均衡器配置

外部负载均衡器：

• 开放端口：80(HTTP)、443(HTTPS/TCP)、22(SSH)
• 健康检查端点配置
• WebSocket支持（用于Web终端）

内部负载均衡器：

• 处理内部服务通信
• 建议使用云服务商提供的LB服务

2. 数据库层配置

PostgreSQL集群：

• 1主2从架构
• 配置流复制
• 建议使用云数据库服务（如AWS RDS）

PgBouncer：

• 连接池大小建议：pool_size = 20
• 配置健康检查

3. Redis配置

# 缓存Redis
gitlab_rails['redis_cache_instance'] = "redis://10.6.0.51:6379"
gitlab_rails['redis_cache_password'] = "REDIS_PASSWORD"

# 持久化Redis
gitlab_rails['redis_queues_instance'] = "redis://10.6.0.61:6379"
gitlab_rails['redis_shared_state_instance'] = "redis://10.6.0.61:6379"

4. Gitaly集群配置

# Gitaly配置示例
socket_path = "/var/opt/gitlab/gitaly/gitaly.socket"
runtime_dir = "/var/opt/gitlab/gitaly"
[[storage]]
name = "default"
path = "/var/opt/gitlab/git-data/repositories"

5. GitLab Rails配置

external_url 'https://gitlab.example.com'
gitlab_rails['db_adapter'] = "postgresql"
gitlab_rails['db_host'] = "10.6.0.40" # 内部LB地址
gitlab_rails['db_password'] = "DB_PASSWORD"

性能优化建议

1. 大型仓库处理：

   • 增加Gitaly节点资源
   • 考虑仓库分片策略

2. 高负载场景：

   • 扩展Rails节点数量
   • 优化Sidekiq队列配置

3. 监控指标：

   • 关注P99响应时间
   • 设置数据库连接池告警

验证与测试

性能基准

GitLab官方测试验证了以下场景：

• 持续500 RPS API请求
• 50 RPS Web访问
• 50 RPS Git拉取操作
• 10 RPS Git推送操作

扩展建议

当出现以下情况时应考虑扩展架构：

1. 持续超过基准RPS指标
2. 存在超大单体仓库(>5GB)
3. 额外集成工作负载增加

总结

本文描述的25,000用户参考架构提供了GitLab企业级部署的标准化方案。实际部署时需根据具体业务需求调整资源配置，特别是对于有特殊性能要求的场景。建议生产环境部署前在测试环境充分验证系统性能表现。

gitlabhq GitLab CE Mirror | Please open new issues in our issue tracker on GitLab.com 项目地址: https://gitcode.com/gh_mirrors/gi/gitlabhq