雲原生落地實踐：山西數智時代基於 Rainbond 實現智慧景區

大家好，我是山西數智時代科技有限公司的趙佳鵬，我們公司成立於2018年，專注於智慧旅遊、景區資訊化建設。公司目前的主要產品有小悠出行管理系統、景區數字化執行管理系統、鼎雲校園擺渡車運營管理系統、行車資訊管理及流轉系統、覓四方商城系統等，是集智慧旅遊規劃、設計、建設、運營為一體的旅遊全產業鏈服務商。

智慧景區的整體架構

最早我們的業務是單體服務，單體服務最大的問題就是業務無法解耦，抗併發能力不高。業務升級為微服務架構之後解決了業務之間的解耦，提升了業務的抗併發能力，升級微服務架構之後也增加了很多新功能，比如實時分賬、套票的支援，多種渠道的購票融合，支付安全性、搶購、活動等都帶來了一定的複雜度，在檢票的時候要保證多個渠道的庫存、票狀態要實時同步等對技術上有一定的要求。 單體服務到微服務也是一次巨大的挑戰，伺服器成本、人員成本、單體業務解耦、服務劃分、運維等方面都存在很多問題。

存在的技術問題：

• 資源利用率，以前伺服器都是每臺上邊部署幾個專案，比如有臺伺服器 CPU、記憶體、磁碟等資源很多，但另一臺伺服器資源又很少，資源多的伺服器沒法完全利用起來，資源少的伺服器滿了之後就沒辦法再部署業務，這會導致大量資源無法有效的完全利用。
• 運維方式不統一，以前部署專案的時候多個專案組都是各自部署各自專案，各自部署方式不一樣一會用主機方式，一會用映象方式，每次需要找日誌的時候都要查詢半天，伺服器上邊的資料夾也是建立的亂七八糟的，沒有統一的部署方式導致出問題後需要巨大的成本。
• 專案環境重複部署，之前伺服器上會部署多個專案，每個專案環境都是各自專案組成員負責，導致環境不統一，有的中介軟體需要部署好幾遍，Nginx 也是部署了很多不同的版本，浪費了大量的時間去做了相同的事情，加大了運維成本。
• 部署成本高，之前用 GitLab CI/CD 部署專案時需要寫大量的 YAML 配置，同時還要解決 HTTP、HTTPS 訪問，證書每次都需要去手動生成，然後再拷貝到伺服器上，出現問題再一遍一遍的去改配置，YAML 語法也需要每個專案組的成員去學習，導致專案的成本提高。

雲原生平臺選型

採用微服務架構之後，我們決定全面轉向容器化、雲原生方向，所以我們需要一個對開發者友好、視覺化部署、自動構建、易用的一個雲原生 PaaS 平臺。

在選擇 Rainbond 之前也使用過其他開源 PaaS 平臺，由於公司沒有專業的運維人員，在使用的時候發現對程式設計師都不是很友好，還是脫離不了 YAML 的編寫，學習成本太高，沒有很好的擴充套件功能，後來瞭解到 Rainbond 後發現對程式設計師特別友好，不需要寫大量的 YAML 檔案，通過介面化配置就能部署專案，而且官方文件很完善，部署例子也很多，操作簡單，功能也能滿足公司的需求。

使用 Rainbond 承載所有業務場景

在雲原生架構之前，多臺伺服器的單獨運維和部署複雜度高、資源利用率低、重複操作率高，對於線上專案的成本很大，線上服務出問題後無法及時的判斷問題出在哪個服務上，需要人工先找服務在哪臺伺服器，然後在通過一系列命令去檢視等等。

在轉向使用 Rainbond 雲原生架構後，由 Rainbond 統一管理伺服器、排程資源，而我們只需要管理業務，降低了運維成本。以及相關運維操作都可以通過介面化實現，比如通過拓撲圖就可以看到所有服務執行情況，哪個服務出現異常清晰明瞭，業務相關日誌可以通過日誌介面輕鬆檢視，並且有歷史日誌儲存等等。

