2017年，這一年在容器技術(shù)發(fā)展史上具有重要的分水嶺意義，標(biāo)志著“后微服務(wù)時代”的開始。這一年，發(fā)生了幾件重大事件，徹底改變了容器管理領(lǐng)域的格局。

首先是 CoreOS，一直以來與 Docker 競爭的 RKT 容器技術(shù)的領(lǐng)頭羊，宣布放棄其容器管理系統(tǒng) Fleet，轉(zhuǎn)而支持 Kubernetes。接著，容器管理行業(yè)的領(lǐng)頭羊 Rancher Labs 也放棄了自家多年開發(fā)的 Cattle 系統(tǒng)，采納“All-in-Kubernetes”的策略，從此 Rancher 2.0 版本起只支持 Kubernetes。

同年，Kubernetes 的主要對手 Apache Mesos 宣布了與 Kubernetes 的集成計劃，“Kubernetes on Mesos”，這標(biāo)志著他們從競爭對手轉(zhuǎn)變?yōu)橹С终?，?Kubernetes 能夠與 Mesos 的其他頂級框架（例如 HDFS、Spark 和 Chronos 等）實現(xiàn)資源的動態(tài)共享和隔離。

此外，2017年10月，Docker 的母公司，也是 Kubernetes 最大的競爭對手之一，宣布 Docker 將同時支持 Swarm 和 Kubernetes，這在事實上承認了 Kubernetes 的領(lǐng)導(dǎo)地位。

這些事件標(biāo)志著長達三至四年的容器技術(shù)競爭戰(zhàn)爭，主要圍繞 Docker Swarm、Apache Mesos 和 Kubernetes，最終以 Kubernetes 的勝利告終。Kubernetes 的崛起不僅是容器技術(shù)發(fā)展的一個重要里程碑，也預(yù)示著軟件架構(gòu)發(fā)展新紀(jì)元的到來。

需求場景

在采用了基于 Spring Cloud 的微服務(wù)架構(gòu)之后，小書店 Fenix's Bookstore(虛擬) 成功地應(yīng)對了伸縮性、獨立部署、運維管理等方面的挑戰(zhàn)，以及產(chǎn)品經(jīng)理提出的日益增長的復(fù)雜業(yè)務(wù)需求。然而，對于團隊中的開發(fā)者、設(shè)計師和架構(gòu)師來說，工作并沒有變得更加輕松。微服務(wù)所涉及的新技術(shù)術(shù)語，如配置中心、服務(wù)發(fā)現(xiàn)、網(wǎng)關(guān)、熔斷、負載均衡等，對新手來說學(xué)習(xí)曲線陡峭。而從產(chǎn)品的角度看，Spring Cloud 的各種組件，如 Config、Eureka、Zuul、Hystrix、Ribbon、Feign 等，也構(gòu)成了產(chǎn)品編譯后代碼的主要部分。

微服務(wù)架構(gòu)選擇在應(yīng)用層面解決分布式問題，而不是在基礎(chǔ)設(shè)施層面，主要是因為軟件的應(yīng)用服務(wù)比硬件基礎(chǔ)設(shè)施更加靈活，而后者難以跟上前者的步伐。但是，隨著 Kubernetes 在容器編排管理方面的統(tǒng)一，這些技術(shù)性的底層問題開始在基礎(chǔ)設(shè)施層面找到了廣泛認可的解決方案。因此，F(xiàn)enix's Bookstore 開始了它在“后微服務(wù)時代”的又一次架構(gòu)升級，此次升級主要集中在兩個目標(biāo)上。

Fenix's Bookstore 的微服務(wù)架構(gòu)升級主要圍繞兩個核心目標(biāo)進行。第一個目標(biāo)是減少非業(yè)務(wù)功能代碼的占比。在這家書店的系統(tǒng)中，用戶服務(wù)（Account）、商品服務(wù)（Warehouse）和交易服務(wù)（Payment）是承擔(dān)實際業(yè)務(wù)邏輯的核心模塊。而認證授權(quán)服務(wù)（Security）則同時涉及技術(shù)和業(yè)務(wù)層面，配置中心（Configuration）、網(wǎng)關(guān)（Gateway）和服務(wù)注冊中心（Registry）則完全是技術(shù)性質(zhì)的組件。目的是盡可能地消除這些純技術(shù)組件，以及那些附屬于其他業(yè)務(wù)模塊的技術(shù)性功能。

第二個目標(biāo)是在盡量不改變原有代碼的情況下完成遷移。依托于 Spring Framework 4 中的 Conditional Bean 等聲明式編程特性，現(xiàn)代 Java 技術(shù)組件越來越傾向于聲明式（Declarative Programming）而非命令式編程（Imperative Programming）。這樣的編程風(fēng)格允許開發(fā)者從目標(biāo)出發(fā)描述編碼意圖，而不是圍繞具體的技術(shù)實現(xiàn)過程，從而減少代碼與技術(shù)實現(xiàn)的耦合。如果需要更換技術(shù)實現(xiàn)，只需調(diào)整配置聲明即可。

