Help us learn about your current experience with the documentation. Take the survey.

参考架构

层级：免费版、高级版、旗舰版
提供方式：GitLab 自托管

GitLab 参考架构是经过验证的生产就绪型环境设计，用于大规模部署 GitLab。每个架构都提供了详细的规格说明，您可根据自身需求使用或调整。

可用的参考架构

以下是可供您的环境使用的推荐起始点。

这些架构根据峰值负载命名，基于用户数量或每秒请求次数（RPS）。RPS 是根据平均真实数据计算的。

每个架构都设计为可扩展且弹性。它们可根据工作负载相应地向上或向下调整。例如，一些已知的重负载场景，如使用大型单体仓库或显著的额外工作负载。

有关每个参考架构测试内容的详细信息，请参阅各页面的「测试方法」部分。

GitLab 软件包（Omnibus）

以下是基于 Linux 软件包的参考架构列表：

最多 20 RPS 或 1,000 用户 API: 20 RPS，Web: 2 RPS，Git（拉取）: 2 RPS，Git（推送）: 1 RPS
最多 40 RPS 或 2,000 用户 API: 40 RPS，Web: 4 RPS，Git（拉取）: 4 RPS，Git（推送）: 1 RPS
最多 60 RPS 或 3,000 用户 API: 60 RPS，Web: 6 RPS，Git（拉取）: 6 RPS，Git（推送）: 1 RPS
最多 100 RPS 或 5,000 用户 API: 100 RPS，Web: 10 RPS，Git（拉取）: 10 RPS，Git（推送）: 2 RPS
最多 200 RPS 或 10,000 用户 API: 200 RPS，Web: 20 RPS，Git（拉取）: 20 RPS，Git（推送）: 4 RPS
最多 500 RPS 或 25,000 用户 API: 500 RPS，Web: 50 RPS，Git（拉取）: 50 RPS，Git（推送）: 10 RPS
最多 1000 RPS 或 50,000 用户 API: 1000 RPS，Web: 100 RPS，Git（拉取）: 100 RPS，Git（推送）: 20 RPS

云原生混合架构

以下是云原生混合参考架构列表，其中部分推荐组件可在 Kubernetes 中运行：

最多 40 RPS 或 2,000 用户 API: 40 RPS，Web: 4 RPS，Git（拉取）: 4 RPS，Git（推送）: 1 RPS
最多 60 RPS 或 3,000 用户 API: 60 RPS，Web: 6 RPS，Git（拉取）: 6 RPS，Git（推送）: 1 RPS
最多 100 RPS 或 5,000 用户 API: 100 RPS，Web: 10 RPS，Git（拉取）: 10 RPS，Git（推送）: 2 RPS
最多 200 RPS 或 10,000 用户 API: 200 RPS，Web: 20 RPS，Git（拉取）: 20 RPS，Git（推送）: 4 RPS
最多 500 RPS 或 25,000 用户 API: 500 RPS，Web: 50 RPS，Git（拉取）: 50 RPS，Git（推送）: 10 RPS
最多 1000 RPS 或 50,000 用户 API: 1000 RPS，Web: 100 RPS，Git（拉取）: 100 RPS，Git（推送）: 20 RPS

开始之前

首先，考虑自托管方式是否适合您和您的需求。

在生产环境中运行任何应用程序都很复杂，GitLab也不例外。虽然我们力求让这个过程尽可能顺畅，但根据您的架构设计，仍会存在一些普遍的复杂性。通常，您需要管理所有方面，例如硬件、操作系统、网络、存储、安全、GitLab本身等等。这包括环境的初始设置以及长期的维护工作。

如果您决定采用这种方式，必须具备在生产环境中运行和维护应用程序的实际知识。如果您不具备这样的条件，我们的专业服务团队提供实施服务。那些想要长期更托管化解决方案的人，可以探索我们的其他产品，如 GitLab SaaS 或 GitLab Dedicated。

如果您正在考虑使用 GitLab 自托管方案，我们鼓励您完整阅读本页，特别是以下章节：

选择从哪个架构开始

参考架构旨在平衡三个重要因素：性能、弹性和成本。它们的设计目的是简化大规模部署 GitLab 的过程。然而，要知道哪种架构符合您的需求并据此启动，仍然可能是一个挑战。

作为一般指导原则，您希望环境越高性能或弹性越好，其复杂度就越高。

