9 月 13 日,2025 Inclusion・外滩大会「开源嘉年华」正在限量报名中! 了解详情
写点什么

知乎部署系统演进

  • 2019-04-15
  • 本文字数:4875 字

    阅读完需:约 16 分钟

知乎部署系统演进

应用部署是软件开发中重要的一环,保持快速迭代、持续部署,减少变更和试错成本,对于互联网公司尤为重要。本文将从部署系统的角度,介绍知乎应用平台从无到有的演进过程,希望可以对大家有所参考和帮助。


知乎部署系统由知乎工程效率团队打造,服务于公司几乎所有业务,每日部署次数在 2000 次左右,在启用蓝绿部署的情况下,大部分业务的生产环境上线时间可以在 10 秒以下(不包含金丝雀灰度验证过程)。


目前知乎部署系统主要实现了以下功能:


  • 支持容器、物理机部署,支持在线、离线服务、定时任务以及静态文件的部署

  • 支持办公网络预上线

  • 支持金丝雀灰度验证,期间支持故障检测以及自动回滚

  • 支持蓝绿部署,在蓝绿部署情况下,上线和回滚时间均在秒级

  • 支持部署 Merge Request 阶段的代码,用于调试


下文将按时间顺序,对部署系统的功能演进进行介绍。

技术背景

在介绍部署系统之前,首先需要对知乎的相关基础设施和网络情况进行简单的介绍。

知乎网络情况

知乎的网络如图所示:



知乎网络环境简图


主要划分为三个部分:


  • 生产环境网络:即知乎对外的在线服务器网络,基于安全性考虑,与其他网络环境完全隔离。

  • 测试环境网络:应用在部署到生产环境之前,首先会部署在测试环境,测试环境网络上与生产环境完全隔离。

  • 办公室网络:即知乎员工内部网络,可以直接访问测试环境,也可以通过跳板机访问生产环境服务器。

流量管理

知乎采用 Nginx + HAProxy 的方式管理应用的流量走向:



知乎在线业务流量架构


应用开发者在 Nginx 平台上配置好 Location 和 HAProxy 的对应关系,再由 HAProxy 将流量分发到 Real Server 上去,同时 HAProxy 承担了负载均衡、限速、熔断等功能。

持续集成

知乎采用 Jenkins + Docker 进行持续集成,详见《知乎容器化构建系统设计和实践》,持续集成完成后,会生成 Artifact,供部署系统以及其他系统使用。

物理机部署

像大多数公司一样,知乎最开始是以物理机部署为主,业务自行编写脚本进行部署,部署时间长、风险大、难以回滚。在这种情况下,大约在 2015 年,初版的部署系统 nami (取名自《海贼王》娜美)诞生了。


最初的部署系统采用 Fabric 作为基础,将 CI 产生的 Artifact 上传到物理机上解压,并使用 Supervisor 进行进程管理,将服务启动起来:



物理机部署


初版的部署系统虽然简单,但是为了之后的改进奠定了基础,很多基础的概念,一直到现在还在使用。

应用(App)与服务(Unit)

与 CI 相同,每个应用对应一个 GitLab Repo,这个很好理解。


但是在实际使用过程中,我们发现,同一套代码,往往对应着多个运行时的服务,比如以部署系统 nami 本身为例,虽然是同一套代码,但是在启动的时候,又要分为:


  • API 服务

  • 定时任务

  • Celery 离线队列


这些运行单元的启动命令、参数等各不相同,我们称之为服务(Unit)。用户需要在部署系统的前端界面上,为每个 Unit 进行启动参数、环境变量等设置,整个应用才能正常启动起来。

候选版本(Candidate)

所有的部署都是以 CI 产生 Artifact 作为基础,由于 Artifact 的不可变性,每次部署该 Artifact 的结果都是可预期的。也就是说,每个 Artifact 都是代码的一次快照,我们称之为部署的候选版本( Candidate)。


由于每次 CI 都是由 GitLab 的 Merge Request 产生,候选版本,其实就是一次 MR 的结果,也就是一次代码变更。通常情况下,一个候选版本对应一个 Merge Request:



每个候选版本对应一个 Merge Request


如图所示是某个应用的候选版本列表,每个候选版本,用户都可以将其部署到多个部署阶段(Stage)。

部署阶段(Stage)

上文提到,知乎服务器网络分为测试环境和生产环境,网络之间完全隔离。应用总是先部署测试环境,成功后再部署生产环境。


在部署系统上,我们的做法是,对每个候选版本的部署,拆分成多个阶段(Stage):



构建/部署阶段


图中该应用有 6 个阶段:


  • (B)构建阶段:即 CI 生成 Artifact 的过程。

  • (T)测试环境:网络、数据都与生产环境相隔离。

  • (O)办公室阶段:一个独立的容器,只有办公室网络可以访问,其他与线上环境相同,数据与生产环境共享。

  • ©金丝雀 1:生产环境 1%

  • 的容器,外网可访问。

  • ©金丝雀 2:生产环境 20% 的容器,外网可访问。

  • §生产环境:生产环境 100% 容器,外网可访问。


部署阶段从前到后依次进行,每个 Stage 的部署逻辑大致相同。


对于每个部署阶段,用户可以单独设置,是否进行自动部署。如果所有部署阶段都选择自动部署,那么应用就处于一个持续部署(Continuous Deployment)的过程。

基于 Consul 和 HAProxy 的服务注册与发现

每次部署物理机时,都会先将机器从 Consul 上摘除,当部署完成后,重新注册到 Consul 上。


上文提到,我们通过 HAProxy 连接到 Real Server,原理就是基于 Consul Template 对 HAProxy 的配置进行更新,使其总是指向所有 RS 列表。


另外,在迁移到微服务架构之后,我们编写了一个称为 diplomat 的基础库,从 Consul 上拉取 RS 列表,用于 RPC 以及其他场景的服务发现。

容器部署

旧版容器系统 Bay

2015 年末,随着容器大潮的袭来,知乎也进入容器时代,我们基于 Mesos 做了初版的容器编排系统(称为 Bay),部署系统也很快支持了容器的部署。


Bay 的部署很简单,每个 Unit 对应一个容器组,用户可以手动设置容器组的数量和其他参数。每次部署的时候,滚动地上线新版本容器,下线旧版本容器,部署完成后所有旧版本容器就都已回收。对于一些拥有数百容器的大容器组,每次部署时间最长最长可以达到 18 分钟。

各项功能完善

在迁移到容器部署的过程中,我们对部署系统也进行了其他方面的完善。


首先是健康检查,所有 HTTP、RPC 服务,都需要实现一个 /check_health 接口,在部署完成后会对其进行检查,当其 HTTP Code 为 200 时,部署才算成功,否则就会报错。


其次是在线/离线服务的拆分,对于 HTTP、RPC 等在线业务,采用滚动部署;对于其他业务,则是先启动全量新版本容器,再下线旧版本容器。

预上线与灰度发布

基于容器,我们可以更灵活地增删 Real Server,这使得我们可以更简单地将流量拆分到不同候选版本的容器组中去,利用这一点,我们实现了办公室网络预上线和金丝雀灰度发布。

办公室网络预上线

为了验证知乎主站的变更,我们决定在办公室网络,提前访问已经合并到主干分支、但还没有上线的代码。我们在 Nginx 层面做了流量拆分,当访问源是办公室网络的时候,流量流向办公室专属的 HAProxy:



办公室流量拆分


对于部署系统来说,所需要做的就是在「生产环境」这个 Stage 之前,加入一个「办公室」Stage,对于这个 Stage,只部署一个容器,并将这个容器注册到办公室专属的 HAProxy,从外网无法访问此容器。

金丝雀灰度发布

在 2016 年以前,知乎部署都是全量上线,新的变更直接全量上线到外网,一旦出现问题,很可能导致整个网站宕机。


为了解决这个问题,我们在「办公室」和「生产环境」Stage 之间,加入了「金丝雀 1」和「金丝雀 2」两个 Stage,用于灰度验证。


原理是,部署一定量额外的新版本容器,通过 HAProxy,随机分发流量到这些新版本容器上,这样如果新版本代码存在问题,可以在指标系统上明显看出问题:



Nginx 指标大盘


其中,「金丝雀1」阶段只启动相当于「生产环境」阶段 1% 的容器,「金丝雀2」阶段则启动 20% 数量的容器。


为了避免每次部署到金丝雀后,都依赖人工去观察指标系统,我们在部署系统上,又开发了「金丝雀自动回滚」功能。主要原理是:


  • 将金丝雀阶段的指标与生产环境的指标分离

  • 金丝雀部署完成后,对指标进行检测,与生产环境进行对比,如果发现异常,则销毁金丝雀容器,并通知用户

  • 如果在 6 分钟内没有发现指标异常,则认为代码没有明显问题,才允许用户部署「生产环境」Stage



金丝雀出现异常,回滚时会自动通知开发者


金丝雀阶段自动监测的指标包括该应用的错误数、响应时间、数据库慢查询数量、Sentry 报错数量、移动端 App 崩溃数量等等。

新版容器部署

针对旧版容器系统 Bay 部署速度慢、稳定性差等问题,我们将容器编排从 Mesos 切换到 Kubernetes,在此基础上开发出新一代的容器系统 NewBay。


相应地,部署系统也针对 NewBay 进行了一番改造,使得其在功能、速度上均有明显提升。

蓝绿部署

在旧版 Bay 中,每个 Unit 对应唯一的容器组,新版本容器会覆盖旧版本容器,这会导致:


  • 一旦部署失败,服务将处于中间状态,新旧版本会同时在线

  • 回滚旧版本代码速度较慢,而且有可能会失败


我们设计了一套新的部署逻辑,实现了蓝绿部署,即新旧版本容器组同时存在,使用 HAProxy 做流量切换:



蓝绿部署可以有效减少回滚时间


这使得:


  • 流量的切换原子化,即使部署失败也不会存在新旧版本同时在线的情况

  • 由于旧版本容器组会保留一段时间,这期间回滚代码仅需要将流量切回旧版本,回滚时间可以达到秒级

预部署

使用 NewBay 之后,大型项目的部署时间由原来的 18 分钟降至 3 分钟左右,但这其中仍有优化的空间。


为了加快部署速度,我们会在金丝雀阶段,提前将「生产环境」Stage 所需要的全量容器异步地启动起来,这样在部署「生产环境」Stage 时,仅需要将流量切换为全量即可:



预部署可以有效减少上线时间


通过这方面的优化,在全量上线到生产环境时,上线时间同样可以达到秒级。

分支部署

以上部署均是针对代码合并到主干分支后进行的部署操作,或者可以称之为「上线流程」。


但是实际上很多情况下,我们的代码在 Merge Request 阶段就需要进行部署,以方便开发者进行自测,或者交由 QA 团队测试。


我们在 CI/CD 层面对这种情况进行了支持,主要原理是在 MR 提交或者变更的时候就触发 CI/CD,将其部署到单独的容器上,方便开发者进行访问。



多个 Merge Request 同时部署和调试


分支部署实现细节较多,篇幅所限,在此不进行展开。

部署系统平台化

为了方便用户使用 CI/CD,管理应用资源,处理排查故障等,我们将整套知乎的开发流程进行了平台化,最终实现了 ZAE(Zhihu App Engine):



ZAE 是一套完整的开发者平台


用户可以方便地查看部署进度和日志,并进行一些常规操作:



在 ZAE 上查看部署进度


## 尾声知乎部署系统从 2015 年开始开发,到目前为止,功能上已经比较成熟。其实,部署系统所承担的责任不仅仅是上线这么简单,而是关系到应用从开发、上线到维护的方方面面。良好的部署系统,可以加快业务迭代速度、规避故障发生,进而影响到一家公司的产品发布节奏。


知乎部署系统以及 ZAE 开发者平台由知乎工程效率(EP)团队开发和维护,主要贡献者为


@Iven Hsu @Cosven @Amyyyyy @lfyzjck。工程效率团队致力于提高业务开发效率,提高工程代码质量和业务交付质量,统一知乎开发者的开发规范、流程和框架。对于这方面感兴趣的小伙伴们,可以与 iven@zhihu.com 联系。


