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

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

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

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

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

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

為了終端使用者的使用體驗，開發手機APP的企業需要按應用商店的標準開發和上架，企業應用商店的實現也是類似的思路，企業應用的供應商需要按企業應用商店的標準打包和上架，Rainbond內建的應用商店有一整套的應用打包、測試和上架過程，比如從原始碼打包、二進位制檔案打包、容器打包等，這些打包過程都不需要改動原有程式碼。按照應用商店的規範打包和上架，不僅簡化了應用的安裝和升級過程，同時也建立了企業應用的驗收標準。

企業應用管理複雜，該如何簡化管理？

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

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

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

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

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

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

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

對於企業應用整體而言，可以執行批次的管理操作：

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

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

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

對於指定的服務元件而言，可以進行的主動管理操作會更多一些：

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

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

伸縮管理，主動地為服務元件設定計算資源、例項數量

環境配置，主動為服務元件設定環境變數，掛載配置檔案

儲存管理，主動為服務元件新增持久化設定，使資料持久化的儲存

埠管理，主動為服務元件新增埠訪問策略

外掛管理，主動為服務元件安裝可以擴充套件運維能力的外掛

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

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

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

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

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

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

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

安裝過程自動化，安裝過程需要為每一個服務自動化完成軟體包安裝、服務配置、埠管理、服務啟動等步驟。
升級過程自動化，升級過程需要自動化完成對比版本差異、差異安裝、滾動升級等步驟。
啟動過程自動化，當一個企業應用有多個子服務時，還需要自動處理它的服務啟動順序。

2.健康檢測與故障恢復

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

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

對於檢測失敗之後的處理，平臺提供兩種策略，下線與重啟。

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

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

3.高可用能力

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

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

4.自動伸縮能力

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

Rainbond 平臺對於其託管的每個企業應用的當前狀態瞭如指掌。當然也瞭解當前企業應用的資源使用數量是否已經接近分配的上限。透過自動伸縮的設定，可以為企業應用設定一個上限，當 Rainbond 發現企業應用使用的資源已經超過這個設定值時，自動的擴充套件例項的數量。這個設定值，可以是記憶體使用量/率或CPU使用量/率，亦或是兩種資源的綜合設定值。