編者按：本文來自微信公眾號“KodeRover”（ID:KodeRover），作者：新之助，36氪經授權發布。

我們深度認同 Zadig的設計理念，并且認為 Zadig 真正意義上解決了微服務集成測試的痛 點。 Zadig 毫無疑問是業界優秀的 CI/CD 產品，它也是真正理解微服務、重視微服務、解決微服務痛點的產品。 

我們充分感受到 Zadig 的優秀設計思想是非常值得字節 DevOps 團隊借鑒學習的，相信 Zadig 會有更美好未來！”                         

                                                                 - 飛書高級 SRE 工程師：  新之助 

字節跳動的飛書是整合即時溝通、視頻會議、日歷、云文檔、OKR、企業郵箱、服務臺等功能于一體的新型辦公軟件。飛書設計理念先進，功能齊全，而且性能穩定：她不僅是字節跳動高效增長的引擎，也正成為越來越多優質企業的辦公協同必備軟件。你知道嗎，飛書軟件的快速迭代的神秘助手之一正是 Zadig！這篇文章，飛書 SRE 工程師新之助就來和大家分享飛書和 Zadig 當初是如何相中彼此的。 

以下為“新之助”分享的案例，供大家參考 

 背景

飛書的整體技術架構承接字節基礎架構，以微服務為核心，運行在大規模自研容器平臺TCE（起源于Kubernetes）之上。飛書音視頻部門成立于 2018 年中旬，早期的團隊成員對 Go 語言和微服務的最佳實踐在認知上有比較明顯的不足。在經歷了近一年半的迭代中，我們才逐步探索出一套勉強適用于團隊的 Workflow，但與此同時也積累了較重的技術包袱。

首先需要聲明的是，對于飛書這樣一個 to B 的產品來說，質量和穩定性極為重要。因此數據監控和自動化測試是產品的生命線，本文不討論數據監控的具體實踐，主要是闡述自動化測試的演進之路。 

在最早期從 0 到 1 的階段，音視頻服務端的業務側實際上只有 1 個單體服務，該服務簡單依賴少數外部的飛書 IM 服務（例如賬號服務、卡片服務、消息服務等），存儲也只包括 MySQL和 Redis。我們花費了一些時間討論單元測試和功能測試的實現路徑，并且快速得到了有效的反饋，這一切在只有1個單體服務的情況下非常簡單。 

最終方案概述起來大致是：Mock 外部 RPC 接口返回值，存儲層 MySQL/Redis 使用 Docker 容器，通過原生的 go test 加上 assert 工具包輔助進行單元測試和功能測試。此處單元測試和功能測試的主要區別是：功能測試會要求該單體服務啟動運行之后，模擬客戶端請求發向服務，專注于測試接口級別的功能完整性。 

進一步地，在定制了一套 CI 流水線之后，整個初步的 Workflow 便形成了。 

然而由于對微服務的拆分原則缺乏系統性的認知，我們在接下來的一年中迎來了爆炸式的服務數量增長。這里面除了業務增長所必須要新增的服務之外，更多的是為了方便不同Owner 維護而獨立出來的“冗余”服務。但從長期來看，微服務數量增加是必然現象。 

此時，早期設計的單元測試作用越來越小，功能測試更是已經名存實亡。由于每個服務都存在數量不小的外部依賴，尤其是需要多個 RPC 串聯的時候，大量的 Mock 接口不僅脫離真實業務場景，而且維護 Mock 本身的邏輯也有非常高的成本。在業務的快速迭代中，外部接口同樣日新月異，變化速度之快，使得編寫功能測試用例幾乎成為不可能的事情。 

我們終于意識到需要徹底拋棄 Mock，提供一種能力串聯所有的微服務，做端到端的集成測試，這才是未來的發展方向。 

恰逢此時的飛書進入發展新階段，在更大的戰略方針上面首次提出所有飛書服務需要支持私有化部署。這是一個重要契機，讓我們開始全面思考開源的技術方案。 

因此，在私有化部署和集成測試兩重動力驅動之下，我們正式立項探索可行的解決方案。 

探索期

2019年底，在經過一輪簡單的討論之后，我們決定先從問題的簡化版開始探索：搭建一個All In One 的環境，將目前已經存在的音視頻微服務全部部署在該環境中，并且彼此之間能夠互相訪問。我們后來將這個環境命名為 OneBox。 

OneBox 若能實現將會帶來兩個重要作用： 

理清字節云依賴。在 OneBox 的落地實踐中，我們必然會逐步梳理清楚現有代碼中哪些強依賴字節云上環境，從而在私有化部署的場景中改造或者移除。

微服務集成測試。OneBox 真正搭建完成之后，我們可以利用整個環境當做微服務集成測試的基準環境，微服務的整體集成測試也就具備落地的可能性。

由于生產環境中的服務是運行在 TCE 上面的（字節自研 Kubernetes 引擎，但強依賴字節云上環境），因此我們第一直覺就是考慮基于原生 Kubernetes 的私有化部署方案。 

我們申請了一臺配置優秀的物理機，快速搭建了  Rancher  和 Rancher Kubernetes 集群。然后 case by case 的分析每個音視頻服務的依賴，進行逐步改造：例如將原本依賴于字節 debian 基礎鏡像改造成依賴于開源 debian 基礎鏡像、將原本依賴字節云 MySQL/Redis/ES/Kafka/RocketMQ 的 go-driver 改造降級成開源版本、服務之間的調用方式從原本字節統一的 Consul 改造成原生的 Kubernetes Service 等等。 