本节解释了选择参考架构时需考虑的事项。

预期负载（每秒请求数或用户数）

合适的架构规模主要取决于您环境的预期峰值负载。衡量该负载最客观的方式是通过进入环境的峰值每秒请求数（RPS）。

每种架构都针对不同类型的请求（API、Web、Git）设计了特定的 RPS 目标。这些细节在各个页面的 测试方法论 部分有描述。

确定 RPS 可能显著依赖于具体的环境配置和监控栈。一些潜在选项包括：

使用类似 sum(irate(gitlab_transaction_duration_seconds_count{controller!~'HealthController|MetricsController'}[1m])) by (controller, action) 查询的 [GitLab Prometheus](../monitoring/prometheus/_index.md#示例 Prometheus 查询)。
来自 GitLab 支持团队的 get-rps 脚本。
其他监控解决方案。
负载均衡器统计信息。

如果您无法确定 RPS，我们提供了一种基于等效用户数的替代性容量规划方法。该数量映射到典型的 RPS 值，同时考虑手动和自动化使用场景。

初始容量规划指南

要确定适合预期负载的架构，请参阅以下初始容量规划指南表：

负载类别	每秒请求量（RPS）				典型用户数	参考架构
负载类别	API	Web	Git 拉取	Git 推送	典型用户数	参考架构
超小型	20	2	2	1	1,000	最多 20 RPS 或 1,000 用户
小型	40	4	4	1	2,000	最多 40 RPS 或 2,000 用户
中型	60	6	6	1	3,000	最多 60 RPS 或 3,000 用户
大型	100	10	10	2	5,000	最多 100 RPS 或 5,000 用户
超大型	200	20	20	4	10,000	最多 200 RPS 或 10,000 用户
双倍大型	500	50	50	10	25,000	最多 500 RPS 或 25,000 用户
三倍大型	1000	100	100	20	50,000	最多 1000 RPS 或 50,000 用户

在选择初始架构前，请彻底阅读本节。需考虑其他因素（如高可用性（HA）或使用大型单体仓库），因为这些因素可能超出仅依据 RPS 或用户数量做出的选择范围。

如果不确定，先从较大规模开始，监控后再缩小规模

若您对所需环境规模存疑，可考虑先从较大规模入手，监控其运行情况，再根据指标缩小规模。

从较大规模开始再逐步缩小是一种审慎的做法，适用于以下场景：

无法确定 RPS 时
环境负载可能异常高于预期时
存在大型单体仓库或显著的额外工作负载时

例如，若有 3,000 个用户，且已知存在自动化操作会大幅提升并发负载，则可先以 100 RPS / 5,000 用户级别的环境启动，监控后若指标支持，可一次性或分步缩小所有组件规模。

独立部署（非高可用）

对于服务 2,000 名或更少用户的环境，通常建议采用独立部署方式——部署非高可用的单节点或多节点环境。此方式下，可通过自动备份等策略实现恢复。这些策略能在保证良好恢复时间目标（RTO）或恢复点目标（RPO）的同时，避免高可用带来的复杂度。

在独立部署中，尤其是单节点环境，有多种安装和管理选项可供选择。其中包括直接通过选定云服务商的市场部署，这能进一步降低复杂度。

高可用性（HA）

高可用性确保 GitLab 部署中的每个组件都能通过各种机制处理故障。然而，实现这一点很复杂，所需的环境也可能相当庞大。

对于服务于 3000 或更多用户的环境，我们通常建议使用高可用性策略。在这个级别，停机对更多用户的影响更大。出于这个原因，此范围内的所有架构都设计内置了高可用性。

您是否需要高可用性（HA）？

如前所述，实现高可用性需要付出代价。由于每个组件都需要复制，因此环境要求非常庞大，这带来了额外的实际和维护成本。

对于我们许多用户少于 3000 的客户，我们发现备份策略足够且更可取。虽然这确实有较慢的恢复时间，但也意味着您的架构更小，维护成本更低。

作为一般准则，仅在以下情况下采用高可用性：

当您有 3000 或更多用户时。
当 GitLab 停机会严重影响您的工作流程时。

精简版高可用性（HA）方案

如果您仍需为较少的用户提供高可用性，可以通过调整的 3K 架构实现。

零停机升级

标准环境的高可用性支持零停机升级，但云原生混合（Cloud Native Hybrid）不受支持。这使得在升级期间环境能够保持运行。然而，这个过程因此更加复杂，并且有一些文档中详细说明的限制。

在进行此过程时，值得注意的是，当高可用性机制生效时，可能仍然会有短暂的停机时刻。

在大多数情况下，进行升级所需的停机时间不应过长。仅当这是您的关键需求时才使用这种方法。

云原生混合（Kubernetes 高可用性）

作为高可用性的额外弹性层，您可以在 Kubernetes 中部署选定的组件，即所谓的云原生混合参考架构。出于稳定性考虑，Gitaly 等有状态组件无法在 Kubernetes 中部署。

与标准参考架构相比，云原生混合是一种替代且更高级的设置。在 Kubernetes 中运行服务很复杂。仅当您具备扎实的 Kubernetes 工作知识和经验时才使用此设置。

GitLab Geo（跨区域分布 / 灾难恢复）

通过 GitLab Geo，您可以实现不同区域的分布式环境，并配备完整的灾难恢复（DR）设置。GitLab Geo 至少需要两个独立的环境：

一个主站点。
一个或多个充当副本的辅助站点。

如果主站点不可用，您可以故障转移到其中一个辅助站点。

仅当 DR 是您环境的关键需求时，才使用这种 高级且复杂 的设置。您还必须就每个站点的配置方式做出额外决定。例如，每个辅助站点是否与主站点具有相同的架构，或者每个站点是否配置为高可用性。

大型单体仓库 / 其他工作负载

大型单体仓库或显著的其他工作负载可能会对环境的性能产生明显影响。根据具体情况，可能需要进行一些调整。

如果这种情况适用于您，请联系您的 GitLab 代表或我们的支持团队以获取进一步指导。

云服务提供商服务

对于上述所有策略，您可以将选定的 GitLab 组件运行在等效的云服务提供商服务上，例如 PostgreSQL 数据库或 Redis。

有关更多信息，请参阅推荐的云服务提供商和服务。

决策树

在参考以下决策树之前，请先完整阅读之前记录的指南。

%%{init: { 'theme': 'base' } }%%
graph TD
   L0A(<b>我应该使用哪种参考架构？</b>)
   L1A(<b>你的预期负载是多少？</b>)

   L2A("每秒60次请求（RPS）/ 3000名用户或更多？")
   L2B("每秒40次请求（RPS）/ 2000名用户或更少？")

   L3A("<a href=#do-you-need-high-availability-ha>你需要高可用性（HA）吗？</a><br>(或零停机升级)")
   L3B[你有Kubernetes中特定组件的使用经验<br/>并希望增加额外弹性吗？]

   L4A><b>建议</b><br><br>支持HA和可缩减的60 RPS / 3000用户架构]
   L4B><b>建议</b><br><br>最接近预期负载且支持HA的架构]
   L4C><b>建议</b><br><br>最接近预期负载的云原生混合架构]
   L4D>"<b>建议</b><br><br>带备份的单体20 RPS / 1000用户或40 RPS / 2000用户架构"]

   L0A --> L1A
   L1A --> L2A
   L1A --> L2B
   L2A -->|是| L3B
   L3B -->|是| L4C
   L3B -->|否| L4B

   L2B --> L3A
   L3A -->|是| L4A
   L3A -->|否| L4D
   L5A("<a href=#gitlab-geo-cross-regional-distribution--disaster-recovery>你需要跨区域分布<br/>或灾难恢复吗？</a>") --> |是| L6A><b>附加建议</b><br><br> GitLab Geo]
   L4A ~~~ L5A
   L4B ~~~ L5A
   L4C ~~~ L5A
   L4D ~~~ L5A

   L5B("你有<a href=#large-monorepos>大型单体仓库</a>或预期<br/>会有大量<a href=#additional-workloads>额外工作负载</a>吗？") --> |是| L6B><b>附加建议</b><br><br><a href=#if-in-doubt---start-large-monitor-and-scale-down>从大规模开始，监控后缩容</a><br><br> 联系GitLab代表或支持团队]
   L4A ~~~ L5B
   L4B ~~~ L5B
   L4C ~~~ L5B
   L4D ~~~ L5B

