驯服单体库怪兽：我们走向更精简、更快速的GitLab仓库之旅

At Grab, our engineering teams rely on a massive Go monorepo that serves as the backbone for a large portion of our backend services. This repository has been our development foundation for over a decade, but age brought complexity, and size brought sluggishness. What was once a source of unified code became a bottleneck that was slowing down our developers and straining our infrastructure.

在Grab，我们的工程团队依赖于一个庞大的Go单体仓库，它作为我们大部分后端服务的支柱。这个仓库已经成为我们十多年来的开发基础，但随着时间的推移，复杂性增加，规模也带来了迟缓。曾经是统一代码源的它，变成了一个瓶颈，减缓了我们的开发者的速度，并给我们的基础设施带来了压力。

A primer on GitLab, Gitaly, and replication

关于GitLab、Gitaly和复制的入门

To understand our core problem, it’s helpful to know how GitLab handles repositories at scale. GitLab uses Gitaly, its Git RPC service, to manage all Git operations. In a high-availability setup like ours, we use a Gitaly Cluster with multiple nodes.

要理解我们的核心问题，了解 GitLab 如何在大规模下处理仓库是有帮助的。GitLab 使用 Gitaly，其 Git RPC 服务，来管理所有 Git 操作。在像我们这样的高可用性设置中，我们使用多个节点的 Gitaly 集群。

Here’s how it works:

它是如何工作的：

• Write operations: A primary Gitaly node handles all write operations.
• 写操作: 一个 主 Gitaly 节点处理所有写操作。
• Replication: Data is replicated to secondary nodes.
• 复制：数据被复制到辅助节点。
• Read operations: Secondary nodes handle read operations, such as clones and fetches, effectively distributing the load across the cluster.
• 读取操作：辅助节点有效地处理读取操作，如克隆和获取，合理分配集群的负载。
• Failover: If the primary node fails, a secondary node can take over. For the system to function effectively, replication must be nearly instantaneous. When secondary nodes experience significant delays syncing with the primary—a condition called replication lag—GitLab stops routing read requests to the secondary nodes to ensure data consistency. This forces all traffic back to the primary node, eliminating the benefits of our distributed setup. Figure 1 illustrates the replication architecture of Gitaly nodes.
• 故障转移：如果主节点失败，辅助节点可以接管。为了使系统有效运行，复制必须几乎是瞬时的。当辅助节点在与主节点同步时经历显著延迟——这种情况称为复制延迟——GitLab会停止将读取请求路由到辅助节点，以确保数据一致性。这迫使所有流量返回主节点，从而消除了我们分布式设置的好处。图1展示了Gitaly节点的复制架构。

Figure 1: The replication architect...