|
接收程序員的技術(shù)早餐 從單體到微服務(wù)，論企業(yè)級應(yīng)用服務(wù)器到微服務(wù)基礎(chǔ)設(shè)施架構(gòu)設(shè)計演進 作為一名軟件工程師或者系統(tǒng)架構(gòu)師，當(dāng)我們在構(gòu)造大型應(yīng)用系統(tǒng)時，常常需要畫出一個體系架構(gòu)圖，來表現(xiàn)要開發(fā)的應(yīng)用系統(tǒng)的軟件架構(gòu)。 我想很多軟件開發(fā)人員都有這樣的疑問：這幾年業(yè)界都在談微服務(wù)，容器化，這樣的技術(shù)變化的原因是什么？新的或者原有的軟件系統(tǒng)到底該用什么樣的技術(shù)架構(gòu)體系？如果需要改造，應(yīng)該怎么做？ 希望通過閱讀本文給您一些啟發(fā)。 應(yīng)用服務(wù)器是近十幾年來應(yīng)用開發(fā)的主流部署環(huán)境。以 Java 語言社區(qū)為例，Java EE 應(yīng)用服務(wù)器是軟件中間件開發(fā)領(lǐng)域的主要產(chǎn)品，包括以 Weblogic, Websphere 商業(yè)產(chǎn)品， JBoss AS(Wildfly), Glassfish 開源產(chǎn)品，還有 Tomcat, Jetty 等 Servlet 容器服務(wù)器，Spring Framework 應(yīng)用框架等，這些共同組成商業(yè)業(yè)務(wù)軟件最重要的部分。 容器 Docker，容器編排 Kubernetes 等帶來了容器化微服務(wù)軟件技術(shù)浪潮，互聯(lián)網(wǎng)公司作為先行者，并在國內(nèi)外引領(lǐng)軟件設(shè)計的方法變革，Cloud Native 已經(jīng)成為當(dāng)前軟件設(shè)計中必須考慮的要素。 那么，“傳統(tǒng)”的應(yīng)用服務(wù)器和 Kubernetes 之間是否有技術(shù)關(guān)聯(lián)性？如果有，它們的內(nèi)在聯(lián)系是什么？ 我在專業(yè)技術(shù)網(wǎng)站找到了兩幅圖片，分別是完整的 JavaEE 實現(xiàn) Wildfly 應(yīng)用服務(wù)器域模式和 kubernetes 架構(gòu)體系圖。 
圖片出處： https://kb./index.php/Wildfly_Domain_Mode_Concepts 
圖片出處： https:///blog/introduction-kubernetes-architecture/ 以上兩幅圖，并不能表現(xiàn)這兩個產(chǎn)品所有技術(shù)架構(gòu)細(xì)節(jié)，但已經(jīng)能夠充分表現(xiàn)它們的架構(gòu)特點和組件之間的關(guān)系。 我們發(fā)現(xiàn)，兩者的架構(gòu)有很多一致的地方： 都有一個主控節(jié)點。Kubernetes 稱為 Master Node，Wildfly 中含有 domain controller 的 host1，也是作為主控節(jié)點。 通過主控節(jié)點管理多個工作節(jié)點。Kubernetes 有兩個 Worker Node，Wildfly 圖中也有兩個工作節(jié)點 host2 和 host3。 管理員通過管理接口 (Rest API) 來對整個系統(tǒng)進行管理，Kubernetes 是通過 kubectl 訪問 API server，Wildfly 是通過 jboss-cli 工具訪問管理接口，服務(wù)器處理組件是 domain controller。當(dāng)然，它們也都提供圖形管理工具。 工作節(jié)點上都有控制進程，Kubernetes 是 kubelet 和 kube-proxy，Wildfly 為 host controller 和 process controller，其中 kubelet 和 host controller 作用類似，都是起到工作節(jié)點和主控節(jié)點通信和管理節(jié)點工作進程的作用。 每個工作節(jié)點上都有多個工作進程，只不過 Kubernetes 是由容器管理 Pod，而 Wildfly 是 JVM 進程管理工作線程。
另外在圖示中沒有表示出來，在邏輯上概念相似的還有： Kubenetes 中的 controller-manager 包括各類功能的控制器模塊。Wildlfy 中有類似的功能模塊，也在 domain controller 中，它們都具備可擴展能力。 Rest API 對外接口采用簡單易懂的 Json 格式。而各個節(jié)點間為了高效率，通信方式為二進制數(shù)據(jù)流，可以配置加密方式。 盡管在工作進程中，Pod 和線程是不同的。但它們邏輯上也有相似之處：都是獨立的工作主體；都有完整的生命周期；Pod 間共享網(wǎng)絡(luò)，存儲等信息，線程間可以傳遞上下文。我個人更愿意把 Pod 看作是高一個或者半個維度的，隔離性更好的“工作線程池”。 不同的節(jié)點或者進程中的服務(wù)工作單元，可以動態(tài)組成服務(wù)群組。Wildfly 中有 Server Group 概念，一個應(yīng)用可以被同時部署到 Server Group 的所有工作單元；Kubernetes 的 Pod 可以通過定義的 Label 來 Selector，即可以篩選出具有某些標(biāo)記的 Pod，而作為服務(wù)群組對外提供服務(wù)。 Kubernetes 有 Service 來提供服務(wù)，對于服務(wù)消費者，后面的 Pod 服務(wù)提供者的信息都是透明的，而且還有 Ingress 對外部應(yīng)用進一步暴露服務(wù)能力。Wildfly 提供了 Wildfly-cluster 作為服務(wù)組件的反向代理，雖然做不到像 Service 那樣直接通過 iptables 底層機制去映射網(wǎng)絡(luò)訪問端口，但同樣也有強大的根據(jù)負(fù)載能力調(diào)節(jié)轉(zhuǎn)發(fā)請求量的特性，更多起到 Ingress 的作用。 Kubernetes 對有狀態(tài)的組件支持，是通過 StatefulSet，掛接 Persistent Volumes，啟動時重新構(gòu)建相同狀態(tài)的工作容器。而 Wildfly 中對狀態(tài)的管理，包含 Stateful SessionBean, Servlet session 等等，都是通過 Infinispan 的分布式機制，復(fù)制狀態(tài)到多個節(jié)點。而且還有一種遠程 Infinispan 的配置方法，和 Kubernates 對狀態(tài)的管理在邏輯上完全一致了。 對于 Master 主控節(jié)點的安全性管理，兩者都有完備 RBAC 用戶管理認(rèn)證授權(quán)機制，以及完備的加密方式，密鑰配置管理等功能。
Java EE 技術(shù)一直是一個完整的開發(fā)生態(tài)，同樣，Kubernetes 也快速形成了更加龐大的生態(tài)體系，我們從其中一些對開發(fā)很重要的方面進行分析。 JavaEE 有一套標(biāo)準(zhǔn)的打包方式，如構(gòu)建 jar，組合成應(yīng)用 war，進而打包成企業(yè)完整應(yīng)用 ear。Kubernetes 是利用容器鏡像，即 docker 的打包機制來管理容器。在 docker 之上，Kubernetes 提出 Pod 概念。對于整體的應(yīng)用部署，目前 Kubernetes 社區(qū)提供了 helm 工具和 chart 包格式。當(dāng)然也類似 yum 工具管理的 rpm 格式。 Kubernetes 動態(tài)擴容，即 ReplicaSets 定義的創(chuàng)建特定數(shù)目的實例，可以說是 Kubernetes 最重要的特性之一。JavaEE 定義的 Stateless SessionBean，在應(yīng)用服務(wù)器實現(xiàn)中，會創(chuàng)建一個池來實例化多個，雖然實例個數(shù)控制粒度沒有那么細(xì)，但也是可以通過控制臺來定義其實例數(shù)量的，實例池由容器來保證其可用實例數(shù)目。 Kubernetes 用 ConfigMap 來定義配置信息，用 Secrets 來定義安全方面的配置信息。JavaEE 也有類似的定義，比如 Resource 和 Securtiy 方面的 annotation。在應(yīng)用服務(wù)器擴展方面，Wildfly 可以自行定義 xml schema，提供友好可讀的 xml 配置信息，以及 Security Domain/Realm 來定義安全方面的配置信息。 原 Coreos（后被紅帽收購）定義的 Operator Framework（運維框架），基于 Kubernetes CRD（Custom Resource Definitions），定義了完整的一套打包，部署，管理應(yīng)用的方法，有了這樣的工具，第三方軟件產(chǎn)品，可以用一種相對“標(biāo)準(zhǔn)”的方式提供容器化的產(chǎn)品。Custom Resource Definitions 是 Kubernetes 的擴展機制，可以預(yù)見 Kubernetes 三方擴展將會如雨后春筍般出現(xiàn)。對應(yīng)的，Wildfly 有子系統(tǒng)（subsystem 擴展機制），可以在 Wildfly 服務(wù)器內(nèi)核之上，開發(fā)子系統(tǒng)來擴展功能，Wildfly 所有的 Java EE 都是通過子系統(tǒng)方式實現(xiàn)的。它們都是通過擴展 Controller 的功能，把管理命令掛接到 API server 之上，設(shè)計思路驚人的一致！ Wildfly 工作節(jié)點的管理，可以通過暴露信息發(fā)給主控節(jié)點，也可以利用 JMX，Java agent，Interceper 等方式來發(fā)送數(shù)據(jù)到分布式數(shù)據(jù)中心上（比如可以加載 jolokia），再用獨立的或者統(tǒng)一的控制臺來管理。同樣的，Istio 項目，也是利用 sidecar 模式，在 pod 工作進程上，掛接一個 envoy 模塊，由其完成流量分配，安全管理，policy 設(shè)置等功能，再由控制臺統(tǒng)一管理。 Kubernetes 被成為容器編排產(chǎn)品，所謂編排 (orchestration)，就是把不同的應(yīng)用運行組件，按照實現(xiàn)定義好的規(guī)則，根據(jù)其依賴性能夠啟動運行，并保證其運行健壯的能力。Java EE 各個規(guī)范間也有依賴性，比如 Webservice 依賴于 Servlet，Wildfly 有一個組件成為 DeploymentFramework，也是處理組件之間的依賴關(guān)系的，服務(wù)器會按照應(yīng)用定義好的最終狀態(tài)聲明，按照自己的依賴性原則，逐個啟動各個服務(wù)，保證應(yīng)用最后可用。
畢竟 Kubernetes 是演進后技術(shù)，具有大量新的特性： 存儲方面的特性，Kubernetes 可以掛載各種存儲，包括普通的文件系統(tǒng)，NFS，云端的 S3，開源存儲方案 Ceph 等應(yīng)有盡有。Wildfly 還是使用標(biāo)準(zhǔn)的操作系統(tǒng)的文件和目錄。利用容器，Kubernetes 能更方便的對文件限額，資源使用量等進行定義和限制操作。 網(wǎng)絡(luò)方面的特性，Wildfly 定義了網(wǎng)絡(luò)接口配置屬性，可以對網(wǎng)絡(luò) IP，端口，偏移值等進行設(shè)置。但這些和 Kubernetes 相比就是九牛一毛，Kubernetes 在 Service 層，就利用 iptables 等方法做網(wǎng)絡(luò)請求的路由映射，而且商業(yè) Kubernetes 產(chǎn)品都會加入 SDN（軟件定義網(wǎng)絡(luò)）的方案，網(wǎng)絡(luò)管理成為應(yīng)用體系重要的一部分。 Kubernetes 中非常重要的組件是 scheduler 調(diào)度器，這個在 Wildfly 中沒有功能完全一致的組件，因為企業(yè)應(yīng)用的集群部署是按組整體部署的。Wildfly 提供了控制臺工具來部署到不同的節(jié)點上，盡管這個過程可以自動化，甚至可以引入一些智能的成分來“調(diào)度”，但還是和 Kubernetes 提供的調(diào)度能力相差甚遠。 對工作節(jié)點的管理的規(guī)模不同。企業(yè)應(yīng)用服務(wù)器集群一般在數(shù)十臺左右，和互聯(lián)網(wǎng)動則成千上萬的服務(wù)器差了幾個數(shù)量級。對事務(wù)的一致性要求也是不同的，它們對于狀態(tài)信息的分布式分發(fā)復(fù)制方式存在差別。 企業(yè)級應(yīng)用服務(wù)器，應(yīng)用上下文信息包含了事務(wù)，安全等信息，在線程間進行傳遞。而應(yīng)用分布化后，微服務(wù)之間也要傳遞安全，事務(wù)等信息，就要用 OIDC/Jwt，TCC/Saga 等分布式方案。業(yè)務(wù)目標(biāo)是一致的，但實現(xiàn)方法有很大差異，也對軟件架構(gòu)設(shè)計提出了非常高的要求。
毫無疑問 Kubernetes 已經(jīng)贏得了容器之戰(zhàn)，甚至取代 docker 成為容器技術(shù)中最重要的開源產(chǎn)品。開發(fā)工程師和架構(gòu)師也需要適應(yīng)微服務(wù)化技術(shù)的變化，部署應(yīng)用到云端上，這個趨勢已經(jīng)開始了。同時，Kubernetes 和其生態(tài)，對于應(yīng)用開發(fā)和運維也提出更高的要求。企業(yè)在開發(fā)軟件應(yīng)用時，也要多方位考慮，包括應(yīng)用復(fù)雜度，訪問量，事務(wù)的要求，運維能力等。再選擇技術(shù)方案和中間件產(chǎn)品 / 云計算平臺。軟件設(shè)計從來都沒有銀彈，最適合的才是最好的。 今日薦文 點擊下方圖片即可閱讀 
|
