Code：美团代码托管平台的演进与实践

美团代码托管平台经过长期的打磨，完成了分布式架构的改造落地，托管数以万计的仓库，日均Git相关请求达到千万级别。本文主要介绍了美团代码托管平台在迭代演进过程中面临的挑战及解决思路，希望对大家有所帮助或启发。

• 1. 引言

• 2. 美团代码托管平台建设之路

  • 2.1 代码托管平台的发展史

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

  • 3.1 扩展性目标

  • 3.2 可用性目标

• 4. 总结

• 5. 未来展望

1. 引言

Code是美团自研的代码托管平台，其中包括了代码版本管理、分支管理及代码评审等功能，协同众多研发流程工具平台，支撑内部所有工程师的日常研发工作。经过近3年的建设，目前Code托管了数以万计的仓库，日常处理千万级的Git相关请求，稳定支撑着美团研发流程规范的持续落地。本文主要介绍美团在建设代码托管平台过程中面临的一些挑战和实践经验。

2. 美团代码托管平台建设之路

2.1 代码托管平台的发展史

回顾美团代码托管平台的发展史，整个历程可以划分为三个阶段：单机部署、多机部署以及自研分布式代码托管平台。

第一阶段：单机部署

美团最初的代码托管平台，和绝大多数Web系统一样，单机部署即可运行，所有用户的请求均通过Web应用进行响应。由于Git使用基于文件组织形式的存储模式，无论是通过页面访问还是执行Git命令操作，最终都会表现为磁盘的文件读写，高IO磁盘尤为重要。整体架构如下图1所示：

图1 单机部署

第二阶段：多机部署

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

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

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

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

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

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

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

图2 多机部署

如图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. 针对于应用层分片的劣势，在架构设计时也做了相应的针对性优化，具体如下：