classDef default fill:#FCA326
linkStyle default fill:none,stroke:#7759C2

要求

在实施参考架构前，请查看以下要求和指南。

支持的机器类型

这些架构在设计上具有灵活性，允许选择机器类型的同时确保一致的性能。虽然我们在每个参考架构中提供了具体的机器类型示例，但这些并非强制性的默认选项。

你可以使用任何满足或超过各组件指定要求的机器类型，例如：

新一代机器类型（如GCP n2系列或AWS m6系列）
不同架构（如基于ARM的实例，例如AWS Graviton）
更适合你特定工作负载特性的替代机器类型家族（例如更高的网络带宽）

此指导同样适用于任何云服务提供商的服务，例如AWS RDS。

由于性能不一致，不建议使用任何“突发型”（burstable）实例类型。

有关我们测试的机器类型及测试方式的详细信息，请参阅验证和测试结果。

支持的磁盘类型

大多数标准磁盘类型预计可在GitLab中使用。但请注意以下几点：

Gitaly存储对磁盘有特定的disk requirements 要求。
由于性能不一致，我们不推荐使用任何“突发型”磁盘类型。

其他磁盘类型预计可与GitLab配合使用。请根据你的需求（如耐用性或成本）进行选择。

支持的基础设施

GitLab应能在大多数基础设施上运行，例如知名云服务提供商（AWS、GCP、Azure）及其服务，或满足以下两个条件的自管理（ESXi）环境：

