擁抱Kubernetes,再見了Spring Cloud

相信很多開發者在熟悉微服務工作後，才發現：

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