携程网是如何做好持续交付的？

随着云计算、容器等新兴技术的发展，“持续交付”这个老生常谈的问题，忽如一夜春风来，仿佛找到了从理想通向现实的大门。各类相关工具、产品、服务，也是纷纷出现：如 Jenkins 2.0，Jenkins X，阿里云效，Netflix Spinnaker，Jfrog Artifactory 等等。

我是王潇俊，携程网系统研发总监, 接下来，我会结合在携程网工作的真实案例，分享关于持续支付的一些想法和经验。

首先我们要搞清楚什么是持续交付，其实这就好像你去问 100 个哲学家，“哲学”的定义是什么，你会获得 101 个答案一样。与马丁 · 福勒（Martin Fowler）老爷子在 2006 年，提出“持续集成”概念时一样，我们可以把“持续交付”定义为“一套软件工程方法论和许许多多的最佳实践的集合”。

持续交付也通常以“发布流水线”的方式来解释，即研发团队从开发，到测试，再到部署，最终将产品交付给最终用户使用的过程。如下图：

持续交付它所要达到的目标是在“最终用户”和“研发团队”之间建立紧密的反馈环：通过持续交付新的软件版本，以验证新想法和软件改动的正确性，并衡量这些改动对软件价值的影响。这里说的“软件价值”，说白了就是收入、日活、GMV 等 KPI 指标了。

在互联网应用盛行、速度为王的今天，持续交付的价值被突显出来。持续交付的能力，正成为评定一家互联网公司研发能力的重要指标。无论是什么企业，无论你的职位高低，作为不同的角色、站在不同的角度，都可以或者应该去尝试持续交付，它一定会让你觉得物超所值。

• 你是不是时常困扰于技术选型的问题？

• 你是不是经常头痛于已制定的标准难以落地？

• 你是不是时常考虑如何提高跨部门协作的效率？

• 你是不是担心“黑天鹅”的降临？

• 你一定希望团队的知识能够传承。

• 你一定希望团队专注于业务而非工程。

• 你一定希望以一个较平稳的节奏持续工作。

• 你应该是产品真正的第一个用户。

• 你应该完全知悉当前的进度和质量。

• 你的产品应该随时能发布。

• 你可以通过对持续交付的学习，进一步加强自己对整个软件工程的认识。

• 你可以利用持续交付的工具或最佳实践，提高自己的工作效率和质量。

• 你可以参与到持续交付实施中去，享受为其他程序员提供效率工具的挑战和乐趣。

扫码试看或订阅专栏

在我开设的技术专栏《持续交付 36 讲》完结之际，整理了大家的留言，总结了比较典型的 5 个问题，针对这 5 个问题再详细展开，分享一些携程在这些方面的真实方案和实践：

1. 测试环境使用和管理的实例；

2. 怎么处理数据库发布和回滚；

3. Immutable，在携程是如何落地的；

4. 携程的破坏性测试，DR 演练；

5. 携程 GitLab HA 方案。

携程的测试环境包括这么三类：

1. FAT 环境，为每个团队或功能准备的独立功能测试环境；

2. FWS 环境，部署稳定版本的功能服务，以供其他团队联调的环境；

3. UAT 环境，用户接受测试的环境，包括独立部署的 DB、缓存和中间件。

这三类环境中，UAT 环境的使用和管理方法大家都已经比较熟悉了，所以这里我再着重和你分享一下 FAT 和 FWS 环境相关的内容。

我在这里放置了一张图片，用于展示 FAT 和 FWS 环境的关系，

图 1 FAT 和 FWS 环境的关系

FAT 环境属于不同部门，可以包括多套环境。在管理时既可以按需临时生成，也可以作为常备环境持久保留。我们可以在一套 FAT 环境中，部署任意个服务应用。

而 FWS 环境主要部署的是中间件和公共服务，通常情况下它的版本与生产版本一致。

FWS 和 FAT 这两类环境，在网络上完全相同，并共用一组数据库和缓存。

既然 FWS 和 FAT 这两类环境完全相同，而且不同的 FAT 环境中也会存在相同的服务应用，那么我们就必然要解决一个问题，即：如何控制服务的调用关系。

