第二阶段：多机部署

在访问规模不大的情况下，第一阶段这种单机架构可以满足日常的开发需求。但随着研发团队业务需求的不断增长，测试自动化流程的逐步完善，扩展性瓶颈也愈发明显，主要表现为以下2个方面：

• 存储：由于公司资源限制和地域分配不均等因素，代码托管平台部署机器已配置最大容量的可用SSD磁盘，使用率仍高达80%，可用空间严重不足。

• 负载：随着研发人员的不断增多，在访问高峰期，CPU和IO负载高达95%以上，页面出现严重的卡顿，仅能通过限流保障系统的持续服务。

因而，单机部署无法再承载高峰期的访问量，系统扩容刻不容缓。于是，我们开始设计了一套能够通过多机负载同一仓库IO的读写分离架构方案，以解决较为严重的IO负载问题。在读写分离架构中，最重要的是要保证用户视角的数据一致性（用户随时可以读取提交的最新代码），这里采取了以下措施：

1. 写操作仅发生在主节点。

2. 采用懒汉同步模式，在读取数据时触发从节点同步数据，若失败，则路由到主节点。

3. 采用独主兜底模式，遇到突发情况时可以迅速禁用从节点，保障数据安全。

如图2所示，我们将仓库访问形式按照应用层协议区分为HTTP和SSH，分别由对应的解析代理模块进行读写分发操作后再下发到主从节点（此处采用了Round-Bobin的算法分发读请求），使得整体读吞吐量扩大了2倍。对于从节点，我们部署了Agent，在用户发起读请求时会触发同步仓库数据的Fetch操作，以保证数据的一致性。

第三阶段：自研分布式代码托管平台

在第二阶段，虽然通过多机负载IO的读写分离架构短暂性地解决了扩展性瓶颈问题，但仓库数据仍在持续不断地指数增长。同时，除扩展性问题之外，可用性瓶颈也凸显出来，主要表现在以下2个方面：

• 运维：无论是日常迭代更新版本还是热修复紧急Bug，都需要停服才能部署系统，停服期间用户无法使用代码托管平台。

• 备份：系统采用冷备份的方式多副本存储Git数据，无法保证核心数据的实时恢复，异常情况下存在数据丢失风险。

因此，搭建具备高可用性和水平扩展性的分布式架构迫在眉睫。我们调研了业界主流代码托管平台的分布式方案，并结合公司内部的业务特性，最终选择了基于应用层分片的分布式架构，该架构满足了以下2个特性：

• 高可用：采用三副本多活模式，规避代码丢失风险，且系统版本更新无需停服，单机断电、宕机均可正常提供服务。

• 水平扩展：可通过扩容分片集群的方式进行存储和负载扩展，实现广义下的“无限”容量。

综上所述，Code基于GitLab生态开源组件二次开发，并采用了应用层分片多活模式的分布式架构方案，简介如下：

1. 底层存储服务基于GitLab生态开源组件二次开发，有良好的生态和丰富的功能支持。

2. 各服务间均通过gRPC进行交互通信，主要考虑点是Git大多数为二进制数据通信，gRPC基于HTTP 2.0，有良好的传输性能和流式支持。

3. 通过路由模块实现逻辑层与存储层有效隔离，逻辑层对物理分片无感知，存储层如同一个整体提供服务。

4. 采用了多活复制模式的数据保障架构，提高读写吞吐量，满足日均千万级的请求量需求。

5. 针对于应用层分片的劣势，在架构设计时也做了相应的针对性优化，具体如下：

• 热点库：提供了自动化的分片迁移能力，在发现仓库出现热点时，可进行分片迁移达到分片均衡。

• 跨分片数据交互：通过业务层的Git事务包装，我们使用共享Object的模式并确保相互关联的仓库均落在同一分片上，既避免了跨分片通信的问题，也减少了磁盘空间占用和访问时延。

3. 美团代码托管平台架构演进的落地和挑战

代码托管平台在架构演进过程中，最终完成了以下两个目标：

• 高可用：针对计算和存储资源，可以实现水平扩展。

