共计 4126 个字符，预计需要花费 11 分钟才能阅读完成。
简介：这事儿和伽利略无关。
代码平台的倒退之路
置信很多做后端服务的同学在看到单机、读写拆散、分片这些字眼肯定不会感觉生疏。没错，代码服务在倒退的开始阶段面临的问题和其余 web 服务大体一致，所以应用的解决方案也大体一致。
单机服务
家喻户晓，Git 是一种分布式的版本控制软件，每个人的本地都有一份残缺的代码版本数据。但为了解决多人协同开发和流程管控（评审、测试卡点等），须要一个集中式的远端地方仓库来实现这些性能，这就是单机服务的起源。
读写拆散
随着协同人数的增多，以及提交数量的变多，单机升配也无奈解决调用量过高的问题。而通过统计咱们发现，对于 Git 服务读写比例大略是 20:1，为了保障主链路提交的失常，咱们做了读写拆散，来扩散压力。通过主备同步来实现数据的同步，并应用一写多读的架构来扩大读服务的能力。
分片
但无论如何做读写拆散，所有机器的规格始终是一样的。尽管仓库数量的减少、平台用户的减少，无论是存储还是计算都会达到单机所能承载的极限。这个时候咱们采纳了分片的形式，行将不同的仓库划分到不同的片中，而每个片都是一个残缺的读写拆散架构。当一个申请到来时，服务会依据查问库特色信息，决定这个仓库所在的分片，而后又依据接口的读写个性，将申请转发到具体的机器上。有点相似于数据库中的分库分表。这样以来，通过分片 + 读写拆散的架构，咱们实践上能够反对程度上的有限扩容。
问题及思考
那么分片 + 读写拆散是否是解决代码服务大规模、高并发问题的银弹呢？在咱们看来，答案是否定的。
随同着代码服务体量的倒退，咱们解决的外围问题始终以来次要是两个：
- 集中式的 Git 存储服务，既是 I / O 密集型也是计算密集型（Git 的压缩算法）；
- 文件数量泛滥，单个仓库的文件数量也可能是十万甚至百万级，对数据一致性的保障和运维可靠性的挑战极大。
实际上，代码平台架构的倒退，就是在这两个问题之间找均衡，以在肯定规模状况下保障整个平台的稳定性。但始终没有根本性地解决掉这两个问题。然而随着规模逐渐上涨，上述的两个外围问题引发的劣势又逐渐变得显著起来。
代码服务主备架构：有状态服务带来的问题
对高可用零碎比拟相熟的同学，从名字上应该就看出些许端倪。主备架构的读写拆散计划其人造引入的就是有状态服务的问题。
整个零碎的申请流转，次要分两次转发：
- 通过对立的代理层，可将用户的不同客户端申请转发到对应的零碎上，如 Git 命令行客户端的 SSH 协定和 HTTP 协定、页面的拜访及 API 接口申请等。
- 而后对接的模块会将用户不同协定的申请转换为外部的 RPC 调用，并通过对立的 RPC 代理模块 RPC Proxy 和分片服务 Shard Config 将申请按分片和读写转发到对应的服务上。
读和写操作如何解决
如果是一个写操作（如：push，从页面上对文件、分支等进行新增、删除、批改等操作），申请则会落到仓库对应分片的 RW/WO 服务器上，在 RW/WO 服务写入实现当前，再通过 Git 协定的同步形式，同步到同分片的其余机器上，这样一次写操作就实现了。而对于读操作，则是在仓库对应分片中随机找一个 RO 的机器进行转发。
问题剖析
当某个分片的主节点产生异样（服务 crash 或服务器宕机等），分片内的机器状态会发生变化。本来的 RW/WO 状态会置为不可用，Backup 的机器会取代原来的 RW/WO 服务来承接写操作的申请。
从零碎的角度上剖析，主备架构存在以下四个问题：
1、可用性：
- 因为读写操作是拆散的，所以在写服务器 failover 期间，服务的写性能是无奈应用的；
- 对于单片而言，写操作是单点的，一台服务稳定则整个分片都稳定。
2、性能：
主备机器在同步上须要额定的工夫开销。对于涣散文件、文件压缩的 Git 仓库，这个耗时比单文件拷贝耗时更久。
3、平安：
用户侧的短时间内的刹时操作，对于节点同步来说可能是并发的，无奈保障同步中的事务程序。
4、老本：
- 同分片写，主备机器要求规格完全一致。但因为接管的申请不同，存在重大的资源耗费不均；
- 因为同步的小文件多，对延时敏感，跨机房异步同步，机器规格一比一复制。
这四个零碎上缺点带来的问题，在肯定应用规模和服务稳定性要求下是能够容忍的。但随着商业化的深刻和用户规模的增长，这些问题的解决变得火烧眉毛。接下来我将和大家分享在过来的一年中，咱们团队对这些架构上问题的思考和解决思路。
代码服务多正本架构：毁灭有状态的存储服务
在上一个大节中，咱们曾经比拟清晰地意识到架构上面临的四个问题次要是有状态服务带来的。那么在新架构的设计中，咱们的指标只有一个——毁灭有状态的服务。指标有了，如何去实现？咱们首先对业内几个风行的分布式系统做了深刻的理解和学习，比方 ETCD、Paxos 协定的学习等。同时咱们也学习了代码服务的老大哥——Github 开源的寥寥文章，但 Github 认为分布式架构是他们的外围竞争力，所以可参考的文章较少，但从这些文章中咱们仍然深受启发。首先对于任何架构降级，要能做到“开着飞机换引擎”，让架构软着陆是架构降级的保底要求。因而在 grpc 的代理层之上没有任何的改变。从外部的 RPC 调用以下则是咱们新架构施行的中央。
和前一节的不同，在新的底层设计中：
- 咱们心愿设计一个 GPRC D-PROXY 的模块，能将 gRPC 的申请做到写时复制，从而达到多写的第一步；
- 其次在 Proxy Config 的模块中来寄存仓库、正本、机器等元数据；
- 再次通过一个分布式的锁（D-Lock）来实现对仓库级别的锁管制；
- 最初咱们心愿有一个疾速的算法能计算仓库的 checksum，疾速辨认仓库的正本是否统一。
通过这些模块的组合实现仓库多正本的并发写入、随机读取，咱们就能够去除底层存储节点的状态，从而能将仓库的正本离散到不同机房中。此外得益于机器与正本的解耦，每个服务器都能够有独立的配置，这也为后续的异构存储打下了根底。
代码服务多正本架构的实现
有了根底的设计，通过 MVP 的实现，咱们验证了这个架构的可行性。并通过一年多的工夫进行开发和压测，最终将咱们的多正本架构胜利上线并逐渐开始提供服务。在实现过程中，咱们为这个零碎起了一个颇有意义的名字——伽利略，因为在咱们的多正本架构中，最小的正本数是 3，而伽利略在创造了地理望远镜察看到火星的卫星恰好就是 3 个。咱们心愿秉承这个不停摸索的精力，所以起了这个有意义的名字。在具体的设计中，咱们通过对 gRPC proxy 模块的改写，让来自用户的一次写操作实现写复制，并通过对 git 的改写以反对分段提交。咱们基于 git 的数据个性，编写了 checksum 的模块，能够对 git 仓库进行疾速的全量和增量一致性计算。
伽利略架构在零碎架构层面解决了之前主备架构带来的问题：
1、可用性晋升：多写和随机读让底层的 git 存储服务不存在写单点和 failover 的切换问题；
2、写性能晋升：正本并发多写，让底层的正本间不存在主备复制的工夫开销，性能比肩单盘；
3、平安：写操作的分段提交和锁的管制，在解决分布式系统写平安的根底上也管制了用户写操作的事务性；
4、老本大幅度降低：
- 每个正本都会承当读写操作，水位均匀
- 正本与机器解耦，开释机器的规格限度，能够依据仓库的拜访热度采纳不同波及机型和存储介质
说了这么多，当用户执行 push 后，在伽利略中会产生什么呢？咱们用一个动画来简略演示下：
- 用户 3 和用户 4 是两个焦急上班的同学，他们本地 master 分支别离是提交 3 和提交 4；
- 底部灰色的圆圈代表的是服务端一个仓库三个正本的装填，能够看到其中两个 master 分支指向的是提交 2，而其中有一个可能因为网络或者其余起因导致其 master 的指向为 1；
- 当用户 3 和用户 4 前后提交了代码，因为用户 3 更快达到服务，所以会率先启动写的流程；
- 在一个写的流程开始，首先会对以后仓库正本的一致性进行查看，零碎很容易就发现落后的正本 1 与其余两个正本不统一，因而会将其标记为 unhealthy。对于 unhealthy 的正本，是不会参加伽利略写或读的任何操作；
- 当用户 4 的申请也被受理后，也会触发一致性查看，然而因为正本 1 曾经被标记为 unhealthy，所以对于用户 4 的流程，这个正本就“不可见”了；
- 在用户 3 的过程查看后，发现少数正本是统一，则认为是能够写入的，便会将非援用数据传输到正本中；同理用户 4 的过程也是一样，且因为非援用数据不会变更分支信息，所以不须要加锁，能够同时操作；
- 当用户 3 的过程收到非援用的数据传输胜利后，便要开始进行援用的更新，这时第一步先去抢占这个仓库的锁。很侥幸锁是闲暇的，用户 3 的过程加锁胜利，开始改写正本的援用指向；
- 当用户 4 的过程也实现了非援用数据传输后也开始进行援用的更新。同样，再更新操作前要去抢锁，但发现锁曾经被占用，则用户 4 的过程进入期待阶段（如果期待超时，则间接通知用户 4 提交失败）；
- 当用户 3 的过程改写援用胜利后，会开释掉仓库锁。此时服务端的仓库的 master 分支曾经被批改为指向 3。用户 3 能够开心上班了；
- 当锁被开释后，用户 4 的过程疾速抢占，并尝试批改援用指向，但发现更改的指标援用 master 曾经和之前不同（之前是 2，当初是被用户 3 更改的 3），此时用户 4 的过程会失败并开释掉锁。在用户 4 的本地会收到相似“远端分支曾经被更新，请拉取最新提交后再推送”的相似提醒。
以上就是多个用户同时提交时，伽利略零碎外部产生的事件。目力好的同学可能会问，那在零碎中被断定 unhealthy 的正本会怎么办呢？这个就是方才在架构实现中提到的运维零碎会做的事务弥补了，运维零碎在收到 unhealthy 上报和定时扫描后都会触发对 unhealthy 正本的修复，修复后的正本在确认统一后会置为 healthy 并持续提供服务，当然这个过程在判断修复是否统一也是加锁操作的。
代码托管运维治理平台
除了上大节提到的正本修复，在零碎运行中，还须要很多的运维操作。以往这些都是由运维同学操作的。Git 服务波及数据和同步，比单纯的业务零碎要运维复杂度要高，对应运维危险也比拟高。在过来的一年中咱们联合以往的运维教训，以及新架构的须要，以工具化、自动化、可视化为指标，为伽利略零碎打造了对应的运维治理平台：
通过这个平台咱们大大晋升了运维的品质、也充沛开释了运维人员的精力。
原文链接
本文为阿里云原创内容，未经容许不得转载。
