揭秘腾讯代码管理核心工蜂 Git 系统架构

腾讯工蜂 Git

https://code.tencent.com

引言：

近日，2018 DevOps China 沙龙在深圳腾讯大厦举办。本次沙龙邀请了多位嘉宾，分享了关于 DevOps 的实践与心得。会上，腾讯高级工程师、工蜂系统架构负责人罗奇带来“揭秘腾讯代码管理核心：工蜂 Git 系统架构”的经验分享，为大家阐述了腾讯工蜂的起源、发展以及未来规划。

1 腾讯工蜂

腾讯工蜂是腾讯经过 10 年的积累和摸索打造的企业代码管理协作解决方案。具备代码检视、分支管理、会话式开发、集成定制、审查和监控等企业级研发管理系统特性，秉承了前沿的研发思想和先进的研发理念，助力企业贯穿研发流程，让开发和研发管理更加敏捷高效。

2 工蜂系统的架构

从 2012 年开始，Git 逐渐成熟。因为 Git 的去中心化、快速拉取分支和便捷使用等特性，被众多开发者所青睐，Git 的使用在国内逐渐流行起来。此时腾讯也正着手准备搭建 Git 代码托管系统，计划将原来的 SVN 逐步切换到 Git 上。

我们采用自研的方式，是因为它既能够满足整个腾讯的日益增长的代码托管需求，又能够很好地适应公司企业管理、安全和内部开源文化。在架构方面，面对腾讯这样的体量，我们需要分布式集群的能力和高可用的解决方案，也需要强化后台管理、监控、运维能力。再者，自研有很好的可控性，可以做很多企业定制化的功能。

在系统架构的选择上，为应对腾讯上百 T 的代码库总量，和不断产生的平台方接入需求，比如自动构建、自动代码扫描等，我们选择了微服务。微服务结合容器部署方案，具备快速水平扩展、可插拔和增量发布等特性，这些特性能够很好的满足高可用高并发场景。

在存储扩容方案上，考虑到 Git 的代码库服务是 IO 密集型，再加上大库在分布式存储中的性能不足，最终选定数据分片作为存储扩容方案。使用数据分片的优点在于，它可以根据业务需求实现不同的分片策略，控制灵活和方便扩展。

在工蜂架构的流程图中，列举了 SSH、HTTP、WEB 和 API 四种网络请求的方式。Auth 用于统一的认证服务，Router 用于数据分片寻址的路由服务，Manager 用于后台数据的组装服务，最后端则是代码库集群。

路由是所有服务的核心，所有对代码仓库操作的请求都要通过路由进行寻址，并且通过切面的方式，最终实现对业务调用的透明和较低的侵入。

以客户端 HTTP 请求这条链路为例，用户请求先通过 Nginx，转发到 HTTP 代理，经过调用 Auth 认证，认证成功后由路由查找对应集群节点，最后透传到对应的 Server 集群。

图中右边的代码库 Server 采用的是两地三中心的容灾解决方案。

3 架构提供了哪些能力

• 水平扩展能力，由于服务都采用容器部署，再加上无状态的底层服务，水平扩展将更加方便。即使突然有大量业务接入时，系统也能随时通过调整实例数量的方式进行轻松扩展，做到快速响应。
• 服务间的独立性，单链路出现异常时，其它链路依然保持正常工作。例如数据库所在的网络受到影响，web 服务出现短暂异常，但由于 HTTP 代理有缓存路由数据，所以用户最基本的 Pull/Push 等客户端操作依然能够正常运行，开发人员的基本代码操作不会受到任何影响。
• 提供熔断、有损服务，防止瞬时负载过高引发的雪崩效应。
• 服务的高可用，我们通过运用两地三中心和主写双活的方式，并且采用跨机房，定期增量备份等措施，提供高标准的可用性和容灾备份能力。

4 实际运营中遇到了哪些问题

随着工蜂系统用户量的增长，系统在运行中也逐渐涌现出新的问题，例如出现了异地项目访问慢、大库项目逐渐增多和大库 Merge 操作超时等问题。为了能够尽快解决这些眼前的问题，我们决定对工蜂系统进行一次新版本的进化。

5 工蜂系统架构的进化

