相信很多Java從業(yè)者在熟悉了微服務(wù)開發(fā)后，自以為用 Spring Cloud 已經(jīng)成功打造了微服務(wù)架構(gòu)帝國，Java 已經(jīng)壟斷微服務(wù)領(lǐng)域，殊不知當(dāng)引入?k8s 后，Spring Cloud 卻和 Cloud Native 的生態(tài)發(fā)展脫軌了。

從 2013 年的 Spring Boot

2012年10月，Mike Youngstrom在Spring jira中創(chuàng)建了一個功能需求，要求在Spring框架中支持無容器Web應(yīng)用程序體系結(jié)構(gòu)。他建議通過main方法引導(dǎo)的Spring容器內(nèi)配置Web容器服務(wù)。這一需求促成了2013年初開始的Spring Boot項(xiàng)目。2014年4月，Spring Boot 1.0.0發(fā)布。從那以后，一些Spring Boot小版本開始出現(xiàn)。

• Spring Boot 1.1（2014年6月）：改進(jìn)的模板支持，gemfire支持，elasticsearch和apache solr的自動配置

• Spring boot 1.2（2015年3月）：升級到servlet 3.1/tomcat 8/jetty 9和spring 4.1，支持banner/jms /SpringBoot Application注釋

• Spring boot 1.3（2016年12月）：升級到spring4.2，新的spring-boot-devtools，緩存技術(shù)的自動配置（ehcache，hazelcast，redis，guava和infinispan）以及完全可執(zhí)行的jar支持

• Spring boot 1.4（2017年1月）：升級到spring 4.3，couchbase/neo4j支持，啟動失敗分析和RestTemplateBuilder

• Spring boot 1.5（2017年2月）：支持kafka /ldap，第三方庫升級，放棄對CRaSH支持和執(zhí)行器日志終端用以動態(tài)修改應(yīng)用程序日志級別

• Spring boot的簡便性使java開發(fā)人員能夠快速大規(guī)模地應(yīng)用于項(xiàng)目。Spring boot可以說是Java中開發(fā)基于RESTful微服務(wù)Web應(yīng)用的最快方法之一。它也非常適合docker容器部署和快速原型設(shè)計

• Spring Boot 2.0.0，于2018年3月1日發(fā)布，新版本特點(diǎn)有：基于 Java 8，支持 Java 9；支持 Quartz 調(diào)度程序；支持嵌入式 Netty，Tomcat, Undertow 和 Jetty 均已支持 HTTP/2；執(zhí)行器架構(gòu)重構(gòu)，支持 Spring MVC, WebFlux 和 Jersey；對響應(yīng)式編程提供最大支持；引入對 Kotlin 1.2.x 的支持，并提供了一個 runApplication 函數(shù)，用Kotlin 通用的方式啟動 Spring Boot 應(yīng)用程序。

一直到 Spring Cloud，第一批選型它的大公司很早就構(gòu)建出了完整微服務(wù)生態(tài)，很多解決方案也被開源，很多坑點(diǎn)已被國內(nèi)巨頭踩完所以相當(dāng)穩(wěn)定。對于很多想要使用微服務(wù)架構(gòu)的中小公司，這絕對是最佳進(jìn)場時機(jī)，直接使用 Spring Cloud 全家桶，絕對是穩(wěn)定而正確的微服務(wù)架構(gòu)選擇。

但當(dāng)你所在公司引入?k8s 后，就變天了。

k8s 和 Spring Cloud 的激烈沖突

Java 生態(tài)的 Spring Cloud 可謂是迄今最完整的微服務(wù)框架，基本滿足所有微服務(wù)架構(gòu)需求，網(wǎng)上教程也不勝枚舉。但也因?yàn)?Spring Cloud 生態(tài)過于完整，而如今 k8s?又大行其道，當(dāng)我們把基于 Spring Cloud 開發(fā)的服務(wù)放到 k8s 后， 一些機(jī)制就不受 k8s 生態(tài)管控了。

因?yàn)閺臄U(kuò)展部署、運(yùn)維角度出發(fā)的 k8s，在最原始容器、應(yīng)用部署及網(wǎng)絡(luò)層管理的基礎(chǔ)上，已逐步實(shí)現(xiàn)并貼近應(yīng)用層的需要，一些微服務(wù)架構(gòu)下的基礎(chǔ)需求（如：Service Discovery、API Gateway 等）開始直接或間接被納入 k8s 生態(tài)。導(dǎo)致雙方有很多組件功能重疊，只能擇一而終。比如一旦你選了 Spring Cloud 的解決方案，就得放棄 k8s 那邊的機(jī)制。

