阿里巴巴代码平台架构的演进之路

单机服务

读写分离

分片

1. 集中式的Git存储服务，既是I/O密集型也是计算密集型（Git的压缩算法）；
2. 文件数量众多，单个仓库的文件数量也可能是十万甚至百万级，对数据一致性的保证和运维可靠性的挑战极大。

代码服务主备架构：有状态服务带来的问题

1. 通过统一的代理层，可将用户的不同客户端请求转发到对应的系统上，如Git命令行客户端的SSH协议和HTTP协议、页面的访问及API接口请求等。
2. 然后对接的模块会将用户不同协议的请求转换为内部的RPC调用，并通过统一的RPC代理模块RPC Proxy和分片服务Shard Config将请求按分片和读写转发到对应的服务上。

读和写操作如何处理

问题分析

1. 可用性：

1. 由于读写操作是分离的，所以在写服务器failover期间，服务的写功能是无法使用的；

2. 对于单片而言，写操作是单点的，一台服务波动则整个分片都波动。

2. 性能：

1. 主备机器在同步上需要额外的时间开销。对于松散文件、文件压缩的Git仓库，这个耗时比单文件拷贝耗时更久。

3. 安全：

1. 用户侧的短时间内的瞬时操作，对于节点同步来说可能是并发的，无法保证同步中的事务顺序。

4. 成本：

1. 同分片写，主备机器要求规格完全一致。但由于接收的请求不同，存在严重的资源消耗不均；

2. 由于同步的小文件多，对延时敏感，跨机房异步同步，机器规格一比一复制。

1. 我们希望设计一个GPRC D-PROXY的模块，能将gRPC的请求做到写时复制，从而达到多写的第一步；
2. 其次在Proxy Config的模块中来存放仓库、副本、机器等元数据；
3. 再次通过一个分布式的锁（D-Lock）来完成对仓库级别的锁控制；
4. 最后我们希望有一个快速的算法能计算仓库的checksum，快速识别仓库的副本是否一致。

代码服务多副本架构的实现

1. 可用性提升：多写和随机读让底层的git存储服务不存在写单点和failover的切换问题；
2. 写性能提升：副本并发多写，让底层的副本间不存在主备复制的时间开销，性能比肩单盘；

3. 安全：写操作的分段提交和锁的控制，在解决分布式系统写安全的基础上也控制了用户写操作的事务性；
4. 成本大幅度降低：

1. 每个副本都会承担读写操作，水位平均

2. 副本与机器解耦，释放机器的规格限制，可以根据仓库的访问热度采用不同涉及机型和存储介质

1. 用户3和用户4是两个着急下班的同学，他们本地master分支分别是提交3和提交4；
2. 底部灰色的圆圈代表的是服务端一个仓库三个副本的装填，可以看到其中两个master分支指向的是提交2，而其中有一个可能因为网络或者其他原因导致其master的指向为1；
3. 当用户3和用户4前后提交了代码，由于用户3更快达到服务，所以会率先启动写的流程；
4. 在一个写的流程开始，首先会对当前仓库副本的一致性进行检查，系统很容易就发现落后的副本1与其他两个副本不一致，因此会将其标记为unhealthy。对于unhealthy的副本，是不会参与伽利略写或读的任何操作；
5. 当用户4的请求也被受理后，也会触发一致性检查，但是由于副本1已经被标记为unhealthy，所以对于用户4的流程，这个副本就“不可见”了；
6. 在用户3的进程检查后，发现多数副本是一致，则认为是可以写入的，便会将非引用数据传输到副本中；同理用户4的进程也是一样，且因为非引用数据不会变更分支信息，所以不需要加锁，可以同时操作；
7. 当用户3的进程收到非引用的数据传输成功后，便要开始进行引用的更新，这时第一步先去抢占这个仓库的锁。很幸运锁是空闲的，用户3的进程加锁成功，开始改写副本的引用指向；
8. 当用户4的进程也完成了非引用数据传输后也开始进行引用的更新。同样，再更新操作前要去抢锁，但发现锁已经被占用，则用户4的进程进入等待阶段（如果等待超时，则直接告诉用户4提交失败）；
9. 当用户3的进程改写引用成功后，会释放掉仓库锁。此时服务端的仓库的master分支已经被修改为指向3。用户3可以开心下班了；
10. 当锁被释放后，用户4的进程快速抢占，并尝试修改引用指向，但发现更改的目标引用master已经和之前不同（之前是2，现在是被用户3更改的3），此时用户4的进程会失败并释放掉锁。在用户4的本地会收到类似“远端分支已经被更新，请拉取最新提交后再推送”的类似提示。

代码托管运维管理平台