• 高扩展：缩短停机时间，提高可用性，系统稳定可靠。

接下来，针对于每个目标，本文分别从技术挑战、方案选型、设计及解决方案等方面详细介绍我们的实践经验。

3.1 扩展性目标

3.1.1 技术挑战

在进行水平扩展改造时，主要面临了以下两类挑战：

• 规模性：在研发流程自动化等背景下，美团代码托管平台需要具备千万级吞吐、低延迟及高可用的系统性能，以提高研发效率。

• 兼容性：技术改造涉及的场景比较多，主要有两方面的考量：（1）用户低感知，新老系统保证现有通信方式及平台使用方式不变；（2）兼顾过渡时期底层存储介质多样性、运维体系兼容等问题，并保障上下游系统的正常运行。

3.1.2 方案选型

经过对主流代码托管平台（GitHub、GitLab、Bitbucket等）的调研分析，发现各大平台主要采用了以下两种架构解决扩展性问题。

通过上述对比可以发现，如果直接接入共享存储，暂时无法满足代码托管平台的稳定性和性能要求（若Git机制进行并行优化，且使用更高读写性能的分布式存储系统，或许是一个不错的选择）。在共享存储优化改造成本较高的前提下，我们最终采用了应用层分片的分布式架构，它既满足扩展性的要求，也更加成熟和稳定，并表现出不错的性能。

3.1.3 方案设计

我们通过代理模块实现了请求分发，通过路由模块实现了仓库分片，通过应用模块的无状态改造实现了弹性伸缩，从而达成了水平扩展的架构目标。下面将对这些模块进行详细的介绍。

代理模块

• SSH Proxy：提供Git-SSH请求代理，通过路由模块获取路由信息，到目标机器执行SSH操作。SSH Proxy组件基于go-crypto库开发，实现了公钥识别用户，流量控制，长连接超时处理，SSH转gRPC等功能。后续计划引入signature校验，以应对不同的使用场景。

• HTTP Proxy：提供Git-HTTP/Web请求代理，通过路由模块存储的仓库分片映射关系，决策仓库路由节点。HTTP Proxy基于Go-Gin开发，实现了请求甄别，流量控制，多层代理等功能。最初HTTP Proxy还被作为灰度迁移的核心组件，通过流量统一收口，支持请求分发到新老Code系统，以确保请求和数据的平滑迁移。

路由模块

• Shard：记录仓库与其所在分片之间的映射关系，是应用层分片架构的“中枢系统”。Shard服务除维护映射关系外，还是容灾模块必不可少的“决策者”，通过获取各个节点当前访问仓库的最新版本，从而决定读写路由。由于Golang出色的高并发表现，目前路由相关接口的平均响应时间在15ms以内。该模块的主要特性如下：

1. 建立仓库和分片的映射关系，为了避免由于仓库路径更新造成文件夹拷贝/移动等行为带来一定的复杂性，这里采用了仓库ID作为唯一标识。

2. 利用Go Routine获取节点的数据同步状态，并通过超时机制保障用户非无限时等待。

3. 使用Key-Value Cache存储仓库和分片的映射，以降低映射关系的请求时延。

应用模块

应用模块主要包括以下两点功能：

• 提供Git相关的业务逻辑接口处理代码内容信息、代码评审等复杂性业务请求。

• 监听代码和分支变更消息，发送事件通知打通第三方业务系统和收集度量信息。

整体模块架构如下图7所示：

3.1.4 解决思路

规模性解决思路

规模化的主要目标是：具备支撑千万级请求的系统能力，并支持计算、存储等资源的水平扩展能力，其中路由均衡是必不可少的一环。

a. 路由均衡

Code系统对数据源可靠性要求较高，而对性能要求相对比较低，因而我们采用了严格仲裁的路由模式，具体的逻辑配置如下：

