相信很多開發(fā)者在熟悉微服務(wù)工作后，才發(fā)現(xiàn)：
以為用 Spring Cloud 已經(jīng)成功打造了微服務(wù)架構(gòu)帝國蟹腾，殊不知引入了 k8s 后，卻和 Cloud Native 的生態(tài)發(fā)展脫軌值戳。
從 2013 年的 Spring Boot
2012年10月炉爆，Mike Youngstrom在Spring jira中創(chuàng)建了一個(gè)功能需求，要求在Spring框架中支持無容器Web應(yīng)用程序體系結(jié)構(gòu)赴捞。他建議通過main方法引導(dǎo)的Spring容器內(nèi)配置Web容器服務(wù)衩辟。這一需求促成了2013年初開始的Spring Boot項(xiàng)目的開發(fā)波附。2014年4月，Spring Boot 1.0.0發(fā)布封寞。從那以后仅财，一些Spring Boot小版本開始出現(xiàn)盏求。
- Spring Boot 1.1（2014年6月）：改進(jìn)的模板支持，gemfire支持磅废，elasticsearch和apache solr的自動(dòng)配置
- Spring boot 1.2（2015年3月）：升級(jí)到servlet 3.1/tomcat 8/jetty 9和spring 4.1荆烈，支持banner/jms /SpringBoot Application注釋
- Spring boot 1.3（2016年12月）：升級(jí)到spring4.2，新的spring-boot-devtools宫峦，緩存技術(shù)的自動(dòng)配置（ehcache玫鸟，hazelcast，redis妥曲，guava和infinispan）以及完全可執(zhí)行的jar支持
- Spring boot 1.4（2017年1月）：升級(jí)到spring 4.3，couchbase/neo4j支持铸本，啟動(dòng)失敗分析和RestTemplateBuilder
- Spring boot 1.5（2017年2月）：支持kafka /ldap遵堵，第三方庫升級(jí)，放棄對(duì)CRaSH支持和執(zhí)行器日志終端用以動(dòng)態(tài)修改應(yīng)用程序日志級(jí)別
- Spring boot的簡便性使java開發(fā)人員能夠快速大規(guī)模地應(yīng)用于項(xiàng)目锡足。 Spring boot可以說是Java中開發(fā)基于RESTful微服務(wù)Web應(yīng)用的最快方法之一壳坪。它也非常適合docker容器部署和快速原型設(shè)計(jì)
- 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徙歼；對(duì)響應(yīng)式編程提供最大支持；引入對(duì) Kotlin 1.2.x 的支持魄梯，并提供了一個(gè) runApplication 函數(shù)，用Kotlin 通用的方式啟動(dòng) Spring Boot 應(yīng)用程序灭翔。
一直到 Spring Cloud肝箱，第一批選型它的大公司很早就構(gòu)建出了完整微服務(wù)生態(tài)，很多解決方案開放源碼煌张，很多坑點(diǎn)已被踩完相當(dāng)穩(wěn)定。
對(duì)于很多想要使用微服務(wù)架構(gòu)的中小公司链嘀，絕對(duì)是最佳進(jìn)場時(shí)機(jī)怀泊，直接使用 Spring Cloud 全家桶误趴，絕對(duì)是穩(wěn)定而正確的選擇。
但當(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)的工具和機(jī)制管控轴或。
因?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)致雙方有很多組件功能重復(fù)静浴，且只能擇一而終， 一旦你選了 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、Hashicorp曹锨。主要原理都是在服務(wù)部署時(shí)，去注冊(cè)自己的服務(wù)齐鲤，讓其他服務(wù)可檢索到自己椒楣。
spring.cloud.service-registry.auto-registration.enabled
@EnableDiscoveryClient(autoRegister=false)
但在 k8s ，服務(wù)的注冊(cè)和查詢由 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 可使用碘裕，而且通常還會(huì)搭配 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ù)載均衡和熔斷器會(huì)依賴服務(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)然也能完全不理會(huì) k8s 原生組件，完全采用 Spring Boot 和 Spring Cloud 的解決方案顽素，只把 k8s 當(dāng)做部署應(yīng)用的工具和平臺(tái)胁出。但顯然在未來，Service Mesh 及其通用的 Cloud Native 技術(shù)發(fā)展闹蒜，就會(huì)和Spring Cloud脫軌抑淫，無法再和我們的應(yīng)用深度整合始苇。
相比于 Spring Cloud 生態(tài)都只能使用 Java ， k8s 生態(tài)的發(fā)展和設(shè)計(jì)更為通用且廣泛函喉，一些 Spring Cloud 內(nèi)的元件功能荣月，在 Kubernetes 除了包含支援以外哺窄，甚至有更多的整合和考量及延伸的功能账锹。
由于 CNCF 的推波助瀾及更多國際大廠投入奸柬，新工具啤握、運(yùn)維方法排抬、整合能力層出不窮。因此番甩，在選型微服務(wù)架構(gòu)時(shí)届搁，k8s 的各種原生解決方案卡睦，都需要被放入評(píng)估考量中。
目前網(wǎng)絡(luò)上很多 Spring Boot 和 Spring Cloud 的很多已經(jīng)過時(shí)恕齐，而且都沒整合 k8s显歧，與當(dāng)下主流的基礎(chǔ)設(shè)施環(huán)境有落差，學(xué)習(xí)時(shí)都要自己斟酌考量确镊。
