滴滴、阿里云、语雀相继宕机，损失巨大，软件的高可用失效了么？

本文介绍: 极狐GitLa b 高可用 + GEO 架构，提升企业源代码托管服务的可靠性、可用性。

在北京寒冬的夜里，小程加班完成了当天最后一个任务，他拖着疲惫的身体离开了位于西二旗的工位，走到办公楼下，下意识地拿出手机打开滴滴，准备打车回家，但是他却发现滴滴的打车页面显示网络异常。起初小程以为是手机流量没开或者手机欠费，经过反复确认后发现不是话费欠费问题，于是他重启了滴滴 app，甚至重启了手机，但都是一样的结果：

在寒风中折腾了半个小时，将本来就没穿秋裤的小程冻得瑟瑟发抖，直到在 DevOps 技术交流群中看到很多小伙伴都遇到了这种情况，小程意识到，可能是滴滴出问题了。群里的小伙伴也在讨论：是不是高可用没做好？

事后，滴滴出行发布了致歉信并发布了事故的初步调查原因：并不是网络攻击而是底层系统软件发生故障。

同样的 P0 事故在半个月之前发生在了阿里云身上。

11 月 12 日，双十一刚过，阿里云发生了宕机，旗下的钉钉、淘宝、闲鱼等产品皆受到了不同程度的影响，此次事故还影响到了使用阿里云的一些企业级客户。经过数小时的修复后，服务恢复正常。

如果再往前一个月，同样的 P0 事故又发生在了语雀身上。

10 月 23 日，程序员节的前一天，语雀出现重大服务故障，持续了 7 个多小时才完全恢复。事故的整个过程及原因分析法不在了关于语雀 23 日故障的公告中。

一个多月的时间内，大厂的产品相继发生了三起 P0 事故。其实任何一家企业都不想自身的产品或服务出现 P0 事故，任何一个程序员都不想有处理 P0 事故的机会。事故既然已经发生，那么就要去复盘，然后制定对应的计划避免后续再发生类似的故障。而这类计划中可能会有一个永远绕不过去的话题：高可用。

高可用是一种软件架构模式，主要是为了让应用程序能够满足业务规模的快速发展，尤其对于大规模或者超大规模的企业来讲，高可用是提升企业服务可靠性、可用性的重要手段。

设想一个场景：企业内部正在抓紧研发一款基于 AIGC 的产品，产品所处的赛道还处于空白状态，突然得知，另外一家竞品公司决定提前发布产品。于是公司全员开始加班，希望能比竞品更早发布产品，以达到快速占领市场的目的。但是在关键时刻，源代码托管平台崩了，数千人无法提交代码了。运维人员查看之后发现单点设置的源代码托管平台，在数千人的协作下崩盘了。由于没有采用企业级的服务，运维人员只能自行查找资料去修复。ETA：unknown。所有人只能眼睁睁地在办公室看竞品的发布会了。

如何避免这种“悲剧”？

答案是：搭建源代码托管平台的高可用架构。

极狐GitLab 高可用方案

极狐GitLab 高可用扩展性 架构

极狐GitLab 提供高可用扩展性架构，其源自全球最大代码托管平台之一的 GitLab.com 十多年的技术实践沉淀，该架构通过了全球 3000 万注册用户的检验。

极狐GitLab 高可用扩展性架构通过把极狐GitLab 中所有组件单独抽出来，以分布式集群的方式部署，每一个服务和组件都是多副本的，在整体架构设计上不存在单点故障，并结合负载均衡、水平伸缩、分布式架构、主从多副本机制和云原生等多种机制，实现理论上无限扩展的能力。

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

极狐GitLab 在数据存储方面使用了多个组件，如 PGSQL 和 Redi s，不少客户已经将极狐GitLab 实例中的这些组件替换为第三方的高可用组件。但极狐GitLab 中最核心的存储组件却不是 PGSQL 也不是 Redi s，而是 Gitaly，这是 GitLab 自研的组件，用于对代码仓库进行管理和指令互动，因此它的地位最重要，负载也最高。

因为有些企业的数据量多达 30 T 级别，使用单个磁盘或单个节点的成本很高，且性能无法保证。Gitaly Cluster 高可用 Git 仓库服务持多副本和分片，把不同的代码库分到不同的存储片上，这也是提高可用性和性能的方式。

极狐GitLab GEO 多地域部署架构

相较于支持 1000 人起步的高可用可扩展架构，极狐GitLab GEO 多地域部署架构则更为轻量和简单，更加适合中小型企业。

GEO 多地域部署架构实现一主多从，主从之间的数据实时同步。极狐GitLab GEO 多地域部署方案是热备份，即便主节点宕机，也可以把从节点处将其恢复，或提升从节点为主节点，那么丢失的数据最多是 1～2 分钟的数据。所以 GEO 多地域部署的时效性和可靠性大大高于传统冷备份方式，属于准高可用，同时是灾备架构，并支持异地容灾。