1. 首頁 > 生活百科 > >

云原生時代的DevOps平臺設計之道( 四 )

生活百科


易于理解的應用模型從工作負載層面上講，Kubernetes 只通過 Deployment、Statefulset 等抽象描述單個組件的特征，然而多數情況下，開發人員開發出的業務系統會包含若干微服務組件 。那么如何對整個業務系統進行統一的管理就變成了一個問題 。解決方案之一 ， 就是通過云原生應用平臺 ， 在單個組件之上，抽象出應用這個概念 。應用應該是由人為規定的一組服務組件（workload）組成 ， 服務組件之間具有顯式或隱式的關聯調用關系，彼此之間有機組合成為一個整體，作為一套完整的業務系統對外提供服務 。
開發人員可以將所有的服務組件視作一個整體來進行管理 ， 而非機械的單獨管理每一個服務組件，這種操作體驗無疑會更簡單，也便于開發人員理解 。對應用的管理可以包括統一的生命周期管理、統一的安裝升級卸載，靈活拼裝服務組件之間的調用關系 ， 更合理的處理業務系統的交付流程 。
目前 Kubernetes 領域內較為成熟的交付工具 Helm ，其設計也暗合此類模型，一條簡單的 helm install xxx 命令，即可安裝起一大堆組件以及圍繞這些組件的配置 。

云原生時代的DevOps平臺設計之道

文章插圖
Rancher 并沒有實現自己的應用模型，其應用的安裝方式集成了 Helm，并沒有體現出應用管理能力 。
KubeSphere 則更進一步，在項目下的應用負載中提出了應用的概念 。在應用中可以通過 Helm 或自建的形式部署服務，集成了微服務治理、單個組件的版本控制、路由管理、灰度發布等能力 。其對 Helm 模板的支持 ， 使得其從理論上可以支持任何市面上已有的 Helm Chart 包的安裝部署 。
Rainbond 的應用概念是最完善的，除了常規的生命周期操作、整個應用級的版本控制這樣的常規能力之外，還有些非常易用的自研功能，能夠簡化開發人員對自己應用的管理 。比如基于泛解析域名機制實現的對外服務域名，點擊開啟對外服務，就會生成一個公網可用的域名訪問自己的應用，這比一層一層的配置 Ingress 規則容易太多 。又比如應用復制能力 ， 可以批量的將整套應用復制到另一個工作空間，而不必重新手動搭一套 。
應用模板是 KubeSphere 和 Rainbond 均提出的一個概念，應用模板存在的意義是可以將開發好的應用復制到不同的環境中去，是一種制備新一代制品并交付分發的技術 。應用模板的基礎使用體驗，是可以快速方便的安裝整套應用系統，最好是一鍵化的體驗 ， KubeSphere 和 Rainbond 都提供了應用商店，供用戶快速安裝一些已經制作好的應用模板 。應用模板更高層次的使用體驗，則是開發人員可以無任何技術負擔的開發出自己的應用模板，而不僅僅是從應用商店拉取別人制作好的應用模板 。
易于掌控的微服務架構微服務架構也是云原生平臺不可缺少的一個元素 。微服務架構旨在幫助開發人員建設高類聚、低耦合的現代應用系統，將以往煙囪式的業務系統架構，拆散成為一大堆彼此間更為獨立，包含自身功能特點的微服務模塊 。容器與相關編排技術的成熟，為微服務架構的落地打下了基礎 。云原生應用平臺，則為開發人員更簡單的入手微服務框架提供了可能 。
云原生平臺首選的微服務框架，應該是以 Istio、Linkerd 為代表的 Service Mesh 微服務框架，也被稱為“服務網格” 。相對于 Spring Cloud 、 Dubbo ，這種微服務框架提供了更高的自由度和適應性 ， 開發人員不需要被某種開發語言或產品綁定，只需要回歸網絡編程即可將自己的業務系統連接成為一個整體 。這里要重點提出的是微服務架構對業務代碼無侵入，只有無侵入的實現，才能最大限度降低開發人員花費精力學習其他領域知識的可能性 。
DevOps 工程師可以通過設計云原生平臺功能來進一步優化配置微服務的使用體驗，大膽設想一下，開發人員只需要在兩個服務組件之間拖動一條表征微服務調用關系的線，就可以生成對應的微服務配置 。這樣的操作體驗完全可以使注冊中心、控制平面這種微服務領域中復雜的概念對開發人員屏蔽 。本質上講 ， 維護注冊中心或者控制平面也是運維人員需要關心的工作 。
云原生時代的DevOps平臺設計之道

文章插圖
Rancher 由于其自身的定位，產品中沒有集成任何微服務相關的能力，用戶需要手動安裝 Istio 等微服務框架，通過復雜的 yaml 配置，來引用微服務能力 。

推薦閱讀