近年來，雲端業務體系不斷髮展壯大，企業的需求也主要呈現出兩個方向，一方面不斷增加的數據量要求雲端能夠實現流量監控和管理；另一方面也需要雲端能夠便捷的進行容量擴展和業務升級。在這種要求下，容器技術不斷發展成熟，以 Kubernetes 爲代表的新興技術也開始在成爲各家雲服務提供商的必爭之地。
但是最終雲服務的使用者是開發者，雲產品的成功與否有話語權的永遠是真正的用戶。當下雲計算領域競爭激烈，容器服務層出不窮，那麼究竟怎樣的產品服務才能俘獲開發者的心呢？
爲了得到真實而又客觀的答案，華爲雲聯合 InfoQ 共同發起了一場開發者衆測活動，共 12 名來自不同企業的開發者，針對華爲雲的容器服務進行了全面的測試，本文便是以 12 位參與者的測試報告爲基礎進行整合，力求客觀展現華爲雲的容器技術特點，併爲有容器業務需求的開發者提供技術要點。
綜述：在完善中追求完美
在本次測試的環節裏，共有 12 人蔘與了本次測試，而由於開發者們的資歷、業務需求以及測試環境的不同，因此不同的測評用戶得出了不同的結論。
從測試用戶的反饋來看，華爲雲容器的優勢在於：功能豐富，分類合理；容器的創建速度快；應用及系統監控指標全面；資源利用率高；擁有詳細的事件日誌；對 Kubernetes 底層改造有相當徹底的研究和實踐；提升了應用的管理和運維能力；頁面操作響應快；打造了以 CCE 爲核心的大規模可維護性極高的雲集羣；可升縮性強，部署快，相比自建節省很多資源開銷。
不過同樣的產品中，測試用戶也列出了一些可改進的點：頁面上可以嘗試摺疊用戶不是很關心的部分基礎操作；部分有狀態顯示的頁面刷新速度不夠及時；希望錯誤信息能給出詳細的、清晰易懂的錯誤提示；服務列表的頁面跳轉如果能開啓新的標籤體驗更佳。
那麼這些優缺點是如何得出的呢? 爲了詳細闡述華爲雲的技術特性，筆者將測試用例和實際應用場景相結合以具體進行分析。
以 spring Cloud 爲例，構建一個應用軟件系統，需要的技術架構大致如下
圖片引用自網絡
生產環境部署此套應用需要如下幾點可靠的保障：
如果按照生產級別的標準完成上述內容，需要一定的運維經驗和技術功底。自行安裝軟件需要合理配置各種參數，這絕非一日兩日的研究可以做到的。那麼華爲雲解決這些問題的方法是怎樣的呢？在此次測試中筆者發現，華爲雲針對需求有不同的解決方案。
從測試結果來看，搭建一個以 Spring Cloud 爲微服務框架的應用系統，通過使用華爲雲是可以做到生產級別的保障要求的。更進一步的話，可以藉助 Istio 服務網格，放棄使用 Spring Cloud 微服務框架，在應用毫無感知的情況下搭建微服務架構。
那麼具體到測試中，這些不同功能的表現情況到底如何呢？以下就是本次測試中測試者對華爲雲在不同環節表現的評價。
1. 雲容器引擎 CCE（Cloud Container Engine）測試
目前，雲容器引擎可以提供高性能可擴展的容器服務，整合網絡和存儲能力，兼容了 K8S 和 Docker 的容器生態。可選 Istio 服務網絡，用戶也可自行選擇安裝插件。此次測試的目的是爲了驗證用戶成功創建容器隧道網絡虛擬機集羣和無狀態工作負載時的體驗。
在這一案例場景下的解決方案：
- 購買雲容器引擎就等於購買了華爲彈性雲服務器 ECS，ECS 的個數就是雲容器引擎的節點個數。這個節點個數是可以動態調控的
- 節點已完整安裝操作系統
- 節點已完整安裝 Dokcer 和 K8S 相關服務
- 節點間網絡在雲容器引擎創建過程中就已經創建完畢
- 用戶可以在創建過程中申請公網 IP，此公網 IP 可以映射到指定節點
- 雲容器引擎支持 Istio 服務網絡
- 雲容器引擎支持節點的系統監控，如：CPU，內存，磁盤，網絡等；具體應用實例的監控，如：實例佔用 CPU 監控，實例佔用內存監控，實例讀取磁盤監控，實例網絡上行下行流量監控等
測試感受：
-
CCE 集羣創建指引清晰。在需要填寫的內容旁邊存在一個小問號，將鼠標懸停就可以看到解釋信息。
-
CCE 的創建過程比較簡單，不需要很多的專業知識，全程可視化；而原生的 K8S 安裝需要配置各種參數，必須對 K8S 比較熟悉才行。
-
CCE 安裝很快，各個參數配置好後，差不多 4 分鐘左右集羣就創建好了。
-
CCE 的可視化管理功能很全面，監控也很全面，出現問題基本上都可以在網頁上處理掉，不需要面對各種配置文件，日誌文件。下圖爲實例異常後的實例自動回覆事件日誌
- web 客戶端；創建基礎設施日誌完整呈現；方便部署；免去開源繁瑣的編譯安裝，部署配置；而且資源分配的可伸縮性十分便利。
小結：
雲容器引擎 CCE 有按需收費和包週期兩種收費模式提供給用戶選擇，適合固件投資有限的用戶使用。其最適用於大規模使用 Docker 或者大規模集羣治理的業務場景。CCE 同樣適合那些有波峯訪問的集羣服務，其動態擴容可以輕鬆化解服務器資源緊張的問題。在運維方面，CCE 提供了豐富的運維監控頁面，可以對集羣，節點，工作負載進行實時監控。
2. Istio 服務網格測試
Istio 服務網格區別於 Spring Cloud 和 Dubbo，其可以在應用無感知的情況下構建微服務系統框架。相比於 K8S 對容器的治理，Istio 網絡可以做到更加細粒度的服務治理。Istio 服務網格的核心技術是將 sidecar 注入到應用服務中，使得 sidecar 可以代理應用服務的全部流量。然後通過對 sidecar 的管理和策略下發，從而構建了高度可伸縮、有彈性、安全且可便於監控的微服務架構系統。此次測試的目的是爲了驗證華爲雲創建 Istio 服務網格的虛擬機集羣的體驗。
對上述案例場景的解決方案：
- 當我們使用 Spring Cloud 微服務框架時，我們會向業務代碼中注入很多管理和運維相關的功能，如：服務註冊，服務發現，負載均衡，熔斷，灰度發佈等。這些管理和運維相關的功能本不應該成爲業務開發者的負擔。Istio 服務網格做到了將這些運維和管理功能抽離業務代碼，使得開發者可以更加關注業務邏輯的實現。而運維和管理功能則交給運維人員進行統一管理。
- Istio 服務網格與經典型彈性負載均衡結合，可以在業務服務無感的情況下，達到熔斷容錯、故障注入、流量管理等效果。
測試感受：
- 在創建和管理 bookinfo 應用中，見證了 Istio 對應用全生命週期中各資源狀態的直觀掌控能力，同時對流量的監控粒度精細。下圖爲 bookinfo 應用請求流向圖：
- 在應用的實例鏡像版本的柔性升級過程中，金絲雀灰度發佈，對版本升級的策略生成及下發、升級過程的控制、應用負載狀態監測。
小結：
使用 Istio 服務網絡，可以輕鬆做到金絲雀發佈，服務高可用，細粒度的請求監控。Istio 可以說是下一代微服務架構的發展方向。華爲雲已經支持 Istio 服務網絡，已經爲未來的微服務體系鋪平了道路。Istio 服務網絡可以將運維和管理功能徹底從業務代碼中脫離，做到對應用服務的完全透明，比較適合那些不希望使用 Spring Cloud 等微服務框架的應用集羣。
3. AOS 應用編排服務和可視化模板設計器
自動化部署面臨的問題有如下幾點：自動化腳本編寫複雜，自動化腳本可閱讀性差，腳本參數動態配置表現不佳，環境搭建複雜，資源配給複雜。那麼華爲雲的 AOS 的是如何解決上述問題的呢？
華爲雲的服務主要有如下特點：
- 由於網絡，應用，數據庫，服務器節點等對象互相關聯，通過可視化的關係圖描述出來是非常直觀的。
- 運行環境需要做到可複製，可配置，可升級。應用服務編排服務可以通過可視化的方式生成可配置的模板。模板可以保存和繼續編輯。
- AOS 設計器簡化了模板的撰寫工作，通過圖形化的界面進行展示，提升了模板的直觀可閱讀性。平時的模板編寫都需要手動編寫，但設計器提供了簡約的，可拖拽式的畫板操作。
- 模板可以支持環境變量，用戶在創建堆棧的時候配置動態參數，增加了腳本的靈活性。
- 資源可視化，配給資源只需輕輕拖拽。自動化部署過程中最複雜的莫過於資源配給，設計器可以將資源通過圖形的方式展現出來，使得用戶可以清晰明瞭的看到資源與資源之間的關係。不僅如此，設計器會在資源間強制建立一些基本的關係，可以幫助用戶快速分配資源。
- 用戶自己創建的腳本還可以申請上傳共有模板，同時用戶也可以借鑑其他用戶發佈的共有模板。
測試感受：
- 使用模板創建應用很方便，整個配置過程也很簡單、快速，不需要很多專業知識或者在代碼層面做配置，降低了用戶上手的難度。
- 在測試中，通過華爲雲引擎提供的應用編排服務 AOS 組件，輕鬆瞬速的實現了 WordPress 應用發佈，從公用模板庫中引用華爲雲引擎內建模板鏡像，到建立堆棧、發佈應用一氣呵成。下圖爲 wordpress 的可視化模板：
小結：
Dokcer 將應用和環境融爲一體，使得應用獲得了很強的可移植性。而 AOS 應用編排服務則是將整個集羣和集羣需要的所有組件融爲一體，這其中包括數據庫服務，負載均衡服務，網絡，存儲，節點，防火牆。如此複雜的融合僅需要在畫板上簡單的拖拽就可以實現。
4. 工作負載提升應用高可靠性
工作負載即服務的抽象，如：微服務中把複雜的業務邏輯拆分成不同的微服務，每個微服務在華爲雲中都可以稱爲一個工作負載；同一個服務的多個實例屬於同一個工作負載；數據庫服務也是一個工作負載。工作負載分爲無狀態的工作負載和有狀態的工作負載。無狀態指的是，服務之間完全獨立，提供完全相同的服務，不存在任何依賴關係。有狀態值的是，服務之間有依賴關係，有相互調用的情況，有存儲共享的情況。此次測試的目的是驗證創建無狀態工作負載時的體驗。
對上述案例場景的解決方案：
- 工作負載可以配置伸縮策略，根據峯值流量自動調整實例個數。
- 通過配置工作負載的調度策略，如：服務對於節點的親和性配置；服務對同類型服務的非親和性配置等。有了調度策略，可以保證相同的服務實例絕不會部署在同一臺 ESC 節點上，同時也可以保證有特殊需要的服務一定部署在不同的物理機房（可用區）中。
- 針對每一個工作負載可以設置多種類型的健康檢查，如：HTTP 請求檢查，TCP 端口檢查，執行命令檢查等。當發現實例不健康後，不會有任何的流量繼續走向該實例。
- 工作負載中可以針對不同的實例進行監控，如：CPU，內存，網絡，磁盤等。
測試感受：
-
本次測試親歷了華爲虛擬化集羣的兩個用例，一個是在集羣中建立無狀態負荷，並做了實例鏡像版本的柔性升級，即灰度測試，一個是在集羣的跨虛機容器間網絡性能測試及反親和性測試，均取得了較滿意的效果。
-
總的使用感覺對比之前的 K8S 使用感受感覺雲容器的啓動和故障恢復速度略慢。
-
自動恢復功能很好，當一個實例死掉後，能夠迅速創建新的實例。下圖爲實例自動恢復事件日誌：
- 在部署失敗的情況下，給用戶的信息感知還是不夠具體，需要有更加直觀的問題所在點
小結：
工作負載是華爲雲對單個微服務應用集合的稱呼。工作負載可以對單個微服務集合配置健康檢查、部署策略、伸縮策略，訪問方式等。在 AOS 應用編排服務中部署的堆棧也會出現在工作負載中。如此的設計也可以在華爲雲不同服務之間完成交互和配合。
5. 總結
從本次測試結果來看，結合 12 位測試者的測試報告可以看出，華爲雲的容器產品依舊保持了一貫風格風格，大膽的擁抱了雲原生應用管理與部署，可以提供大規模應用綜合治理服務。雖然在細節方面依然存在一些普遍性的不足，但是將複雜的資源分配、環境部署交給華爲雲來完成，能夠爲開發者提供更加高效的工作環境。
從華爲雲的定位來看，企業級 Kubernetes 容器集羣的高可用性和安全性，得到了普遍認可；其多樣化付費方式、性能穩定、管理便捷並且提供了一些技術模板，對於初級開發者非常友好，這將會有效降低中小型企業的容器管理難度。在與部分華爲雲的客戶接觸中，華爲雲的服務態度與對客戶的重視程度也獲得了不錯的口碑。有測試者也在結果中提到：“華爲雲將 docker 和 Kubernetes 結合，提升了應用服務的可移植性，加強了應用服務的綜合治理能力。”
而從市場來看，目前大多數的雲服務產品在彈性擴容伸縮方面存在一定的不足，而華爲雲在此方面的穩定性屬於市場上少有的。在與業務銜接時，華爲雲全面採用的 Kubernetes 技術可以在監控和管理方面幫助企業獲得先機。
6. 文末福利
作爲雲服務直接用戶的你，對於雲服務的剛需是什麼？你有什麼想對華爲雲說的嗎？歡迎在評論區留言告訴我們，爲了答謝大家對華爲雲的支持，截止本週四下午 5 點前，評論點贊最高的五位用戶將獲贈華爲榮耀手環 3 一個（支持 NFC 支付、50 米防水，兼容 iOS& 安卓）！
與此同時，你還可以點擊訪問華爲雲雙十二活動現場，獲取一籮筐的福利，我要是你會多薅點羊毛屯着過冬。