重磅干货！一文读懂「企业级架构」

首先来看两个真实的小故事：

小 A 公司有 50 人，作为运维人员，小 A 为公司搭建了一个私有化 GitLab 社区版。

 

某日，开发同学发现不能够访问 GitLab 了。小 A 查看发现磁盘快满了，经过 15 分钟扩容后恢复服务。

 

由于当时只有三四个开发同学在提交，其他人都在本地写代码，因此对公司影响不大。

小 B 公司有 500 人，作为 SRE，小 B 也为公司搭建了一个私有化 GitLab 社区版。由于公司规模不小，所以配置了基础资源监控，像小 A 公司突然发现满磁盘容量的问题肯定不会发生。然而在某上线日，显示 GitLab 服务器 502，很多团队在公司大群投诉。

 

小 B 快速排查，发现 IO 满了，想查看日志，但日志量过大，来不及定位问题。小 B 花了 15 分钟重启，问题得到解决，但免不了要面对 4、5 个团队投诉，还影响了本年度 SLA 目标。

 

不止是满 IO 问题，平时还会遇到代码仓库不响应等。小 B 觉得很苦恼，他还有其他运维开发任务，没有多余的时间花费在定位问题上。

GitLab 作为源代码管理 + 一站式 DevOps 平台，是公司最核心的资产平台。当公司人数较少时，短时停机对公司影响还不算大；但当公司规模达到一定级别之后，任何停机均会造成极大损失。

如何避免此类损失？企业级架构，正是关键保障。

什么是企业级架构？

企业级架构，通常是指在企业环境中设计和构建软件系统时所遵循的架构原则和指导方针。它的主要目的是为了确保软件系统能够高效地满足企业的业务需求，并能够适应企业环境中的变化和挑战。

企业级软件架构通常包括对软件系统的总体设计方案、技术架构、数据架构以及安全架构等方面的指导和约束。

为什么要搭建企业级架构？

从前面的故事中也可以看出，不同规模的企业，对于企业级架构有着不同的诉求。但大家有着基本一致的目的，即实现更好的用户体验、降本增效和信息安全。

更好的用户体验

企业级架构有助于企业提高自身整体运营能力，从而有助于进行更好信息化建设和基础设施建设。基础设施的稳定性和可用性，能够降低开发者负担，提供更好的用户体验。

降本增效

首先我们先说 “反模式” 概念。Martin Fowler 的一篇文章在讨论内部质量对于一个项目的重要性时，提到 “反模式”，即低质量项目开发得更快，成本更低，所以在商业决策时，就有很多人倾向于先做功能，而不做质量。

在搭建赖以生存的基础架构系统时，同样存在一些公司重功能而不重质量。可想而知，随着项目开发深入，其修改成本也会越来越高。如下图所示，调研发现拐点来得很早，一般在项目的前几周就会发生。低质量项目一旦过了这个拐点，成本就会比高质量项目高很多。

人们会习惯性的认为质量和成本是一枚硬币的两面，殊不知质量其实是降低成本的金字塔基石。

当我们把这个思路推广到内部生产系统，生产系统的可靠性也是高质量生产（编码）的基石，不稳定的源代码系统会带来很多具体成本，阻碍企业可持续发展。因此，企业级构架是企业降本增效的有效举措。

信息安全

对于生产系统，无论是软件还是硬件，安全都是不可或缺的。在木桶理论中，安全是一个木桶的底线；在泛信息系统的安全等级中，也有机密性、完整性、可用性三大要素。而可用性受到的影响，也会影响安全评级。所以企业级架构是一套安全的信息化系统的必要组成部分，是信息安全的保障之一。

常见的 “反模式” 企业级架构及其缺点

在现实中，我们看到了各种企业级架构方案，包括了 NFS、rsync、多实例节点以及其他反模式，它们通常存在如下缺点。

NFS 企业级网络文件共享方案

NFS 是常见的共享存储机制，大家会自然地使用它作为 git 仓库存储。但会遇到以下两种问题：

IO 慢问题

NFS 并不适合处理大批量小文件，经常遇到在处理小文件时的性能问题，导致用户访问一个 GitLab 页面都需要 1 分钟甚至更长时间。

其原因可能是多样的，如在较老的 NFS 版本中，碰到了 NFS 的网络带宽被 TEST_STATEID 请求占用的情况：https://gitlab.com/gitlab-org/gitlab-foss/-/issues/52017，这是源于  NFS 的一个 Bug，需要升级 NFS 版本并改配置。

在 high-traffic monorepo 场景下，历史丢失问题

虽说 GitLab 也有 git gc 和 git repack 来组合松散对象，由于 Git 仓库本身会有很多小文件，尽管一些 NFS 提供了对小文件性能优化的选项，但未来，这些 NFS mount 的选项会在多节点间造成不一致，从而导致数据丢失。

