本文讲述了Gitlab的系统设计，对其架构进行了简化的概述，并解释了Gitlab重要架构组件的工作原理。GitHub的系统设计也将采用类似的思路。
GitLab是一个基于网络的DevOps生命周期工具，它提供了一个提供维基、问题跟踪和持续集成及部署管道功能的Git仓库管理器，采用开源许可，由GitLab公司开发。
下面是简化的gitlab架构，可以用来理解Gitlab的工作。
Gitlab通常安装在GNU/Linux上，但最大的Gitlab实例在Gitlab.com上。现在，让我们来详细谈谈Gitlab的架构。
Gitlab 的架构由以下几个部分组成。
- Nginx
- PUMA
- SIDEKIQ
- gitlab工作母机
- POSTGRESQL
- HTTP/HTTPS
- SSH
- GITALY
- REDIS
我们现在将更深入地研究每个组件。
NGINX
Gitlab使用NGINX作为网络服务器，通过GitLab Workhorse代理进入Puma应用服务器。
NGINX有一个Ingress端口，用于接收所有的HTTP请求，并将它们路由到GitLab中适当的子系统。
Gitlab使用NGINX是因为它能处理大量的连接。
NGINX通常被用作反向代理和负载平衡器，以管理传入的流量，并将其分配给较慢的上游服务器--从传统的数据库服务器到微服务的任何东西。NGINX也是最快的网络服务器之一。
Nginx的替代品。Apache、Apache Tomcat、LiteSpeed Web Server和AWS Elastic Load Balancing也可用于类似目的。
PUMA
GitLab使用Puma应用服务器来提供网页和GitLab API。Puma是一个Ruby应用服务器，用于运行核心的Rails应用程序，为GitLab提供面向用户的功能。Gitlab 曾经使用 Unicorn 来提供网页服务，但 Gitlab 13.0 不再支持 Unicorn。
对Puma的偏爱可能是因为Puma与其他Ruby Webserver不同，它是为速度和并行性而建立的。它还为Ruby网络应用提供了一个非常快速和并发的HTTP 1.1服务器。
Puma的一些最流行的替代品和竞争对手是Atlas、Panther、NGINX、Apache HTTP Server和Microsoft IIS。
SIDEKIQ
Gitlab使用Sidekiq作为工作队列，而它又使用Redis作为工作信息、元数据和传入工作的非持久性数据库后端。Sidekiq是一个Ruby后台作业处理器，从Redis队列中提取作业并进行处理。
Sidekiq通常是rails应用程序的首选，因为它在后台处理中的简单性和效率，可以在同一进程中使用线程同时处理许多作业。
Sidekiq的一个流行替代品是kafka。
gitlab工作主力
通常情况下，Puma和Workhorse之间的通信是通过Unix域套接字完成的，然而，也可以通过TCP转发请求来完成。Workhorse访问gitlab/public目录，绕过Puma应用服务器来提供静态页面、上传和预编译资产。
POSTGRESQL
GitLab应用程序使用PostgreSQL来保存数据库信息，如用户、权限和问题。GitLab 将裸露的 Git 仓库存储在配置文件中定义的位置，即 repositories: 部分。它还将默认的分支和钩子信息与裸仓库一起保存。
为什么有人要使用POSTGRESQL？
Postgres允许你安全地存储大型和复杂的数据。它可以帮助开发者建立最复杂的应用程序，运行管理任务和创建整体环境。
HTTP/HTTPS
当通过HTTP/HTTPS为存储库提供服务时，GitLab使用GitLab API来解决授权和访问问题，并为Git对象提供服务。
通过HTTP进行的Git操作使用了Git文档中描述的无状态 "智能 "协议，但处理这些操作的责任是由几个GitLab组件分担的。
SSH
附加组件GitLab Shell通过SSH为存储库提供服务。它在配置文件中定义的位置管理SSH密钥，即GitLab Shell部分。该位置的文件不应该被手动编辑。
GitLab Shell通过Gitaly访问裸仓库，为Git对象提供服务，并与Redis通信，向Sidekiq提交作业供GitLab处理。GitLab Shell查询GitLab的API以确定授权和访问。
GITALY
Gitaly从GitLab Shell和GitLab Web应用中执行Git操作，并为GitLab Web应用提供了一个API，以从Git中获取属性（例如，标题、分支、标签或其他元数据），并获取Blobs（例如，差异、提交或文件）。
Gitaly 提供了对 Git 仓库的高级 RPC 访问。GitLab使用它来读写Git数据。
REDIS
Redis是一个内存数据结构存储，作为一个分布式的内存键值数据库、缓存和消息代理，具有可选的耐久性。
在Gitlab的架构中，Redis被包装成一个用于存储、会话数据、临时缓存信息和后台作业队列的地方。
Gitlab特意将Redis用于缓存，作为Sidekiq的作业处理队列，以管理共享的应用程序状态，并作为ActionaCable的pub/sub队列。
通过OpenGenus的这篇文章，你一定对GitLab的系统设计有了完整的了解。
