背景
大家好，我是北京數立通科技有限公司的李棟。最近幾年，我一直負責“智慧鉅鹿”這一智慧城市專案的執行與維護工作。這個專案涉及到10多家供應商開發的 30 多套智慧城市應用的運維管理，使用傳統方式進行部署與管理肯定會造成混亂。我們在專案開始之初，就試圖藉助雲原生相關的技術來提高部署與管理效率。
初識 Rainbond
選型的目光，在一開始就落在了基於容器化技術實現的 Kubernetes 和 Docker Swarm 這兩個編排工具上。那時候國內應用雲原生技術的場景還很少，專案組內的運維工程師們也並不是很擅長容器化等相應技術。為了進一步瞭解這些編排工具，我發動了工程師們分別去進行調研，當我拿到調研結果時，尷尬的發現光是這些編排工具的安裝方式，每個工程師帶回來的方案都不一樣。雲原生的入門門檻之高，出乎我的意料。
退而求其次，我決定引入一款方便工程師們上手的應用管理平臺，來代替運維工程師完成和 Kubernetes 等編排工具的複雜互動工作。至此， Rainbond 第一次進入我的視野。
上手 Rainbond
我算是 Rainbond 的老使用者了，從 3.X 版本開始就一直在使用它來管理智慧鉅鹿專案的所有智慧城市應用。目前，共計有 30 多套智慧城市應用穩定執行於兩個 Rainbond 叢集中，我們正致力於將智慧城市應用從較老的 3.X 版本 Rainbond 叢集遷移至比較新的 5.X 版本 Rainbond 叢集中。
回想最初開始使用 Rainbond 時，其易用性給我留下了深刻的印象。我們的工程師不再需要直接面對學習門檻極高的 Kubernetes ，甚至連將智慧城市應用進行容器化的操作流程也不需要關注，Rainbond 自帶的原始碼構建功能直接接手了容器化工作。
經過兩年多的執行，Rainbond 的穩定性也令人滿意，目前智慧鉅鹿專案團隊已經完全掌控了這款應用管理平臺。
最有價值的場景
使用 Rainbond 這幾年，我認為給它帶來了很多價值點：
- 穩定性保證
真正能夠讓 Rainbond 在智慧鉅鹿專案中紮根的，是它體現出的穩定性，產品本身沒有嚴重的BUG，老版本中的一些小毛病團隊也都已經克服。作為一款執行在智慧城市資料中心中的應用管理平臺，穩定性的重要程度是要高於其他因素的。在這一點上，Rainbond 表現的很好，即使遭遇了宿主機伺服器當機，應用也可以自動故障遷移、快速恢復。出了問題的宿主機，在問題修復之後，也可以自動重新加入叢集。
- 便捷的圖形化管理介面
作為智慧城市資料中心的應用管理平臺，它輔助我們管理了所有智慧城市應用。藉助圖形化的介面，運維工程師可以很方便的針對這些應用進行操作，包括啟停、編排、伸縮等。由於不必編寫複雜的 Yaml 配置檔案，也沒有命令列互動，智慧鉅鹿專案團隊的工程師們都得以很快上手。
- 突出的易用性
我認為易用性是 Rainbond 最大的特點。它以應用為核心抽象，圍繞應用所設計的諸多功能都十分有用。比如自動伸縮、健康檢測等都是非常實用的功能。閘道器策略的配置也非常友好，操作難度基本為零，繫結域名匹配證書都非常方便。
- 合理的可觀測性
Rainbond 提供了全面的監控報警系統，無論是計算資源還是上層的應用系統，一旦出現問題都可以很快暴露出來。結合自動化運維能力，問題應用系統可以做到自愈自恢復。而通過觀察應用系統訪問量和資源消耗情況，可以更合理的進行資源分配工作。
- 補足供應商管理流程
智慧城市應用來自於很多不同的供應商，在以往使用傳統模式部署與運維時，每一家供應商的套路都不一樣。這種不同不僅僅體現在開發語言、技術架構上，也體現在具有各自不同的部署方式與運維管理方式。這可苦了我們的運維管理人員，接手的每一套智慧城市應用的運維管理方式都不一樣。
這樣的境況在引入 Rainbond 之後好了很多。運維管理團隊依靠 Rainbond 建立起一套專門針對外部供應商的准入機制，利用統一的規範管理所有智慧城市應用，極大提高了管理效率，也使得運維管理團隊可以在脫離供應商支援的情況下，將智慧城市應用管理的很好。目前的管理模式，是將供應商准入環境與最終生產環境按照團隊的方式隔離開，供應商開發人員，僅需要關注業務程式碼的開發過程，智慧鉅鹿運維管理團隊，會根據程式碼將業務上線到生產環境中去。真正落地了開發與生產隔離的管理方式。
總結
我在智慧鉅鹿專案中引入 Rainbond 這款產品已經兩年多了，作為應用管理平臺，它切實助力到智慧城市應用的日常運維管理工作。目前正處於一個將老版本 Rainbond 叢集遷移到新版本的過渡階段，相信以後還會繼續攜手 Rainbond 同行。