知乎部署系统演进.docxVIP

知乎部署系统演进 在引见部署系统之前，首先需要对知乎的相关基础设备和网络情况进行简约的引见。 知乎网络情况 知乎的网络如图所示： 知乎网络环境简图 次要划分为三个部分： 生产环境网络：即知乎对外的在线服务器网络，基于平安性考虑，与其他网络环境完全隔离。 测试环境网络：应用在部署到生产环境之前，首先会部署在测试环境，测试环境网络上与生产环境完全隔离。 办公室网络：即知乎员工内部网络，可以直接访问测试环境，也可以通过跳板机访问生产环境服务器。 流量管理 知乎接受 Nginx + HAProxy 的方式管理应用的流量走向： 知乎在线业务流量架构 应用开发者在 Nginx 平台上配置好 Location 和 HAProxy 的对应关系，再由 HAProxy 将流量分发到 Real Server 上去，同时 HAProxy 担当了负载均衡、限速、熔断等功能。 持续集成 知乎接受 Jenkins + Docker 进行持续集成，详见《知乎容器化构建系统设计和实践》，持续集成完成后，会生成 Artifact，供部署系统以及其他系统使用。 物理机部署 像大多数公司一样，知乎最开头是以物理机部署为主，业务自行编写脚本进行部署，部署时间长、风险大、难以回滚。在这种情况下，大约在 2021 年，初版的部署系统 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 2021 年末，随着容器大潮的袭来，知乎也进入容器时代，我们基于