相信很多開發者在熟悉微服務工作後，才發現：
以為用 Spring Cloud 已經成功打造了微服務架構帝國，殊不知引入了 k8s 後，卻和 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、Hashicorp。主要原理都是在服務部署時，去註冊自己的服務，讓其他服務可檢索到自己。

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，與當下主流的基礎設施環境有落差，學習時都要自己斟酌考量。

參考

• https://www.cnblogs.com/doit8791/p/10507858.html