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提供的多語言原語。