每个架构中详细说明的规格。
本节中的任何要求。

但是，这并不能保证与所有可能的配置都兼容。

有关更多信息，请参阅推荐的云服务提供商和服务。

网络（高可用性）

以下是高可用方式运行GitLab的网络要求。

网络延迟

网络延迟应尽可能低，以便在GitLab应用中进行同步复制（例如数据库复制）。通常应低于5毫秒。

可用区（云服务提供商）

跨可用区部署受支持，通常建议用于增强弹性。你应使用奇数个可用区，以满足GitLab应用的要求，因为某些组件使用奇数个节点来进行法定投票（quorum voting）。

数据中心（自托管）

跨多个自托管数据中心部署是可行的，但需谨慎考量。这要求各中心间具备低延迟的同步能力、能防止脑裂场景的健壮冗余网络链路、所有中心位于同一地理区域，以及跨奇数个中心部署以保证正确法定投票（如可用区）。

对于多数据中心部署引发的基础设施相关问题，GitLab支持可能无法提供协助。选择跨中心部署通常由您自行承担风险。

不支持将单个GitLab环境跨不同区域部署。数据中心应位于同一区域。

大型单体仓库

这些架构经测试适用于遵循最佳实践的各类规模仓库。

然而，大型单体仓库（几GB及以上）会显著影响Git性能，进而拖累整个环境表现。其存在及使用方式会对从Gitaly到基础架构的全系统造成巨大压力。

性能影响主要源于软件层面，额外硬件资源的边际效益会递减。

若此情况适用于您，我们强烈建议参考关联文档，并联系您的GitLab代表或我们的支持团队获取进一步指导。

大型单体仓库会带来显著成本。若有此类仓库，请遵循以下指引保障性能并控制成本：

优化大型单体仓库。利用LFS等功能避免存储二进制文件，及其他缩减仓库规模的方法，可大幅提升性能并降低成本。
视单体仓库具体情况，可能需提升环境规格补偿。Gitaly可能需额外资源，同时Praefect、GitLab Rails和负载均衡器也可能需要。这取决于单体仓库本身及使用方式。
若单体仓库显著增大（20GB及以上），可能需更进阶策略，例如进一步提升规格，或在某些场景下为其单独配置Gitaly后端。
网络与磁盘带宽是大型单体仓库的另一潜在考量。极重负载下，若存在大量并发克隆（如CI），可能出现带宽饱和。此时应尽可能减少完整克隆。否则需提升环境规格以扩容带宽，具体因云服务商而异。

额外工作负载

这些架构基于真实数据进行了设计与测试，适用于标准GitLab配置。

然而，额外工作负载会通过触发后续操作放大操作影响。若您使用以下功能，可能需调整建议规格补偿：

节点上的安全软件。
数百个针对大型仓库的并发CI作业。
高频运行的自定义脚本。
多个大型项目中的集成。
服务器钩子。
系统钩子。

一般而言，您应建立强大监控机制，量化额外工作负载影响以确定必要变更。联系您的GitLab代表或我们的支持团队获取进一步指导。

