Spark 灰度发布在十万级节点上的成功实践 CI CD

原创文章，转载请务必将下面这段话置于文章开头处。
本文转发自技术世界，原文连接　http://www.jasongj.com/spark/ci_cd/

本文所述内容基于某顶级互联网公司数万节点下 Spark 的 CI 与 CD & CD 实践。为了提升本文内容的可借鉴性，隐去了公司特有内容，只保留通用部分

Spark CI 持续集成实践

CI 介绍

持续集成是指，及时地将最新开发的且通过测试的代码集成到主干分支中。

持续集成的优势

• 快速发现错误 每次更新都及时集成到主干分支中，并进行测试，能够快速发现错误，方便定位错误
• 避免子分支大幅偏离主干分支 主干在不断更新，若是不常常集成，会产生后期集成难度变大，甚至难以集成，并形成不一样开发人员间没必要要的重复开发
• 为快速迭代提供保障 持续集成为后文介绍的持续发布与持续部署提供了保证

Spark CI 实践

目前主流的代码管理工具备，Github、Gitlab等。本文所介绍的内容中，全部代码均托管于私有的 Gitlab 中。

鉴于 Jenkins 几乎是 CI 事实上的标准，本文介绍的 Spark CI CD & CD 实践均基于 Jenkins 与 Gitlab。

Spark 源码保存在 spark-src.git 库中。

因为已有部署系统支持 Git，所以可将集成后的 distribution 保存到 Gitlab 的发布库（spark-bin.git）中。

每次开发人员提交代码后，均经过 Gitlab 发起一个 Merge Requet （至关于 Gitlab 的 Pull Request）

每当有 MR 被建立，或者被更新，Gitlab 经过 Webhook 通知 Jenkins 基于该 MR 最新代码进行 build。该 build 过程包含了

• 编译 Spark 全部 module
• 执行 Spark 全部单元测试
• 执行性能测试
• 检查测试结果。若是有任意测试用例失败，或者性能测试结果明显差于上一次测试，则 Jenkins 构建失败

Jenkins 将 build 结果通知 Gitlab，只有 Jenkins 构建成功，Gitlab 的 MR 页面才容许 Merge。不然 Gitlab 不容许 Merge

另外，还需人工进行 Code Review。只有两个以上的 Reviewer 经过，才能进行最终 Merge

全部测试与 Reivew 经过后，经过 Gitlab Merge 功能自动将代码 Fast forward Merge 到目标分支中

该流程保证了

• 全部合并进目标分支中的代码都通过了单元测试（白盒测试）与性能测试（黑盒测试）
• 每次发起 MR 后都会及时自动发起测试，方便及时发现问题
• 全部代码更新都能及时合并进目标分支

Spark CD 持续交付

CD 持续交付介绍

持续交付是指，及时地将软件的新版本，交付给质量保障团队或者用户，以供评审。持续交付可看做是持续集成的下一步。它强调的是，无论怎么更新，软件都是可随时交付的。

这一阶段的评审，通常是将上文集成后的软件部署到尽量贴近生产环境的 Staging 环境中，并使用贴近真实场景的用法（或者流量）进行测试。

持续发布的优势

• 快速发布 有了持续集成与持续发布，可快速将最新功能发布出来，也可快速修复已知 bug
• 快速迭代 因为发布及时，能够快速判断产品是否符合产品经理的预期或者是否能知足用户的需求

Spark CD 持续发布实践

这里有提供三种方案，供读者参考。推荐方案三

方案一：单分支

正常流程

以下图所示，基于单分支的 Spark 持续交付方案以下

