打造支撑百万用户的分布式代码托管平台-阿里云开发者社区

开发者社区> 开发与运维> 正文
登录阅读全文

打造支撑百万用户的分布式代码托管平台

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

在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本地的代码是全库的。

去中心却集中

74b710a01bbe4cba7536c604628c2d7becdd03b5

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

数据完整性check

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

SVN怎么迁移GIT

(1)使用GIT SVN工具

(2)https://yq.aliyun.com/articles/6046 图文教学文档

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

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

Gitlab CE架构

458684e5930bc977f89e27b61e3a38432961f568

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

遇到的挑战

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

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

设计思路

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

1fde4dbd004807773b96be5ad97b08a7457fec3f

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

构建稳定性

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

6ff2bdac292bf3f7bc8836ba8ed38e0c1aba83d4

上图展示了两个机房之间的数据同步,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,做到性能更加优化。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章