【声明】本博客所有内容均为个人业余时间创作，所述技术案例均来自公开开源项目（如Github，Apache基金会），不涉及任何企业机密或未公开技术，如有侵权请联系删除
背景
上篇 blog
【Ubuntu】【Gitlab】拉出内网 Web 服务：http.server 单/多线程分析（八）
分析了如果单个 Python 进程想要用多核运行，很难实现，然后分析了 Python 多进程的场景，最后得出结论：还是得配合 Nginx 反向代理实现，最后还是逃不过 Nginx，下面继续 Nginx 分析
Nginx 配置审视
OK，前面一系列单/多线程分析的 blog 从高性能，高并发的角度，分析了生产环境下 Web 服务还是得用 Nginx，而不是 Python http.server，除此之外，从安全角度，http.server 也不如 Nginx 可靠，就不展开分析了
下面回到之前 blog 【Ubuntu】【Gitlab】拉出内网 Web 服务：Nginx 事件驱动分析（一） 里提到的这句话
最开始 blog 【Ubuntu】【GitLab】局域网用 Ubuntu 搭建 GitLab 里介绍的，需要修改 /etc/gitlab/gitlab.rb 文件，在里面添加一个自定义的 Nginx 配置项
首先，这里的 nginx['custom_nginx_config'] 配置项是 GitLab 提供的一个高级自定义选项 ，这里的 nginx['custom_nginx_config'] = <<-EOF 是 Ruby 语言中的 Here Document 用法，用来定义多行字符串，其中 <<-EOF 表示从下一行开始，直到遇到单独一行的 EOF 为止，中间所有内容都作为字符串赋值给 nginx['custom_nginx_config']
修改完 /etc/gitlab/gitlab.rb 文件后，在终端输入
bash
sudo gitlab-ctl reconfigure让配置生效，最后可在生成文件 /var/opt/gitlab/nginx/conf/nginx.conf 中找到相关内容
可以看到，配置项 custom_nginx_config 里面的内容会被展开插入到 nginx.conf 的 http {} 块中（通常在末尾），这个自定义的 server 会干预 Nginx 结构，绕过 GitLab 默认的 Workhorse + Puma 架构
标准 GitLab 的架构是：
首先，在这里，Puma 是个高性能的 Ruby 应用服务器，它直接运行 Gitlab 的 Rails 应用代码
- 从业务层面：Puma 会处理包括用户登录，项目管理，Merge Request，API 等所有后端业务逻辑，相当于 Gitlab 的业务大脑
- 从技术层面 ：Puma 会处理 HTTP 请求（比如 Web 服务器具体路径
/projects/123，/api/v4/users等），并与数据库（PostgreSQL）交互，执行 Ruby 代码，生成 HTML 或 JSON 响应等
作为后端，Puma 虽然能处理很多业务，功能很强大，但也有其局限性，比如
- 不适合处理大文件上传和下载，会阻塞工作线程
- 不擅长处理静态资源，比如 JS，CSS，images 等
- 对长连接（比如 Git over HTTP，CI job logs 流式输出等）支持不够高效
在此背景下，Gitlab 引入了中间层 Gitlab-Workhorse
Gitlab-Workhorse 是用 Go 语言写的一个轻量级反向代理服务，其本身不属于 Web 框架，而是一个专用请求处理器，专门处理 Puma 不擅长但很重要的任务
Gitlab-Workhorse 核心职责包括
- 静态文件服务：如果用户请求的是静态文件，Gitlab-Workhorse 可以直接返回文件，绕过 Puma，极大提升性能
- 大文件上传：接收用户上传的 LFS 文件，附件等，先存到临时目录，再通知 Puma 处理元数据，避免 Puma 线程被长时间占用
- Git HTTP(S) 操作 ：处理
git clone，git push，git fetch请求等，这些是长连接，流式操作，Puma 处理效率低 - CI Job Logs 流式输出：实时推送日志到前端，不阻塞 Rails 进程
- 请求预处理：验证 token，限速，过滤恶意请求等
OK，本篇先到这里，如有疑问，欢迎评论区留言讨论，祝各位功力大涨，技术更上一层楼！！！更多内容见下篇 blog
【Ubuntu】【Gitlab】拉出内网 Web 服务：Gitlab 配置审视（二）