• 使用版本号判定哪个节点提供的代码内容最新：版本号越大，代表数据越新，当版本最大时即为最新的数据。当W+R > N时总能读到最新的数据（N：总节点个数，W：判断写入成功需要的响应节点数，R：读取数据时至少要成功读取的个数），当W越小时，写入的可用性就越高，R越小，读取的可用性就越高。我们选择了N=3，R=W=2的常规推荐配置，根据概率推算可达到99.999%的可用性水平。

• 采用读修复模式：当读取数据时，若发现节点数据不一致，此时触发数据同步逻辑，以修复落后节点的数据。

该功能内置于路由模块的Shard服务，架构如下图8所示：

兼容性解决思路

兼容性目标总结为一句话就是：业务使用无感知。因此，我们主要从以下三个方面考虑兼容性。

a. 与各系统交互方式及现有基础设施兼容

Code系统的众多下游系统（多套前端UI、业务研发流程工具平台等）依赖系统提供的开放API、Hook机制等扩展功能，为了减少系统升级对业务方造成影响，需要保证系统交互方式兼容；同时还要确保系统运维监控体系正常运行，维持可监测状态，我们主要做了以下四件事情：

• 兼容核心功能：使用频度高的功能平移到新系统，而使用中低频的功能，与业务沟通使用场景，再评估是否兼容。

• 重新设计部分功能：提供更为合理的WebHook配置能力及崭新的代码评审功能。

• 边缘功能运营下线：推进废弃和历史遗留功能的下线，并提供合理的替代方案。

• 打通运维体系：保持现有监控埋点及运维接口接入方式，使系统处于可维护、可监测的状态。

b. 非分布式版本无缝切换到分布式版本

Code系统仓库众多，需要有低成本的用户自主切换方式保障数据逐步迁移，我们主要做了以下三件事情：

• 可视化自动切换：通过页面一键迁移按钮，低成本实现从非分布式版本切换到分布式版本（迁移进度可感知，执行过程中仓库可读不可写，确保数据完整）。

• Proxy屏蔽底层存储介质多样性：通过Proxy保持单一的调用方式不变，可兼顾获取非分布式版本和分布式版本的存储数据。

• 特殊数据共享存储：用户和SSH Public Key等数据与仓库数据没有强制关联关系，可实现数据共享。

c. 历史数据平滑迁移

Code系统存在众多的历史代码数据和业务数据，如何有效、完整地将历史数据平滑迁移到新的分布式系统，变得尤为重要。为了达成业务使用无感知的目标，主要做了以下两件事情：

• 优先迁移“轻量”仓库：先迁移使用功能单一的仓库，根据用户反馈逐步完善迁移能力。

• 业务维度批次迁移：按照业务线划分迁移批次，同类使用模式的仓库同期迁移，以规避反馈问题多样性。

3.2 可用性目标

3.2.1 技术挑战

在进行可用性改造时，我们主要面临数据安全性层面的挑战。代码作为公司的重要资产之一，需达到两方面的要求：

1. 代码单点丢失可数据恢复。

2. 用户视角可以读到正确的代码数据。

3.2.2 方案选型

目前，业界主要有以下三种主流的数据复制模式。

业界大多数分布式Git系统采用的是单主复制模式保障数据安全，随着美团内部研发流程的逐步完善，对于创建代码注释Tag等需求逐步增加，读写比从最初的10:1缩短到现在的5:1，因此需要较高的写入性能。

我们权衡了高吞吐量和数据强一致性的双重目标，在单主复制架构的基础上，采用以仓库维度单主复制为核心，节点多活为特性的复制模式（下文简称为多活模式），从而保证了数据安全和系统可用性。

3.2.3 方案设计

我们主要通过存储模块中，对Git的读、写及初始化三类不同的请求分别采取相对应的数据处理机制，并结合多活复制模式，达成了高可用性的目标。

存储模块

Git Server：主要存储和管理Git仓库数据，提供Git相关的gRPC接口。该服务基于GitLab生态开源组件二次开发，主要在数据同步机制、容灾模块、部分底层命令上做了适配性优化，共涉及以下4个逻辑模块：

1. Replication Manager：数据复制核心模块，根据不同的请求（读、写或初始化）执行不同的复制逻辑，从而保障数据一致性。