我們迅速在原生 Kubernetes中 啟動了一個又一個微服務，并且微服務之間完全互通。然而正當我們以為一切順利的時候，卻還是遇到了致命問題：存在某些字節自研的存儲組件沒有容器化，而服務卻強依賴該存儲組件。

也正是這個原因最終影響了飛書私有化部署的整體方案，我們不可能完全改造成開源存儲，而字節存儲的云原生化還在逐步規劃當中。 

最終飛書的私有化部署方案基本如下（IaaS+PaaS+SaaS 一體化）： 

綜上所述，飛書私有化部署的整體方案和產品形態都是非常重量級的。但是 OneBox 的探索之路仍然要繼續下去，因為我們還需要 OneBox 來完成音視頻微服務的集成測試。 

不同于飛書私有化部署這個目標，我們還存在另一個致命的制約因素：飛書音視頻業務本身無法閉環。我們的集成測試雖然是聚焦于音視頻業務的，但飛書的業務本身是一體化無法分割的，因此我們必然要依賴飛書其它部門的微服務。 

正是由于無法閉環，因此最早期設計功能測試框架的時候，我們以 Mock 作為解決方案。但正如我上面所說，Mock 接口返回值的做法在快速迭代的微服務架構中是 ROI  極低的做法。 

我們最終思考許久之后，做出了兩大決策： 

對于飛書服務的外部依賴復用字節云上統一測試環境（該環境名為 staging，是在字節云上面飛書整體的測試環境，數據庫與生產環境完全獨立）。

對于無法容器化的存儲組件復用字節云上的存儲，我們形象稱之為外掛。

上圖所示的 Staging 是字節 云上面的飛書測試環境。 而 OneBox 則是音視頻業務的All In One環境。 

OneBox 里面的計算層都是基于原生的 Kubernetes。常規服務指使用常見的開源存儲組件，如：MySQL/Redis 的服務，可以通過部署 MySQL/Redis StatefulSet 到 Kubernetes。特殊服務指使用字節自研存儲組件，只能通過外掛方式去訪問。 

對于 OneBox 依賴 Staging 飛書其它部門的服務，我們不通過 Mock 完成，而是直接發送真實的 RPC 請求。 

決定 OneBox 架構之后，下一步要解決的核心問題就是 工具選型 ，我們認為工具是非常重要的。我們需要快速復刻多個 OneBox 作為基準測試環境，對于每個服務代碼倉庫的每次改動提交去部署其中某一個基準環境，再發起上游的集成測試用例。 

一開始我們在工具選型上面主要考慮的是： 

• Jenkins
• Gitlab CI
• Rancher CI

當時本人并不知道 KodeRover 的產品 Zadig （開源之后的名字，下文統一用 Zadig 這一名稱），后來 在同事的推 薦之下也納入調研范疇。不過我們幾乎在理解 Zadig 之后就迅速敲定了它。 

Zadig 最吸引我們的特性是： 

• 快速創建環境。Zadig基于 Kubernetes Namespace能夠一鍵快速復刻環境，這一特性正是我們最需要的。
• 微服務啟動順序。Zadig 允許我們為微服務指定啟動順序，解決了我們處理微服務之間依賴關系的問題。
• 代碼倉庫集成。Zadig 同時支持 Gitlab 和 Gerrit，非常符合字節的技術棧。

相比之下無論是Jenkins、Gitlab 還是 Rancher 本身都不涉及微服務的概念，它們是面向更加通用的場景而設計的。 

運行期

我們 深度認同Zadig的設計理念 ，并且認為 Zadig 真正意義上解決了微服務集成測試的痛點。 

但因為 TCE（字節自研 Kubernetes 引擎）和原生 Kubernetes 的差異巨大，我們無法通過 Zadig 來管理TCE。因此，我們將 Zadig 定位成 音視頻微服務集成測試平臺 。 

飛書音視頻服務端的整體發布模型是基于  Gitlab Flow ： 

對于非核心服務，我們采用單分支模型：master 發版。對于核心服務，我們采用雙分支模型：master 發版測試環境和 online 發版生產環境。 

Zadig在飛書實踐中的位置大致如下： 

有了 Zadig 的集成測試能力，我們對進入 Master 分支的改動更加自信，整體帶來的收益也比較大。 另一方面，Zadig 簡約清爽的 UI 設計讓我們非常喜愛這個平臺，因此我們在后續的工作中也接入了很多不包含服務部署只利用 Zadig 定時任務的一些工作流。 

結語

Zadig 毫無疑問是業界優秀的 CI/CD 產品 ，它也是真正理解微服務、重視微服務、解決微服務痛點的產品。 

我們充分感受到 Zadig 的優秀設計思想是非常值得字節 DevOps 團隊借鑒學習的，相信Zadig會有更美好未來！ 

 關于 Zadig

通過在包括頭條、騰訊、七牛云、非碼等企業的多年上千次迭代，今天的 Zadig 已經成為微服務 + Kubernetes 技術棧團隊的最佳研發交付方案，同時無縫兼容任何研發團隊現有交付工具鏈和研發流程，無縫集成 GitHub/GitLab、Jenkins、多家云廠商，幫助團隊一步到位打造強大的 DevOps 和 CI/CD 工程基建能力，變云原生為生產力。 

Zadig 本身是基于 Kubernetes 設計、研發的開源分布式持續交付 (Continuous Delivery) 產品，為開發者提供云原生運行環境，支持開發者本地聯調、微服務并行構建和部署、集成測試等。Zadig 內置了面向 Kubernetes、Helm、云主機、大體量微服務等復雜業務場景的最佳實踐，為工程師一鍵生成自動化工作流 。 

歡迎參與開源

歡迎大家 Star、Fork、 Watch！ 和眾多開發者一起探討、交流，共建開源社區！