下面是新版本的架构流程图，黄色部分是系统增加的新特性。我们引入 IDC 选择器来解决异地部署的问题，引入 LFS 用来解决大库问题，从而分别实现异地项目快速访问和大库操作快速响应。

• LFS

在实际运营中，有大量用户反馈加载慢的问题，通过扫描发现此类用户的项目包含大量依赖包文件，其中还关联大量的历史。除此之外，有些游戏业务部门的项目数据量超过 50G，其中包含大量的图片和视频资源。

为了解决项目容量大而导致操作加载缓慢的问题，我们引入了开源的 Git-lfs 方案。从图中我们可以看到，用户本地库有各种类型的文件，包括代码、图片、视频等文件，通过把这些文件存储在 Git 仓库之外，在 Git 仓库中只保留文件的文本指针，这种方式可以减小 Git 仓库本身的体积，也可以加快克隆仓库的速度。

下面是 LFS 部署的架构流程图。我们部署了 LFS 代理和专门的 LFS 服务器。当用户有 LFS 操作时，Git 智能协议会将代码、图片、视频等文件的文本指针，通过 HTTP 代理推送到代码仓库，再将文件资源推送到 LFS 代理，LFS 代理会先查找路由，进行权限认证，最终把文件资源推送到 LFS 服务器。此外，为了能够让用户在后台进行统一的控制，我们还在 HTTP 代理中添加了后台配置，对单个文件、单次提交进行拦截，拦截后会通知用户使用 LFS 进行转换。

• 异地协同开发

我们发现，异地项目访问慢的情况发生在这种场景：同一部门的员工分别分布在深圳和北京，他们都需要使用工蜂系统。北京的小组有独立的项目，而深圳与北京的员工之间又有公共的项目。当项目中出现对于大库的 Clone 和 Push 等操作时，系统响应会非常缓慢。作为同一个部门，在有公共项目的情况下，部署两套完全不同的环境是不可能的，那如何解决这种问题呢？

假设 IDC1 是深圳，IDC2 是北京。我们只需在深圳的一套完整系统中增加 IDC 协调器，然后在北京部署最基本的 HTTP 代理、路由、IDC 选择器和用于读写的新的 Server 集群，就可以解决上述问题。当北京的同事在使用客户端操作时，访问请求会由 IDC 选择器分配到对应的地方，从而实现就近访问。协同开发方面，由于北京和深圳的 Web 和数据库采用同一套系统，所以数据之间是相互可见的，同事之间可以通过 Fork 公共项目来进行协同开发。

还有另外一种异地协同开发的场景。例如北京的同事需要使用深圳共用的构建系统，进行版本的构建和发版。这种场景是需要在不同网络中使用同一个版本库。为了能够实现这种异地构建的场景，我们在北京部署最基本的 HTTP 代理、路由、IDC 选择器和一台备机（备机和主机分配在同一个集群）。当主机接收到写请求时，协调器会根据 IDC 标志，分别对两边的备机下发同步任务，实现数据的同步，这样就可以满足异地构建的需求。

6 进化所带来的能力提升

• 大库方案

在上一个版本中，我们已经通过将存储数据分片和微服务，让整体存储容量可以自由地水平扩展，最终实现整体存储容量无上限。现在通过 LFS，单个库也能实现理论上容量无限制。现在不仅能够轻松应对游戏部门整体项目迁移的需求，还能做到后台统一配置和管理拦截大文件的规则。

• 异地协同开发能力

通过 IDC 选择器，现在工蜂系统能做到就近访问和协同开发，在保证数据统一和系统易维护的基础之上，为分公司同事提供了较好的使用体验。

• 计算和存储分离

MySQL 的分片支持，让数据容量和 API 调用也能实现分片操作，从而提供海量数据的支持。

• 提供 Open API 和 OAuth 功能，更好地跟第三方应用集成

7 对未来的期望

工蜂系统作为代码托管系统，是 DevOps 研发工具链中重要的一个环节。目前工蜂系统已经通过 Web Hooks、API 和 OAuth 实现了和其它系统的对接，共同打通需求、代码托管和构建等整个环节。今后，我们将更多地专注于企业的需求，让工蜂系统开放更多的能力和更加紧密地集成 DevOps 上的服务，最终形成研发工具链的闭环。