2. Code Core：Git Server的核心服务模块，主要提供了Git的gRPC API供上游模块使用。

3. Git Core：实现扩展性和高可用性的重要组件，这里通过源码的方式将GitLab生态开源组件引入到项目中，作为第三方Git API供项目使用。

4. Git Command Factory：Git命令的中枢控制器，提供控制Git进程数量、传递参数上下文，隔离执行环境及格式化输出数据等功能。

各个逻辑模块间关联如下图10所示：

Git Cluster：又称为分片，它由三个Git Server节点组成。三个节点间通过各自的Replication Manager模块获取到集群中其余节点的IP等信息，使用gRPC协议进行数据复制备份，可以保证用户视角的数据一致性，逻辑架构如下图11所示：

3.2.4 解决思路

数据安全性解决思路

Code系统要解决的问题中，数据安全问题尤为重要，是保证研发流程安全可靠的关键。在考虑数据安全性解决思路之前，先要明确数据一致性判别准则，Code采用以下准则评判两个仓库数据一致。

数据一致评判准则：若仓库所在两个节点存储的refs数据完全一致，则称为这两个节点上的仓库数据一致。

目前系统数据安全机制主要有以下几个特点：

a. 多活复制

目前Code系统每个分片包含3个节点，即代码数据保证三副本，即使出现1~2台节点故障导致数据不可恢复的情况，也可通过其他节点进行数据恢复。我们采用了多活复制模式，即任何一个满足必要条件（当前访问仓库在该节点的数据均重演至最新版本）的机器节点均可以进行读写操作，与单主模式相比提高了写操作的吞吐量，节省了主备切换的成本，使部署、节点替换及异常恢复更加简单。多活复制模式约束有以下两点：

1. “单写”机制：在同一时刻，同一个仓库的写操作须在同一节点进行。

2. 数据安全锁机制：若某仓库底层Git的操作出现异常错误，则在数据未恢复前，其后对该仓库的所有操作均会在该节点进行，会产生局部热点。

多活复制主要由数据存储和数据压缩两个部分组成。

01 数据存储

1. Git主要由objects和refs两类数据组成。objects数据为不可变数据，创建后为只读模式，以文件的形式存储于本地磁盘中；refs数据为可变数据，可以进行更新。两类数据分别采用不同数据源进行存储。

2. 用户在访问仓库时，如果某个objects没有在任何一个分支的关联链中，那么判定为不可达，对于不可达的objects，无需维护其一致性。不可达object的示例如下：

02 数据压缩

在Code系统中，需要记录refs的变更日志以进行数据回放，保证系统的数据一致性。由于每个仓库的refs数据变换是比较频繁的，会产生大量的日志，从而造成存储压力。因而我们采用了日志压缩技术，减少不必要的数据开销，压缩方式如下图13所示：

例如上图中的main分支，其初始状态为main -> a，第4个log为main -> e，第5个log为main -> f，则这3个log可以压缩为一个log，即main -> f并将其应用于初始状态，与压缩前回放触发的结果是一致的，main都将指向值为f的commit。

03 相关优化

在实践过程中，我们发现采用纯Git命令执行数据复制操作无法有效控制资源分配，因而从通信方式、并发形式及复制粒度等方面做了优化，从而提高了整体的数据复制效率。

b. 跨机房备份

Code系统每组分片的3个节点至少来自于两个不同的机房（目前按照规范化部署，均改造为3机房），若其中一个机房发生故障，仍可提供服务。我们对该架构做了针对性的容灾演练，通过演练验证了节点掉线对系统的影响较小，结合灵活的节点替换能力，可在30分钟内上线新的节点，达到容灾平衡状态。

c. 数据热备

Code提供数据热备机制，通过数据复制的方式，任何写入的新数据会立即同步到其余副本节点，基本“0”延迟，保证了用户视角的强一致性。数据同步机制是热备的关键，我们主要通过以下步骤实现。

01 写操作阶段