• 全部开发都在 spark-src.git/dev（即 spark-src.git 的 dev branch） 上进行
• 每周一将当前最新代码打包，放进 spark-bin.git/dev 的 spark-${ build # }（如图中第 2 周的 spark-72）文件夹内
• spark-prod 指向当前 spark-dev 指向的文件夹（如图中的 spark-71 ）
• spark-dev 指向 spark-${ build # }（如图中的 spark-72）
• 自动将 spark-bin.git 最新内容上线到 Staging 环境，并使用 spark-dev 进行测试
• spark-prod 比 spark-dev 晚一周（一个 release 周期），这一周用于 Staging 环境中测试

注：

• 蓝色圆形是正常 commit
• 垂直虚线是发布时间点，week 一、week 二、week 三、week 4
• 最上方黑色粗横线是源码时间线
• 下方黄色粗横线是 release 时间线
• 绿色方框是每周生成的 release，带 build #
• 蓝色方框是开发版本的 symbolic
• 橘色方框是线上版本的 symbolic

bug fix

在 Staging 环境中发现 spark-dev 的 bug 时，修复及集成和交付方案以下

• 若是在 Staging 环境中发现了 spark-dev 的 bug，且必需要修复（如不修复，会带到下次的 spark-prod 的 release 中），则提交一个 commit，而且 commit message 包含 bugfix 字样（如图中黑色圆形 commit 9 所示）
• 该 bugfix 被 Merge 后，Jenkins 获得通知
• Jenkins 发现该 commit 是 bugfix，当即启动构建，生成spark-${ build \# }（如图中的 spark-73）
• spark-dev 指向 spark-${ build \# } （如图中的 spark-73 ）

hot fix

生产环境中发现 bug 时修复及交付方案以下

• 若是发现线上版本（即 spark-prod）有问题，须及时修复，则提交一个 commit，而且 commit message 包含 hotfix 字样 （如图中红色圆形 commit 9 所示）
• 该 hotfix 被 Merge 后，Jenkins 获得通知
• Jenkins 发现该 commit 是 hotfix，当即启动构建，生成 spark-${ build \# }（如图中的 spark-73）
• spark-dev 与 spark-prod 均指向 spark-${ build \# } （如图中的 spark-73 ）
  
  
  
  

Pros.

• spark-src.git 与 spark-bin.git 都只有一个分支，维护方便
• spark-prod 落后于 spark-dev 一周（一个 release），意味着 spark-prod 都成功经过了一周的 Staging 环境测试

Cons.

• 使用 spark-prod 与 spark-dev 两个 symbolic，若是要作灰度发布，须要用户修改相应路径，成本较高
• hotfix 时，引入了过去一周多（最多两周）未经 Staging 环境中经过 spark-dev 测试的 commit，增长了不肯定性，也违背了全部非 hotfix commit 都通过了一个发布周期测试的原则

方案二：两分支

正常流程

以下图所示，基于两分支的 Spark 持续交付方案以下

• spark-src.git 与 spark-bin.git 均包含两个分支，即 dev branch 与 prod branch
• 全部正常开发都在 spark-src.git/dev 上进行
• 每周一（若是是 weekly release）从 spark-src.git/dev 打包出一个 release 放进 spark-bin.git/dev 的 spark-${ build \# } 文件夹内（如图中第 2 周上方的的 spark-2 ）。它包含了以前全部的提交（commit 一、二、三、4）
• spark-bin.git/dev 的 spark 做为 symbolic 指向 spark-${ build \# } 文件夹内（如图中第 2 周上方的的 spark-2）
• spark-src.git/prod 经过 fast-forward merge 将 spark-src.git/dev 一周前最后一个 commit 及以前的全部 commit 都 merge 过来（如图中第 2 周需将 commit 1 merge 过来）
• 将 spark-src.git/prod 打包出一个 release 放进 spark-bin.git/prod 的 spark-${ build \# } 文件夹内（如图中第 2 周下方的的 spark-1 ）
• spark-bin.git/prod 的 spark 做为 symbolic 指向 spark-${ build \# }

bug fix

在 Staging 环境中发现了 dev 版本的 bug 时，修复及集成和交付方案以下

• 在 spark-src.git/dev上提交一个 commit （如图中黑色的 commit 9），且 commit message 包含 bugfix 字样
• Jenkins 发现该 commit 为 bugfix 后，当即构建，从 spark-src.git/dev 打包生成一个 release 并放进 spark-bin.git/dev 的 spark-${ build \# } 文件夹内（如图中第二周与第三周之间上方的的 spark-3 ）
• spark-bin.git/dev 中的 spark 做为 symbolic 指向 spark-${ build \# }
  
  
  
  

hot fix

在生产环境中发现了 prod 版本的 bug 时，修复及集成和交付方案以下

• 在 spark-src.git/dev 上提交一个 commit（如图中红色的 commit 9），且 commit message 包含 hotfix 字样
• Jenkins 发现该 commit 为 hotfix 后，当即将 spark-src.git/dev 打包生成 release 并 commit 到 spark-bin.git/dev 的 spark-${ build \# } （如图中上方的 spark-3 ）文件夹内。 spark 做为 symbolic 指向该 spark-${ build \# }
• 经过 cherry-pick 将 commit 9 double commit 到 spark-src.git/prod（如无冲突，则该流程全自动完成，无需人工参与。如发生冲突，经过告警系统通知开发人员手工解决冲突后提交）
• 将 spark-src.git/prod 打包生成 release 并 commit 到 spark-bin.git/prod 的 spark-${ build \# } （如图中下方的 spark-3 ）文件夹内。spark做为 symbolic 指向该spark-${ build \# }

Pros.

• 不管是 dev 版仍是 prod 版，路径都是 spark。切换版对用户透明，无迁移成本
• 方便灰度发布
• hotfix 不会引入未经测试的 commit，稳定性更有保障
• prod 版落后于 dev 版一周（一个 release 周期），即 prod 通过了一个 release 周期的测试，稳定性强

Cons.

• hot fix 时，使用 cherry-pick，但 spark-src.git/dev（包含 commit 一、二、三、四、5） 与 spark-src.git/prod（包含 commit 1） 的 base 不同，有发生冲突的风险。一旦发生冲突，便需人工介入
• hot fix 后再从 spark-src.git/dev 合并 commit 到 spark-src.git/prod 时须要使用 rebase 而不能直接 fast-forward merge。而该 rebase 可能再次发生冲突
• bug fix 修复的是当前 spark-bin.git/dev 的 bug，即图中的 commit 一、二、三、4 后的 bug，而 bug fix commit 即 commit 9 的 base 是 commit 5，存在必定程度的不一致
• bug fix 后，第 3 周时，最新的 spark-bin.git/dev 包含了 bug fix，而最新的 spark-bin.git/prod 未包含该 bugfix （它只包含了 commit 二、三、4 而不包含 commit 五、9）。只有到第 4 周，spark-bin.git/prod 才包含该 bugfix。也即 Staging 环境中发现的 bug，须要在一周多（最多两周）才能在 prod 环境中被修复。换言之，Staging 环境中检测出的 bug，仍然会继续出如今下一个生产环境的 release 中
• spark-src.git/dev 与 spark-src.git/prod 中包含的 commit 数一致（由于只容许 fast-forward merge），内容也最终一致。可是 commit 顺序不一致，且各 commit 内容也可能不一致。若是维护不当，容易形成两个分支差异愈来愈大，不易合并

方案三：多分支

正常流程

以下图所示，基于多分支的 Spark 持续交付方案以下

• 正常开发在 spark-src.git/master 上进行
• 每周一经过 fast-forward merge 将 spark-src.git/master 最新代码合并到 spark-src.git/dev。以下图中，第 2 周将 commit 4 及以前全部 commit 合并到 spark-src.git/dev
• 将 spark-src.git/dev 打包生成 release 并提交到 spark-bin.git/dev 的 spark-${ build \# }（以下图中第 2 周的 spark-2） 文件夹内。spark 做为 symbolic，指向该 spark-${ build \# }
• 每周一经过 fast-forward merge 将 spark-src.git/master 一周前最后一个 commit 合并到 spark-src.git/prod。如第 3 周合并 commit 4 及以前的 commit
• 上一步中，若是 commit 4 后紧临有一个或多个 bugfix commit，均需合并到 spark-src.git/prod 中，由于它们是对 commit 4 进行的 bug fix。后文介绍的 bug fix 流程保证，若是对 commit 4 后发布版本有多个 bug fix，那这多个 bug fix commit 紧密相连，中间不会被正常 commit 分开
• 将 spark-src.git/prod 打包生成 release 并提交到 spark-bin.git/prod 的 spark-${ build \# }（以下图中第 2 周的 spark-2） 文件夹内。spark 做为 symbolic，指向该 spark-${ build \# }
  
  
  
  

bug fix

在 Staging 环境中发现了 dev 版本的 bug 时，修复及集成和交付方案以下

• 以下图中，第 2 周与第 3 周之间在 Staging 环境中发现 dev 版本的 bug，在 spark-src.git/dev（包含 commit 一、二、三、4） 上提交一个 commit（如图中黑色的 commit 9），且 commit message 中包含 bugfix 字样
• Jenkins 发现该 bugfix 的 commit 后当即执行构建，将 spark-src.git/dev 打包生成 release 并提交到 spark-bin.git/dev 的 spark-${ build \# }（如图中的 spark-3） 文件夹内，spark 做为 symbolic，指向该 spark-${ build \# }
• 经过 git checkout master 切换到 spark-src.git/master ，再经过 git rebase dev 将 bugfix 的 commit rebase 到 spark-src.git/master，若是 rebase 发生冲突，经过告警通知开发人员人工介入处理冲突
• 在一个 release 周期内，如发现多个 dev 版本的 bug，均可按上述方式进行 bug fix，且这几个 bug fix 的 commit 在 spark-src.git/dev 上顺序相连。所以它们被 rebase 到 spark-src.git/master 后仍然顺序相连

hot fix

在生产环境中发现了 prod 版本的 bug 时，修复及集成和交付方案以下

• 在 spark-src.git/prod 中提交一个 commit，且其 commit message 中包含 hotfix 字样
• Jenkins 发现该 commit 为 hotfix，当即执行构建，将 spark-src.git/prod 打包生成 release 并提交到 spark-bin.git/prod 的 spark-${ build \# }（如图中的 spark-3） 文件夹内，spark 做为 symbolic，指向该 spark-${ build \# }
• 经过 git checkout master 切换到 spark-src.git/master，再经过 git rebase prod 将 hotfix rebase 到 spark-src.git/master
• 在一个 release 周期内，如发现多个 prod 版本的 bug，均可按上述方式进行 hot fix
  
  
  
  

灰度发布

本文介绍的实践中，不考虑多个版本（经实践检验，多个版本维护成本过高，且通常无必要），只考虑一个 prod 版本，一个 dev 版本

上文介绍的持续发布中，可将 spark-bin.git/dev 部署至须要使用最新版的环境中（不必定是 Staging 环境，能够是部分生产环境）从而实现 dev 版的部署。将 spark-bin.git/prod 部署至须要使用稳定版的 prod 环境中

回滚机制

本文介绍的方法中，全部 release 都放到 spark-${ build \# } 中，由 spark 这一 symbolic 选择指向具体哪一个 release。所以回滚方式比较直观

• 对于同一个大版本（dev 或者 prod）的回滚，只需将 spark 指向 build # 较小的 release 便可
• 若是是将部分环境中的 prod 版迁至 dev 版（或者 dev 版改成 prod 版）后，须要回滚，只需将 dev 改回 prod 版（或者将 prod 版改回 dev 版）便可

Pros.

• 正常开发在 spark-src.git/master 上进行，Staging 环境的 bug fix 在 spark-src.git/dev 上进行，生产环境的 hot fix 在 spark-src.git/prod 上进行，清晰明了
• bug fix 提交时的 code base 与 Staging 环境使用版本的 code 彻底一致，从而可保证 bug fix 的正确性
• bug fix 合并回 spark-src.git/master 时使用 rebase，从而保证了 spark-src.git/dev 与 spark-src.git/master 全部 commit 的顺序与内容的一致性，进而保证了这两个 branch 的一致性
• hot fix 提交时的 code base 与 生产环境使用版本的 code 彻底一致，从而可保证 hot fix 的正确性
• hot fix 合并回 spark-src.git/master 时使用 rebase，从而保证了 spark-src.git/dev 与 spark-src.git/master 全部 commit 的顺序性及内容的一致性，进而保证了这两个 branch 的一致性
• 开发人员只须要专一于新 feature 的开发，bug fix 的提交，与 hot fix 的提交。全部的版本维护工做所有自动完成。只有当 bug fix 或 hot fix rebase 回 spark-src.git/master 发生冲突时才需人工介入
• spark-bin.git/dev 与 spark-bin.git/prod 将开发版本与生产版本分开，方便独立部署。而其路径统一，方便版本切换与灰度发布

Cons.

• 在本地 spark-src.git/master 提交时，须先 rebase 远程分支，而不该直接使用 merge。在本方案中，这不只是最佳实践，仍是硬性要求
• 虽然 bug fix 与 hot fix commit 都经过 rebase 进入 spark-src.git/master。但发生冲突时，须要相应修改 spark-src.git/master 上后续 commit。如上图中，提交红色 commit 9 这一 hot fix 后，在 rebase 回 spark-src.git/master 时，若有冲突，可能须要修改 commit 2 或者 commit 三、四、5。该修改会形成本地解决完冲突后的版本与远程版本冲突，须要强制 push 回远程分支。该操做存在必定风险

Spark CD 持续部署

持续部署是指，软件经过评审后，自动部署到生产环境中

上述 Spark 持续发布实践的介绍都只到 "将 *** 提交到 spark-bin.git" 结束。可以使用基于 git 的部署（为了性能和扩展性，通常不直接在待部署机器上使用 git pull --rebase，而是使用自研的上线方案，此处不展开）将该 release 上线到 Staging 环境或生产环境

该自动上线过程便是 Spark 持续部署的最后一环

Spark 系列文章

• Spark性能优化之道——解决Spark数据倾斜（Data Skew）的N种姿式
• Spark SQL / Catalyst 内部原理 与 RBO
• Spark SQL 性能优化再进一步 CBO 基于代价的优化
• Spark CommitCoordinator 保证数据一致性
• Spark 灰度发布在十万级节点上的成功实践 CI CD