比如在 NFS 中，发生过大仓库的历史丢失问题，原因是 NFS v4.0 client 对于过期文件处理不当，没有重新校验 inode 和 dentry，导致打开了 stale file，造成了历史丢失，下面链接记录了如何定位的详情：https://about.gitlab.com/blog/2018/11/14/how-we-spent-two-weeks-hunting-an-nfs-bug/
 

针对这个问题，GitLab 自研了 Gitaly 负责 Git 仓库的存储和读写，将各种 Git 操作暴露为 GRPC 调用。Gitaly 基于的 Golang 优秀的多协程能力也使仓库处理性能更好。这样解决了早期 Rails 直接通过 Git 命令行操作 NFS 上的 Git 仓库，规模变大后导致的网络 IO 延迟问题。

rsync 自配置 GitLab 主备模式

在实际的情况下，有看到使用 rsync 配置 GitLab 的架构。一般方案如下：

使用 rsync 来对于磁盘进行备份，需要配置定时同步时间（如每 5 分钟同步一次）；

将 PG 等数据库放在外部进行同步。

常见问题：

主备模式无法解决大规模人员导致 load 问题，只能解决一些备份问题，无法达到高可用；

rsync 相关克隆方式比较原始，如果需要做 A-S 备份，其相对于 GEO 切换更麻烦。

多实例节点

多实例节点，即不同部门/团队使用不同的实例。

这个使用方法由于多套权限体系、多套数据，造成了物理上的部门墙，不同部门间的沟通协作不畅，极大降低了效率。同时需要更多运维人员来处理不同实例的问题。并且，如果需要基于多实例进行二次开发，需要考虑的问题比单实例复杂更多。

随意 “魔改” 架构

极狐 GitLab 提供了 Omnibus 安装方式，让所有组件可以快速安装在一台机器上，使 GitLab 的私有化安装部署很容易以最快的速度运行起来。

然而，有一些组件的 load 会比较重，所以用户自己把一些组件拆分单独部署。如下架构，为了有更多的前端来响应用户需求，其设计中有多个 rails。

这个架构有比较多的问题，比如 DNS 没有通过 LB 指向前端，导致前端无法实现真正的负载均衡；比如 Gitaly、DB、Redis 在一台机器上，引起雪崩效应：

单节点 Gitaly 无法满足多用户 I/O，导致 I/O 达到 100% 使用率，此时 Gitaly 产生 hung，影响 Git 仓库相关功能；

而 DB 等由于使用的是同一台机器，该机器 I/O 爆掉，导致 DB 也无法服务，致使除了 Git 仓库外的其他功能也受到影响。

在极狐 GitLab 支持过的客户中，还见到过各种 “魔改” 架构，此类架构并没有经过充分测试，最终导致各种问题。

极狐 GitLab 企业级架构

看完了各种魔改架构之外，我们来一起看看极狐 GitLab 提供的企业级架构。

极狐 GitLab 企业级架构包括高可用可扩展架构与 GEO 多地部署架构，皆经过了 GitLab Performance Tool 的充分测试，能够更好的为企业服务。

如何判断自己需要哪一种的极狐 GitLab 企业级方案？可以依照下面两个流程图来判断：

1. 判断需要哪种架构来满足高可用需求：

2. 判断是否需要 Geo 多地部署：

方案：面向不同团队规模的两种架构

极狐 GitLab 高可用可扩展架构

极狐 GitLab 的高可用和扩展性源自全球最大代码托管平台之一的 GitLab.com 十多年的技术实践沉淀。在整体架构设计上不存在单点故障，并结合负载均衡、水平伸缩、分布式架构、主从多副本机制和云原生等多种机制，实现理论上无限扩展的能力。

极狐 GitLab 提供支撑从 1000 人到 50000 人规模的架构最佳实践参考和专业服务支持，为企业构建高度可靠 DevOps 研运平台保驾护航。

例如，对于 3000 以内的研发人员（随着人员增加，节点数会有一定调整），提供以下高可用架构：

Application Server 处理实时和异步请求，至少 2 节点实现 HA；

PostgreSQL 采用 Consul 方案，Redis 使用 Sentinel，至少 3 节点把相关组件部署在一起实现高可用；

代码仓库存储在 Gitaly 节点，建议使用 3 个节点保证高可用；Praefect 作为 Gitaly 节点的 proxy/router，至少需要 3 节点；

共享存储建议使用对象存储。

极狐 GitLab Geo 多地部署架构

当开发团队分布在两个或多个地理位置，但他们的极狐 GitLab 实例位于一个位置时，获取和克隆大型存储库可能需要很长时间。

极狐 GitLab Geo 专为分布式团队构建，允许用户的极狐 GitLab 实例的只读镜像，减少克隆和获取大型存储库所需的时间，并改进用户协作流程。

它是如何工作的？

项目存储库和数据库（包括用户帐户、问题、合并请求、组、项目数据等）都复制到用户的辅助实例上；