负载均衡器

根据架构类型的不同，这些架构最多会使用两个负载均衡器：

外部负载均衡器 - 为任何面向外部的组件提供流量，主要是Rails。
内部负载均衡器 - 为以高可用（HA）方式部署的选定内部组件提供流量，例如Praefect或PgBouncer。

关于具体使用哪个负载均衡器或其精确配置的细节超出了GitLab文档的范围。最常见的选项是在机器节点上设置负载均衡器，或者使用云提供商提供的类似服务。如果部署云原生混合环境，图表可以通过Kubernetes Ingress来处理外部负载均衡器的设置。

每个架构类型都包含一个推荐的基础机器规格，用于直接在机器上部署。不过，它们可能需要根据所选负载均衡器和预期工作负载等因素进行调整。值得注意的是，机器的网络带宽可能会有所不同（网络带宽），这也应纳入考虑范围。

以下各节提供了关于负载均衡器的额外指导。

负载均衡算法

为确保对节点的调用均匀分布并保证良好性能，请尽可能使用基于最少连接数的负载均衡算法或等效算法。

我们不推荐使用轮询算法，因为实践中已知它们无法均匀分配连接。

网络带宽

当负载均衡器部署在机器上时，其可用的总网络带宽在不同云提供商之间可能有显著差异。一些云提供商（如AWS）可能会采用突发系统，通过信用额度来确定任意时刻的带宽。

您的负载均衡器所需的网络带宽取决于数据形状和工作负载等因素。每个架构类型的推荐基础规格是基于真实数据选择的。不过，在某些场景下（例如大型单体仓库的一致克隆（大型单体仓库）），您可能需要相应地调整规格。

禁用交换空间

参考架构中不推荐使用交换空间。它是一种故障保护机制，会对性能产生很大影响。这些架构设计为在大多数情况下拥有足够的内存，从而避免对交换空间的需求。

Praefect PostgreSQL

Praefect需要自己的数据库服务器。为了实现完全的高可用性（HA），需要一个第三方PostgreSQL数据库解决方案。

我们希望未来能为这些限制提供内置解决方案。在此期间，可以按照规范使用Linux包安装非高可用的PostgreSQL服务器。有关更多详情，请参阅以下问题：

参考架构	GCP	AWS	Azure	裸金属
Linux 软件包	🟢	🟢	🟢¹	🟢
云原生混合架构	🟢	🟢

云服务	GCP	AWS	Azure	裸金属
对象存储	🟢 Cloud Storage	🟢 S3	🟢 Azure Blob Storage	🟢 MinIO
数据库	🟢 Cloud SQL¹	🟢 RDS	🟢 Azure Database for PostgreSQL Flexible Server
Redis	🟢 Memorystore	🟢 ElastiCache	🟢 Azure Cache for Redis (Premium)

偏离建议的参考架构

偏离参考架构越远，获得支持就越困难。每次偏离都会引入一层复杂性，使潜在问题的排查变得更加复杂。

这些架构使用官方的Linux包或Helm Charts来安装和配置各个组件。各组件安装在独立的服务器（虚拟化或裸金属）上。机器硬件要求列在配置列中。每个可用架构的GCP/AWS/Azure列中列出了等效的VM标准规格。

你可以在Docker上运行GitLab组件，包括Docker Compose。Docker得到良好支持，并在不同环境中提供一致的规格。不过，它仍是额外的一层，可能会增加一些支持上的复杂性。例如，无法在容器中运行strace。

不受支持的设计

尽管我们努力为GitLab环境设计提供广泛的支持，但某些方法无法有效工作。以下章节详细说明了这些不受支持的方法。

Kubernetes中的有状态组件

在Kubernetes中运行有状态组件（如Gitaly Cluster (Praefect)）不受支持。

Gitaly Cluster (Praefect)仅支持在传统虚拟机上运行。Kubernetes严格限制内存使用。然而，Git的内存使用不可预测，可能导致Gitaly Pod偶尔因内存不足（OOM）而终止。OOM终止会导致重大中断和潜在的数据丢失。因此，Gitaly未在Kubernetes中进行测试或支持。更多信息请参见epic 6127。

这适用于Postgres和Redis等有状态组件。你可以使用其他受支持的云服务商服务，除非特别说明不受支持。

