雲原生應用管理,像管理手機APP一樣管理企業應用


我們在使用智能手機的時候,手機APP從應用市場一鍵安裝,安裝好即點即用,當有新版本一鍵升級,如果不想用了長按圖標刪除,整個過程非常簡單,小朋友都能熟練掌握。而對於企業應用,由於結構復雜、可用性要求高、配置多等特點,導致企業應用的管理工作異常復雜。企業內部一般都會有專門的運維工程師來負責保障企業應用的正常運行。

Rainbond 是一款雲原生企業應用管理平台,本文將以它為例講解,如何像管理手機 APP 一樣簡化管理企業應用。

建立企業應用商店,從應用商店一鍵安裝企業應用

手機 APP 的安裝已經做到了極致的簡單,在預裝好的 AppStore 中一鍵安裝想要的APP即可。這種一鍵安裝的體驗流程,哪怕一個小朋友都可以很好的掌握。企業應用部署難度大,組件數量多,其安裝的復雜程度遠高於手機 APP 。那么在企業應用的安裝領域,能否做到安裝手機APP一樣的一鍵式體驗呢?

類比手機 APP 的安裝過程,應用商店這個集合了大批 APP 的平台是必不可少的一環,正是有蘋果 AppStore、Google Play 這樣生態繁盛的應用商店,才讓手機消費者隨心所欲的安裝手機 APP。Rainbond應用商店是企業級的AppStore。每個用戶都可以將自己部署在 Rainbond 上的企業應用發布到應用商店中去,供其他用戶使用,其他用戶只要從應用商店一鍵安裝和升級,使用體驗和手機AppStore的體驗類似。

WechatIMG148

為了最終用戶的使用體驗,開發手機APP的企業需要按應用商店的標准開發和上架,企業應用商店的實現也是類似的思路,企業應用的供應商需要按企業應用商店的標准打包和上架,Rainbond內置的應用商店有一整套的應用打包、測試和上架過程,比如從源碼打包、二進制文件打包、容器打包等,這些打包過程都不需要改動原有代碼。按應用商店的規范打包和上架,不僅簡化了應用的安裝和升級過程,同時也建立了企業應用的驗收標准。

WechatIMG149

企業應用管理復雜,該如何簡化管理?

對於一個手機 APP 而言,實際上我們可以做的管理操作很少,僅僅涉及到安裝、升級、刪除。而一個企業應用則要復雜得多,一個企業應用所需要的管理操作,至少包含了以下這些點:

  • 生命周期管理:就像手機用戶需要安裝、使用、升級、刪除 APP一樣,安裝、升級、啟動、關閉、刪除等生命周期管理相關的操作,是企業應用所需要的最基礎的管理操作。
  • 批量管理:手機 APP 只有一個組件需要管理,而企業應用往往是多個服務組件相互依賴組合形成的。所以會需要有批量操作的需求。
  • 資源分配:手機用戶從來不用關心需要為一個 APP 分配多少資源,而企業應用的管理者必須關心為每個組件分配合理的計算資源。計算資源分配不足會讓企業應用運行不暢甚至無法運行,過多的分配計算資源會導致資源浪費。
  • 伸縮特性:手機 APP 並沒有運行多份的需求,它只需要保證在手機中正常運行, 滿足主人的個人使用壓力即可。企業應用無論是在高可用方面還是在抗並發方面,都會對橫向伸縮能力提出要求。
  • 可觀測性:手機用戶從來不關心是否能夠看到手機 APP 的運行狀態,只關心它們的功能。但是企業應用管理者會對企業應用提出很高的可觀測性要求,包括運行狀態、資源占用、性能表現、運行穩定性等。
  • 故障恢復:手機用戶允許 APP 偶爾出現閃退,無非是重新打開一次罷了。而企業應用管理者對企業應用的期待是,即使企業應用出現了問題,也可以快速從故障狀態中恢復過來。
  • 遷移/備份:手機 APP 的用戶數據都保存在雲端,數據的遷移、備份操作簡單。企業應用重視數據,對遷移備份等操作要求很高,有的場景甚至要求跨集群遷移備份。

經過對比,可以發現企業應用在管理方面需要注重的點,比手機APP復雜得多。但這不意味着企業應用管理人員一定要付出更多的努力來管理企業應用。選擇正確的企業應用管理工具,會使得企業應用管理工作事半功倍。

