Spark灰度發(fā)布在十萬(wàn)級(jí)節(jié)點(diǎn)上的實(shí)踐
本文介紹了頂級(jí)互聯(lián)網(wǎng)公司數(shù)萬(wàn)節(jié)點(diǎn)下 Spark 的 CI 與 CD & CD 灰度發(fā)布實(shí)踐。包含如何維護(hù)源代碼，如何維護(hù) Release 多版本，開(kāi)發(fā)版與正式版，以及如何實(shí)現(xiàn)灰度發(fā)布，如何進(jìn)行 hotfix 等。為了提高本文內(nèi)容的可借鑒性，隱去了公司特有內(nèi)容，只保留通用部分。
CI 介紹
持續(xù)集成是指，及時(shí)地將最新開(kāi)發(fā)的且經(jīng)過(guò)測(cè)試的代碼集成到主干分支中。
持續(xù)集成的優(yōu)點(diǎn)
- 快速發(fā)現(xiàn)錯(cuò)誤 每次更新都及時(shí)集成到主干分支中，并進(jìn)行測(cè)試，可以快速發(fā)現(xiàn)錯(cuò)誤，方便定位錯(cuò)誤。
- 避免子分支大幅偏離主干分支 主干在不斷更新，如果不經(jīng)常集成，會(huì)產(chǎn)生后期集成難度變大，甚至難以集成，并造成不同開(kāi)發(fā)人員間不必要的重復(fù)開(kāi)發(fā)。
- 為快速迭代提供保障 持續(xù)集成為后文介紹的持續(xù)發(fā)布與持續(xù)部署提供了保證。
Spark CI 實(shí)踐
目前主流的代碼管理工具有，Github、Gitlab等。本文所介紹的內(nèi)容中，所有代碼均托管于私有的 Gitlab 中。
鑒于 Jenkins 幾乎是 CI 事實(shí)上的標(biāo)準(zhǔn)，本文介紹的 Spark CI CD & CD 實(shí)踐均基于 Jenkins 與 Gitlab。
Spark 源碼保存在 spark-src.git 庫(kù)中。
由于已有部署系統(tǒng)支持 Git，因此可將集成后的 distribution 保存到 Gitlab 的發(fā)布庫(kù)(spark-bin.git)中。
每次開(kāi)發(fā)人員提交代碼后，均通過(guò) Gitlab 發(fā)起一個(gè) Merge Requet (相當(dāng)于 Gitlab 的 Pull Request)
每當(dāng)有 MR 被創(chuàng)建，或者被更新，Gitlab 通過(guò) Webhook 通知 Jenkins 基于該 MR 最新代碼進(jìn)行 build。該 build 過(guò)程包含了
- 編譯 Spark 所有 module
- 執(zhí)行 Spark 所有單元測(cè)試
- 執(zhí)行性能測(cè)試
- 檢查測(cè)試結(jié)果。如果有任意測(cè)試用例失敗，或者性能測(cè)試結(jié)果明顯差于上一次測(cè)試，則 Jenkins 構(gòu)建失敗
Jenkins 將 build 結(jié)果通知 Gitlab，只有 Jenkins 構(gòu)建成功，Gitlab 的 MR 頁(yè)面才允許 Merge。否則 Gitlab 不允許 Merge
另外，還需人工進(jìn)行 Code Review。只有兩個(gè)以上的 Reviewer 通過(guò)，才能進(jìn)行最終 Merge
所有測(cè)試與 Reivew 通過(guò)后，通過(guò) Gitlab Merge 功能自動(dòng)將代碼 Fast forward Merge 到目標(biāo)分支中
該流程保證了
- 所有合并進(jìn)目標(biāo)分支中的代碼都經(jīng)過(guò)了單元測(cè)試(白盒測(cè)試)與性能測(cè)試(黑盒測(cè)試)
- 每次發(fā)起 MR 后都會(huì)及時(shí)自動(dòng)發(fā)起測(cè)試，方便及時(shí)發(fā)現(xiàn)問(wèn)題
- 所有代碼更新都能及時(shí)合并進(jìn)目標(biāo)分支
Spark CD 持續(xù)交付
CD 持續(xù)交付介紹
持續(xù)交付是指，及時(shí)地將軟件的新版本，交付給質(zhì)量保障團(tuán)隊(duì)或者用戶，以供評(píng)審。持續(xù)交付可看作是持續(xù)集成的下一步。它強(qiáng)調(diào)的是，不管怎么更新，軟件都是可隨時(shí)交付的。
這一階段的評(píng)審，一般是將上文集成后的軟件部署到盡可能貼近生產(chǎn)環(huán)境的 Staging 環(huán)境中，并使用貼近真實(shí)場(chǎng)景的用法(或者流量)進(jìn)行測(cè)試。
持續(xù)發(fā)布的優(yōu)點(diǎn)
- 快速發(fā)布 有了持續(xù)集成與持續(xù)發(fā)布，可快速將最新功能發(fā)布出來(lái)，也可快速修復(fù)已知 bug
- 快速迭代 由于發(fā)布及時(shí)，可以快速判斷產(chǎn)品是否符合產(chǎn)品經(jīng)理的預(yù)期或者是否能滿足用戶的需求
Spark CD 持續(xù)發(fā)布實(shí)踐
這里有提供三種方案，供讀者參考。推薦方案三。
方案一：?jiǎn)畏种?/strong>
正常流程
如下圖所示，基于單分支的 Spark 持續(xù)交付方案如下：
- 所有開(kāi)發(fā)都在 spark-src.git/dev(即 spark-src.git 的 dev branch) 上進(jìn)行
- 每周一將當(dāng)前最新代碼打包，放進(jìn) spark-bin.git/dev 的 spark-${ build # }(如圖中第 2 周的 spark-72)文件夾內(nèi)
- spark-prod 指向當(dāng)前 spark-dev 指向的文件夾(如圖中的 spark-71 )
- spark-dev 指向 spark-${ build # }(如圖中的 spark-72)
- 自動(dòng)將 spark-bin.git 最新內(nèi)容上線到 Staging 環(huán)境，并使用 spark-dev 進(jìn)行測(cè)試
- spark-prod 比 spark-dev 晚一周(一個(gè) release 周期)，這一周用于 Staging 環(huán)境中測(cè)試
注：
- 藍(lán)色圓形是正常 commit
- 垂直虛線是發(fā)布時(shí)間點(diǎn)，week 1、week 2、week 3、week 4
- 最上方黑色粗橫線是源碼時(shí)間線
- 下方黃色粗橫線是 release 時(shí)間線
- 綠色方框是每周生成的 release，帶 build #
- 藍(lán)色方框是開(kāi)發(fā)版本的 symbolic
- 橘色方框是線上版本的 symbolic
bug fix
在 Staging 環(huán)境中發(fā)現(xiàn) spark-dev 的 bug 時(shí)，修復(fù)及集成和交付方案如下：
- 如果在 Staging 環(huán)境中發(fā)現(xiàn)了 spark-dev 的 bug，且必須要修復(fù)(如不修復(fù)，會(huì)帶到下次的 spark-prod 的 release 中)，則提交一個(gè) commit，并且 commit message 包含 bugfix 字樣(如圖中黑色圓形 commit 9 所示)
- 該 bugfix 被 Merge 后，Jenkins 得到通知
- Jenkins 發(fā)現(xiàn)該 commit 是 bugfix，立即啟動(dòng)構(gòu)建，生成spark-${ build # }(如圖中的 spark-73)
- spark-dev 指向 spark-${ build # } (如圖中的 spark-73 )
hot fix
生產(chǎn)環(huán)境中發(fā)現(xiàn) bug 時(shí)修復(fù)及交付方案如下：
- 如果發(fā)現(xiàn)線上版本(即 spark-prod)有問(wèn)題，須及時(shí)修復(fù)，則提交一個(gè) commit，并且 commit message 包含 hotfix 字樣 (如圖中紅色圓形 commit 9 所示)
- 該 hotfix 被 Merge 后，Jenkins 得到通知
- Jenkins 發(fā)現(xiàn)該 commit 是 hotfix，立即啟動(dòng)構(gòu)建，生成 spark-${ build # }(如圖中的 spark-73)
- spark-dev 與 spark-prod 均指向 spark-${ build # } (如圖中的 spark-73 )
Pros.
- spark-src.git 與 spark-bin.git 都只有一個(gè)分支，維護(hù)方便
- spark-prod 落后于 spark-dev 一周(一個(gè) release)，意味著 spark-prod 都成功通過(guò)了一周的 Staging 環(huán)境測(cè)試
Cons.
- 使用 spark-prod 與 spark-dev 兩個(gè) symbolic，如果要做灰度發(fā)布，需要用戶修改相應(yīng)路徑，成本較高
- hotfix 時(shí)，引入了過(guò)去一周多(最多兩周)未經(jīng) Staging 環(huán)境中通過(guò) spark-dev 測(cè)試的 commit，增加了不確定性，也違背了所有非 hotfix commit 都經(jīng)過(guò)了一個(gè)發(fā)布周期測(cè)試的原則
方案二：兩分支
正常流程
如下圖所示，基于兩分支的 Spark 持續(xù)交付方案如下：
- spark-src.git 與 spark-bin.git 均包含兩個(gè)分支，即 dev branch 與 prod branch
- 所有正常開(kāi)發(fā)都在 spark-src.git/dev 上進(jìn)行
- 每周一(如果是 weekly release)從 spark-src.git/dev 打包出一個(gè) release 放進(jìn) spark-bin.git/dev 的 spark-${ build # } 文件夾內(nèi)(如圖中第 2 周上方的的 spark-2 )。它包含了之前所有的提交(commit 1、2、3、4)
- spark-bin.git/dev 的 spark 作為 symbolic 指向 spark-${ build # } 文件夾內(nèi)(如圖中第 2 周上方的的 spark-2)
- spark-src.git/prod 通過(guò) fast-forward merge 將 spark-src.git/dev 一周前最后一個(gè) commit 及之前的所有 commit 都 merge 過(guò)來(lái)(如圖中第 2 周需將 commit 1 merge 過(guò)來(lái))
- 將 spark-src.git/prod 打包出一個(gè) release 放進(jìn) spark-bin.git/prod 的 spark-${ build # } 文件夾內(nèi)(如圖中第 2 周下方的的 spark-1 )
- spark-bin.git/prod 的 spark 作為 symbolic 指向 spark-${ build # }
bug fix
在 Staging 環(huán)境中發(fā)現(xiàn)了 dev 版本的 bug 時(shí)，修復(fù)及集成和交付方案如下
- 在 spark-src.git/dev上提交一個(gè) commit (如圖中黑色的 commit 9)，且 commit message 包含 bugfix 字樣
- Jenkins 發(fā)現(xiàn)該 commit 為 bugfix 后，立即構(gòu)建，從 spark-src.git/dev 打包生成一個(gè) release 并放進(jìn) spark-bin.git/dev 的 spark-${ build # } 文件夾內(nèi)(如圖中第二周與第三周之間上方的的 spark-3 )
- spark-bin.git/dev 中的 spark 作為 symbolic 指向 spark-${ build # }
hot fix
在生產(chǎn)環(huán)境中發(fā)現(xiàn)了 prod 版本的 bug 時(shí)，修復(fù)及集成和交付方案如下：
- 在 spark-src.git/dev 上提交一個(gè) commit(如圖中紅色的 commit 9)，且 commit message 包含 hotfix 字樣
- Jenkins 發(fā)現(xiàn)該 commit 為 hotfix 后，立即將 spark-src.git/dev 打包生成 release 并 commit 到 spark-bin.git/dev 的 spark-${ build # } (如圖中上方的 spark-3 )文件夾內(nèi)。 spark 作為 symbolic 指向該 spark-${ build # }
- 通過(guò) cherry-pick 將 commit 9 double commit 到 spark-src.git/prod(如無(wú)沖突，則該流程全自動(dòng)完成，無(wú)需人工參與。如發(fā)生沖突，通過(guò)告警系統(tǒng)通知開(kāi)發(fā)人員手工解決沖突后提交)
- 將 spark-src.git/prod 打包生成 release 并 commit 到 spark-bin.git/prod 的 spark-${ build # } (如圖中下方的 spark-3 )文件夾內(nèi)。spark作為 symbolic 指向該spark-${ build # }
Pros.
- 無(wú)論是 dev 版還是 prod 版，路徑都是 spark。切換版對(duì)用戶透明，無(wú)遷移成本
- 方便灰度發(fā)布
- hotfix 不會(huì)引入未經(jīng)測(cè)試的 commit，穩(wěn)定性更有保障
- prod 版落后于 dev 版一周(一個(gè) release 周期)，即 prod 經(jīng)過(guò)了一個(gè) release 周期的測(cè)試，穩(wěn)定性強(qiáng)
Cons.
- hot fix 時(shí)，使用 cherry-pick，但 spark-src.git/dev(包含 commit 1、2、3、4、5) 與 spark-src.git/prod(包含 commit 1) 的 base 不一樣，有發(fā)生沖突的風(fēng)險(xiǎn)。一旦發(fā)生沖突，便需人工介入
- hot fix 后再?gòu)?spark-src.git/dev 合并 commit 到 spark-src.git/prod 時(shí)需要使用 rebase 而不能直接 fast-forward merge。而該 rebase 可能再次發(fā)生沖突
- bug fix 修復(fù)的是當(dāng)前 spark-bin.git/dev的 bug，即圖中的 commit 1、2、3、4 后的 bug，而 bug fix commit 即 commit 9 的 base 是 commit 5，存在一定程度的不一致
- bug fix 后，第 3 周時(shí)，最新的 spark-bin.git/dev 包含了 bug fix，而最新的 spark-bin.git/prod 未包含該 bugfix (它只包含了 commit 2、3、4 而不包含 commit 5、9)。只有到第 4 周，spark-bin.git/prod 才包含該 bugfix。也即 Staging 環(huán)境中發(fā)現(xiàn)的 bug，需要在一周多(最多兩周)才能在 prod 環(huán)境中被修復(fù)。換言之，Staging 環(huán)境中檢測(cè)出的 bug，仍然會(huì)繼續(xù)出現(xiàn)在下一個(gè)生產(chǎn)環(huán)境的 release 中
- spark-src.git/dev 與 spark-src.git/prod 中包含的 commit 數(shù)一致(因?yàn)橹辉试S fast-forward merge)，內(nèi)容也最終一致。但是 commit 順序不一致，且各 commit 內(nèi)容也可能不一致。如果維護(hù)不當(dāng)，容易造成兩個(gè)分支差別越來(lái)越大，不易合并
方案三：多分支
正常流程
如下圖所示，基于多分支的 Spark 持續(xù)交付方案如下
- 正常開(kāi)發(fā)在 spark-src.git/master 上進(jìn)行
- 每周一通過(guò) 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) 文件夾內(nèi)。spark 作為 symbolic，指向該 spark-${ build # }
- 每周一通過(guò) fast-forward merge 將 spark-src.git/master 一周前最后一個(gè) commit 合并到 spark-src.git/prod。如第 3 周合并 commit 4 及之前的 commit
- 上一步中，如果 commit 4 后緊臨有一個(gè)或多個(gè) bugfix commit，均需合并到 spark-src.git/prod 中，因?yàn)樗鼈兪菍?duì) commit 4 進(jìn)行的 bug fix。后文介紹的 bug fix 流程保證，如果對(duì) commit 4 后發(fā)布版本有多個(gè) bug fix，那這多個(gè) bug fix commit 緊密相連，中間不會(huì)被正常 commit 分開(kāi)
- 將 spark-src.git/prod 打包生成 release 并提交到 spark-bin.git/prod 的 spark-${ build # }(如下圖中第 2 周的 spark-2) 文件夾內(nèi)。spark 作為 symbolic，指向該 spark-${ build # }
bug fix
在 Staging 環(huán)境中發(fā)現(xiàn)了 dev 版本的 bug 時(shí)，修復(fù)及集成和交付方案如下：
- 如下圖中，第 2 周與第 3 周之間在 Staging 環(huán)境中發(fā)現(xiàn) dev 版本的 bug，在 spark-src.git/dev(包含 commit 1、2、3、4) 上提交一個(gè) commit(如圖中黑色的 commit 9)，且 commit message 中包含 bugfix 字樣
- Jenkins 發(fā)現(xiàn)該 bugfix 的 commit 后立即執(zhí)行構(gòu)建，將 spark-src.git/dev 打包生成 release 并提交到 spark-bin.git/dev 的 spark-${ build # }(如圖中的 spark-3) 文件夾內(nèi)，spark 作為 symbolic，指向該 spark-${ build # }
- 通過(guò) git checkout master 切換到 spark-src.git/master ，再通過(guò) git rebase dev 將 bugfix 的 commit rebase 到 spark-src.git/master，如果 rebase 發(fā)生沖突，通過(guò)告警通知開(kāi)發(fā)人員人工介入處理沖突
- 在一個(gè) release 周期內(nèi)，如發(fā)現(xiàn)多個(gè) dev 版本的 bug，都可按上述方式進(jìn)行 bug fix，且這幾個(gè) bug fix 的 commit 在 spark-src.git/dev上順序相連。因此它們被 rebase 到 spark-src.git/master 后仍然順序相連
hot fix
在生產(chǎn)環(huán)境中發(fā)現(xiàn)了 prod 版本的 bug 時(shí)，修復(fù)及集成和交付方案如下
- 在 spark-src.git/prod 中提交一個(gè) commit，且其 commit message 中包含 hotfix 字樣
- Jenkins 發(fā)現(xiàn)該 commit 為 hotfix，立即執(zhí)行構(gòu)建，將 spark-src.git/prod 打包生成 release 并提交到 spark-bin.git/prod 的 spark-${ build # }(如圖中的 spark-3) 文件夾內(nèi)，spark 作為 symbolic，指向該 spark-${ build # }
- 通過(guò) git checkout master 切換到 spark-src.git/master，再通過(guò) git rebase prod 將 hotfix rebase 到 spark-src.git/master
- 在一個(gè) release 周期內(nèi)，如發(fā)現(xiàn)多個(gè) prod 版本的 bug，都可按上述方式進(jìn)行 hot fix
灰度發(fā)布
本文介紹的實(shí)踐中，不考慮多個(gè)版本(經(jīng)實(shí)踐檢驗(yàn)，多個(gè)版本維護(hù)成本太高，且一般無(wú)必要)，只考慮一個(gè) prod 版本，一個(gè) dev 版本
上文介紹的持續(xù)發(fā)布中，可將 spark-bin.git/dev 部署至需要使用最新版的環(huán)境中(不一定是 Staging 環(huán)境，可以是部分生產(chǎn)環(huán)境)從而實(shí)現(xiàn) dev 版的部署。將 spark-bin.git/prod部署至需要使用穩(wěn)定版的 prod 環(huán)境中
回滾機(jī)制
本文介紹的方法中，所有 release 都放到 spark-${ build \# } 中，由 spark 這一 symbolic 選擇指向具體哪個(gè) release。因此回滾方式比較直觀
- 對(duì)于同一個(gè)大版本(dev 或者 prod)的回滾，只需將 spark 指向 build # 較小的 release 即可
- 如果是將部分環(huán)境中的 prod 版遷至 dev 版(或者 dev 版改為 prod 版)后，需要回滾，只需將 dev 改回 prod 版(或者將 prod 版改回 dev 版)即可
Pros.
- 正常開(kāi)發(fā)在 spark-src.git/master 上進(jìn)行，Staging 環(huán)境的 bug fix 在 spark-src.git/dev 上進(jìn)行，生產(chǎn)環(huán)境的 hot fix 在 spark-src.git/prod 上進(jìn)行，清晰明了
- bug fix 提交時(shí)的 code base 與 Staging 環(huán)境使用版本的 code 完全一致，從而可保證 bug fix 的正確性
- bug fix 合并回 spark-src.git/master 時(shí)使用 rebase，從而保證了 spark-src.git/dev 與 spark-src.git/master 所有 commit 的順序與內(nèi)容的一致性，進(jìn)而保證了這兩個(gè) branch 的一致性
- hot fix 提交時(shí)的 code base 與 生產(chǎn)環(huán)境使用版本的 code 完全一致，從而可保證 hot fix 的正確性
- hot fix 合并回 spark-src.git/master 時(shí)使用 rebase，從而保證了 spark-src.git/dev 與 spark-src.git/master 所有 commit 的順序性及內(nèi)容的一致性，進(jìn)而保證了這兩個(gè) branch 的一致性
- 開(kāi)發(fā)人員只需要專注于新 feature 的開(kāi)發(fā)，bug fix 的提交，與 hot fix 的提交。所有的版本維護(hù)工作全部自動(dòng)完成。只有當(dāng) bug fix 或 hot fix rebase 回 spark-src.git/master 發(fā)生沖突時(shí)才需人工介入
- spark-bin.git/dev 與 spark-bin.git/prod 將開(kāi)發(fā)版本與生產(chǎn)版本分開(kāi)，方便獨(dú)立部署。而其路徑統(tǒng)一，方便版本切換與灰度發(fā)布
Cons.
- 在本地 spark-src.git/master 提交時(shí)，須先 rebase 遠(yuǎn)程分支，而不應(yīng)直接使用 merge。在本方案中，這不僅是最佳實(shí)踐，還是硬性要求
- 雖然 bug fix 與 hot fix commit 都通過(guò) rebase 進(jìn)入 spark-src.git/master。但發(fā)生沖突時(shí)，需要相應(yīng)修改 spark-src.git/master上后續(xù) commit。如上圖中，提交紅色 commit 9 這一 hot fix 后，在 rebase 回 spark-src.git/master 時(shí)，如有沖突，可能需要修改 commit 2 或者 commit 3、4、5。該修改會(huì)造成本地解決完沖突后的版本與遠(yuǎn)程版本沖突，需要強(qiáng)制 push 回遠(yuǎn)程分支。該操作存在一定風(fēng)險(xiǎn)
Spark CD 持續(xù)部署
持續(xù)部署是指，軟件通過(guò)評(píng)審后，自動(dòng)部署到生產(chǎn)環(huán)境中。
Continuous Deploy
上述 Spark 持續(xù)發(fā)布實(shí)踐的介紹都只到 "將 *** 提交到 spark-bin.git" 結(jié)束?？墒褂没?git 的部署(為了性能和擴(kuò)展性，一般不直接在待部署機(jī)器上使用 git pull --rebase，而是使用自研的上線方案，此處不展開(kāi))將該 release 上線到 Staging 環(huán)境或生產(chǎn)環(huán)境
該自動(dòng)上線過(guò)程即是 Spark 持續(xù)部署的最后一環(huán)。