從升級的角度看，如果僅以 Java 代碼來衡量，這次遷移到 Kubernetes 后的項目與之前基于 Spring Cloud 的版本在代碼層面上沒有任何區(qū)別，每一行 Java 代碼都保持不變。但實際上，區(qū)別在于 Kubernetes 實現(xiàn)中直接刪除了配置中心和服務(wù)注冊中心等工程，在其他工程的 pom.xml 文件中也移除了像 Eureka、Ribbon、Config 等組件的依賴。取而代之的是引入了一系列以 YAML 配置文件為基礎(chǔ)的 Skaffold 和 Kubernetes 資源描述。這些資源描述文件將動態(tài)構(gòu)建出 DNS 服務(wù)器、服務(wù)負載均衡器等虛擬化基礎(chǔ)設(shè)施，替代了原有應(yīng)用層面的技術(shù)組件。升級后的應(yīng)用架構(gòu)如下圖所示：

圖片

技術(shù)組件

Fenix's Bookstore 采用基于 Kubernetes 的微服務(wù)架構(gòu)，并采用 Spring Cloud Kubernetes 做了適配，其中主要的技術(shù)組件包括以下幾種。

在 Fenix's Bookstore 的微服務(wù)架構(gòu)中，為了實現(xiàn)容器環(huán)境的感知，我們使用了Spring Cloud Kubernetes，它集成了 Fabric8 的 Kubernetes Client。但是，Spring Cloud Kubernetes 版本 1.1.2 中使用的 Fabric8 Kubernetes Client 版本是 4.4.1，這個版本根據(jù) Fabric8 提供的兼容性列表，僅支持到 Kubernetes 1.14。盡管在 Kubernetes 1.16 上也能運行，但在 1.18 版本上就無法正確識別 Api-Server。因此，在 Maven 項目中添加依賴時，需要手動排除舊版本，并引入更新的版本（在這個項目中使用的是 4.10.1）。

配置管理方面，項目利用 Kubernetes 的 ConfigMap 來進行配置管理，并通過 Spring Cloud Kubernetes Config 自動地將 ConfigMap 的內(nèi)容注入到 Spring 的配置文件中，實現(xiàn)動態(tài)更新。服務(wù)發(fā)現(xiàn)是通過 Kubernetes 的 Service 實現(xiàn)的，Spring Cloud Kubernetes Discovery 能自動將 HTTP 服務(wù)請求轉(zhuǎn)換為完全限定域名（FQDN）。負載均衡方面，則直接利用 Kubernetes Service 的內(nèi)置負載均衡功能（即 DNS 負載均衡），因此不再需要像 Ribbon 這樣的客戶端負載均衡組件。從 Spring Cloud Kubernetes 1.1.2 開始，Ribbon 的適配支持已被移除，且暫時沒有對 Spring Cloud LoadBalancer 這一替代品提供適配。

至于服務(wù)網(wǎng)關(guān)，雖然保留了 Zuul，但沒有采用 Kubernetes 的 Ingress 來替代。這里有兩個主要考慮因素：首先，Ingress Controller 并非 Kubernetes 的內(nèi)置組件，有多種可選方案（例如 KONG、Nginx、Haproxy 等），且需要獨立安裝。為了保持演示項目的環(huán)境簡單，我選擇不使用 Ingress；其次，考慮到 Fenix's Bookstore 的前端項目存放在網(wǎng)關(guān)中，即使移除了 Zuul，仍然需要保持一個前端項目的存在。因此，移除 Zuul 并不能進一步減少項目數(shù)量，這減弱了移除 Zuul 的必要性

在 Fenix's Bookstore 的微服務(wù)架構(gòu)更新中，服務(wù)熔斷功能仍然由 Hystrix 實現(xiàn)。由于 Kubernetes 本身不提供細致的服務(wù)治理能力，如熔斷、流量控制和監(jiān)控等，我們計劃在后續(xù)基于 Istio 的服務(wù)網(wǎng)格架構(gòu)中解決這些問題。在認證授權(quán)方面，我們繼續(xù)使用 Spring Security OAuth 2.0。雖然 Kubernetes 的 RBAC（基于角色的訪問控制）能夠處理服務(wù)層面的訪問控制問題，但 Spring Security 跨越了業(yè)務(wù)和技術(shù)的界限，其認證授權(quán)模塊仍然負責(zé)前端用戶的認證和授權(quán)，這是與業(yè)務(wù)直接相關(guān)的部分。

它是基于 Apache 2.0 協(xié)議授權(quán)的。遵守這一許可協(xié)議的條件下，你可以自由地對代碼進行修改和重新發(fā)布，甚至用于商業(yè)目的。但是，你需要遵守以下要求：署名在原始代碼及其衍生代碼中保留原作者的署名和代碼來源信息；保留許可證在原始代碼及其衍生代碼中保留 Apache 2.0 協(xié)議文件。