git 分布式文件系统问题

Question

类似这些代码托管平台github,gitlab,Bitbucket,oschina,coding.net,csdn等,在涉及到git对文件操作的时候，都有用到哪些相关技术啊？尤其在文件数量很大的时候，有哪些常见优化手段？？？

Answer 1

我说点好玩的：

我姑妄诌之，你姑妄听之。

gitlab之类git服务的瓶颈一般不在cpu，而在io。

cpu扩容很简单，加机器。io扩容很难。

尤其是gitlab，绑死了libgit，导致文件系统的io成了系统瓶颈。

阿里给了一个（两个）方案。

1，对进入的http(https)流量做一致性哈希，进行流量分片，不同的流量打入不同的后段服务器。

ssh流量进行流量转换，从ssh流量转换成http流量，然后一致性哈希。

一台机器只对应部分（例如十分之一）的请求。

至于gitlab，加机器就行了。

运维起来比较复杂，技术含量中等，实现起来比较复杂。

但是阿里并没有选择这种方案，选择了第二种。

2，改造libgit

这个说起来非常简单。

阿里有自研的对象存储平台（oss，貌似叫阿里云对象存储），只要改造libgit，将所有的io操作嫁接到oss上即可。

cpu到瓶颈了？直接加机器。

io到瓶颈？把黑锅甩给oss。

运维起来简单，技术含量高。

下面信口胡诌一个运维起来简单，实现起来简单的方案。

既然瓶颈是io了，我们搞个分布式的文件系统不就得了，不用改代码，还和现有系统无缝连接。

并没有专门咨询过oschina的方案，不过从目前流出的一些情报来看，猜测他们使用ceph解决gitlab的io问题。

更新：
oschina的方案。
https://my.oschina.net/GIIoOS...

也是上面那几条，

团队决定使用 Ceph FS，当服务最终迁移到 Ceph 上时，迁移成功一天之后就出现了严重的宕机事故，经过研究发现， Git 存储库具有海量的小文件，海量小文件一直是分布式文件系统的难题，并且当时 Ceph 也并未完善，我们不得不回退到旧的 NFS 方案。 码云的分布式由此被提出到议程。

后来有团队成员提出了使用 NGINX 动态代理，通过解析请求的 URL，将与存储相关的请求代理到存储服务器上，然后， 存储服务器上的 Gitlab 对请求进行解析。这样一来， 浏览器访问，以及 Git 的 HTTP 协议 clone 都能够分发到各个存储服务器上。 这个时候剩下的就是如何实现 NGINX 动态代理了，由于我实现 git 的 svn 接入时有过 NGINX 模块开发经验，所以就被安排到 NGINX 动态代理模块的开发， 以及路由模块的开发。路由策略一开始直接使用Gitlab 的 Magic Path 策略，即取用户的前两个字符 (A~Z|a~z|0~9|-_) 等， 不同的 Magic Path 对应不同的内网 IP。后来改为在 MySQL 中存储用户的仓库所在的机器内网 IP，并将 IP 缓存到 Redis 中，独立存储。 路由模块自主的向 Redis~MySQL 读取路由，当从 MySQL 中也找不到存储机器时，才返回错误。对于存储库无关的 URL 请求， 随机分发到不同的存储服务器上。先后有 zouqilin 和 lowkey2046 参与开发。

NGINX 的动态代理方案中，其模块开发也经历了基于 NDK 旧版路由，NDK 新版路由，以及 Upstream 新版路由的演进。 目前已经稳定运行，其中不乏企业用户的私有化部署。

对于 SSH 协议方案的分布式支持，最初采用的是 zouqilin 的意见: 使用端口转发。 gitlab-shell 只需要少量修改就能支持了 SSH 端口转发。 这个时候，唯一没有分布式支持的就是 svn 协议，作为 svn 兼容实现的开发者，我在接受 svn 分布式任务后，使用 Boost.Asio 开发实现了 svnsrv 动态代理服务器，经过一些波折，svnsrv 服务器也逐渐稳定下来。