有状态节点的自动伸缩

作为一般指导原则，只有GitLab的无状态组件可以运行在自动伸缩组中，即GitLab Rails和Sidekiq。其他具有状态的组件（如Gitaly）不支持这种方式。更多信息请参见issue 2997。

这适用于Postgres和Redis等有状态组件。你可以使用其他受支持的云服务商服务，除非特别说明不受支持。

云原生混合设置通常比自动伸缩组更受青睐。Kubernetes能更好地处理只能在一个节点上运行的组件，例如数据库迁移和Mailroom。

跨多区域部署单一环境

GitLab不支持跨多个区域部署单个环境。此类设置可能导致严重问题，例如过高的网络延迟，或在区域间连接失败时出现脑裂场景。

多个GitLab组件执行同步复制或需要奇数个节点才能正常工作，例如Consul、Redis Sentinel和Praefect。将这些组件分布在具有高延迟的多个区域会严重影响其功能及整体系统性能。

此限制适用于所有潜在的GitLab环境设置，包括云原生混合替代方案。

若要在多个数据中心或区域部署GitLab，我们提供了GitLab Geo作为全面解决方案。

验证与测试结果

GitLab会定期对这些架构进行冒烟测试和性能测试，以确保它们保持合规。

测试方式

测试通过使用从样本客户数据派生的特定编码工作负载进行，利用GitLab Environment Toolkit (GET)通过Terraform和Ansible进行环境部署，以及GitLab Performance Tool (GPT)通过k6进行性能测试。

测试主要在GCP和AWS上进行，使用它们的标准化计算产品（GCP的n1系列，AWS的m5系列）作为基准配置。选择这些机型是为了确保广泛的兼容性，作为最低通用目标。使用满足CPU和内存要求的不同或更新的机型完全受支持——有关更多信息，请参阅支持的机器类型。无论在其他云服务商还是本地，只要硬件符合规格，这些架构的性能预期相似。

性能目标

每个参考架构都会根据真实客户数据针对特定吞吐量目标进行测试。对于每1000名用户，我们测试：

API：20 RPS
Web：2 RPS
Git（拉取）：2 RPS
Git（推送）：0.4 RPS（四舍五入到最近的整数）

列出的RPS目标是基于对应用户总数的实际环境负载的真实客户数据选择的，包括CI和其他工作负载。

在测试环境中观察到组件之间的网络延迟小于5毫秒，但请注意这并非硬性要求。

测试覆盖范围和结果

测试设计旨在有效覆盖所有参考架构目标。测试频率因架构类型和规模而异：

Linux包环境：在GCP和AWS上对所有规模的架构进行每日或每周测试。
云原生环境：在GCP和AWS上对选定的配置进行每周测试。

我们的测试还包括这些架构的原型变体探索，以备未来纳入。测试结果公开可在参考架构wiki查看。

维护参考架构环境

维护参考架构环境通常与其他GitLab环境相同。

在本节中，您可以找到相关领域的文档链接和具体的架构说明。

扩展环境

参考架构作为起点设计，整体具备弹性和可扩展性。部署后，您可能因额外性能容量或降低成本等原因，希望根据自己的具体需求调整环境。这种行为是预期的。如果指标显示某个组件资源耗尽，可以迭代式或整体扩展至下一个架构规模。

如果某个组件持续耗尽其分配的资源，请在执行任何重大扩展前联系我们的支持团队。

大多数组件可按常规方式进行垂直或水平扩展。但在操作前，需注意以下事项：

垂直扩展Puma或Sidekiq时，必须调整worker数量以利用额外的规格。Puma会在下一次重新配置时自动扩展。不过，您可能需要提前更改Sidekiq配置。
Redis和PgBouncer主要是单线程的。如果这些组件出现CPU耗尽，可能需要水平扩展。
以HA形式部署时，Consul、Redis Sentinel和Praefect组件需要奇数个节点以满足投票仲裁要求。
显著扩展某些组件可能导致显著的连锁影响，进而影响环境性能。更多指导见扩展的连锁影响。

相反，如果您有可靠的指标表明环境过度配置，则可以向下扩展。向下扩展时应采用迭代方式，以确保不会出现问题。

扩展的连锁效应

