参考架构 - GitLab - GitLab 文档中心

Tier: 基础版，专业版，旗舰版

Offering: 私有化部署

极狐GitLab 参考架构是经过验证的、可用于生产环境的设计，旨在大规模部署极狐GitLab。每种架构都提供了详细规范，您可以根据需求使用或调整。

开始之前#

首先，请考虑极狐GitLab 私有化部署是否适合您和您的需求。

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

如果您决定选择这条路线，必须具备在生产环境中运行和维护应用程序的实际知识。如果您不具备相应能力，我们的专业服务团队可提供实施服务。对于希望获得更长期托管解决方案的用户，可以探索我们的其他产品，例如 JihuLab.com。

如果您考虑使用极狐GitLab 私有化部署方案，我们建议您完整阅读本页面，特别是以下部分：

决定从哪种架构开始
大型单体仓库
额外工作负载
监控和调整您的环境

决定从哪种架构开始#

参考架构旨在平衡三个重要因素：性能、弹性和成本。它们提供了经过验证的起点，用于根据典型工作负载模式大规模部署极狐GitLab。虽然它们使初始部署变得更加容易，但大多数环境都可以根据通过监控发现的实际使用模式进行调整。选择一个适当的起点很重要，但预计需要根据您的特定工作负载特征进行调整。

一般而言，您希望环境的性能或弹性越高，其复杂性也越高。

本节介绍了选择参考架构时需要考虑的事项。

预期负载#

适当的架构规模主要取决于环境的预期峰值负载。每秒请求数（RPS）是用于衡量极狐GitLab 基础设施规模的主要指标，但其他因素也可能适用。

有关全面的 RPS 分析和数据驱动的规模调整决策，请参见参考架构规模调整，其中提供了：

详细的 PromQL 查询，用于提取峰值和持续 RPS 指标
工作负载模式分析和 RPS 组成指导，以识别特定组件的调整
单体仓库、网络使用和增长规划的评估方法

对于快速估算 RPS，一些可能的选择包括：

Prometheus 查询，例如：

prometheus
sum(irate(gitlab_transaction_duration_seconds_count{controller!~'HealthController|MetricsController'}[1m])) by (controller, action)

极狐GitLab RPS 分析器。
其他监控解决方案。
负载均衡器统计信息。

如果您无法确定 RPS，则提供基于 Linux 软件包和云原生混合架构的用户数量等效值作为替代规模调整方法。该数量映射到典型 RPS 值，同时考虑手动和自动使用。

可用的参考架构#

以下参考架构作为环境的推荐起点提供。

