前些年，隨著微服務(wù)的概念提出以及落地，不斷有很多的公司都加入到了這場技術(shù)革新中，現(xiàn)在可謂是人人都在做和說微服務(wù)。
提到微服務(wù)，Java棧內(nèi)，就不得不提SpringBoot、SpringCloud、Dubbo。
近幾年，隨著Cloud Native技術(shù)的普及，又涌現(xiàn)出了一大批新技術(shù)，Docker、Kubernetes、Istio、Service Mesh，這些新技術(shù)的加入，又對(duì)微服務(wù)有了更深層次的定位。
那么，我們?cè)撊绾稳ザㄎ贿@些技術(shù)在我們實(shí)際工作中的應(yīng)用呢？如果你參與到了技術(shù)選型中，就不得不把這些弄清晰，否則將毒害整個(gè)團(tuán)隊(duì)。

首先讓我們了解下SpringBoot和SpringCloud的發(fā)展（下列內(nèi)容摘自網(wǎng)絡(luò)）

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)用程序。

隨著2015年3月SpringCloud的第一個(gè)版本Angel發(fā)布，微服務(wù)的全部落地，正式拉開序幕。
SpringCloud是一系列框架的有序集合。它利用Spring Boot的開發(fā)便利性巧妙地簡化了分布式系統(tǒng)基礎(chǔ)設(shè)施的開發(fā)，如服務(wù)發(fā)現(xiàn)注冊(cè)、配置中心、消息總線、負(fù)載均衡、斷路器、數(shù)據(jù)監(jiān)控等，都可以用Spring Boot的開發(fā)風(fēng)格做到一鍵啟動(dòng)和部署。Spring Cloud并沒有重復(fù)制造輪子，它只是將各家公司開發(fā)的比較成熟、經(jīng)得起實(shí)際考驗(yàn)的服務(wù)框架組合起來，通過Spring Boot風(fēng)格進(jìn)行再封裝屏蔽掉了復(fù)雜的配置和實(shí)現(xiàn)原理，最終給開發(fā)者留出了一套簡單易懂、易部署和易維護(hù)的分布式系統(tǒng)開發(fā)工具包。我們可以看出，Spring Cloud 是一套微服務(wù)框架。

我們?cè)賮砹私庀翶ubernetes與SpringCloud的對(duì)比

想要更多的了解SpringCloud可以參考我的另幾份文章
微服務(wù) 一：微服務(wù)架構(gòu)概述
微服務(wù) 二：微服務(wù)開發(fā)框架SpringCloud
微服務(wù) 三：服務(wù)注冊(cè)與發(fā)現(xiàn)
微服務(wù) 四：客戶端負(fù)載均衡器
微服務(wù) 五：斷路器
微服務(wù) 六：服務(wù)網(wǎng)關(guān)
微服務(wù) 七：配置管理
微服務(wù) 八：服務(wù)跟蹤
微服務(wù) 九：持續(xù)交付

Kubernates概述
下一代微服務(wù)技術(shù)-服務(wù)網(wǎng)格-Istio

SpringCloud與Kubernetes的功能重疊

SpringCloud與Kubernetes的層次重疊

Kubernetes和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ī)制。

服務(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ù)載均衡和熔斷器。

最后

• 目前Kubernetes已成容器編排技術(shù)的事實(shí)標(biāo)準(zhǔn)，容器編排將意味著服務(wù)、計(jì)算資源將能夠更高效的被調(diào)度。如果你拋棄編排，或者自己構(gòu)建一套編排系統(tǒng)，你將異常艱辛；
• 遇到很多項(xiàng)目是使用了Kubernetes編排，但是微服務(wù)全家桶使用了SpringCloud，當(dāng)你對(duì)兩個(gè)技術(shù)有了充分的理解之后，你也會(huì)異常的難受，既啟用了Kubernetes相關(guān)功能，但又要跛腳的去調(diào)試SpringCloud內(nèi)部功能。比如：Kubernetes內(nèi)部啟用了DNS實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)，即方便又高效，但是SpringCloud又有自己的服務(wù)發(fā)現(xiàn)，雙層服務(wù)發(fā)現(xiàn)，讓人實(shí)在難受。
• 沒有一成不變的技術(shù)方案，優(yōu)雅的方案是可以隨著時(shí)代，逐漸迭代，從而更新自我，如果我們一開始的方向錯(cuò)了，便將逐漸走入到另一個(gè)洪流之中，最終也將消失。