共计 7560 个字符，预计需要花费 19 分钟才能阅读完成。
Gitee 自 2013 年推出以来，每年的数据量都是倍增的，截止到 2021 年 3 月份，Gitee 上曾经有了 600 万 + 的开发者，超 1500 万的仓库，成为了国内名列前茅的研发合作平台。在数据日益增长的过程中，Gitee 的架构也是通过了数个迭代，能力撑持起目前的数据量级。我曾在不少的大会上分享过 Gitee 的架构，也和很多有相似场景的同学一起探讨过，偶尔被问起有没有专门的文章来介绍 Gitee 架构的，所以难得假期有工夫，将此主题整顿成文，以供大家参阅。
作为国内倒退最快的代码托管平台，Gitee 每天数据都在飞速的增长中，而且随着 DevOps 概念的遍及，继续构建也给平台带来更多的申请和更大的并发量，每天须要解决上千万的 Git 操作，Gitee 架构也是在这个过程中逐渐迭代倒退起来的，回望 Gitee 架构的倒退，次要分为 5 个阶段：
- 单机架构
- 分布式存储架构
- NFS 架构
- 自研分片架构
- Rime 读写拆散架构
接下来就分享下 Gitee 整个架构的演进史。
单机架构
Gitee 上线于 2013 年 5 月份，上线之初就是一个单纯的单体 Rails 利用，所有的申请都是通过这个 Rails 利用进行负载的。
除了把 Mysql 和 Redis 独自一台机器进行部署之外，跟绝大多数 Web 利用不一样的是 Gitee 须要存储大量的 Git 仓库，无论是 Web 读写仓库还是通过 Git 的形式操作仓库，都是须要利用间接操作服务器上的裸仓库的。这种单体架构在访问量不大的时候还算能够，比方团队或者企业外部应用，然而如果把他作为一个私有云的 SaaS 服务提供进来的话，随着访问量和使用量的增长，压力也会越来越显著，次要就是以下两个：
- 存储空间的压力
- 计算资源的压力
因为开源中国社区的影响力，Gitee 在刚上线之处就涌入了大部分用户，齐全不须要放心种子用户的起源。相同，随着社区用户越来越多的应用，首先遭逢的问题就是存储的压力，因为过后应用的是阿里云的云主机，最大的磁盘只能抉择 2T，尽管前面通过一些渠道实现了扩容，然而云主机后的物理机器也只是一个 1U 的机器，最多只能有 4 块硬盘，所以当存储达到靠近 8T 之后，除了外挂存储设备，没有什么更好的间接扩容的形式了。
而且随着使用量的减少，每到工作日的高峰期，比方早上 9 点左右，下午 5 点左右，是推拉代码的高峰期，机器的 IO 简直是满负载的，所以每到这个时候整个零碎都会十分迟缓，所以零碎扩容的事件迫不及待。通过探讨，团队决定抉择应用分布式存储系统 Ceph，在通过了一系列不算特地谨严的「验证」后（这也是前面出问题的根本原因），咱们就洽购机器开始进行零碎的扩容了。
分布式存储架构
Ceph 是一个分布式文件系统，它的次要指标是设计成基于 POSIX 的没有单点故障的分布式文件系统，可能轻松的扩大到数 PB 级别的容量，所以过后的想法是借助于 Ceph 的横向扩容能力以及高可靠性，实现对存储系统的扩容，并且在存储系统下层提供多组无状态的利用，使这些利用共享 Ceph 存储，从而进一步实现了计算资源扩容的目标。
于是在 2014 年 7 月份的时候咱们洽购了一批机器，开始进行零碎的搭建和验证，而后筛选了一个周末开始进行零碎的迁徙与上线。迁徙实现后的性能验证一切正常，然而到了工作日，随着访问量的减少，所有开始往不好的方向倒退了，整个零碎开始变得十分迟缓，通过排查，发现零碎的瓶颈在 Ceph 的 IO 上，于是紧急调用了一台 ISCSI 存储设备，将数据进行迁徙进行压力的分担。本认为所有稳固了下来，然而更可怕的事件产生了，Ceph RBD 设施忽然间被卸载，所有的仓库数据都没了，霎时整个群和社区都炸开了锅，通过 14 个小时的剖析和钻研，终于把设施从新挂载上，而后全速将数据迁往 ISCSI 存储设备，才逐渐平息了这场风波。
- 海量小文件的读写性能瓶颈
- RBD 块设施意外卸载
起初通过钻研，才发现分布式存储系统并不适宜用在 Git 这种海量小文件的场景下，因为 Git 每一次的操作都须要遍历大量的援用和对象，导致每一次操作整体耗时十分多，Github 之前发过一篇博客，也有提到分布式存储系统不适用于 Git 这种场景。而且在块设施被卸载掉的时候，咱们破费了长达 14 个小时的工夫去进行复原，这也是对工具没有一个深刻理解就去贸然应用的结果。通过这次血与泪的教训，咱们更加审慎，更加仔细的去做后续所有的调整。
NFS 架构
不过，存储压力和计算压力仍旧在，是火烧眉毛须要解决的问题，怎么办呢？于是为了长期解决问题，咱们采纳了绝对原始的计划，也就是 2014 年 Gitlab 官网提供的计划
这个计划次要就是应用 NFS 来进行磁盘的共享，在上游搭建多台利用实例来实现计算资源的扩大，然而因为存储都是走网络，必然会带来性能的损耗，而且在理论利用的过程中，因为 Git 操作的场景比较复杂，会带来一系列的问题
- 内网带宽瓶颈
- NFS 性能问题导致雪崩效应
- NFS 缓冲文件导致删除不彻底
- 无奈不便的横向扩大存储，毫无维护性
内网带宽瓶颈
因为存储都是通过 NFS 进行挂载的，如果有比拟大的比方超过 1G 的仓库，它在执行 Clone 的时候将会耗费大量的内网带宽，个别状况下咱们的服务器的网口都是 1Gbps 的，所以很容易就会把网卡占满，占满导致的状况就是其它仓库的操作速度被拖慢，进而导致大量的申请阻塞。这还不是最重大的，最重大的状况是外部服务网口被占满，导致 Mysql、Redis 等服务重大丢包，整个零碎会十分迟缓，这种状况过后的解决形式就是把外围服务的调用走其它网口来解决，然而 NFS 网口的问题依然没法解决。
NFS 性能问题导致雪崩效应
这个就比拟好了解了，如果某台 NFS 存储机器的 IO 性能过慢，同时所有的利用机器都有这个存储机器的读写申请，那整个零碎就会出问题，所以这个架构下的零碎是十分软弱的，经不起考验。
NFS 缓冲文件导致删除不彻底
这个问题是十分头疼的问题，问题的起因是因为为了晋升文件的读写性能，开启了 NFS 内存缓存，所以会呈现有些机器删除了 NFS 存储上的一些文件，然而在另外的机器上还存在于内存中，导致利用的一些逻辑断定出问题。
举个例子，Git 在推送的过程中会产生 .lock 文件，为的是避免在分支推送的过程中其它客户端同时推送造成的问题，所以如果咱们往 master 分支推送代码的时候，服务端会产生 master.lock 文件，这样其它客户端就没有方法同时往 master 分支上推送代码了。在推送完代码后，Git 会主动的革除掉 master.lock 文件，但因为下面咱们说的起因，有一些状况下咱们在一台利用机处理完推送申请后，明明曾经删除掉这个 master.lock 文件了，然而在另外一台利用机器的内存里还存在，就会导致无奈推送。解决这个问题的办法就是敞开 NFS 内存级别的缓存，然而性能就会受损，还真是难以抉择，好在呈现这种问题的状况极少，所以为了性能，只能忍耐了。
维护性差
还是那句老话，因为历史起因，利用的存储目录构造是固定的，所以咱们不得不通过软连贯的形式对整个目录进行扩容，而扩容的前提是要把 NFS 存储的设施挂载在目录呀，所以过后整个零碎每个利用机器的挂载状况是非常复杂的
git@gitee-app1:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 184G 15G 160G 9% /
/dev/sda2 307G 47G 245G 16% /home
172.16.3.66:/data 10T 50G 9.9T 1% /data
172.16.30.1:/disk1 10T 50G 9.9T 1% /disk1
172.16.30.2:/disk2 10T 50G 9.9T 1% /disk2
172.16.30.3:/disk3 10T 50G 9.9T 1% /disk3
172.16.30.4:/disk4 10T 50G 9.9T 1% /disk4
172.16.30.5:/disk5 10T 50G 9.9T 1% /disk5
172.16.30.6:/disk6 10T 50G 9.9T 1% /disk6
172.16.30.7:/disk7 10T 50G 9.9T 1% /disk7
...哇，看到这样的目录构造，运维要哭了，保护起来极其艰难，如此上来，失控是早晚的事。
自研分片架构
NFS 这样的形式能够抵御一阵子，然而并不是长久之计，所以必须寻求扭转，在架构上做改良。现实的形式当然是 Github 那种分片架构，通过 RPC 的形式将利用和仓库调用拆来到来，这样无论是扩大和保护都会比拟不便
然而这种革新须要对利用进行革新，老本大，周期长，而且鉴于过后的状况，根本没有太多的研发资源投入在架构上，那怎么办呢？过后在做这个架构探讨的时候，咱们有一位前端共事（昵称：一只大熊猫）提了一个想法，既然利用无奈拆离，那为什么不再网上一层做分片路由呢？
题外话：团队外部的「发问」是十分有必要的，而且激发了团队探讨的气氛，咱们可能更好的做一些有价值的货色，所以每一个团队成员，尤其是作为一个开发者，永远不要怕说，你的一个小小的想法，对于团队可能是一次十分久远的影响。比方这位熊猫学生的一句话，就间接决定了后续 Gitee 架构的倒退方向，有空心愿可能再一起吃竹子 ;D
于是，第一版本的架构应运而生，咱们不扭转利用原有的构造，并容许利用是有状态的，也就是利用与仓库捆绑，一组利用对应一批仓库，只有可能在申请上进行辨识，并将其散发到对应的利用上进行解决即可。
从业务角度来讲，Gitee 上的申请分为 3 类：
- http(s) 申请，浏览仓库以及 Git 的 http(s) 形式操作代码
- SSH 申请，Git 的 SSH 形式操作代码
- SVN 申请，Gitee 个性，应用 SVN 的形式操作 Git 仓库
所以咱们只须要对这三类申请进行分片路由，从申请中截取仓库信息，依据仓库信息找到对应的机器，而后进行申请的转发即可。由此咱们开发了 3 个组件，别离为这三种申请做路由代理
Miracle http(s) 动静散发代理
组件基于 Nginx 进行二次开发，次要的性能就是通过对 URL 进行截取，获取到仓库的命名空间，而后依据这个命名空间进行 Proxy。比方上图中咱们申请了 https://gitee.com/zoker/taskover 这个仓库，Miracle 或通过 URL 得悉这个申请是申请 zoker 的仓库，所以 Miracle 会先来路由 Redis 查找 User.zoker 的路由，如果不存在则去数据库进行查找，并在路由 Redis 进行缓存，用来晋升获取路由 IP 地址的速度。拿到 IP 之后，Miracle 就会动静的将这个申请 Proxy 对应的后端 App1 上，那么用户就会正确的看到这个仓库的内容。
对于路由的散发肯定是要保障精确的，如果 User.zoker 取到的是一个谬误的 IP，那么用户看到的景象就是空仓库，这不是咱们所冀望的。另外，对于非仓库的申请，也就是跟仓库资源无关的申请，比方登陆，动静等，将会随机散发到任一台后端机器，因为与仓库无关，所以任意一台后端机器均可解决。
SSH & SVN 动静散发代理
SSHD 组件次要是用来对 Git 的 SSH 申请进行散发代理，应用 LibSSH 进行二开；SVNSBZ 是针对 SVN 申请的动静散发代理。两者实现的逻辑与 Miracle 相似，这里不再赘述。
遗留问题
这种架构上线后，无论是从架构负载上，还是从运维保护老本上，都有了极大的改良。然而架构的演进总是无止境的，没有万金油，以后的架构还是存在一些问题：
- 以用户为原子单位的分片过大
- Git via https 申请由 GiteeWeb 解决，互相会影响
- Git via SSH、SVN 相干操作的 Api 仍旧由 GiteeWeb 解决
- 未解决单仓负载过大的问题
因为是以用户或者组织为原子单位进行分片，所以如果一个用户下的仓库过多，体积过大，可能一台机器也解决不完，尽管咱们在利用上限度了单个用户可创立的仓库数量以及体积，然而这种场景必定会呈现，所以须要提前思考。而且如果单仓库拜访量过大，比方某些热门的开源我的项目，极其状况下一台机器也可能无奈接受住这些申请，仍旧是有缺点的。
此外，Git 申请波及到鉴权，所有的鉴权还是走的 GiteeWeb 的接口，并且 Git 的 https 操作仍旧由 GiteeWeb 解决，并没有像 SSH 那样有独自的组件进行解决，所以耦合性还是太强。
基于以上的一些问题，咱们进一步对架构进行了改良，次要做了以下改变：
- 以仓库为原子单位分片
- Git via https 服务拆离
- SSH、SVN 相干操作的 Api 拆离
以仓库分片使路由的原子单位更小，更容易进行治理和扩容，仓库路由次要是以 所属空间 / 仓库地址 为键，相似于 zoker/taskover 这种键进行路由
把 Git 的 http(s) 操作拆离进去的次要目标就是为了不让它影响到 Web 的拜访，因为 Git 的操作是十分耗时的，场景不一样，放在一起容易呈现影响。而鉴权相干的 Api 的独立也是为了缩小 GiteeWeb 的压力，因为推拉这种操作是十分十分多的，所以 Api 的拜访也会十分大，把它跟惯例的用户 Web 申请混在一起也是非常容易相互影响的。
在做完这些拆离之后，GiteeWeb 的稳定性晋升了不少，因为 Api 和 Git 操作带来的不稳固降落了 95% 左右。整个架构组件的形成相似于这样
遗留问题
尽管晋升了零碎整体的稳定性，然而咱们还是须要思考一些极其的状况，比方如果单仓库过大怎么办？单仓库拜访量过大怎么办？好在零碎可能对单仓库的容量进行限度，然而如果是一个十分热十分火的仓库呢？如果呈现那种忽然间大并发的拜访，该如何适应呢？
Rime 读写拆散架构
Gitee 作为国内最大的研发合作平台，也作为名列前茅的代码托管平台，泛滥的开源我的项目在 Gitee 上建设了生态，其中不乏热度十分高的仓库，并且在高校、培训机构、黑客马拉松等场景也是作为代码托管平台的首选，常常都能够遇到大并发的拜访。然而目前架构次要的问题是机器的备份都是冷备，没有方法无效的利用起来，并且单仓申请负载过大的问题也没有解决。
为什么要做 Rime 架构？
自从华为入驻 Gitee 之后，咱们才开始真正的器重这个问题。2020 年开始，华为陆续在 Gitee 平台上开源了 MindSpore、openEuler 等框架，单仓库的压力才逐步显现出来，为了迎接 2020 年 9 月份举世瞩目的鸿蒙操作系统开源，咱们在 2020 上半年持续优化了咱们的架构，使其可能多机负载同一个仓库的 IO 操作，这就是咱们当初的 Rime 读写拆散架构。
实现原理
想要实现机器的多读的成果，就必须思考到仓库同步一致性的问题。试想，如果一个申请被散发到一台备机，刚好主机又刚推送过代码，那么用户在网页上看到的仓库将会是推送前的，这就是一个十分重大的问题，那么该如何保障用户拜访备机也是最新的代码呢？或者说如何保障同步的及时性？这里咱们采纳的如下的逻辑来进行保障
- 写操作写往主机
- 由主机被动发动同步到备机
- 被动保护同步状态，依据同步状态决定路由散发
如上图所示，咱们把仓库的操作分为读和写两种，个别状况下，读能够均等散发到各个的备机，这样一来如果咱们有一台主机，两台备机，那么在不思考其它因素的状况下，实践上仓库的读取能力是减少了 3 倍的。然而思考到仓库会有写的状况，那就会波及到备机的同步，刚刚咱们也说过，如果同步不及时，就会导致拜访到了老的代码，这显然是一个极大的缺点。
为了解决这个问题，咱们利用 Git 的钩子，在仓库被写入之后，同步触发一个同步的队列，这个队列的次要工作有如下几个：
- 同步仓库到备机
- 验证同步后的仓库的一致性
- 治理变更同步状态
当一个仓库有推送之后，会由 Git 钩子触发一个同步工作，这个工作会被动的将增量同步到配置的备机，在同步实现后，会进行援用的一致性校验，这个一致性校验应用的是 blake3 哈希算法，通过对 refs/ 中的内容进行编码，来确认同步后的仓库是否版本完全一致。
对于状态治理，当触发工作之后，会第一之间将两台备机的这个仓库状态设置为未同步，咱们的散发组件对于读操作，只会散发到主机或者设置为已同步状态的备机，当同步实现并且实现一致性校验之后，会将相干备机的同步状态设置为已同步，那么读操作就又会散发到备机上来了。然而如果同步失败，比方上图中同步到 App1bakA 的是胜利的，那么读操作是能够失常的散发到备机的，然而 App1bakB 却是失败的，那么读操作就不会散发到未同步的机器，防止拜访上呈现不统一的问题。
架构成绩
通过对架构的读写拆散的革新，零碎对于单仓库拜访过大的这种状况也可能轻松应答了。2020 年 9 月 10 号，华为鸿蒙操作系统正式在 Gitee 上开源，这个备受瞩目的我的项目一经凋谢就给 Gitee 带来了微小的流量以及大量的仓库下载操作，因为前期工作准备充分，并且读写拆散架构极大晋升了单仓库负载的性能，所以算是完满的为鸿蒙操作系统胜利的保驾护航了。
后续优化
可能有仔细的同学曾经想到了，如果一个仓库不同的在写，并且同时随同着微小的访问量，那么是不是就变成了单机器要去解决这些所有的申请？答案是 Yes，然而这种场景失常状况下是没有的，个别状况下写操作的频率是远远低于读操作的，如果真的呈现了这种状况，只能阐明被攻打了，那么咱们在组件上也进行了单仓库最大并发的限度，这也是咱们保护 Gitee 以来得出的正当的限度条件，齐全不会影响到失常用户的应用。
然而架构的优化是无止境的，对于下面提到的状况，咱们仍旧是须要进行改进的，目前次要的做法次要是提交的时候同步更新，备机同步胜利或者局部备机同步胜利才算本次推送胜利，这种形式毛病是会加长用户推送的工夫，然而可能很好的解决主机单读的问题。目前的架构是多读单写，如果前面这个畛域内呈现了一些频繁写入的场景，能够思考变更为多读多写，做好状态和抵触的保护即可。
将来瞻望
目前的架构最大的问题就是利用和仓库的操作未拆离，这对于架构的扩展性是极为不利的，所以目前或者后续咱们正在做的就是对服务进行拆离和其余方面的优化：
- 仓库的操作拆离，独自以 RPC 的形式进行调用
- 利用的前后端拆散
- 队列、告诉等服务的拆离
- 热点仓库的主动按需扩容
- 依据机器的指标进行新仓库的调配
- …
最初
Gitee 自 2013 年上线以来，直到 2017 年自研架构上线才真正解决了内忧外患，「内」是因为架构无奈撑起访问量导致的各种不稳固，「外」是内部的一些 DDOS、CC 攻打等难以招架，好在架构这项内功修炼切当，这些始终以来的问题才可能轻松自如的应答。
有句老话说得好，脱离了所有场景谈技术的行为都是耍流氓，架构亦如是，脱离了背景去谈架构是毫无意义的，很多时候咱们做了十分多的工作，可能只是可能解决以后或者将来几年的问题，然而咱们须要高瞻远瞩，对后续产品的倒退、数据的增长、性能的加强做预估，这样能力更好的扭转架构来适应这个高速倒退的畛域，进而更好的去服务企业和赋能开发者。
本文作者为 Gitee 负责人周凯，原文发表在微信公众号「Zoker 随笔」（zokersay）
