git 服务器如何扩展？

Question

流行的版本控制服务器（如 github）可能拥有大量流量，需要可扩展且持久的数据存储。我想知道这是如何在后台实现的。

我对它的工作原理几乎没有猜测/假设，但我不确定它们是否 100% 准确：

• 存储库可能存储在磁盘上而不是某些数据库解决方案上（因为 git 服务器已经是自给自足的 AFAIK）
• 一个主机来服务整个流量可能是不够的，所以需要一些负载平衡
• 由于需要多台服务器，每台服务器都有自己的存储，因此将所有存储库保存在所有服务器中是没有意义的。（所以我希望每个存储库都映射到一个主机）
• 为了可靠性，服务器可能不是在单个主机上运行，​​而是在实际同步的复制集群上运行（可能使用 kubernetes 等），并且这些可能与数据库备份一起定期备份。
• 可能有一个主负载均衡器应用程序将请求重定向到适当的集群（因此它知道哪个存储库映射到哪个集群）

另一种可能性是将整个存储.git在数据库中作为 blob 并有一个可扩展的无状态应用程序获取.git每个请求，执行操作，再次存储结果并发送响应但这可能是一个非常低效的解决方案，所以我认为这是不可能的成为底层机制。

所以我的主要问题是：

• 上述假设是否有意义/它们是否准确？
• 如何实现一个负载均衡器应用程序，所有 git 请求都被定向到适当的集群？（例如，将存储库与集群 id 和 ips 映射，将其存储在数据库中，并建立一个将传入请求重定向到匹配集群 ip 的 nodejs 应用程序吗？）
• 如果上述内容不准确，人们将如何实施可扩展的 git 服务器？（以防有更好的方法）

Answer 1

无需依赖猜测。

特别是对于 GitHub，githubengineering 博客详细介绍了他们必须使用什么才能扩展到他们当前的使用水平。

除了升级 Rails 或删除 JQuery，在前端，他们还有：

• GLB：GitHub 的开源负载均衡器：在 GitHub，我们每秒从网络边缘处理数以万计的请求，在GitHub 的金属云上运行。
• GitHub 上的 MySQL 高可用性：GitHub 使用 MySQL 作为其所有非 git 事物的主要数据存储，其可用性对 GitHub 的操作至关重要。
• Stretching Spokes：GitHub 的 Spokes 系统存储多个 Git 存储库的分布式副本。本文讨论了我们如何让 Spokes 复制跨越广泛分离的数据中心。

关于 Kubernetes：

• “ GitHub 上的 Kubernetes ”（2017 年）
• “在 Kubernetes 上调试网络停滞”（2019 年）