使用只读镜像，用户可以更快地获取项目和读取数据，同时仍将所有更改推送到主服务器；

所有复制操作都是异步的，并在它们发生时排队等待调度。

价值：极狐 GitLab 企业级架构提供更好用户体验，助益降本增效，保障系统安全

极狐 GitLab 企业级架构的两种方案：高可用可扩展架构和 GEO 多地部署架构，使得企业在扩张的时候，作为源代码管理和持续集成流水线的平台也可以同步扩容。

使用了极狐 GitLab 企业级架构之后：

一、高可用：降低故障频率，实现更好的用户体验

降低软件故障频率和影响，确保系统即使在遇到意外中断或故障时也能继续运行；

有助于提高软件系统的用户体验和满意度，用户可以依赖它随时访问和响应，提升用户整体体验。

二、高可靠：更加健壮和稳定的系统，节省运维成本，创造业务价值

高可靠对于用户执行重要任务所依赖的关键任务系统尤为重要。开发者可以专注于开发，从而创造更多的价值；

高可靠也能够节约运维时间和成本。比如之前运维人员需要每周定位一次或重启一次；拥有企业级架构后即可把更多的时间放在业务开发和自动化上。

三、高安全：保障数据安全，护航系统安全

从安全的可用性和完整性来说，多节点架构都可以达到更高的目标，从而使得系统更加安全；

不稳定的软件通常更容易受到安全漏洞攻击，因为可能存在更多可被攻击者利用的错误和其他漏洞。稳定的软件系统不太可能存在此类漏洞，有助于保护敏感信息并防止数据丢失或被盗。

服务：极狐 GitLab 企业级架构的搭建服务

看到这，你可能会有疑问：

我不是很懂 HA 或者 GEO，要如何搭建？

我已经有一个 GitLab 在运行中了，如何以最小代价升级为企业级架构？

极狐 GitLab 针对于这种情况，提供了专业服务：

专业服务团队，丰富实施经验，能够应对各种场景和网络环境搭建高可用集群；

同时提供自动化的方式，高效完成搭建，快速达成客户的高可用目标；

保障性能，搭建前有相应的 dry run，确认环境正常；搭建完成之后都会进行性能测试，确保能够达到性能要求。

典型案例

极狐 GitLab 企业级架构已经在多个行业客户场景中实践落地，产生了立竿见影的客户价值，助力客户成功。

🌟案例 1：某国内头部视频网站

从响应慢且每 2 个月宕机一次，到响应速度 5 倍提升的高稳定系统

在采用企业级架构之前，该客户采用单机本地部署，但开发人员数达到 2000 人以上后，稳定性压力大，平均 2 个月宕机一次，对产品交付造成很大的负面影响。并且平台负载高，高峰期响应慢，开发效率受到掣肘。尤其在疫情期间，开发需求大幅增长，每周都有新功能要上线，新版本要发布，问题更为突出。

经过极狐 GitLab 团队定位发现，宕机的组件很多，包括：

• 单节点 Gitaly 撑爆，达到了 rate limit；
• Rails 节点 CPU 性能达到了 80%，报 500 错误；
• Postgres 没有高可用导致的单点问题。

采用极狐 GitLab 企业级高可用可扩展架构之后：

• 系统稳定性大大提高，完美支撑重要交付节点，保障业务收益；
• 实现多机可扩展架构，平台整体性能提高，响应速度最大提高 5 倍，极大改善开发效率；
• 有效支撑客户日益增长的产品开发诉求，助力客户业务增长。

🌟案例 2：某中国头部智能家电厂商

从每天发生 500 故障、每月宕机，到半小时  RPO，恢复时间近 50 倍提升

该客户研发团队超千人，在采用企业级架构之前，有多地开发，离主站点较远站点的用户访问速度慢，经常引起研发抱怨。虽说在 IaaS 层有专线方式，但是专线本身比较贵，而且也在高峰期会被其它应用占用带宽。

除此之外，极狐 GitLab 团队还发现以下问题：

• 异地访问员工占 50%，公司群里每天都有人反馈 500 问题；
• 单机压力过大，平均每月 1 次宕机导致代码仓库不可用；
• 灾备方案 RPO 差，一天一次冷备，恢复时间超过了 24H。

极狐 GitLab 团队分析了厂商需求之后，提供了高可用  +  Geo 多地部署方案，效果显著：

• 在高可用情况下，单机压力减少，宕机频率大大减少；
• 在异地多站点部署情况下，异地访问的员工不再抱怨访问速度慢；
• RPO 目标从 24H 缩短至半小时以内，提升近 50 倍，有效协助运维部门实现 RPO 目标。

极狐 GitLab 企业级架构方案基于成熟、世界顶尖的技术，已经为近 10 个行业、超过 100 家客户落地符合其业务场景的企业级架构，并在可用性、可靠性、安全性等多个维度获得广泛的用户肯定。未来，极狐 GitLab 陪伴更多来自各行各业的客户行稳致远。