2019-04-15 08:0016591

评论

发布
暂无评论
发现更多内容

Alluxio AI助力知乎千卡模型训练

Alluxio

韩国电商巨头Coupang 如何利用分布式缓存加速机器学习模型训练

Alluxio

机器学习 AI 模型训练 电商平台 Coupang

低代码是什么?2025技术详解:平台分类、用户群体与发展趋势

优秀

低代码 低代码开发 低代码平台

懒懒笔记 | 课代表带你梳理【RAG课程 9&10:大模型微调与思维链蒸馏】

商汤万象开发者

HarmonyOS实战:腾讯IM之聊天列表搭建(一)

IT小码哥

鸿蒙 HarmonyOS NEXT harmoyos 腾讯IM

如何利用jobleap.cn更有效地转行以及找到满意的工作

安全乐谷

找工作 简历 秋招 春招 找实习

React-native新架构

溪抱鱼

前端 React 框架

傻瓜式一键部署你的网页,让全世界看见你的想法

Captain

大数据-01-基础环境搭建 超详细 Hadoop Java 环境变量 3节点云服务器 2C4G XML 集群配置 HDFS Yarn MapRedece

武子康

大数据 hadoop mapreduce hive

掘金社区 MCP 上线、Claude 4与Gemini 2.5正面交锋、AI编程助手能力再进化—掘金 AI 编程社区周刊

Captain

谷歌云授权代理|90%用户不知道的5个谷歌云免费实用技巧

Cloud Ace 云一

谷歌云

火热邀测!DataWorks数据集成支持大模型AI处理

阿里云大数据AI技术

人工智能 数据分析 数据处理 #大数据 Dataworks

如何利用JobLeap.cn找到第一份实习

安全乐谷

找工作 秋招 春招 找实习

全球通信产业展会风向标|2025中国信息通信展9月在京召开

AIOTE智博会

通信展 信息通信展 北京通信展

MySQL性能优化策略及高可用架构设计与实践+监控与运维自动化!

程序员高级码农

MySQL 编程 程序员

为什么说JobLeap.cn是文科生找工作的最佳选择?

安全乐谷

找工作 应届生 秋招 春招 找实习

智能驾驶感知算法任务简介

地平线开发者

自动驾驶; 算法工具链 地平线征程6

华东站最后席位丨精彩嘉宾阵容,完整日程揭秘!2025 Altair 区域技术交流会邀您共探 AI + 仿真的智能未来

Altair RapidMiner

人工智能 AI 汽车 数字孪生 CAE

ETL怎么实现多流自定义合并?

谷云科技RestCloud

Java join ETL 数据集成工具 多流合并

什么是新一代智能职业发展平台?jobleap.cn领导的新一代求职平台与传统App有何不同?

安全乐谷

求职 找工作 秋招 春招

为什么JobLeap.cn的新一代智能职业发展平台比传统求职软件更有效

安全乐谷

求职 找工作 秋招 春招 找实习

iVX+ARM 边缘计算技术架构解析:从底层架构到行业应用

代码制造者

优哩哩的推广模式是什么?

web3区块链创业团队DappNetWork

优哩哩是什么平台?

web3区块链创业团队DappNetWork

BeeWorks:构建企业智能数字化协作中枢,实现办公与业务系统的无缝整合

BeeWorks

即时通讯 IM 企业级应用

安全,稳定可靠的政企即时通讯数字化平台

BeeWorks

即时通讯 IM 企业级应用

Databend 产品月报(2025年5月)

Databend

传统企业如何玩转平台工程?2 个运维靠它管 50 + 应用

北京好雨科技有限公司

云原生 k8s rainbond 企业号 5 月 PK 榜

时序数据库 IoTDB 集成 DBeaver,简易操作实现时序数据清晰管理

Apache IoTDB

iVX:图形化编程工程化实践及技术演进

代码制造者

ActiveMQ 可观测性最佳实践

观测云

Activemq

知乎部署系统演进_软件工程_Iven Hsu_InfoQ精选文章