每种架构都设计为[可扩展](#scaling-an-environment)。可以根据工作负载对其进行相应调整，可以向上或向下调整。例如，一些已知的重负载场景，如使用[大型单体仓库](#large-monorepos)或显著的[额外工作负载](#additional-workloads)。

Linux 软件包（Omnibus）#

基于 Linux 软件包的参考架构使用该软件包在虚拟机上部署所有极狐GitLab 组件。所选组件（PostgreSQL、Redis、对象存储）可以选择使用云提供商服务。

以下 RPS 目标反映了典型的工作负载组成。对于非典型工作负载，请参见了解 RPS 组成。

规模	API RPS	Web RPS	Git（拉取） RPS	Git（推送） RPS
1000 位用户	20	2	2	1
2000 位用户	40	4	4	1
3000 位用户	60	6	6	1
5000 位用户	100	10	10	2
10000 位用户	200	20	20	4
25000 位用户	500	50	50	10
50000 位用户	1000	100	100	20

云原生混合#

云原生混合参考架构使用 Helm Charts 在 Kubernetes 中部署选定的无状态组件（Webservice、Sidekiq），而其他组件保留在虚拟机上或使用云提供商服务（PostgreSQL、Redis、对象存储）。

规模	API RPS	Web RPS	Git（拉取） RPS	Git（推送） RPS
2000 位用户	40	4	4	1
3000 位用户	60	6	6	1
5000 位用户	100	10	10	2
10000 位用户	200	20	20	4
25000 位用户	500	50	50	10
50000 位用户	1000	100	100	20

云原生优先（测试版）#

Tier: 基础版，专业版，旗舰版

Offering: 私有化部署

Status: 测试版

云原生优先架构是我们的下一代架构，旨在针对现代部署方法，根据工作负载特征提供四种标准化规模（S/M/L/XL）。这些架构在 Kubernetes 中部署所有极狐GitLab 组件，而 PostgreSQL、Redis 和对象存储则使用外部第三方解决方案，包括托管服务或本地选项。

这些架构通过 Kubernetes 编排降低了运维开销，简化了部署，并增强了弹性。

规模	目标 RPS	工作负载特征
小型（S）	≤100 RPS	轻量整体负载，不适合活跃的单体仓库
中型（M）	≤200 RPS	中等负载，支持使用较少的单体仓库
大型（L）	≤500 RPS	重负载，处理中等使用量的单体仓库
超大型（XL）	≤1000 RPS	密集负载，专为重度使用的单体仓库设计

更多信息，请参见云原生优先参考架构。

如果不确定，从大规模开始，监控，然后缩小#

如果您不确定所需的环境规模，可以考虑从较大的规模开始，进行监控，然后根据指标支持的情况缩小。

当以下情况时，从大规模开始然后缩小是一种谨慎的方法：

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

例如，如果您有 3000 位用户，但也知道存在自动化操作会显著增加并发负载，那么您可以从 100 RPS / 5000 用户等级的环境开始，监控它，如果指标支持，一次性或逐个缩减所有组件。

独立部署（非 HA）#

对于服务 2000 位或更少用户的环境，通常建议采用独立部署方式，部署非 HA 的单节点或多节点环境。通过这种方式，您可以使用诸如自动备份之类的策略进行恢复。这些策略提供了良好的恢复时间目标（RTO）或恢复点目标（RPO），同时避免了 HA 带来的复杂性。

对于独立部署，特别是单节点环境，有多种安装和管理选项可供选择。这些选项包括直接使用特定云提供商市场进行部署的能力，这进一步降低了复杂性。

高可用性（HA）#

高可用性确保极狐GitLab 设置中的每个组件都能通过各种机制处理故障。然而，实现这一点非常复杂，所需的环境规模也相当可观。

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

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

如前所述，实现 HA 是有成本的。环境需求相当大，因为每个组件都需要成倍增加，这会带来额外的实际成本和维护成本。

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

作为一般准则，仅在以下场景中使用 HA：

当您拥有 3000 位或更多用户时。
当极狐GitLab 停机会对您的工作流程产生严重影响时。

缩小的 HA 方法#

如果您仍需要为更少的用户提供 HA，可以使用调整后的 3K 架构来实现。

零停机升级#

标准 HA 环境支持零停机升级（云原生混合不支持）。这允许环境在升级期间保持运行。然而，这个过程因此更加复杂，并且如文档中所述，存在一些限制。

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

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

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

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

一个主站点。
一个或多个作为副本的辅助站点。

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

只有在灾难恢复是您环境的关键需求时，才使用此**高级且复杂**的设置。您还必须对每个站点的配置方式做出额外决策。例如，每个辅助站点是否采用与主站点相同的架构，或者每个站点是否都配置了 HA。

大型单体仓库 / 额外工作负载#

大型单体仓库或显著的额外工作负载会显著影响环境性能。根据上下文可能需要进行一些调整。

有关这些因素的全面分析，请参见参考架构规模调整，其中提供：

单体仓库对基础设施影响的详细评估方法
针对不同工作负载模式的组件级扩展建议
重数据传输场景的网络带宽分析

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

云提供商服务#

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

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

决策树#

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


Rendering chart...

上面的决策树反映了生产就绪的架构。对于包括 Gitaly 在内的完全 Kubernetes 原生部署，请参见[云原生优先（测试版）](cloud_native_first.md)，该版本目前处于测试阶段，尚未推荐用于生产环境。

要求#

在实施参考架构之前，请参阅以下要求和指导。

支持的机器类型#

这些架构设计灵活，可根据机器类型选择，同时确保一致的性能。虽然我们在每个参考架构中提供了特定的机器类型示例，但这些并非旨在成为规定性默认值。

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

更新一代的机器类型（如 GCP n2 系列或 AWS m6 系列）
不同的架构，如基于 ARM 的实例（如 AWS Graviton）
更好地匹配您特定工作负载特征（如更高网络带宽）的替代机器类型系列

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

不建议使用任何“性能突发”型实例，因为其性能不一致。

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

支持的磁盘类型#

大多数标准磁盘类型预计都能与极狐GitLab 一起工作。但是，请注意以下具体说明：

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

其他磁盘类型预计都能与极狐GitLab 一起工作。请根据您的需求（如耐用性或成本）进行选择。

支持的基础设施#

极狐GitLab 应该可以在大多数基础设施上运行，例如信誉良好的云提供商（AWS、GCP、Azure）及其服务，或者私有化部署（ESXi），只要满足以下两点：

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

但是，这并不能保证与每种可能的排列组合都兼容。

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

网络（高可用性）#

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

网络延迟#

网络延迟应尽可能低，以实现极狐GitLab 应用程序之间的同步复制，例如数据库复制。通常应低于 5 毫秒。

可用区（云提供商）#

支持跨可用区部署，通常建议这样做以获得额外的弹性。您应该使用奇数个区，以符合极狐GitLab 应用程序的要求，因为某些组件使用奇数个节点进行法定人数投票。

数据中心（私有化部署）#

跨多个自有数据中心部署是可能的，但需要仔细考虑。这需要数据中心之间具有同步能力的延迟、强大的冗余网络链接以防止脑裂场景，所有数据中心位于同一地理区域，并且跨奇数个数据中心部署以实现正确的法定人数投票（如可用区）。

极狐GitLab 支持可能无法协助处理由多数据中心部署引起的基础设施相关问题。选择跨数据中心部署通常需要自担风险。此外，不支持[跨不同区域部署单个极狐GitLab 环境](#deploying-one-environment-over-multiple-regions)。数据中心应位于同一区域。

大型单体仓库#

这些架构是使用遵循最佳实践的不同大小的仓库进行测试的。

然而，大型单体仓库（数 GB 或更大）会严重影响 Git 的性能，进而影响环境本身。它们的存在及其使用方式会对整个系统（从 Gitaly 到底层基础设施）造成巨大压力。

性能影响主要是软件性质的。额外的硬件资源会导致收益递减。

如果这适用于您，我们强烈建议您遵循链接文档，并及时联系您的极狐GitLab 代表或我们的[支持团队](https://gitlab.cn/support/)获取进一步指导。

大型单体仓库伴随着显著的成本。如果您有这样的仓库，请遵循以下指导以确保良好性能并控制成本：

优化大型单体仓库。使用诸如 LFS 等功能来存储二进制文件，以及其他减少仓库大小的方法，可以显著提高性能并降低成本。
根据单体仓库的情况，可能需要增加环境规格来补偿。Gitaly 可能需要额外资源，以及 Praefect、极狐GitLab Rails 和负载均衡器。这取决于单体仓库本身及其使用方式。
当单体仓库非常大（20 GB 或更大）时，可能需要进一步的额外策略，例如甚至进一步增加规格，或在某些情况下，为该单体仓库单独设置一个 Gitaly 后端。
网络和磁盘带宽是大型单体仓库的另一个潜在考虑因素。在极重负载情况下，如果存在大量并发克隆（例如 CI），可能会出现带宽饱和。在此情况下，尽可能减少完整克隆。否则，可能需要增加环境规格以提高带宽。这在不同的云提供商之间有所不同。

额外工作负载#

这些架构是基于真实数据为标准极狐GitLab 设置设计和测试的。

然而，额外的工作负载可能会通过触发后续操作而成倍增加操作影响。如果使用以下内容，您可能需要调整建议的规格以进行补偿：

节点上的安全软件。
用于大型仓库的数百个并发 CI 作业。
高频运行的自定义脚本。
许多大型项目中的集成。
在拥有大量用户群的项目中的功能标志。
服务器钩子。
系统钩子。

通常，您应该部署强大的监控来衡量任何额外工作负载的影响，从而为需要进行的任何更改提供依据。请联系您的极狐GitLab 代表或我们的支持团队获取进一步指导。

负载均衡器#

这些架构根据类别使用最多两个负载均衡器：

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

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

每个架构类别都包含一个推荐的基准机器大小，用于直接部署在机器上。但是，它们可能需要根据所选负载均衡器和预期工作负载等因素进行调整。值得注意的是，机器可能有不同的网络带宽，这也应考虑在内。

以下部分提供了负载均衡器的额外指导。

均衡算法#

为了确保调用均匀分配到节点并保持良好性能，尽可能使用基于最小连接的负载均衡算法或等效算法。

我们不建议使用轮询算法，因为已知它们在实践中不能均匀地分配连接。

网络带宽#

部署在机器上的负载均衡器可用的总网络带宽在云提供商之间可能存在显著差异。某些云提供商（例如 AWS）可能基于具有额度的突发系统来确定任意时刻的带宽。负载均衡器所需的网络带宽取决于数据形态和工作负载等因素。每个架构类别的推荐基础规模已根据实际数据选定。然而，在某些场景下，例如持续克隆大型 monorepos、频繁使用极狐GitLab 容器镜像仓库、大型 CI 产物，或任何涉及频繁传输大型文件的工作负载，你可能需要相应调整规模。

不使用交换空间#

在参考架构中不建议使用交换空间。交换空间是一种严重影响性能的故障安全机制。在大多数情况下，这些架构设计具有足够的内存，避免使用交换空间。

Praefect PostgreSQL#

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

我们希望未来能为这些限制提供内置解决方案。同时，可以使用 Linux 软件包按照规格设置非高可用的 PostgreSQL 服务器。

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

偏离建议的参考架构#

偏离参考架构越远，获得支持就越困难。每出现一个偏差，都会增加一层复杂性，使得排查潜在问题更加困难。

这些架构使用官方的 Linux 软件包或 Helm Charts 来安装和配置各种组件。组件安装在独立的机器上（虚拟化或裸金属）。在特定参考架构页面上的“配置”列中列出了机器硬件要求。等效的 VM 标准大小列在每个可用架构的 GCP/AWS/Azure 列中。

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

不支持的设计#

尽管我们努力为极狐GitLab 环境设计提供广泛的支持，但某些方法无法有效运作。以下各节详细介绍了这些不受支持的方法。

Kubernetes 中的有状态组件#

在 Kubernetes 中运行有状态组件（例如 Postgres 和 Redis）不受支持。

你可以使用其他受支持的云提供商服务，除非特别指出不支持。

单个 Gitaly 节点可以以有限可用性部署在 Kubernetes 上。这提供了一个非高可用的解决方案，其中每个仓库存储在单个节点上。有关 Gitaly 部署选项和限制的背景信息，请参见 Kubernetes 上的 Gitaly。

对于将 Gitaly 作为完全云原生设置的一部分部署在 Kubernetes 中的参考架构，请参见云原生优先参考架构 (Beta)。

有状态节点的自动伸缩#

作为一般指导原则，只有极狐GitLab 的无状态组件（即极狐GitLab Rails 和 Sidekiq）可以在自动伸缩组中运行。其他有状态的组件（例如 Gitaly）不支持这种方式。

这也适用于 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 和内存要求的不同或更新的机器类型完全受支持 - 有关更多信息，请参阅支持的机器类型。这些架构在满足规格的任何硬件上（无论是在其他云提供商还是本地部署）都应具有类似的性能。

性能目标#

每个参考架构都根据基于真实客户数据的特定吞吐量目标进行测试。对于每 1,000 个用户，我们测试：

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

所列出的 RPS 目标是根据真实客户数据选择的，该数据反映了与用户数量相对应的总环境负载，包括 CI 和其他工作负载。

- 这些 RPS 细分指标代表基于典型工作负载模式的测试目标。你的实际工作负载构成可能会有所不同。有关评估你的具体 RPS 构成以及何时需要调整的指导，请参见 [了解 RPS 构成](sizing.md#understanding-rps-composition-and-workload-patterns)。 - 在测试环境中观察到组件之间的网络延迟小于 5 毫秒，但请注意，这不作为硬性要求。

测试覆盖与结果#

测试旨在有效并为参考架构目标提供良好的覆盖率，涵盖 Linux 软件包和云原生环境。定期审查测试的特定环境和配置，以确保最佳的覆盖率和性价比平衡，并且可能随时间变化。

我们的测试还包括正在探索的这些架构的原型变体，以供未来可能纳入。测试结果公开发布在参考架构 Wiki 上。

维护参考架构环境#

维护参考架构环境与任何其他极狐GitLab 环境基本相同。

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

扩展环境#

参考架构设计为基于典型工作负载模式的经验证起点，而非最终配置。大多数生产部署都受益于根据通过监控出现的实际使用模式进行调整。这些架构整体可伸缩，并且随着你对工作负载特征的了解，可以迭代调整它们。扩展可以按组件逐个进行，或者在指标指示持续资源压力时整体扩展到下一个架构规模。

如果某个组件持续耗尽其分配的资源配置，请在进行任何重大扩展之前联系我们的 [支持团队](https://gitlab.cn/support/)。

何时扩展#

大多数部署在观察实际工作负载模式后都会从调整中受益。触发扩展的常见场景包括：

资源规模调整：

针对 API 密集型工作负载增加 Webservice/Rails 容量，尤其是当 API 流量超过总 RPS 的 90% 时（参见了解 RPS 构成）
针对重度 monorepo 环境或当仓库大小超过 2 GB 时扩展 Gitaly（参见确定组件调整）
针对高 CI/CD 吞吐量或繁重的后台作业处理调整 Sidekiq 工作进程

配置优化：

根据并发访问模式设置 Gitaly 仓库 cgroup 计数（参见 Gitaly cgroups）
配置 Sidekiq 队列优先级以优化作业处理（参见处理特定作业类）

架构改进：

为读取密集型工作负载添加 PostgreSQL 只读副本
将 Sidekiq 拆分为针对不同作业类型的专用池
为具有突发流量尖峰的环境调整最小实例数

这些调整是典型且预期的。参考架构提供了基础，但监控你的特定工作负载决定了最佳配置。有关环境的系统性评估，请参见参考架构规模调整。

针对极狐GitLab Duo Agent Platform 的扩展#

极狐GitLab Duo Agent Platform 引入了超出标准极狐GitLab 工作负载的额外基础设施要求。Agent Platform 工作流通过极狐GitLab Rails API 执行，通过 Sidekiq 异步处理作业，并访问仓库数据以获取代码上下文和分析。

主要组件影响：

Rails (Webservice/Puma) - Agent Platform API 请求增加了总体请求负载，用于流式 AI 响应的 WebSocket 连接由 Workhorse 管理
Sidekiq - AI 补全作业和工作流状态更新作为后台作业处理
PostgreSQL - Agent 工作流会话和状态数据存储在数据库中
Gitaly - 用于代码上下文的仓库文件访问以及针对 agent 生成更改的提交操作

对于计划采用 Agent Platform 的环境：

根据你的标准工作负载 RPS 部署推荐的架构规模
在初始部署期间监控 Rails CPU 利用率
监控 Sidekiq CPU 利用率和作业队列深度
监控 PostgreSQL 以了解工作流状态管理带来的事务速率增加
监控 Gitaly 以了解代码分析功能带来的文件访问模式增加

有关监控这些组件的 Prometheus 查询示例，请参见 Prometheus 查询示例。

如果观察到持续的资源压力，请通过扩展受影响的组件来增加容量。在 Kubernetes 部署中，增加 pod 副本和节点池容量。在 Linux 软件包部署中，可通过添加节点进行水平扩展，或通过增加节点规格进行垂直扩展。

资源需求因 Agent Platform 使用强度以及启用的特定功能而异。参考架构为典型的 Agent Platform 使用模式以及标准的极狐GitLab 工作负载提供了足够的基础容量。

如何扩展#

对于大多数组件，可以照常应用垂直和水平扩展。但是，在此之前，请注意以下注意事项：

在垂直扩展 Puma 或 Sidekiq 时，必须调整工作进程数量以利用额外的规格。Puma 工作进程数通常会自动调整，但 Sidekiq 可能需要手动配置。
Redis 和 PgBouncer 主要是单线程的。如果这些组件出现 CPU 耗尽，它们可能需要进行水平扩展。
在 Linux 软件包部署中，Consul、Redis Sentinel 和 Praefect 组件在以 HA 形式部署时需要奇数个节点以进行投票仲裁。
大幅扩展某些组件可能会产生明显的连锁效应，影响环境的性能。有关更多指导，请参见扩展的连锁效应。

相反，如果你有可靠的指标显示环境过度配置，则可以向下缩减。在向下缩减时应采取迭代方法，以确保不会出现问题。

扩展的连锁效应#

在某些情况下，大幅扩展某个组件可能会对下游组件产生连锁效应，从而影响性能。这些架构在设计时考虑了平衡性，以确保相互依赖的组件在规格上保持一致。值得注意的是，扩展某个组件可能会导致额外的吞吐量传递到它所依赖的其他组件。因此，你可能也需要扩展这些其他依赖组件。要确定这一点，请在扩展之前监控所有依赖服务的饱和度指标。如果多个相互依赖的组件显示出饱和状态，则应以协调的方式一起扩展，而不是顺序扩展，以防止瓶颈仅仅在组件之间转移。

这些架构设计具有弹性，以适应上游组件的扩展。但是，为确保安全，在对环境进行任何重大更改之前，请联系我们的 [支持团队](https://gitlab.cn/support/)。

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

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

从非高可用架构扩展为高可用架构#

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

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

升级#

升级参考架构环境与任何其他极狐GitLab 环境相同。有关更多信息，请参见升级极狐GitLab。还可以使用零停机升级。

你应该按照创建参考架构的顺序对其进行升级。

监控#

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

极狐GitLab 应用程序捆绑了 [Prometheus 和各种与 Prometheus 兼容的导出器](../monitoring/prometheus/_index.md)，可以集成到你的解决方案中。

更新历史#

你可以在极狐GitLab 项目中找到完整的变更历史。