Rainbond從三個方面簡化企業應用的管理:

  1. 讓常規的管理簡單容易上手,比如:安裝、升級、啟動、關閉、刪除、伸縮、配置域名等管理操作都可以一步完成。
  2. 復雜的運維過程實現自動化,比如:安裝/升級/啟動的操作過程、健康檢測、服務高可用、自動伸縮等。
  3. 過程實時監控和可視化,由於管理過程實現了簡單操作和自動化,就需要加強監控和可視化了解應用運行情況,做到過程可控可管。

讓企業應用常規管理簡單容易上手

前文已經分析過,手機用戶對 APP 的管理操作是僅限於開啟、關閉等簡單的操作。對於企業應用而言,我們希望企業應用管理者主動發起的管理操作,也是足夠簡單的操作。企業應用管理人員完全通過圖形化界面,來完成對企業應用的生命周期管理操作。

對於企業應用整體而言,可以執行批量的管理操作:

應用整體的管理

應用批量管理

涉及到生命周期管理的操作包括但不限於:

  • 企業應用整體的啟動、停用、更新、構建、升級
  • 面向企業應用內部所有組件的批量啟動、關閉、更新、構建、重啟、刪除

對於希望將企業應用完整的遷移到其他集群,或者做一份備份的場景而言,圖形化操作的遷移/備份功能可以解決問題:

image-20211123172110092

對於指定的服務組件而言,可以進行的主動管理操作會更多:

image-20211210181939473

除了較為常見的生命周期管理之外,企業應用的管理者還可以有更多的主動操作:

  • 版本管理,在多個構建版本之間一鍵升級或回滾

image-20211210211647240

  • 伸縮管理,主動的為服務組件設置計算資源、實例數量

image-20211210211718070

  • 環境配置,主動為服務組件設置環境變量,掛載配置文件

image-20211210211742077

  • 存儲管理,主動為服務組件添加持久化設置,使數據持久化的保存

image-20211210211814601

  • 端口管理,主動為服務組件添加端口訪問策略

image-20211210211836683

  • 插件管理,主動為服務組件安裝可以擴展運維能力的插件

image-20211210211905872

  • 進入 Web終端,直接操作當前服務組件的容器shell環境

image-20211210211623350

常規企業應用管理操作基本都是UI界面,過程也不需要學習底層技術,通過界面摸索就可以上手。

復雜的運維過程實現自動化

企業應用確實比手機 APP 復雜太多,但是我們又希望企業應用的管理者盡量少操管理的心,那么提供自動化的運維能力就十分有必要。