在某些情况下，显著扩展某个组件可能会导致下游组件出现连锁效应，影响性能。架构设计时考虑了平衡性，以确保相互依赖的组件在规格上保持一致。值得注意的是，扩展某个组件可能导致额外的吞吐量传递给其依赖的其他组件。因此，你可能也需要扩展这些其他依赖组件。

架构已设计为具有弹性，以适应上游组件被扩展的情况。但是，在进行任何重大环境更改之前，请先联系我们的支持团队以确保安全。

以下组件在被显著扩展时可能会影响其他组件：

Puma 和 Sidekiq - 显著扩展 Puma 或 Sidekiq 工作进程会导致内部负载均衡器、PostgreSQL（如果存在则通过 PgBouncer）、Gitaly（如果存在则通过 Praefect）以及 Redis 的并发连接数增加。
- Redis 主要是单线程的。在某些情况下，如果增加的吞吐量导致组合集群中的 CPU 耗尽，你可能需要将 Redis 拆分为单独的实例（例如缓存和持久化）。
- PgBouncer 也是单线程的，但扩展可能会导致新池被添加，进而可能增加到 Postgres 的总连接数。强烈建议只有在有管理 Postgres 连接的经验时才这样做，如有疑问请寻求帮助。
Gitaly 集群（Praefect）/PostgreSQL - 显著扩展额外节点可能会对高可用系统造成不利影响，并因向主节点的复制调用增加而降低性能。

从非高可用架构扩展到高可用架构

在大多数情况下，垂直扩展仅用于增加环境的资源。但是，如果你要迁移到高可用环境，则需要额外的步骤来让以下组件切换到它们的高可用形式。

有关更多信息，请参阅以下文档：

升级

升级参考架构环境与其他 GitLab 环境相同。有关更多信息，请参阅升级 GitLab。还提供零停机升级。

你应该按照创建顺序升级参考架构。

监控

你可以使用各种选项监控你的基础设施和GitLab。有关更多信息，请参阅所选监控解决方案的文档。

GitLab 应用程序捆绑了Prometheus 及各种兼容 Prometheus 的导出器，可以将其接入你的解决方案中。

更新历史

以下是参考架构的重要更新历史记录（自2021年1月1日起，按时间升序排列）。我们计划至少每季度更新一次。

您可以在GitLab项目上找到完整的变更历史。

2025:

2025-02: 进一步明确了支持的机器类型，并说明列出的示例并非作为规定性默认值。

2024:

2024-12: 添加了“开始大规格”（Start Large）部分，以提供初始规模选择的进一步指导。
2024-08: 在“预期负载”部分增加了更多关于如何计算每秒请求数（RPS）的示例。
2024-08: 更新了40 RPS或2000用户的页面上的Redis配置，使其包含正确的Redis配置。
2024-08: 更新了监控节点上Prometheus的Sidekiq配置（针对2000用户场景）。
2024-08: 在页面上添加了“下一步操作”面包屑导航部分，以帮助发现额外功能。
2024-05: 更新了60 RPS或3000用户、100 RPS或5000用户的页面，使其包含最新的Redis指南（关于将Redis Sentinel与Redis本身共置）。
2024-05: 将“运行成本”部分重命名为“成本计算器模板”，以更好地反映计算器仅作起点，需根据具体使用情况调整才能给出更准确的成本估算。
2024-04: 更新了GCP云原生混合部署中Web服务节点的推荐规模。同时调整了NGINX Pod的建议，改为将其作为DaemonSet运行在Web服务节点池上。
2024-04: 更新了20 RPS / 1000用户的架构规范，遵循推荐的16 GB内存目标。
2024-04: 更新了参考架构的标题，加入RPS以增强清晰度，帮助合理选型。
2024-02: 更新了负载均衡器节点的推荐规模（若部署在虚拟机上）。同时添加了网络带宽注意事项。
2024-02: 移除了示例中的Sidekiq最大并发设置，因该设置已弃用且无需显式配置。
2024-02: 调整了2000用户场景下的Sidekiq建议：禁用Rails节点上的Sidekiq，并更新了架构图。
2024-01: 更新了Azure平台上所有参考架构规模的最新云服务推荐。

2023:

2022年：

2022-12-14：移除了使用NFS存储Git数据的指导，因为自15.6或更高版本起，对此的支持已结束。
2022-12-12：添加注释以澄清Amazon RDS Multi-AZ数据库集群与实例之间的区别，后者受到支持。同时将PostgreSQL最大连接数设置为新的默认值500。
2022-12-12：更新Sidekiq最大并发配置以匹配新的默认值20。
2022-11-16：修正了3千架构缩减部分的Praefect和Gitaly指导，指出需要奇数仲裁。
2022-11-15：添加了如何在云原生混合环境中处理GitLab Secrets的指导，并进一步链接到GitLab Charts文档。
2022-11-14：修复了10千架构Sidekiq配置的拼写错误。
2022-11-09：添加了有关大型单体仓库和额外工作负载对性能影响的指导。还扩展了有关SSL的负载均衡器指导，并推荐基于最少连接的路由方法。
2022-10-18：调整对象存储指导，使其更清晰表明它比NFS更受推荐。
2022-10-11：更新Azure指导，由于性能问题仅推荐最多2千。

- [2022-09-27](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/98204)：添加了决策树部分，帮助用户更好地决定使用哪种架构。
- [2022-09-22](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/98263)：添加了明确的步骤，在使用仅对象存储时启用增量日志记录。
- [2022-09-22](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/98184)：扩展了关于推荐云提供商和服务的指南。
- [2022-09-09](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/97245)：扩展了对象存储指南，并更新了Git数据对NFS的支持将在`15.6`版本结束。
- [2022-08-24](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/96150)：添加了更清晰的说明，指出Gitaly集群在Kubernetes中不受支持。
- [2022-08-24](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/96021)：添加了关于支持的CPU和类型的章节。
- [2022-08-18](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/95713)：更新了架构表格，使其对对象存储支持更加清晰。
- [2022-08-17](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/95185)：增加了云原生混合池2k架构的规格，以确保pod有足够的资源。同时增加了Sidekiq工作进程数量。
- [2022-08-02](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/93493)：添加了使用较新Gitaly检查命令的说明（适用于GitLab `15.0`及更高版本）。
- [2022-07-25](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/93141)：将故障排除部分移至更通用的位置。
- [2022-07-14](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/92144)：添加了指导，说明从GitLab `14.4.0`及更高版本开始，Amazon Aurora不再兼容且不受支持。
- [2022-07-07](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/91943)：添加了突出显示的说明，要求从Gitaly存储配置中删除`default`部分，因为这是必需的。
- [2022-06-08](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/86812)：将增量日志记录指南移至单独的部分。
- [2022-04-29](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/85856)：通过新的常规流水线扩展了测试结果部分。
- [2022-04-26](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/85833)：更新了Praefect配置以反映设置名称的变化。
- [2022-04-15](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/85231)：添加了启用对象存储所需的缺失设置。
- [2022-04-14](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/85107)：用AWS机器类型扩展了云原生混合指南。
- [2022-04-08](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/84389)：为AWS和Azure添加了成本估算。
- [2022-04-06](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/84483)：更新了大多数组件的配置示例，以便正确包含Prometheus监控自动发现功能。
- [2022-03-30](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/81538)：使用更清晰的语言和更多细节扩展了验证和测试结果部分。
- [2022-03-21](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/83019)：添加了一条说明，指出在某些场景下，Gitaly可能需要额外的规格。
- [2022-03-04](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/82087)：添加了防止GitLab `kas`服务在不必要的节点上运行的指南。
- [2022-03-01](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/81814)：修复了配置示例中Praefect TLS端口的拼写错误。
- [2022-02-22](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/81247)：添加了启用Gitaly Pack-objects缓存的指南。
- [2022-02-22](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/80892)：添加了关于推荐云提供商和服务的一般性章节。
- [2022-02-14](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/80521)：添加了一篇关于新增GPT测试的博客文章链接。
- [2022-01-26](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/78705)：将测试过程和成本估算合并到一个部分中，并扩展了详细信息。
- [2022-01-13](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/77968)：扩展了关于推荐Kubernetes平台的指南。

**2021**：

- [2021-12-31](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/77437)：修正25k Redis AWS机器尺寸的拼写错误。
- [2021-12-28](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/77243)：向测试过程和结果部分添加云提供商细分。
- [2021-12-17](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/77039)：为测试过程和结果部分添加更多细节。
- [2021-12-17](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/77002)：添加了关于使用修改后的3k架构时的数据库负载均衡要求的说明。
- [2021-12-17](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/76236)：为1k架构（单节点）添加图表。