整體上對於我們來說降低了專案的成本，相應的為公司帶來的利益就比之前多了很多。

使用 Rainbond 的最佳實踐

• 專案團隊管理，公司不同專案會有不同的小組負責，這個功能就可以完美的解決這個問題，可以單獨設定許可權、叢集資源。

• 程式碼倉庫對接和快速部署，公司用的華為雲的程式碼倉庫，在 Rainbond 上可以直接填倉庫地址，然後通過原始碼直接構建部署，同時還支援 Maven多模組的批量構建，公司大部分專案都是多模組專案，用了這個功能之後比之前效率高了很多。
• 測試環境一鍵複製到其他環境，Rainbond 可以將測試環境的應用快速複製到其他環境中，省去了再次部署的問題，在之前不同環境都需要部署一次，用了這個功能後只需要部署一次，然後就可以快速複製到不同環境中。
• 視覺化服務編排，專案部署成功以後可以通過視覺化的方式進行服務編排，這個功能是我在其他 PaaS 平臺沒有看到的，之前服務編排需要寫大量的 YAML 檔案，現在可以直接使用滑鼠一拉一拽就可以完成，而且還是根據元件依賴情況按順序啟動。

使用 Rainbond 總結

從2022年8月份使用 Rainbond 到現在半年多的時間裡，明顯感覺到在專案的開發效率上提升了很多，之前每次重複的工作現在只需要幹一次，運維上也方便了很多，直接介面化配置，比起之前寫大量 YAML 檔案省去了很多時間成本，在運維上省去的時間現在都用來開發專案，修改BUG了。

架構轉變為雲原生架構的這段時間裡，發現了它的很多優點:

• **快速迭代，**在 Rainbond 上進行開發，使開發團隊可以使用自動化能力和編排來快速迭代，讓開發人員有更多的精力聚焦於業務開發上。
• **自動部署，**雲原生方法遠優於傳統的面向虛擬化的業務流程，傳統方法需要投入大量的精力來構建開發環境，以及軟體交付過程中的其他不同環境。而云原生架構具備自動化和組合功能，並且依賴於可靠、經過驗證和稽核的已知良好流程的基礎，交付十分敏捷，而不再需要人工干預重複執行。
• **獨立高效，**雲原生帶來了微服務化架構，一個微服務基本是一個能獨立釋出的應用服務，因此可以作為獨立元件升級或複用等，對整個大應用的影響也較小，每個服務可以由專門的組織來單獨完成，依賴方只要定好輸入和輸出口即可完全開發、甚至整個團隊的組織架構也會更精簡，因此溝通成本低、效率高。
• **遮蔽底層差異，**Rainbond 雖然建立在 K8S 之上，但遮蔽了很多 K8S 的知識以及底層硬體的差異化，而我們的開發人員就不需要考慮應用對於底層硬體的差異，也不需要學習更多的容器知識，只需要專注於業務即可。同時對運維人員也非常友好，不需要再為環境問題而苦惱。

在未來我會更深入的瞭解雲原生和不斷地嘗試 Rainbond 帶來的新功能。

給 Rainbond 的建議

談談自己的感受吧，我在測試環境部署 Rainbond 也是部署了很多遍，每次都會遇到不同的問題，不過還好，Rainbond 社群支援比較給力，每次都能及時幫助解決，不過還是建議部署文件再繼續完善下。到了生產環境部署Glusterfs 叢集儲存的時候也發現了問題走不下去，希望社群也能解決下 Glusterfs 的問題或者引入其他儲存的解決方案。還有自動簽發證書的功能，只支援 ACME 去簽發，由於公司使用的是華為雲的域名，Rainbond 社群 的 ACME 服務不支援華為雲 DNS 導致無法使用這個功能，希望社群能支援範圍更廣的 ACME 去做 SSL 證書籤發。

最後還是很感謝 Rainbond 這個產品以及社群的幫助，用了這個產品之後實實在在從根本上解決了很多問題。希望 Rainbond 在未來能再接再厲做的更好。