Rainbond 被設計成一款具備強大自動化運維能力的平台。這些自動化運維能力,可以最大限度的解放企業應用管理人員的雙手,切實提升生產力。這些自動化運維能力提煉自許多工程師長久以來的運維工作經驗,這些能力往往表現在企業 IT 系統的底層,平日里不顯山露水,但是卻關乎企業應用運行的好壞。

  1. 常規管理的過程實現自動化

    企業應用的常規管理本身是挺復雜的,為了前端的操作簡單,后端的實現過程就必須自動化。
    比如:

    • 安裝過程自動化,安裝過程需要為每一個服務自動化完成軟件包安裝、服務配置、端口管理、服務啟動等步驟。
    • 升級過程自動化,升級過程需要自動化完成對比版本差異、差異安裝、滾動升級等步驟。
    • 啟動過程自動化,當一個企業應用有多個子服務時,還需要自動處理它的服務啟動順序。
  2. 健康檢測與故障恢復

    企業應用管理人員不希望為了應對不知何時會發生的企業應用故障而每時每刻值守在機房。因此 Rainbond 提供健康檢測能力,來替代企業應用管理人員,時刻關注着企業應用的健康狀況。並且提供可選的異常處理手段,在異常發生時自動處理。

    Rainbond 平台支持兩種模式的探針來自動檢測服務組件中所有實例的健康狀況。TCP模式的探針,會每隔一段時間偵測服務組件的指定端口是否可以聯通,這種檢測是基於網絡和端口的聯通性來實現的。而HTTP模式的探針,會每隔一段時間,請求指定的URL,並根據HTTP返回碼來判斷實例的健康狀況。相對而言,TCP探針應用的范圍更廣泛,而 HTTP 探針會更加精確。因為可能存在這樣一種軟件設計缺陷,WEB SERVER 處於正常工作狀態,端口可以正常監聽,但是業務接口已經無法提供正確的返回,這對於最終用戶而言,也是一種應該被檢測到的錯誤。

    對於檢測失敗之后的處理,平台提供兩種策略,下線與重啟。

    將問題實例從負載均衡中下線,這是一種降級行為。觸發下線后,不會再有新的請求到達問題實例,問題實例從巨大的訪問壓力中得以緩解。接下來,如果服務組件足夠健壯,它會在處理完大量的積壓請求后恢復,重新通過健康檢測后上線。這里包含一個隱藏的假設,要求服務組件具備多實例特征,否則問題實例的下線會導致服務組件整體無法提供服務。

    重啟則是一種相對武斷的處理方式。但不可否認的是,在服務組件不那么健壯的情況下,重啟實例是最簡單有效的恢復手段。

    008i3skNly1gxb0mqzbd6j30yt0u0q4i

  3. 高可用能力

    Rainbond 為企業應用提供了高可用能力的支持。在一個 Rainbond 集群中,往往存在多種不同身份的服務器節點,而每種不同身份的服務器節點也不止一台。這意味着 Rainbond 本身就是高可用的,運行在其上的企業應用,也可以自由的在不同的宿主機節點之間漂移。

    在 Rainbond 集群中的某台服務器出現故障時,Rainbond 集群並不會受其影響,也會將受到服務器故障影響的企業應用重新調度到其他正常的服務器中去。企業應用管理人員只需要在事后修復故障的服務器,整個 Rainbond 集群又會完成自愈,而企業應用在這個過程中受到的影響是可以忽略不計,尤其是當企業應用本身伸縮了多個實例的狀態下,可以做到最終用戶無感的處理體驗。

  4. 自動伸縮能力

    如果企業應用的最終用戶是人,那么它的訪問壓力情況,都會有潮汐特征。好比一款供企業內部人員使用的OA系統,工作日的流量遠比休息日高,工作時間的流量遠比下班時間高。那么可否讓這款 OA 系統根據流量的大小,自動調整實例的數量。令其忙時啟動足夠數量的實例抵御訪問壓力,閑時自動降低實例數量,將資源留給其他企業應用。Rainbond 平台可以賦予企業應用自動伸縮的能力。

    Rainbond 平台對於其托管的每個企業應用的當前狀態了如指掌。當然也了解當前企業應用的資源使用數量是否已經接近分配的上限。通過自動伸縮的設置,可以為企業應用設置一個上限,當 Rainbond 發現企業應用使用的資源已經超過這個設定值時,自動的擴展實例的數量。這個設定值,可以是內存使用量/率或CPU使用量/率,亦或是兩種資源的綜合設定值。

    image-20211210220826994

管理過程可觀測和可視化,做到可控可管

手機用戶不會想着觀察 APP 內部的運行狀態,但是企業應用管理人員不這么想。可觀測性是一切管理工作的前提,只有看得見,才能摸得着。

Rainbond 提供的可觀測性無處不在,從集群維度開始,到應用級別,最終到每一個服務組件級別,都體現着豐富的可觀測性。

對於一個企業應用而言,看到它內部的拓撲結構,和所有組件的運行狀態是最基本的可觀測性要求。Rainbond 提供了應用拓撲圖界面,並根據不同的顏色來體現每一個服務組件的運行狀態。綠色代表運行中,黑色代表已停止,而紅色代表服務組件處於異常狀態。

拓撲圖.drawio

對於單個服務組件而言,其可觀測性的粒度要更細致。服務組件的總覽頁面中,描述了當前服務組件的詳細信息,服務組件的每個實例,也都體現自己的運行狀態。

image-20211210222909066

下方的操作記錄,更是詳細描述了服務組件發生過的每一件事。

image-20211210223104722

服務組件的監控頁面,集中的體現了有關其運行狀態的各種可視化圖表。

  • 體現業務性能情況的實時分析曲線

image-20211210223516990

  • 有助於優化程序的5分鍾請求排行

image-20211210223622015

  • 各個實例的資源用量曲線

image-20211210223953109

  • 支持基於 Prometheus 體系的 Exporter 指標自行繪圖

image-20211210224351717

Rainbond 的監控大屏系統,提供全局可觀測性的中心。

image-20211210224803749

寫在最后

Rainbond 提供一個解決企業應用的管理問題的全新思路,它不僅優化了管理和使用體驗,還能高效管理應用供應商,應用商店也讓管理人員對應用自主可控,減少對供應商的依賴。


Rainbond是一個開源的雲原生應用管理平台,使用簡單,不需要懂容器和Kubernetes,支持管理多個Kubernetes集群,提供企業級應用的全生命周期管理,功能包括應用開發環境、應用市場、微服務架構、應用持續交付、應用運維、應用級多雲管理等。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM