藏書館App基於Rainbond實現雲原生DevOps的實踐
我們需要的不是精通Kubernetes的工程師，我們需要一款小白都能用好的管理工具。
—— 廈門正觀易知科技有限公司運維負責人 郭傳壕
大家好，我是廈門正觀易知科技有限公司運維負責人郭傳壕。
藏書館是一個專注用戶自我成長的雲端私人圖書館，集電子書的讀、薦、借、購、存和知識管理功能於一體，致力於用戶的認知賦能，通過讀書習慣的養成，達成自我成長。目前累計註冊用戶已達 1500W ，平臺圖書資源超過200W冊。
我們使用Rainbond已經有2年，我把我們的使用經驗分享給大家。
1.以前的困局
處於雲原生時代中的藏書館的起點很高，我們一開始就選定了微服務架構、Kubernetes、容器化等符合時代潮流的技術體系。然而原生的kubernetes 管理平臺提供的功能並不完全符合我們的預期，二次開發的巨大技術成本也是我們負擔不起的。
在瞭解到 Rainbond 之前，處於創業初期的我們一直受困於產品迭代變更頻繁所帶來的瑣事之中。我所說的瑣事包含微服務架構下50個服務的版本管理、構建產物的更替、線上環境的發佈以及圍繞着應用從開發到上線再到運維的種種繁瑣工作。
我們希望可以從這些瑣事中跳脫出來，專注於業務本身，探索出一條適合kubernetes環境下持續開發、持續交付的簡捷之路。
鑑於此，我們開始積極的尋找一款開源且易用的應用管理平臺。
2.初識 Rainbond
在 Rainbond 之前，我們已經嘗試過了 Rancher 等產品，但產品功能和我們的預期有很大差距。
2 年前，我們通過 Github 第一次瞭解到了 Rainbond 這款產品，驚喜於功能非常契合藏書館的需求。列舉幾個令人印象深刻的能力：
- 應用架構的整體拓撲圖
以上帝視角，一覽無餘的觀測到所有服務組件的運行狀態與依賴關係。強迫症會逼着我們的工程師消滅紅色的異常狀態，而體現運行狀態的綠色真的令人感到安心。
- 可視化的資源佔用情況
資源佔用情況是體現可觀測性很重要的指標。對於初創公司而言，瞭解資源分配是否合理，杜絕資源浪費是很重要的。Rainbond 從團隊到服務組件的每個維度都提供了良好的可觀測性。團隊級別的資源限額能力非常實用，解決了運維團隊無法有效掌控資源分配的難題。
- 自動伸縮
藏書館是一個典型的 2C 場景，如何利用好雲計算提供的彈性，靈活的應對流量高峯呢？答案就是使用自動伸縮功能。Rainbond 提供的自動伸縮功能，突出了簡單易配置的特點。自動伸縮能力極大的解放了運維團隊的工作壓力，從此遠離興師動衆和嚴陣以待。關鍵業務會隨着我們的心意，自動擴張，直到能夠吞吐所有流量。
- 集中式的網關策略管理
2C 場景下的服務發佈，是無論如何也繞不過去的坎兒。無論是藍綠髮布、灰度發佈抑或是A/B測試，這服務發佈相關的十八般武藝多少都會碰到。原生的 Kubernetes Ingress 的確可以實現這些發佈策略，但是我們更希望得到一個產品化的集中式管理頁面來處理這些問題，而不是去麻煩運維工程師們去碰那些格式嚴苛的Yaml文件。Rainbond 網關策略管理完美的實現了我們的需求。
- 應用複製快速生成環境
在藏書館的開發流程中，我們時常需要搭建各種環境，來區分開發、測試、預發佈場景，分別對應不同版本的微服務組件，比如Dev、Prod之類的。但如果每次生成環境都要手動創建服務組件，那真的太低效了。應用複製功能在這個場景下非常有用，它幫助我快速複製出一套環境出來。複製過程中自助選擇構建源的版本，對我而言是鏡像的 Tag。複製後的新環境，保留了所有的服務組件元信息以及依賴關係。
在逐步的探索過程中，和官方團隊在社區中進行的互動，讓我們少走了很多彎路。一款開源產品如果伴隨着有生命力的社區，將會是非常令人安心的。
3.開發測試環境部署
第一步，部署微服務
上手 Rainbond ，是從部署單個微服務開始的，這個過程非常簡單，不需要學習Kubernetes的 Yaml 。開發環境中的組件是基於鏡像構建完成的，只需要按界面的引導填寫好鏡像地址及相關信息就可以了。
我們用的是 Spring Cloud 微服務框架，在 Rainbond 體系下可以很好的運行，我在部署過程中受到了一系列文檔的影響，這裏分享給大家:
- Spring Cloud 微服務部署在 Rainbond 的優勢
- Spring Cloud 微服務與 Service Mesh 的融合
- Spring Cloud 微服務部署在 Rainbond 的案例
第二步，通過可視化的方式服務編排
在編排微服務的過程中，基於圖形化編輯組件依賴關係這個功能，着實驚豔了我。這種編排方式和其他平臺基於複雜 Yaml 文件進行編排的方式有極大的不同。感興趣的小夥伴們可以閱讀下服務編排相關的描述，這的確是一種小白都可以掌控的微服務編排方式。
第三步，對接外部的服務
對於我們這樣一個初創公司而言，將數據庫等服務託管給雲服務商，直接使用 RDS 服務是個既經濟又穩健的選擇。在 Rainbond 體系中，我通過添加第三方組件的方式將位於雲端的 RDS 服務納入管理之中。這種納入讓第三方服務也像部署在平臺之中一樣，可以被其他微服務組件所依賴。
至此，我的開發環境就已經部署完成了。
第四步，複製出了測試環境、預發佈環境和生產環境
在以往的開發過程中，搭建環境是一個很繁瑣的事情。對一個處於快速迭代過程中的產品而言，我們至少需要開發環境、測試環境、生產環境，在我們自己的實際場景中，還引入了預發佈環境。對於代碼而言，我僅需要 Fork 出多個分支，來區分不同環境即可。通過定義流水線，我們也已經完成了不同代碼分支打包鏡像的不同 tag。但是到了搭建環境這一步，難道就只能根據不同的鏡像 tag ，手動一點點的創建組件？想到藏書館業務的近 50 個微服務組件，和彼此間的依賴關係，我的頭就很大，IT 從業者最不能忍受的就是重複工作。
在探索 Rainbond 使用方法的過程中，快速複製這個功能一下子抓住了我的眼球。快速複製功能可以檢出所有組件的構建源信息，對於源碼構建的組件，構建源就是它的代碼倉庫地址、編程語言、代碼分支；而對於鏡像構建的組件，構建源則對應了鏡像地址和 tag。在這樣一個界面下，我可以選擇需要被複制的組件，修改其 tag 版本。這樣的複製能力可以實現環境在不同集羣、不同團隊下的複製。新的環境繼承了原環境中除鏡像 tag 以外的所有設定：依賴關係、組件名稱、環境變量配置、持久化設置等等。
利用這個能力，我基於開發環境，像Fork一份代碼一樣，通過修改 tag 的方式複製出了測試環境、預發佈環境和生產環境。
這一能力極大的節約了我們使用 Rainbond 時，部署各種環境的時間成本。目前，我們也把這一功能用於新人的開發環境搭建，以前手把手教新人如何搭建自己的開發環境是很費心費力的事情。
4.串通持續交付流程
早前，我們已經藉助 Jenkins ，自定義了一套完整的流水線，來實現所有微服務組件的構建。最終的構建產物會被定製爲鏡像推送到鏡像倉庫中去。我們對這一部分的工作是比較滿意的，我們希望 Rainbond 能夠在鏡像倉庫之後集成進來，完成微服務組件的持續構建與部署。
Rainbond 在這一部分是非常開放的，提供了接口來實現與第三方 CI 工具的對接。我們只需要在 Jenkins 的流水線完成鏡像推送後，添加一個步驟簡單的調用下 Rainbond 提供的接口，對應的微服務組件就會自動拉取最新的鏡像，完成上線操作。到目前爲止，整個技術團隊都已經適應了這種使用方式。
實際上這是一個很通用的接口調用方式，無論對接哪一種第三方CI工具，都可以很方便的調用。
每一個運行在 Rainbond 上的微服務組件，在構建源處都可以打開自動構建的設置。自動構建設置有兩種實現：
- 基於 Git-Webhook ，針對基於源代碼構建的微服務組件，可以藉助代碼倉庫的 Webhook 能力，實現代碼一推送，就觸發該服務組件自動構建並上線的效果。支持的代碼倉庫類型比較廣泛，GItlab、Github、Gitee、Gitea等代碼倉庫都支持。
- 基於鏡像倉庫 Webhook ，針對基於鏡像構建的微服務組件，可以藉助鏡像倉庫的 Webhook 能力，實現鏡像一推送，就觸發該服務組件自動構建並上線的效果。Harbor、Dockerhub等鏡像倉庫都支持 Webhook 功能。
- 自定義API，這是最通用的接口調用方式，用戶只需要基於 Http 協議調用，即可觸發該服務組件的自動構建並上線。
觸發上圖中的自動構建 API，最簡單的方式是在命令行中執行一條命令：
curl -d '{"secret_key":"6GvowlHX"}' -H "Content-type: application/json" -X POST https://<Rainbond控制檯地址>/console/custom/deploy/c4e7b60bd800986df940d8103f22d271
目前，我們已經可以做到以很簡單的方式，精確觸發到指定的流水線，完成對應微服務組件的更新上線。
5.其他通過Rainbond解決的問題
隨着對 Rainbond 這款產品認識的不斷加深，我們開始不斷拋卻一些瑣事，一些傳統部署模式下難以規避的問題，藉助 Rainbond 的能力都得以很好的解決：
- 內部依賴配置無法查詢
傳統部署模式下，所有組件之間的相關依賴，都是寫在配置文件中的一系列配置。對產品整體沒有足夠了解的工程師很難掌握所有依賴項的引用地址，寫錯 IP 導致調用不通的失誤時有發生。藉助應用拓撲圖的展現，現在每一個新手工程師，在看到拓撲圖之後，都會立刻對產品的整體結構產生直觀認識。
- 多實例部署異常後排查不便
傳統部署模式下，每個微服務組件如果需要多實例部署，都需要工程師們手動操作服務器上傳jar包進行配置。如果遇到升級調整，偶爾還會錯漏。一旦出現問題需要排查，如何定位正確的實例就已經很麻煩了。Rainbond 環境下，每個微服務組件的多實例版本一致性不需要關心，而出問題排查時，實時日誌推送和Web控制檯都幫了大忙。
- 服務器資源不能共享
傳統部署模式下，我們通過劃分虛擬機來避免計算資源的浪費，然而這還不夠。我們希望計算資源能夠完全池化，面向每個微服務組件來劃分。這一點所有基於 Kubernetes 實現的應用管理平臺都可以實現。而 Rainbond 的伸縮設置，是我見過產品化做的最好，最易用的。Rainbond 平臺上線後縮減了三分之二的服務器資源。
- 相同監聽端口不能同臺部署
端口其實也是一種重要的資源，同個操作系統下，端口的佔用是不可以衝突的。這個問題在大規模微服務組件部署時顯得尤爲突出。Rainbond 這一點做的很好，每個微服務不會直接佔用服務器端口，我們的開發人員可以更自由的定義組件監聽了。
- 開發人員權限管理
真實的業務場景下，軟件系統本身的問題並非都由運維人員處理，更多的情況下需要開發者本人排查和處理。而權限管理則要求開發人員儘可能不具備登錄生產服務器的權限。這就導致了一個兩難的問題，快速解決問題還是嚴格管控權限？這是開發人員和運維人員容易產生衝突的點。引入 Rainbond 之後，這個問題得到了很好的解決，開發人員的所有操作都是在 Rainbond 管理界面進行的，即使需要通過命令行排查問題，也可以通過 Web 控制檯登錄容器環境，而不是宿主機服務器。目前，我們已經形成了應用開發人員基於 Rainbond 運維自己開發微服務組件的模式。
- 應用版本回滾
傳統模式下，微服務組件的部署有多複雜，那麼回滾到上一個版本就只會更復雜。Rainbond 這款產品非常貼心的提供了服務組件級別的一鍵回滾，管理人員可以在版本列表之中隨意選擇需要的版本，進行一鍵回滾，這真的太方便了。
6.寫在最後
和使用其他產品一樣，深入使用 Rainbond 也是需要一些磨合過程的。令我印象深刻的一個情況，是 Rainbond 使用的 Glusterfs 分佈式文件系統，在經過很長一段時間的使用之後，存儲容量被用盡，導致了一系列問題。我們的運維人員缺少對 Glusterfs 的瞭解，對 Rainbond 如何與 Glusterfs 相互作用更是一知半解。無奈之下求助官方，出乎意料的是官方的工程師非常熱心的支持我們解決了問題，並貼心的留下了操作文檔。
我對 Rainbond 最大的感觸是其易用性做的很好。希望 Rainbond 團隊可以將這一點貫徹到底，提供更多能夠解決實際問題的實用特性。我們瞭解到Rainbond的Service Mesh下一步可以支持istio，下一階段我們打算嘗試一下。
