【架構】Kubernetes和Spring Cloud哪一個部署微服務更好？

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