1. 通过引入仓库粒度的写锁，保证同一个仓库同时只能在一个节点执行写入操作，然后通过Git Internal Hook机制触发object数据的同步，并持久化记录refs数据。

2. 副本节点通过读取持久化的refs数据，重演操作，从而保持了refs数据与写入节点一致。

02 读操作阶段

1. 如果当前仓库持有写锁，则直接路由至持有写锁的节点读取数据。

2. 如果未持有写锁，则用各个节点的版本和数据源存储的版本数据进行对比，将版本大于等于数据源存储的最新版本的所有节点作为候选路由节点，并采用负载均衡算法进行路由；如果没有符合条件的节点则需进行同步补偿，待补偿成功后再进行路由选择 。

03 相关优化

在最初实现中，我们采用了无状态同步，发现存在同步任务被多次执行的情况，后续通过任务前置检查等方式避免了不必要的数据同步任务，最终减少了50%的同步任务。

d. 数据巡检

数据巡检是保证系统平稳运行，数据安全可靠必不可少的一个环节，它可以及早地发现系统中潜在的隐患。巡检服务作为Code系统的核心服务，在降低数据风险，提高系统服务的稳定性方面起到了关键作用。对于巡检服务，我们主要从以下几个方面进行考虑：

• 透明性：尽可能地避免对用户的正常请求产生影响，减少不必要的干扰，对于系统访问可以做到平稳可控。

• 可靠性：作为数据安全的重要服务，它自身也要做到弹性伸缩，多点容灾，具有高可用的特性。

• 可维护性：对于数据巡检发现的问题，能够通过有效手段进行处理。同时要提高巡检服务的效率，随着系统架构的迭代出新、模块升级，巡检服务要随之更新，从而做到有效的保障。

综合以上几点，我们采用了无状态的服务架构，提供定点巡检、全量巡检、定时巡检等模式保障数据安全。其中巡检的数据主要分为以下两类：

• refs数据：根据数据一致性评判准则，refs数据是Git核心数据，因而它的检验是必不可少的。

• 版本数据：Code系统是基于版本进行读写路由的，因而当版本过大时，可能会产生大量的数据同步，为了避免突增同步请求对系统造成一定的IO抖动，监控版本差距是尤为必要的。

巡检服务的整体架构如下图17所示：

4. 总结

本文系统性地介绍了美团在Code系统演进过程中面临的扩展性和可用性两大瓶颈，并分别针对上述两类瓶颈和对应的挑战，详细阐述了解决方案和落地的实践经验。

基于上述的架构改造实践，目前美团代码托管平台实现了仓库容量水平扩展、负载自主均衡等特性，稳定支撑着研发流程规范的落地。我们未来会在支撑研发效率，保障研发安全方面继续进行探索和演进，争取积累更多宝贵的实践经验，后续再跟大家分享。

5. 未来展望

• 自动化运维：目前系统的运维机制自动化程度低，我们希望未来可以自动检出系统异常并进行恢复，其中包括数据修复、自动扩容及热点迁移等功能。

• 提供代码领域最佳实践：依托研发工具平台，持续推动美团研发流程规范的迭代更新，沉淀最佳实践并提供有力的工具支撑。

• 代码安全：与信息安全团队紧密合作，提供更为完备的安全控制策略，包括代码扫描、漏洞自动修复、危险行为预警等功能。

6. 本文作者及团队简介

潘陶、费翔、丹丹、毛强等，来自基础研发平台-研发质量与效率团队。

美团研发质量与效率团队，负责公司研发效能领域平台和工具的建设（包括研发需求管理工具、CI/CD流水线、分布式代码托管平台、多语言构建工具、发布平台、测试环境管理平台、全链路压测平台等），致力于不断推进优秀的研发理念和工程实践，建设一流的工程基础设施。

----------  END  ----------

也许你还想看

  | 美团BERT的探索和实践

  | Transformer 在美团搜索排序中的实践

  | 常识性概念图谱建设以及在美团场景中的应用

前端 |  算法 | 后端 | 数据

安全 | Android | iOS  | 运维 | 测试