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

6,329 阅读9分钟

腾讯工蜂Git

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上的服务,最终形成研发工具链的闭环。


扫描二维码,研发管理从此高效、轻便、可靠