在2017在线技术峰会——首届阿里巴巴研发效能嘉年华上，来自研发效能事业部的杨再新分享了《打造支撑百万用户的分布式代码托管平台》。他主要介绍了GIT和SVN思想差异、开源的代码托管平台的挑战、云代码托管平台的架构设计以及云代码托管后续发展。其中，他主要分享了云代码托管平台的设计思路，稳定性、安全性的构建。

以下内容根据直播视频整理而成。

直播视频：https://yq.aliyun.com/edu/lesson/548

PDF下载：https://yq.aliyun.com/attachment/download/?id=1839

GIT和SVN思想差异

GIT和SVN是目前主流的代码托管工具，阿里巴巴目前的代码托管80%在GIT上，经历了从CBS到SVN到现在几乎全部应用转为GIT，其中，GIT和SVN的思想差异主要在以下几个方面：

• GIT是分布式管理工具，是去中心却集中，所有服务可以有中心存在但是又可以去中心；
• 直接记录快照，而非差异；
• 不一样的分支概念，GIT分支是指向hash的指针而不是一个拷贝；
• 三个工作区，三个文件状态，SVN只有一个本地worker和服务器worker，这两个worker是不一样的，而GIT有一个本地暂存的workspace、存到本地的GIT库、存到远端三种文件状态。好处是，GIT本地的代码是全库的。

去中心却集中

图中origin是中央仓库，周边代表四个团队，他们可以从中心获取代码，又相互之间独立。

数据完整性check

在保存到GIT之前，所有数据都要进行内容的校验和计算，并将此结果作为数据的唯一标识和索引。所以如果文件在传输时变得不完整，或者磁盘损坏导致文件数据缺失，GIT都能立即察觉。GIT使用SHA-1算法计算数据的校验和，通过对文件的内容或目录的结构计算出一个SHA-1哈希值，作为指纹字符串。所有保存在GIT数据库中东西都是用此哈希值来作索引的，而不是靠文件名。

SVN怎么迁移GIT

（1）使用GIT SVN工具

• Git svn clone http://code.taobao.org/svn/xxx/
• Git remote add origin git@code.aliyun.com:xxx/xxx.git
• Git push origin –all

（2）https://yq.aliyun.com/articles/6046 图文教学文档

开源的代码托管平台的挑战

阿里巴巴是在2011年开始转用GIT的，刚开始时调用了许多开源代码平台。

Gitlab CE架构

Gitlab自我管理仓库的功能非常强大，可以很大的解放效率，可以自己创建代码库、分配权限。Gitlab CE技术栈前端是由nginx提供http服务，open-ssh全局加密，性能更好，ruby上手非常快，提供API功能方面比较强悍。Git非常依赖于文件体系，所以有专门的文件系统，数据库选择MySQL redis存储缓存。此外还有一个简单的消息系统用来处理异步消息。

遇到的挑战

• 可用性：数据量比较小的时候是单机，机器宕机之后稳定性无法保证，物理扩容比较困难，宕机之后的容灾也是问题。
• 可靠性：数据安全方面，如果磁盘数据坏了之后数据的恢复也是非常大的挑战。
• 高并发的效率：阿里巴巴在研发的投入是非常大的，各种各样的研发工具非常依赖于托管底层的平台，底层平台的数据调用量是非常大的，整个RDC调用数据的量非常大。
• 用户规模。

云代码托管平台的架构设计

设计思路

首先，稳定性优于体验，体验优于成本，运维导向是面向failover。重监控，态势感知，可回溯；重管控，突破规模制约，代码量非常大，管控措施很重要。

上图是机房内的架构，有两个proxy，分为了http协议、SSHD协议。http协议根据http body信息来进行路由转发。SSHD协议解析了所有命令行的信息，包括想获取哪个代码库的数据下载，每个集群有多个节点，每个节点有三台以上的机器，机器有不同角色master、mirror、backup。实际中，读写比例比较悬殊，大约为20:1，所以进行读写分离提高效率。backup的作用是，如果master挂掉的话，监控上会有感应，此时会将backup切换成master。Sharding记录节点机器的状态以及namespace和node节点之间的对应关系，这样迁移的时候只需要先将数据迁移，那么里面的状态就会无缝迁移。

构建稳定性

对于单机房，采用主/备切换，根据监控指标自动切换。用VIP、DNS来切的话，时效性会比较慢。同城灾备，如果整个机房宕机，那么直接切换DNS。异地灾备策略上和同城灾备是一样的。

上图展示了两个机房之间的数据同步，MNS是阿里云的消息服务，机房中任何数据变更时会向MNS发送消息，消息类型比较多，比如仓库的生命周期，订阅消息通过system hook下发存入MNS里面。在容灾机房里面有消息消费，消息消费之后会调用RPC服务，把一些库创建出来。通过异步消息来做，在时效性上有点差，但是可以忍受，但最终数据是一致的。

引入了新的技术栈。以前采用Ruby+MySQL来做，现在采用Golang，性能好，易部署。此外，使用Grpc，其基于http2，是谷歌新开发出来的工具，支持服务端和服务端之间的加密，易扩展，跨语言。使用阿里云的自研消息系统MNS，支持主题/订阅。这样做解决了稳定性，从单机宕机到机房宕机，再到同城宕机都有一定的解决方案。

安全性

数据安全方面采用多重备份，异地灾备。流量控制根据IP做流控，此外还会做namespace流控，因为有些库里面namespace比较多，namespace宕机之后会导致节点的数据量变大，影响整个节点的稳定性，所以需要对namespace做多维度的流量控制。

具体的技术细节是：使用golang的sshd服务替换原生的open-sshd，解决ruby中gitlab-shell启动慢，并且解决authorized_keys的文件变大后，性能下降的问题；用更多的redis来解决webhooks的性能，大量外部系统依赖webhook，确保稳定性，解决webhook的时效性。

大容量支持

大容量上很好的支撑是提供5GB以上的下载流量，整个数据存储在100T以上，用户数可以支撑100w级别，仓库数也可以支撑100w级别。

平台能力

每天支撑阿里百万级别的GIT的操作，覆盖着阿里全部BU，对外能力输出阿里云code。阿里云code平台是2016年上线的，内部体系包括阿里云自己的内部体系以及基于阿里云的其他体系，其他能力一致。

云代码托管后续发展

从技术来说，目前存储和计算的分离做的不够好，node节点上的数据有大量的计算。分离的好处是选用不同的硬件设备来做更好的容量规划。未来希望更好的支持容器化，拆分更多微服务，对各种逻辑进行归类。

功能方面，正在打造更好的代码review平台。由于本地环境特殊复杂，一些工程在本地不是很好搭建，在线IDE使得所有环境都是固态化，减轻开发的负担。继续加强webhook，做到性能更加优化。