藏書館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 控制檯地址>/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，下一階段我們打算嘗試一下。