参考架构
Tier: 基础版，专业版，旗舰版
Offering: 私有化部署
极狐GitLab 参考架构是用于大规模部署极狐GitLab 的推荐、可投入生产的环境设计方案。每个架构都提供了详细的规格，您可以根据自身需求直接使用或进行调整。
开始之前
首先，请考虑极狐GitLab 私有化部署是否适合您和您的需求。
在生产环境中运行任何应用都很复杂，极狐GitLab 也不例外。虽然我们力求尽可能简化这一过程，但根据您的设计，仍然存在一些普遍的复杂性。通常，您必须管理硬件、操作系统、网络、存储、安全、极狐GitLab 本身等各个方面。这既包括环境的初始搭建，也包括长期维护。
如果您决定采用这种方式，您必须具备在生产环境中运行和维护应用的实践经验。如果您不具备这方面的条件，我们的专业服务团队提供实施服务。希望长期获得更托管式解决方案的用户，可以了解我们的其他方案，例如 JihuLab.com。
如果您正在考虑使用极狐GitLab 私有化部署方式，我们建议您完整阅读本页内容，尤其是以下章节：
决定从哪个架构开始
参考架构在性能、弹性和成本之间取得平衡。它们是基于典型工作负载模式的推荐起点。不过，大多数部署都需要通过监控根据实际使用情况进行调优。
一般来说，您希望环境性能越强或弹性越高，其复杂度也就越高。
预期负载
合适的架构规模主要取决于您环境的预期峰值负载。每秒请求数（RPS）是衡量极狐GitLab 基础设施规模的主要指标，但其他因素也可能适用。
有关全面的 RPS 分析和数据驱动的规模决策，请参阅参考架构规模确定，其中提供：
- 用于提取峰值和持续 RPS 指标的详细 PromQL 查询
- 工作负载模式分析和 RPS 构成指导，用于确定针对特定组件的调整
- 针对单体仓库、网络使用和增长规划的评估方法
如需快速估算 RPS，一些可选方案包括：
-
Prometheus 查询，例如：
prometheussum(irate(gitlab_transaction_duration_seconds_count{controller!~'HealthController|MetricsController'}[1m])) by (controller, action) -
其他监控解决方案。
-
负载均衡器统计数据。
如果您无法确定 RPS，Linux 软件包和 Cloud Native Hybrid 架构提供了等效用户数作为替代的规模确定方法。该用户数会映射到典型的 RPS 值，同时考虑手动和自动化使用情况。
可用的参考架构
以下参考架构可作为您环境的推荐起点。
Linux 软件包（Omnibus）
基于 Linux 软件包的参考架构使用该软件包将所有极狐GitLab 组件部署在虚拟机上。部分组件（PostgreSQL、Redis、对象存储）可以选择使用云提供商服务。
以下 RPS 目标反映了典型的工作负载构成。对于非典型工作负载，请参阅了解 RPS 构成。
Cloud Native Hybrid
Cloud Native Hybrid 参考架构使用 Helm Chart 将部分无状态组件（Webservice、Sidekiq）部署在 Kubernetes 中，而部分组件仍保留在虚拟机上或使用云提供商服务（PostgreSQL、Redis、对象存储）。
Cloud Native
Cloud Native 架构将所有极狐GitLab 组件部署在 Kubernetes 中，而 PostgreSQL、Redis 和对象存储使用外部托管服务。四种标准化规模覆盖了大多数生产部署。对于非典型工作负载，请参阅参考架构规模确定。这是新部署的推荐架构。
如有疑问，先采用较大规模，监控后再缩减
如果您不确定所需的环境规模，可以考虑先采用较大的规模，对其进行监控，然后如果指标支持您的情况，再相应地缩减规模。
在以下情况下，先采用较大规模再缩减是一种审慎的做法：
例如，如果您有 3,000 名用户，但同时知道存在会显著增加并发负载的自动化，那么您可以先采用 100 RPS / 5k 用户级别的环境，对其进行监控，如果指标支持，再一次性或逐个缩减所有组件。
独立部署（非 HA）
对于服务 2,000 名或更少用户的环境，通常建议采用独立部署方式，即部署非 HA 的单节点或多节点环境。采用这种方式，您可以运用自动备份等策略进行恢复。这些策略提供了良好的恢复时间目标（RTO）或恢复点目标（RPO），同时避免了 HA 带来的复杂性。
对于独立部署，尤其是单节点环境，有多种安装和管理选项可供选择。这些选项包括通过部分云提供商市场直接部署的能力，可进一步降低复杂性。
高可用性（HA）
高可用性确保极狐GitLab 部署中的每个组件都能通过各种机制处理故障。然而，实现这一点很复杂，所需的环境规模也可能相当大。
对于服务 3,000 名或更多用户的环境，我们通常建议采用 HA 策略。在这一级别，服务中断会对更多用户产生更大影响。因此，此范围内的所有架构在设计上都内置了 HA。
您需要高可用性（HA）吗？
如前所述，实现 HA 是有代价的。环境要求相当大，因为每个组件都需要成倍增加，这会带来额外的实际成本和维护成本。
对于许多用户数少于 3,000 的客户，我们发现备份策略已经足够，甚至更可取。虽然恢复时间较慢，但这也意味着架构规模小得多，维护成本也因此更低。
作为一般准则，仅在以下场景中采用 HA：
- 当您有 3,000 名或更多用户时。
- 当极狐GitLab 停机会对您的工作流产生严重影响时。
缩减版高可用性（HA）方案
如果您仍需要为较少用户提供 HA，可以通过调整后的 3K 架构来实现。
零停机升级
零停机升级适用于采用 HA 的标准环境（Cloud Native Hybrid 不支持）。这允许环境在升级期间保持运行。不过，该过程因此更为复杂，并有一些限制，详见文档。
在进行此过程时，值得注意的是，当 HA 机制生效时，仍可能有短暂的中断时刻。
在大多数情况下，执行升级所需的中断时间不应很长。仅当这是您的关键需求时才使用此方案。
极狐GitLab Geo（跨区域分发 / 灾难恢复）
借助 极狐GitLab Geo，您可以实现位于不同区域的分布式环境，并配备完整的灾难恢复（DR）设置。极狐GitLab Geo 至少需要两个独立的环境：
- 一个主站点。
- 一个或多个作为副本的从站点。
如果主站点不可用，您可以故障转移到其中一个从站点。
仅当 DR 是您环境的关键需求时，才使用这种高级且复杂的设置。您还必须就每个站点的配置方式做出额外决策。例如，每个从站点是否与主站点采用相同的架构，或者每个站点是否配置为 HA。
大型单体仓库 / 额外工作负载
大型单体仓库或大量额外工作负载会显著影响环境的性能。根据具体情况，可能需要进行一些调整。
有关这些因素的全面分析，请参阅参考架构规模确定，其中提供：
- 针对单体仓库对基础设施影响的详细评估方法。
- 针对不同工作负载模式的特定组件扩展建议。
- 针对大量数据传输场景的网络带宽分析。
如果这种情况适用于您，请联系您的极狐GitLab 代表或我们的支持团队以获取进一步指导。
云提供商服务
对于前面描述的所有策略，您可以在等效的云提供商服务上运行部分极狐GitLab 组件，例如 PostgreSQL 数据库或 Redis/Valkey。
有关更多信息，请参阅基础设施和服务。
决策树
在参考以下决策树之前，请先完整阅读前面记录的指导内容。
Rendering chart...
要求
在实施参考架构之前，请参阅以下要求和指导。
支持的机器类型
这些架构在设计上对机器类型的选择保持灵活，同时确保性能一致。虽然我们在每个参考架构中提供了具体的机器类型示例，但这些并非规定性的默认值。
您可以使用任何满足或超过各组件指定要求的机器类型，例如：
- 更新一代的机器类型（如 GCP n2 系列或 AWS m6 系列）
- 不同的架构，如基于 ARM 的实例（例如 AWS Graviton）
- 更符合您特定工作负载特征的替代机器类型系列（例如更高的网络带宽）
本指导同样适用于任何云提供商服务，例如 AWS RDS。
由于性能不稳定，不建议使用任何“突发型”实例类型。
有关我们针对哪些机器类型进行测试以及如何测试的详细信息，请参阅验证和测试结果。
支持的磁盘类型
大多数标准磁盘类型预计都可用于极狐GitLab。不过，请注意以下具体说明：
- Gitaly 对 Gitaly 存储有特定的磁盘要求。
- 由于性能不稳定，我们不建议使用任何“突发型”磁盘类型。
其他磁盘类型预计都可用于极狐GitLab。请根据您的需求（如持久性或成本）进行选择。
支持的基础设施
极狐GitLab 应能运行在大多数基础设施上，例如信誉良好的云提供商（AWS、GCP、Azure）及其服务，或满足以下两项条件的私有化部署（ESXi）：
- 每个架构中详述的规格。
- 本节中的任何要求。
不过，这并不保证与每一种可能的组合都兼容。
有关更多信息，请参阅基础设施和服务。
网络（高可用性）
以下是以高可用性方式运行极狐GitLab 的网络要求。
网络延迟
网络延迟应尽可能低，以支持跨极狐GitLab 应用的同步复制，例如数据库复制。通常应低于 5 毫秒。
可用区（云提供商）
支持跨可用区部署，并且通常建议这样做以增强弹性。您应使用奇数个可用区，以符合极狐GitLab 应用的要求，因为某些组件使用奇数个节点进行法定投票。
数据中心（私有化部署）
跨多个私有化部署数据中心进行部署是可行的，但需要仔细考虑。这要求数据中心之间具备可同步的延迟、稳健的冗余网络链路以防止脑裂场景、所有数据中心位于同一地理区域，以及跨奇数个数据中心部署以进行正确的法定投票（类似可用区）。
极狐GitLab 支持可能无法协助解决由多数据中心部署引起的基础设施相关问题。 选择跨数据中心部署通常由您自行承担风险。 此外，不支持将单个极狐GitLab 环境跨不同区域部署。 数据中心应位于同一区域。
大型单体仓库
这些架构已使用遵循最佳实践的各种规模的代码仓库进行了测试。
然而，大型单体仓库（数 GB 或更大）会显著影响 Git 的性能，进而影响环境本身。它们的存在及其使用方式会给从 Gitaly 到底层基础设施的整个系统带来巨大压力。
性能影响在很大程度上是软件层面的。增加硬件资源会导致收益递减。
如果这适用于您，我们强烈建议您遵循链接的文档，并联系您的极狐GitLab 代表或我们的支持团队以获取进一步指导。
大型单体仓库会带来显著的成本。如果您有这样的代码仓库，请遵循以下指导以确保良好性能并控制成本：
- 优化大型单体仓库。使用 LFS 等功能不存储二进制文件，以及减少代码仓库大小的其他方法，可以 大幅提升性能并降低成本。
- 根据单体仓库的不同，可能需要增加环境规格来补偿。Gitaly 可能需要额外的资源，以及 Praefect、GitLab Rails 和负载均衡器。这取决于单体仓库本身及其使用情况。
- 当单体仓库非常大（20 GB 或更大）时，可能需要进一步的额外策略，例如进一步增加规格，或者在某些情况下，为单体仓库单独使用一个 Gitaly 后端。
- 网络和磁盘带宽是大型单体仓库的另一个潜在考虑因素。在非常重负载的情况下，如果存在大量并发克隆（例如通过 CI），带宽可能会饱和。在这种情况下，尽可能减少完整克隆。否则，可能需要额外的环境规格来增加带宽。这因云提供商而异。
额外工作负载
这些架构已基于真实数据，针对标准极狐GitLab 部署进行了设计和测试。
然而，额外工作负载会通过触发后续操作而使操作的影响成倍增加。如果您使用以下内容，可能需要调整建议的规格来补偿：
一般来说，您应该建立稳健的监控来衡量任何额外工作负载的影响，以便为需要做出的任何更改提供依据。请联系您的极狐GitLab 代表或我们的支持团队以获取进一步指导。
负载均衡器
这些架构根据级别最多使用两个负载均衡器：
- 外部负载均衡器 - 为任何面向外部的组件提供流量，主要是 Rails。
- 内部负载均衡器 - 为以 HA 方式部署的部分内部组件提供流量，例如 Praefect 或 PgBouncer。
使用哪个负载均衡器或其确切配置的具体细节超出了极狐GitLab 文档的范围。最常见的选项是在机器节点上设置负载均衡器，或使用云提供商提供的服务。如果部署 Cloud Native Hybrid 环境，chart 可以通过使用 Kubernetes Ingress 来处理外部负载均衡器的设置。
每个架构级别都包含一个推荐的基础机器规格，可直接部署在机器上。不过，它们可能需要根据所选负载均衡器和预期工作负载等因素进行调整。值得注意的是，机器可能具有不同的网络带宽，这也应加以考虑。
以下各节为负载均衡器提供了额外指导。
均衡算法
为确保对节点的调用均匀分布并获得良好性能，请尽可能使用基于最少连接的负载均衡算法或等效算法。
我们不建议使用轮询算法，因为已知它们在实践中无法均匀分布连接。
网络带宽
部署在机器上时，负载均衡器可用的总网络带宽在不同云提供商之间可能差异显著。一些云提供商，如 AWS，可能采用带积分的突发系统来确定任意时刻的带宽。
您的负载均衡器所需的网络带宽取决于数据形态和工作负载等因素。每个架构级别的推荐基础规格是基于真实数据选定的。不过，在某些场景下，例如持续克隆大型单体仓库、大量使用极狐GitLab 容器镜像仓库、大型 CI 产物，或任何涉及频繁传输大文件的工作负载，您可能需要相应地调整规格。
不使用交换空间
参考架构中不建议使用交换空间。它是一种会极大影响性能的故障保护机制。这些架构在设计上确保在大多数情况下有足够的内存，以避免需要使用交换空间。
Praefect PostgreSQL
Praefect 需要自己的数据库服务器。要实现完整的 HA，需要第三方 PostgreSQL 数据库解决方案。
我们希望将来能为这些限制提供内置解决方案。在此期间，可以按照规格所述，使用 Linux 软件包设置非 HA 的 PostgreSQL 服务器。有关更多详细信息，请参阅以下议题：
基础设施和服务
这些架构可运行在任何满足规格的基础设施上，无论是在云提供商上还是在本地。本文档通篇使用 GCP 和 AWS 作为示例和内部测试，但其他满足要求的提供商预计也能同样良好地运行。
对于 Cloud Native 和 Cloud Native Hybrid 部署，支持任何满足 GitLab Chart 先决条件的 Kubernetes 发行版。Kubernetes 平台特定的行为（网络、存储类、身份验证）不在极狐GitLab 支持范围内。
以下是每种服务类型的示例服务，用于测试和文档。其他满足下文各节所述要求的服务预计也能正常运行：
| 云服务 | GCP | AWS | Azure | 裸金属 |
|---|---|---|---|---|
| 对象存储 | Cloud Storage | S3 | Azure Blob Storage | 兼容 S3 的对象存储 |
| 数据库 | Cloud SQL 1 | RDS | Azure Database for PostgreSQL Flexible Server | |
| Redis | Memorystore | ElastiCache for Valkey 2 |
- 为获得最佳性能，尤其是在较大的环境中（500 RPS / 25k 用户或更高）， 请为 GCP Cloud SQL 使用企业 Plus 版。 根据您的工作负载，您可能需要将最大连接数调整到高于服务默认值。
- 使用 ElastiCache for Valkey 7.2。AWS 上不提供 ElastiCache for Redis 7.2。已知 ElastiCache for Redis 7.1 可以正常工作，但它基于 Redis 7.0 OSS 构建，不建议用于新部署。
数据库服务的最佳实践
您可以使用第三方外部 PostgreSQL 服务，来替代 Linux 软件包内置的 PostgreSQL、PgBouncer 和 Consul 服务发现组件。
请使用运行受支持的 PostgreSQL 版本的信誉良好的提供商。以下是已知可用的服务示例：
配置注意事项
使用外部数据库服务时，请考虑以下事项：
- 为获得最佳性能，请启用带只读副本的数据库负载均衡。将节点数与标准 Linux 软件包部署中使用的节点数保持一致。这种方法对于较大的环境（每秒超过 200 个请求或 10,000+ 用户）尤为重要。
- 高可用性节点要求可能因服务而异，并且与 Linux 软件包安装不同。
- 对于 极狐GitLab Geo，请确保该服务支持跨区域复制。
连接管理
为在使用外部数据库服务时获得最佳连接处理：
- 使用数据库负载均衡将连接分布到只读副本。
- 根据您的环境规模和工作负载调整 PostgreSQL 连接数配置。根据性能进行监控和调整。
- 如果需要额外的连接池，请部署您自己的 PgBouncer。其他第三方连接池解决方案可能可用，但尚未经过验证。
云提供商的连接池服务有以下限制，并且不兼容或不推荐使用：
- AWS RDS Proxy：未经验证可用于极狐GitLab。
- Azure Database for PostgreSQL PgBouncer：单线程架构，可观测性有限。在重负载下可能导致瓶颈。
极狐GitLab 内置的 PgBouncer 只能与内置的 PostgreSQL 配合使用，不能用于外部数据库服务。
数据库服务兼容性
以下数据库云提供商服务不兼容或不推荐使用：
- Amazon Aurora 不兼容且不受支持。有关更多详细信息，请参阅 14.4.0。
- Google AlloyDB 和 Amazon RDS Multi-AZ DB cluster 未经测试，不推荐使用。这两种解决方案预计都无法与极狐GitLab Geo 配合使用。
- Amazon RDS Multi-AZ DB instance 是单独的产品，受支持。
Redis 和 Valkey 服务的最佳实践
请使用运行标准、高性能且受支持版本的外部 Redis 或 Valkey 服务。该服务必须支持：
- Redis 独立（主 x 副本）模式 - 明确不支持 Redis 集群模式
- 通过复制实现高可用性
- 设置 Redis 逐出策略的能力
Redis 主要是单线程的。对于目标为 200 RPS / 10,000 用户级别或更大的环境，请将实例分为缓存和持久数据，以实现最佳性能。
不支持无服务器 Redis 和 Valkey 变体。
对象存储的最佳实践
极狐GitLab 已针对各种对象存储提供商进行了测试，预计它们都能正常工作。
请使用具有完整 S3 兼容性的信誉良好的解决方案。
偏离建议的参考架构
您偏离参考架构越远，获得支持的难度就越大。每一次偏离，都会引入一层复杂性，使潜在问题的故障排除变得复杂。
这些架构使用官方 Linux 软件包或 Helm Chart 来 安装和配置各种组件。这些组件安装在单独的机器上（虚拟化或裸金属）。机器硬件要求在特定参考架构页面的“配置”列中列出。等效的 VM 标准规格列在 每个可用架构的 GCP/AWS/Azure 列中。
您可以在 Docker 上运行极狐GitLab 组件，包括 Docker Compose。Docker 得到良好支持，并在各种环境中提供一致的规格。不过，它仍然是一个额外的层，可能会增加一些支持复杂性。例如，无法在容器中运行 strace。
不支持的方案
虽然我们努力为极狐GitLab 环境设计提供广泛的支持，但某些方案无法有效运作。以下各节详细说明了这些不支持的方案。
Kubernetes 中的有状态组件
不支持在 Kubernetes 中运行有状态组件，例如 Postgres 和 Redis。
您可以使用其他受支持的云提供商服务，除非特别指出为不支持。
单个 Gitaly 节点可以部署在 Kubernetes 上，并且通常可用。这提供了一种非 HA 解决方案，其中每个代码仓库存储在单个节点上。有关 Gitaly 部署选项和限制的背景信息，请参阅 Kubernetes 上的 Gitaly。
有关作为完全云原生设置的一部分在 Kubernetes 中部署 Gitaly 的参考架构，请参阅 Cloud Native 参考架构。
有状态节点的自动扩缩
作为一般指导，只有极狐GitLab 的无状态组件可以在自动扩缩组中运行，即 GitLab Rails 和 Sidekiq。其他有状态的组件，例如 Gitaly，不支持以这种方式运行。有关更多信息，请参阅议题 2997。
这适用于 Postgres 和 Redis 等有状态组件。您可以使用其他受支持的云提供商服务，除非特别指出为不支持。
Cloud Native Hybrid 设置通常比自动扩缩组更受青睐。Kubernetes 能更好地处理只能在一个节点上运行的组件， 例如数据库迁移和 Mailroom。
跨多个区域部署单个环境
极狐GitLab 不支持跨多个区域部署单个环境。这些设置可能导致严重问题，例如过高的网络延迟，或者如果区域之间的连接失败，会出现脑裂场景。
若干极狐GitLab 组件执行同步复制或需要奇数个节点才能正常运行，例如 Consul、Redis Sentinel 和 Praefect。将这些组件分布在高延迟的多个区域中，会严重影响其功能和整体系统性能。
此限制适用于所有可能的极狐GitLab 环境设置，包括 Cloud Native Hybrid 替代方案。
对于跨多个数据中心或区域部署极狐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 构成。
- 测试环境中组件之间的网络延迟观察为 <5 毫秒，但请注意这并非硬性要求。
测试覆盖范围和结果
测试旨在有效并为参考架构目标提供良好的覆盖范围，涵盖 Linux 软件包和 Cloud Native 环境。所测试的具体环境和配置会定期审查，以确保最佳的覆盖范围和成本效益平衡，并可能随时间而变化。
我们的测试还包括正在探索以可能在未来纳入的这些架构的原型变体。测试结果公开发布在参考架构 Wiki 上。
维护参考架构环境
维护参考架构环境通常与任何其他极狐GitLab 环境相同。
在本节中，您可以找到相关领域文档和特定架构说明的链接。
扩展环境
参考架构是基于典型工作负载模式设计的经过验证的起点，而非最终配置。大多数生产部署都能从根据通过监控显现的实际使用模式进行的调整中受益。这些架构通篇都是可扩展的，您可以随着工作负载特征变得清晰而迭代地调优它们。当指标显示持续的资源压力时，可以逐个组件扩展，也可以整体扩展到下一个架构规模。
如果某个组件持续耗尽分配给它的资源，请在进行任何重大扩展之前联系我们的支持团队。
何时扩展
大多数部署都能从观察实际工作负载模式后的调整中受益。触发扩展的常见场景包括：
资源规格调整：
- 为 API 密集型工作负载增加 Webservice/Rails 容量，尤其是当 API 流量超过总 RPS 的 90% 时（请参阅了解 RPS 构成）
- 为单体仓库密集型环境或当代码仓库大小超过 2 GB 时扩展 Gitaly（请参阅识别组件调整）
- 为高 CI/CD 吞吐量或繁重的后台作业处理调整 Sidekiq 工作进程
配置调优：
- 根据并发访问模式设置 Gitaly 代码仓库 cgroup 数量（请参阅 Gitaly cgroup）
- 配置 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 形式部署时需要奇数个节点才能进行法定投票。
- 显著扩展某些组件可能会产生明显的连锁反应，影响环境的性能。有关更多指导，请参阅扩展的连锁反应。
反之，如果您有稳健的指标表明环境过度预配，则可以向下扩展。向下扩展时应采取迭代方式，以确保没有问题。
扩展的连锁反应
在某些情况下，显著扩展某个组件可能会对下游组件产生连锁反应，影响性能。这些架构在设计时考虑了平衡，以确保相互依赖的组件在规格上保持一致。值得注意的是，扩展某个组件可能会导致额外的吞吐量传递给它所依赖的其他组件。因此，您可能也必须扩展这些其他依赖组件。要确定这一点，请在扩展之前监控所有依赖服务的饱和度指标。如果多个相互依赖的组件显示饱和，应以协调的方式一起扩展，而不是依次扩展，以防止瓶颈只是在组件之间转移。
这些架构在设计上具有弹性，以适应上游组件的扩展。不过，为安全起见，在对您的环境进行任何重大更改之前，请联系我们的支持团队。
以下组件在显著扩展时可能会影响其他组件：
- Puma 和 Sidekiq - Puma 或 Sidekiq 工作进程的显著扩展会导致到内部负载均衡器、PostgreSQL（如果存在则通过 PgBouncer）、Gitaly（如果存在则通过 Praefect）和 Redis 的并发连接增加。
- Redis 主要是单线程的。在某些情况下，如果增加的吞吐量导致组合集群中的 CPU 耗尽，您可能需要将 Redis 拆分为单独的实例（例如，缓存和持久）。
- PgBouncer 也是单线程的，但水平扩展可能会导致添加新的池，进而可能增加与 Postgres 的总连接数。强烈建议仅在您有管理 Postgres 连接的经验时才这样做，如有疑问请寻求帮助。
- Gitaly 集群 (Praefect)/PostgreSQL - 显著扩展额外节点可能会对 HA 系统和性能产生不利影响，因为会增加对主节点的复制调用。
从非 HA 架构扩展到 HA 架构
在大多数情况下，只需垂直扩展即可增加环境的资源。不过，如果您要迁移到 HA 环境，则需要为以下组件执行额外步骤，以切换到其 HA 形式。
有关更多信息，请参阅以下文档：
- Redis 到带 Redis Sentinel 的多节点 Redis
- Postgres 到带 Consul + PgBouncer 的多节点 Postgres
- Gitaly 到 Gitaly 集群 (Praefect)
升级
升级参考架构环境与任何其他极狐GitLab 环境相同。有关更多信息，请参阅 升级极狐GitLab。零停机升级也可用。
您应按照创建参考架构的相同顺序升级它。
监控
您可以使用各种选项监控您的基础设施和极狐GitLab。有关更多信息，请参阅所选监控解决方案的文档。
极狐GitLab 应用内置了 Prometheus 和各种 Prometheus 兼容的 exporter，可以接入您的解决方案。
更新历史
您可以在 GitLab 项目上找到完整的更改历史。