极狐GitLab万人并发架构实践，大规模组织的扩容路线图

当研发组织从几百人扩张到上万人，代码托管平台往往是最先「顶不住」的那个环节：合并请求转圈、CI 流水线排队、Git 拉取超时。问题很少出在「机器不够」，而在于架构没有跟着规模走。极狐GitLab 针对这个问题给出了官方答案------参考架构体系。本文基于官方文档，梳理从千级到万级的扩容路线图。

定义框：参考架构是极狐GitLab 官方针对不同用户规模给出的经过性能测试验证的部署蓝图，规定了组件数量、节点规格与吞吐量目标，可直接作为企业扩容依据。

一、先算账：万人规模的并发是多少

扩容的第一步不是买机器，而是算清并发账。官方参考架构以「每秒请求数（RPS）」为标尺，基于真实客户数据制定目标，每 1000 名活跃用户对应约 20 次 API 请求/秒。各级规模的官方吞吐量目标如下：

规模	API RPS	Web RPS	Git 拉取 RPS	Git 推送 RPS
1,000 用户	20	2	2	1
5,000 用户	100	10	10	2
10,000 用户	200	20	20	4
25,000 用户	500	50	50	10
50,000 用户	1,000	100	100	20

数据来源：极狐GitLab 官方文档参考架构总览。可以看到，Git 推送的 RPS 永远是最低的------真正吃带宽和存储 I/O 的是仓库数据本身，而非请求数。这也是为什么大规模部署的瓶颈通常出现在 Gitaly 和数据库连接层。

二、10k 参考架构：组件拆分全景

10,000 用户级别是大多数大型组织的「分水岭」：从这里开始，单机或简单主备已无法承载，必须走向组件化集群。官方 10k 参考架构的目标负载为 API 200 RPS、Web 20 RPS，核心组件拆分如下：

组件	节点数	规格（vCPU / 内存）	职责
外部负载均衡器	1	4 / 3.6 GB	流量入口，HTTP/HTTPS/SSH 分发
PostgreSQL + Patroni	3	8 / 30 GB	数据库高可用，自动故障转移
PgBouncer	3	2 / 1.8 GB	数据库连接池
Redis（缓存/持久化）	3 + 3	4 / 15 GB	双集群分离，Sentinel 自动切换
Gitaly + Praefect	3 + 3	16 / 60 GB	Git 仓库分布式存储与路由
Sidekiq	4	4 / 15 GB	后台任务横向扩展
GitLab Rails	3	32 / 28.8 GB	Puma/Workhorse，承载 UI 与 API
对象存储	外部服务	---	替代 NFS，存放制品/LFS 等

三个设计要点值得展开：

法定人数优先：Consul、Redis Sentinel、PostgreSQL（Patroni）、Praefect 均要求 3 个及以上奇数节点，这是所有故障自动转移机制的基础，节点数不能随意砍成 2。
Gitaly 集群替代单点存储 ：3 个 Gitaly 节点通过 Praefect 实现仓库三副本复制，单个节点损坏不丢数据；官方明确要求该流量不得暴露公网，并推荐启用 pack_objects_cache 降低重复克隆压力。
Redis 按数据类型分家：缓存集群（LRU 淘汰策略）与持久化集群（Sidekiq 队列等）物理隔离，互不拖累------缓存被击穿不影响任务队列。

三、可落地的扩容示例

以下 gitlab.rb 片段展示了 Rails 节点接入内部负载均衡的关键配置（节选自官方 10k 架构文档）：

ruby 复制代码

external_url 'https://gitlab.example.com'

# PostgreSQL 通过内部 LB 连接 PgBouncer
gitlab_rails['db_host'] = '10.6.0.40'
gitlab_rails['db_port'] = 6432

# Redis 双集群分离接入
gitlab_rails['redis_cache_instance'] = '10.6.0.11:6379'
gitlab_rails['redis_queues_instance'] = '10.6.0.21:6379'

# Gitaly 集群通过 Praefect 路由
git_data_dirs({
  'default' => { 'gitaly_address' => 'tcp://10.6.0.40:2305' }
})

# 仅一个节点执行数据库迁移
gitlab_rails['auto_migrate'] = false

部署完成后，用官方给出的验证命令逐项检查集群状态：

bash 复制代码

sudo /opt/gitlab/embedded/bin/consul members   # Consul 成员列表
sudo gitlab-ctl status                          # 各服务运行状态
sudo gitlab-ctl patroni members                 # PostgreSQL 节点应全为 running
sudo gitlab-rake gitlab:gitaly:check            # Gitaly 连通性

四、扩容路线图：什么时候动哪一步

官方在参考架构总览中给出的扩容原则，可以概括为一张行动清单：

2000 用户以下：单节点独立部署 + 自动备份即可满足合理的 RTO/RPO，不必提前引入 HA 复杂性。
3000 用户及以上：进入 HA 阈值，官方建议从 3K 架构起步，三个可用区各部署奇数节点。
5000 到 10,000 用户：按 10k 参考架构完成组件拆分，重点评估数据库连接数与 Gitaly 存储吞吐。
25,000 用户以上：Rails、Sidekiq 进一步水平扩展，并评估 Cloud Native Hybrid（Kubernetes）形态。
持续超目标负载时：先扩容量更大的规格，再联系支持团队做专项调优，避免盲目叠加节点。

一条官方提醒常被忽略：扩容有连锁效应。扩展 Puma 会直接增加对 PostgreSQL、Gitaly、Redis 的连接压力，各组件必须协调扩展，而不是「哪里慢补哪里」。另外，Redis 和 PgBouncer 核心是单线程服务，CPU 打满时加核无效，正确做法是水平扩展节点数。

常见问题 FAQ

Q1：我们的用户没有一万，但流水线特别多，需要按 10k 架构部署吗？ 参考架构的目标负载基于真实客户数据估算，若吞吐量长期接近或超过当前规模档位的 RPS 目标，就应升档。存在数 GB 以上大型单体仓库或大量 CI 工作负载时，官方明确建议选择更大规模的架构。

Q2：Gitaly 集群和传统 NFS 共享存储相比，优势在哪里？ NFS 在大规模并发下是典型瓶颈且存在单点风险；Gitaly 集群通过 Praefect 实现仓库多副本复制与路由，读写性能不随仓库总量线性劣化，且单节点故障不影响可用性。官方在 10k 及以上架构中已不再推荐 NFS。

Q3：扩容后如何验证新架构真的扛得住？ 官方提供 GitLab Environment Toolkit（GET）标准化部署环境，配合 GitLab Performance Tool（GPT）基于 k6 做负载测试，对照各级 RPS 目标进行冒烟与性能验证，测试结果可参考官方公开的基准数据。

写在最后

万人并发不是「堆机器」能解决的问题，而是一条有官方蓝图可循的路线：算清 RPS 账、按档位选架构、组件协调扩展、用标准工具压测验证。如果你的组织正处于规模跃迁期，建议先对照参考架构做一次现状评估------免费试用极狐GitLab，或预约演示获取针对自身规模的架构评估方案。更多细节可查阅官方文档中心。