因为即使是相同的服务应用，部署在不同的 FAT 环境中的应用版本号也可能不一样。如果按照标准服务治理方式的话，那么就需要把所有 FAT 环境中的同一个服务认为是一个服务集群。而同一应用的不同版本同时服务的话，它们提供的功能也不一样，这会对测试产生负面影响，因为无法确定出现 Bug 的版本到底是哪一个。

那么，携程是如何解决这个问题的呢？

携程的解决方案是，由 SOA 通信中间件指定服务的具体地址，即通过配置指定要调用的服务的具体地址。当然，如果每个服务都要去指定配置，那么就太过繁琐了。所以，我们还定义了一条默认规则：

如果没有特别指定的服务调用地址，则优先调用同一个环境中的相关服务。如果同一个环境中该服务不存在，则尝试调用 FWS 中部署的实例。

在携程，我们有一套完整的测试环境自助管理平台，开发人员或 QA 团队可以按需自助完成对对测试环境的任意操作。这里，我也分享一下，在携程创建一个测试环境的大致步骤。

第一步，选择一个已经存在的 FAT 环境，或者重新创建一个 FAT 环境。如果是重新创建的话，可以选择重新创建一个空的环境，或者是复制一个已有的环境。

第二步，选择要在这个 FAT 环境下部署的服务应用，先进行关系绑定（即，这个 FAT 环境下要部署的所有服务应用的描述）再部署。如果该服务属于其他团队，则可以要求该团队协助部署（由平台来处理）。在携程，一个团队只能部署属于自己的服务应用，如果你的 FAT 环境中包含了其他团队的应用，则要由其他团队部署。这样做的好处是各司其职，能更好地控制联调版本。

第三步，配置这个 FAT 环境相关的信息。携程的配置中心，同样也支持多测试环境的功能，可以做到同一个配置 key 在不同环境有不同的 value。

第四步，对于特殊的服务调用，进行单独配置。

经过这样的四步，一个测试环境就被创建起来了。期间测试环境的任何变化，都可以通过环境管理平台完成。比如，增减服务应用、修改配置，或是扩容 / 缩容服务器等。

这也是一个大家比较关心的问题。我来和你分享一下携程的实践吧。

在携程，数据库的变更是和应用发布拆分开的。也就是说，我们的数据库有单独的持续交付流程。这个持续交付的过程大致如图 2 所示。

图 2 数据库持续交付

在这个过程中，有两处 DBA 审核：

• 第一处审核，是在提交脚本之后。审核的内容主要是变更内容是否合法、方式是否得当、是否影响业务等等。

• 第二处审核，是在提交生产变更后。审核的主要的内容是，判断变更是否会对当时的生产系统产生影响。比如，订单表的更新、大表的变化等，就不允许在业务高峰期进行。

整个数据库发布的持续交付流程，是以测试通过为驱动的。这个过程，要经历开发、功能，以及集成测试 3 个环境。而数据库的发布又与代码发布不同步，所以如果有兼容问题的话，就容易被发现了。

那么，怎么做到兼容呢？携程对数据库变更的要求是：

• 第一，与业务相关的，只能新增字段，不能删除字段，也不能修改已有字段的定义，并且新增字段必须有默认值。

• 第二，对于必须要修改原有数据库结构的场景，则必须由 DBA 操作，不纳入持续交付流程。

所以，按照这个管理方式处理数据库的持续交付的话，数据库本身基本就没有需要回滚的场景了。

我之前提到过“不可变”的概念和价值，也讲到了任何系统的变更都要视为一次发布。然而，在传统的基于虚拟机的系统架构下，要做到这一点代价非常大。

所以，携程基于 Docker 容器和 k8s 落地了不可变模型。

具体的实现思路，其实也很简单。在落地不可变模型之前，我们只有应用发布，这一个可追溯的版本树；那么，针对不可变的需求，我们在其上增加了一个系统变更版本树。同样地，原来只在代码交付时才会进行镜像和部署；现在在系统变更时，我们也会针对性地生成镜像、标注版本、进行部署。

将应用发布和系统变更这两条版本树合并，就是完整的不可变模型需要的版本树了，也就是落地了不可变模型。

其实，携程的破坏性测试也只是刚刚起步，还没有完全具备混沌工程的能力，其原因主要是：很多的老旧系统比较脆弱，不具备在所有的随机破坏后快速恢复的能力。