Spring Cloud 官方提供的解決方案

為解決該問題，官方在 Github 上提供了開源方案，說明如何以 Spring Cloud 整合 Kubernetes 生態(tài)下的元件，主要討論從原本組件架構(gòu)過度并一直到 Kubernetes 原生環(huán)境后的處理方法?

https://github.com/spring-cloud/spring-cloud-kubernetes

該解決方案重點(diǎn)如下：

服務(wù)發(fā)現(xiàn) (Service Discovery)

Spring Cloud 的經(jīng)典解決方案：Netflix Eureka、Alibaba Nacos。主要原理都是在服務(wù)部署時，去注冊自己的服務(wù)，讓其他服務(wù)可檢索到自己。

spring.cloud.service-registry.auto-registration.enabled@EnableDiscoveryClient(autoRegister=false)

但在 k8s ，服務(wù)的注冊和查詢由 Service 元件負(fù)責(zé)，其連線名稱，是利用內(nèi)部 DNS 實(shí)現(xiàn)。這代表我們要將服務(wù)發(fā)現(xiàn)功能，接上 k8s 的 Service 機(jī)制。為達(dá)成目的，方案中提供了 DiscoveryClient 組件，讓基于 Spring Cloud 所開發(fā)的程序可方便查詢其他服務(wù)。使用了 Kubernetes 原生的服務(wù)發(fā)現(xiàn)，才能被 Istio 追蹤，未來才能納入 Service Mesh 的管控。

配置管理 (Configuration Management)

Spring Cloud 的解決方案：spring-cloud-config。但在 Kubernetes 上，有 ConfigMap 和 Secret 可使用，而且通常還會搭配 Vault 管理敏感配置。

而該方案提供了 ConfigMapPropertySource 和 SecretsPropertySource，來存取 Kubernetes 上的 ConfigMap 和 Secret。

負(fù)載均衡和熔斷器 (Load Balancing & Circuit Breaker)

Spring Cloud原有方案：Netflix Ribbon 和 Hystrix，但在 k8s 有 Service 實(shí)現(xiàn)負(fù)載均衡，以及 Istio 可實(shí)現(xiàn)熔斷器，開發(fā)者只需專注 crud。由于負(fù)載均衡和熔斷器會依賴服務(wù)發(fā)現(xiàn)機(jī)制，因此 Ribbon 和 Hytrix 原先的功能在 k8s 原生環(huán)境下失效。該解決方案內(nèi)雖然有提到一些關(guān)于 Ribbon 整合 Kubernetes 原生環(huán)境的實(shí)現(xiàn)，但相關(guān)鏈接已消失，應(yīng)該是放棄了。所以推薦避免使用客戶端的負(fù)載均衡和熔斷器。

Spring Cloud V.S k8s 重疊方案

我們當(dāng)然也能完全不理會?k8s 原生組件，完全采用 Spring Boot 和 Spring Cloud 的解決方案，只把 k8s 當(dāng)做部署應(yīng)用的工具和平臺。但顯然在未來，Service Mesh 及其通用的 Cloud Native 技術(shù)發(fā)展，就會和Spring Cloud脫軌，無法再和我們的應(yīng)用深度整合。

相比于 Spring Cloud 生態(tài)都只能使用 Java ， k8s 生態(tài)的發(fā)展和設(shè)計更為通用且廣泛，一些 Spring Cloud 內(nèi)的元件功能，在 Kubernetes 除了包含支援以外，甚至有更多的整合和考量及延伸的功能。由于 CNCF 的推波助瀾及更多國際大廠投入，新工具、運(yùn)維方法、整合能力層出不窮。因此，在選型微服務(wù)架構(gòu)時，k8s 的各種原生解決方案，都需要被放入評估考量中。目前網(wǎng)絡(luò)上很多 Spring Boot 和 Spring Cloud 的很多已經(jīng)過時，而且都沒整合 k8s，與當(dāng)下主流的基礎(chǔ)設(shè)施環(huán)境有落差，學(xué)習(xí)時都要斟酌。