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

語言: CN / TW / HK

大家好,我是山西數智時代科技有限公司的趙佳鵬,我們公司成立於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 在未來能再接再厲做的更好。