但是，携程在同城多机房 DR（灾难恢复）方面，做得还是比较出色的。其实，DR 演练也是一种破坏性测试，一般采用的方式是局部断电或者流量切换。所以，我们也会定时做 DR 演练，以检验系统健壮性是否达标。

其实，破坏性测试和 DR 演练这两种方式的最终结果是一样的，都是将所有生产流量从灾难机房迁移至其他正常机房。当然，要完成这样的切换，同时不影响正常业务，我们需要在架构层面多花费一些精力。比如，数据库的同步、Redis 的同步、SLB 路由的快速切换，等等。

我们一起看一下 DR 演练的具体过程吧。假设 IDC B 的某个服务单元出现了异常，如图 3 所示。

图 3 个别服务单元故障

而此时，IDC A 有这个服务单元的灾备存在，那么系统就会被触发流量切换，即：GLB 会将所有发给故障服务单元 SLB 上的流量，切换到 IDC A 的灾备服务单元上，如图 4 所示。

图 4 流量切换后

这样，故障的服务单元就暂停了服务，直接由灾备服务顶上了。

当然，这种演练不仅仅是整个服务单元异常这一种场景，还可用于单元内的个别服务的异常演练，这时的流量切换就不再是由 GLB 这种上层来做了，而是利用 SLB 这一层的能力，切换部分服务的流量到灾备服务上。

最后，你还要记住的很重要的一点就是，要能探测到故障单元是否恢复正常了。如果恢复正常了的话，流量还要还原回去。这部分的能力，可以利用 SLB 的健康检测实现。

其实，整个 DR 演练过程中最容易出现问题的是，数据库和缓存的处理。如果没有跨机房数据实时同步的能力，建议最好不要尝试，毕竟不要把演练变成了破坏。

携程的 GitLab HA 方案，主要是基于 Sharding 思想，大致的架构设计如图 5 所示。

图 5 携程 GitLab HA 方案

这个方案的核心思想是：通过 Nodejs ssh2 代理和分发所有 SSH 请求，利用 Nginx 代理和分发所有 http 请求。具体的实施，包括以下三点：

第一，每台宿主机上有多个 GitLab 实例，可以是虚拟机形式，当然也可以是容器形式。

第二，同台宿主机上的 GitLab 实例共享一个 Volume，这样就保证了即使某一个 GitLab 实例故障，也可以快速将流量切换到同宿主机的其他实例上，继续提供服务。

第三，我们对每台宿主机的仓库，简单地用 rsync 做了冷备。此处并没做互备，否则就变成 NFS 方案了（因为，我们的目的是，只要保证存储故障时可恢复，所以无需采用 NFS 方案）。

这个方案的开发成本和维护成本都比较小、简单实用，你也可以借鉴。

持续交付的价值不仅仅局限于简单地提高产品交付的效率，它还通过统一标准、规范流程、工具化、自动化等等方式，影响着整个研发生命周期。

持续交付最终的使命是打破一切影响研发的“阻碍墙”，为软件研发工作本身赋能。无论你是持续交付的老朋友还是新朋友，无论你在公司担任管理工作还是普通的研发人员，持续交付都会对你的工作产生积极的作用。

如果你想系统的学习持续交付，可以通过极客时间订阅我的专栏《持续交付 36 讲》。现在订阅还有福利。

极客时间《持续交付 36 讲》专栏围绕持续交付知识详解、持续交付的平台化、打造移动 App 的持续交付体系、利用开源工具快速打造持续交付平台，共 4 大模块 36 讲展开分享，量身定制你的持续交付体系。

希望通过专栏的学习，你和你的团队可以在保证交付质量的前提下，加快交付速度，从而更快地得到市场反馈，引领产品的方向，最终达到扩大收益的目的。现在订阅，有以下福利：

福利一：今天限时拼团优惠价 49 元 /2 人，原价 68 元 /36 讲，10 月 29 日恢复原价。

福利二：每邀请一位好友购买，你可以获得 18 元现金返现，多邀多得，上不封顶，随时返现。（提现流程：极客时间 APP- 我的 - 分享有赏）

彩蛋：如果你对持续交付感兴趣，欢迎你进入极客时间持续交付技术交流群，进群方式，添加小助手微信（geektime123), 备注持续交付，邀你进群。

点击【阅读全文】，立即享受限时福利！