《百度万人协同规模下的代码管理架构演进》读后感

《百度万人协同规模下的代码管理架构演进》主要讲解了百度代码管理架构演进的历程，对不同阶段的不同问题，采用的不同方案进行了详细的讲解。

1、产品初创时期

为了快速验证产品，采用了精益的思路快速实现了MVP。在代码库服务设计上，暂时不考虑容量和性能的问题，采用了Master-Slave这种单实例结构， 在这种架构下，主要从两个方面保证服务的安全可靠。

（1）存储上做了RAID，同时使用DRBD实时备份数据，保证数据可靠性。我们采用的是DRBD的同步复制协议，也就是说master的数据都会实时同步到slave上。

（2）为了保证服务的高可用，使用KeepAlived，确保在master故障时能够快速切换到slave，实现自动failover。

2、产品发展时期

随着平台的快速发展，代码库的并发和容量都在急剧增长。我们首先采用大内存、SSD硬盘来提升硬件性能。然后进行I/O、网络、缓存等优化。经过反复的性能测试得到了单机的最优配置。

在扩容方案上主要考虑了两种方案：分布式存储和数据分片。

（1）分布式存储

优点是架构简单，数据有备份，容量可以横向伸缩。

缺点是I/O性能下降。

（2）数据分片

优点是性能可靠，控制灵活，便于扩展（根据业务需求实现不同的分片策略和负载均衡方案）。

缺点是对现有的架构改变较大；跨分片的操作实现成本较高。

经过性能测试和MVP验证后，最终选择了数据分片的方案。主要的原因就是代码服务是高I/O的服务，分布式存储的I/O性能较本地存储差距比较明显，尤其写的性能更是下降了一个数量级。根据Repositories进行分片，将不同的Repositories分配到不同的实例。数据库服务采用主备的方式独立部署，同时支持了数据库访问的读写分离。用户请求首先经过proxy，调用统一的路由服务将请求转发到对应实例。认证服务独立部署，proxy集成认证模块，加强了用户身份认证。路由服务是核心服务。为了降低业务系统的改造成本，设计了统一的路由服务和路由模块，通过切面的方式拦截所有对代码库的访问请求，从而实现对业务代码的较低侵入和对调用方的透明。在路由设计上，因为首先使用了去中心化的微服务架构，所以采用客户端路由的方式。同时，增加了本地缓存，即使路由服务宕机，路由依然可以正常运行。

3、产品成熟时期

由于编译、自动化测试、持续集成等需求出现了爆发式的增长，代码库每日读的请求超过30万次，每日写的请求超2万次。高峰时段，TPS将近1000，千兆网卡全部被打满。经过对吞吐量的需求的评估，预计TPS将突破10000。为了保证性能，高峰时段下载代码的速率，自动化系统应该在30MB/s以上，开发人员必须在5MB/s以上。因此，吞吐量不足的问题已经成为最核心的问题。改进方案如下：

（1）增加带宽，千兆网卡换成万兆网卡。

（2）增加机器。通过拆分更小的实例来分摊带宽压力。增加每组实例的只读节点，因为我们的场景是读远大于写的，吞吐量的压力大多来自读请求。同时将闲置的冷备节点升级成只读节点。通过proxy判断读写请求，将写请求发给master节点，读请求通过负载均衡模块分别发给实例的所有节点。在这版架构升级的过程中，我们还是采用DRBD+KeepAlived实现容灾备份方案。读写分离大大提高了系统吞吐量，但是DRBD冷备机器闲置，严重浪费资源。百度做了进一步的改进，废弃了DRBD备份，并且实现自己的高可用方案。百度的方案主要分为两个阶段：

（1）master节点的失效判定。某个proxy节点的心跳检测捕获master节点异常后，发起投票，如果过半数的proxy节点都判断master节点异常，就判定master失效。

（2）slave节点提升。再进行一轮投票，将这组git实例中一个slave节点提升为master节点。投票完成之后，将新的实例信息写入路由服务，路由服务通知所有调用方路由变更，及时更新本地路由缓存。