Spring Cloud 和Kubernetes都自稱自己是部署和運行微服務的最好環境，但是它們在本質上和解決不同問題上是有很大差異的。在本文中，我們將看到每個平台如何幫助交付基於微服務的架構（MSA），它們擅長哪個領域，並且如何兩全其美的使用從而在微服務之旅上獲得成功。
背景
最近我讀了 A. Lukyanchikov的一篇非常棒的文章（https://dzone.com/articles/microservice-architecture-with-spring-cloud-and-do），關於使用Spring Cloud和Docker來構建微服務架構。如果你還沒看過，建議你看一下，它給出了一個綜合的概述：如何使用Spring Cloud來創建一個簡單的基於微服務的系統。為了創建一個可增長到數十或上百個服務的可擴展、彈性的微服務系統，必須在一個擁有廣泛構建時和運行能力工具集的幫助下集中管理和治理。通過Spring Cloud，涉及到實現功能性服務（例如統計服務、賬戶服務和通知服務）並且支持基礎服務（例如日志分析、配置服務器、服務發現、服務授權）。一個使用Spring Cloud的MSA描述圖表如下：
用Spring Cloud的MSA（來自A. Lukyanchikov）
這張圖涵蓋了系統的運行方面，但是不涉及打包、持續集成、縮放、高可用和自我修復，這些在MSA中同樣非常重要。我們假設大部分Java開發人員熟悉Spring Cloud，在本文中，我們將做個類比並且看看Kubernetes如何聯系Spring Cloud來處理這些額外的障礙。
微服務障礙
通過特征對比而不是做一個比較，我們來看一下廣闊的微服務障礙和Spring Cloud與Kubernetes如何處理這些障礙。如今MSA的優點就是它是一種得益於易理解和權衡下的架構風格。微服務通過獨立部署和多樣化技術使得模塊邊界強化。但是它們以開發分布式系統成本和巨大的運營開銷為代價。一個關鍵的成功要素就是集中在周圍的工具上，將會幫你處理盡可能多的MSA問題。啟動過程快而簡單是很重要的，但是產品過程是很長的，你需要變得更厲害才能成功。
微服務關注點
在上面的圖中，我們可以看到一個最常見的技術障礙列表（不涵蓋非技術性的障礙，例如組織結構、文化等等）需要在MSA中處理。
技術映射
兩個平台Spring Cloud和Kubernetes非常不同並且它們之間沒有直接的相同特征。如果在兩個平台上每個MSA障礙映射到技術/項目以前常用來處理它，會提出如下圖表。
Spring Cloud和Kubernetes技術
上面的圖表主要的結論就是：
- Spring Cloud擁有豐富的、綜合的JAVA類庫來處理所有執行障礙作為部分應用堆棧。因此，微服務自身有類庫和執行代理來做客戶端服務發現負載均衡、配置升級、指標追蹤等等。模式例如單例模式集群服務和批量作業也在JVM中管理。
- Kubernetes可多語言，沒有只是把JAVA平台當目標，處理了所有語言用一類方法的分布式計算挑戰。它為了在平台層配置管理、服務發現、負載均衡、追蹤、指標、單例模式、調度作業提供服務，並且在應用套件之外。應用程序為了客戶端邏輯無需任何類庫或代理，它可以使用任何語言來編寫。
- 在一些方面，兩個平台依靠相似的第三方工具。例如ELK和EFK stacks, tracing libraries等等。一些類庫，像是Hystrix和Spring Boot，在兩個環境中都同樣使用很好。在一些方面兩個平台是互補的，可以組合創建一個更強大的解決方案( KubeFlix 和Spring Cloud Kubernetes這樣的例子)。
微服務需求
為了演示每個項目的范圍，這里有個（幾乎）端到端的MSA需求表格，在底部從硬件開始，上到頂部DevOps和自服務經驗，以及它如何將Spring Cloud和Kubernetes平台聯系到一起。
微服務需求
在某些情況下，兩個項目用不同的方法滿足同樣的需求，在一些方面，一個項目可以比另一個項目更強。但也有個sweet的地方，就是兩個平台可以互補並組合成一個更出眾的微服務體驗。例如，Spring Cloud提供Maven插件來創建單獨JAR應用程序包。結合Docker、Kubernetes的聲明式部署和調度能力，輕松運行微服務。同樣，Sring Cloud有應用程序內類庫來創建彈性、容錯微服務，使用Hystrix（bulkhead和斷路器模式）與Ribbon（負載均衡）。但這是不夠的，當組合Kubernetes健康檢查、過程重啟和自動伸縮能力，微服務變成一個真正的抗脆弱系統。
優點和缺點
因為兩個平台沒有直接可比的功能特征，不是挖掘每個條目，以下是每個平台的優缺點總結。
Spring Cloud
Spring Cloud為開發人員提供工具，在分布式系統中來快速構建一些常用模塊，例如配置管理、服務發現、斷路機制、路由等等。在Netflix OSS庫頂層構建，用java編寫，面向Java開發人員。
優點
- Spring平台本身提供統一的編程模式和Spring Boot的快速應用創建能力，給開發人員一個優質的微服務開發體驗。例如，用少量的注解就可以創建一個配置服務器，再多一點注解，可以用客戶類庫來設置服務。
- 類庫有豐富的選擇，覆蓋大部分運行障礙。當所有類庫使用java編寫好，它提供多種特征、優秀的控制和微調選項。
- 不同的Spring Cloud類庫可與另一個很好的結合。舉個例子，一個Feign端同樣使用Hystrix作斷路機制，Ribbon作負載均衡需求。所有都是注解驅動的，讓Java開發人員更簡單的開發。
缺點
- Spring Cloud的一個主要優勢也是其缺點就是——它只能使用Java。MSA一個推動動機就是交換技術堆棧、類庫甚至語言的能力，當需要時。用Spring Cloud是不可能的。如果你想使用Spring Cloud/Netflix OSS基礎設置服務，例如配置管理、服務發現或者負載均衡，解決方案是不優雅的。Netflix Prana項目實現了sidecar模式，顯示基於Java客戶類庫越過HTTP，使得用non-JVM語言編寫的應用程序存在於NetflixOSS生態系統變得可能，但它不是很優雅。
- Java開發人員有責任關心並且處理Java應用程序。每個微服務需要運行各種客戶端來配置恢復、服務發現和負載均衡。設置它們很容易，但沒有隱藏創建時和運行時對環境的依賴性。例如，開發人員創建一個使用EnableConfigServer的配置服務器，但這只是高興的方法。每次開發人員想運行一個單個微服務，他們需要配置服務器啟動並運行。對於控制環境中，開發運行需要思考讓配置服務器高可用，因為它可以通過Git和SVN支持，他們需要一個共享文件系統。同樣，為了服務發現，開發人員首先需要啟動一個Eureka服務。一個受控制的環境，他們需要在每個AZ上用多個實例集群等等。就像一個Java開發人員需要創建和管理一個除了實現所有功能服務之外的非凡的微服務平台。
- 在微服務旅程中，Spring Cloud獨自擁有一個小范圍，為了一個完整的微服務體驗，開發人員也將需要考慮自動部署、調度、資源管理、進程隔離、自我修復、構建管道等等。對於這點，我認為比較單獨Spring Cloud和Kubernetes是不公平的，一個更公平的比較是Spring Cloud+ Cloud Foundry (或Docker Swarm)與Kubernetes。但那也意味着一個完整的端到端微服務體驗，Spring Cloud必須補充一個應用程序平台，就像Kubernetes那樣。
Kubernetes
Kubernetes是一個開源系統，用來自動部署、縮放和管理容器應用。它可以使用多語言並且提供原語服務開通、運行、縮放和分布式系統管理。
優點
- Kubernetes是一個多語言和未可知語言的容器管理平台，它可以運行原生雲和運行傳統容器化應用程序。它提供的服務，例如配置管理、服務發現、負載均衡、指標收集和日志聚集，都通過各種各樣的語言來實現。這允許組織中有多個團隊來使用一個平台（包括Java開發者使用Spring），並且用於多種目的：應用程序開發、測試環境、創建環境（運行資源控制系統、創建服務其、存儲庫）等等。
- 當比較Spring Cloud、Kubernetes處理廣泛MSA問題時，除了提供運行服務，Kubernetes也讓你提供環境、設置資源限制、RBAC、管理應用程序生命周期，實現自動縮放和自我修復（表現的幾乎像是一個抗脆弱的平台）。
- Kubernetes技術是基於谷歌15年的R&D和管理容器的經驗。另外，將近1000名提供者，這是在Github上最活躍的一個開源社區之一。
缺點
- Kubernetes是多語言的，同樣的，它的服務和原語是通用的，並且對於不同平台來說不是最佳的，例如Spring Cloud for JVM。舉個例子，配置傳遞給應用程序作為環境變量或掛載文件系統。它沒有Spring Cloud Config提供的奇特的配置升級能力。
- Kubernetes不是一個面向開發者的平台。它打算讓那些在意DevOps的人員來使用。因此，Java開發人員需要學習一些新概念和開放的學習一些新方法來解決問題。盡管它是超簡單的開始一個開發人員使用 MiniKube的Kubernetes實例，這有一個巨大的操作開銷就是手動安裝一個高可用的Kubernetes集群。
- Kubernetes仍然是一個相對較新的平台（2歲），它還在積極的發展和成長。因此伴隨着每次釋放有許多新特性增加，可能很難跟上。好消息是這是設想中的，API是可擴展和向后兼容的。
兩個世界中的最佳
如你所見，兩個平台在核心領域都很強，並且在其他領域改進。Spring Cloud可以快速使用、對開發者友好的平台，然而Kubernetes對DevOps友好，艱難的學習曲線，但是覆蓋更廣泛的微服務障礙。以下是這些點的總結。
優點和缺點
兩種架構處理了不同范圍的MSA障礙，並且它們從根本上用了不同的方法。Spring Cloud方法是試圖解決在JVM中每個MSA挑戰，然而Kubernetes方法是試圖讓問題消失，為開發者在平台層解決。Spring Cloud在JVM中非常強大，Kubernetes管理那些JVM很強大。同樣的，它就像一個自然發展，結合兩種工具並且從兩個項目中最好的部分受益。
通過Kubernetesd支持的Spring Cloud
通過這樣一種結合，Spring提供應用程序打包，Docker和Kubernetes提供部署和調度。Spring通過Hystrix線程池提供應用程序內隔板，Kubernetes通過資源、進程和命名空間隔離提供隔板。Spring為每個微服務提供健康終端，Kubernetes執行健康檢查並且為健康服務通信路由。Spring外部化且升級配置，Kubernetes給每個微服務分配配置。這樣的還有很多。
我喜歡的微服務堆棧
我最喜歡哪個微服務平台？兩個都喜歡。我喜歡Spring框架帶來的開發者體驗。全部都是注解驅動的，類庫覆蓋所有種類的功能需求。我也喜歡Apache Camel（寧願Spring Spring Integration）為集成、連接器、消息、路由、彈性和在應用層的容錯所做的。然后與集群和多種應用程序實例管理，我更喜歡Kubernetes神奇的力量。每當有一個功能重疊，例如服務發現、負載均衡、配置管理，我試着使用Kubernetes提供的多語言原語。
參考資料：
http://blog.csdn.net/qq_34463875/article/details/53816943
spring-boot 和 docker 集成：http://www.open-open.com/lib/view/open1450684294167.html