[[361031]]

 相信很多Java從業者在熟悉了微服務開發后，自以為用 Spring Cloud 已經成功打造了微服務架構帝國，Java 已經壟斷微服務領域，殊不知當引入 k8s 后，Spring Cloud 卻和 Cloud Native 的生態發展脫軌了。

從 2013 年的 Spring Boot

2012年10月，Mike Youngstrom在Spring jira中創建了一個功能需求，要求在Spring框架中支持無容器Web應用程序體系結構。他建議通過main方法引導的Spring容器內配置Web容器服務。這一需求促成了2013年初開始的Spring Boot項目。2014年4月，Spring Boot 1.0.0發布。從那以后，一些Spring Boot小版本開始出現。

• Spring Boot 1.1(2014年6月)：改進的模板支持，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，緩存技術的自動配置(ehcache，hazelcast，redis，guava和infinispan)以及完全可執行的jar支持
• Spring boot 1.4(2017年1月)：升級到spring 4.3，couchbase/neo4j支持，啟動失敗分析和RestTemplateBuilder
• Spring boot 1.5(2017年2月)：支持kafka /ldap，第三方庫升級，放棄對CRaSH支持和執行器日志終端用以動態修改應用程序日志級別
• Spring boot的簡便性使java開發人員能夠快速大規模地應用于項目。Spring boot可以說是Java中開發基于RESTful微服務Web應用的最快方法之一。它也非常適合docker容器部署和快速原型設計
• Spring Boot 2.0.0，于2018年3月1日發布，新版本特點有：基于 Java 8，支持 Java 9;支持 Quartz 調度程序;支持嵌入式 Netty，Tomcat, Undertow 和 Jetty 均已支持 HTTP/2;執行器架構重構，支持 Spring MVC, WebFlux 和 Jersey;對響應式編程提供最大支持;引入對 Kotlin 1.2.x 的支持，并提供了一個 runApplication 函數，用Kotlin 通用的方式啟動 Spring Boot 應用程序。

一直到 Spring Cloud，第一批選型它的大公司很早就構建出了完整微服務生態，很多解決方案也被開源，很多坑點已被國內巨頭踩完所以相當穩定。對于很多想要使用微服務架構的中小公司，這絕對是最佳進場時機，直接使用 Spring Cloud 全家桶，絕對是穩定而正確的微服務架構選擇。

但當你所在公司引入 k8s 后，就變天了。

k8s 和 Spring Cloud 的激烈沖突

Java 生態的 Spring Cloud 可謂是迄今最完整的微服務框架，基本滿足所有微服務架構需求，網上教程也不勝枚舉。但也因為 Spring Cloud 生態過于完整，而如今 k8s 又大行其道，當我們把基于 Spring Cloud 開發的服務放到 k8s 后， 一些機制就不受 k8s 生態管控了。

因為從擴展部署、運維角度出發的 k8s，在最原始容器、應用部署及網絡層管理的基礎上，已逐步實現并貼近應用層的需要，一些微服務架構下的基礎需求(如：Service Discovery、API Gateway 等)開始直接或間接被納入 k8s 生態。導致雙方有很多組件功能重疊，只能擇一而終。比如一旦你選了 Spring Cloud 的解決方案，就得放棄 k8s 那邊的機制。

Spring Cloud 官方提供的解決方案

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

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

該解決方案重點如下：

服務發現 (Service Discovery)

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

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

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

配置管理 (Configuration Management)

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

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

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

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

Spring Cloud V.S k8s 重疊方案

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

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