微服務Spring Cloud與Kubernetes比較

轉 http://www.tuicool.com/articles/VnMf2y3

Spring Cloud或Kubernetes都宣稱它們是開發運行微服務的最好環境，哪一個更好？答案是兩個都是，但他們擁有各自不一樣的特徵方式。

背景故事

最近，Lukyanchikov發表了一篇使用Spring Cloud和Docker創建微服務架構的 文章 。 它給出瞭如何使用Spring Cloud建立一個簡單的基於微服務的系統所需的全面概述。 爲構建一個可擴展到數十或數百個服務的伸縮彈性的微服務系統，必須藉助具備寬泛的構建時間和運行能力的工具集進行集中管理和管理。 Spring Cloud包括實現功能性服務（如統計服務，賬戶服務和通知服務）和支持基礎設施服務（如日誌分析，配置服務器，服務發現，受權服務）。

這些服務涵蓋了系統的運行時各個方面，但不涉及打包，持續集成，擴展，高可用性和自我修復，這在MSA(微服務架構)世界中也很是重要。 假設大多數Java開發人員熟悉Spring Cloud，在本文中，咱們將繪製一個平行圖，經過解決這些額外的問題，瞭解Kubernetes與Spring Cloud的關係。

有關MSA的好處是，它有一種架構風格很好理解的好處，微服務可實現強大的模塊邊界，具備獨立的部署和技術多樣性。 但代價是開發 分佈式 系統成本和顯著運營開銷 。一個關鍵的成功因素是使用各類工具解決這些問題，

微服務關注點

微服務關注方面有：配置管理、服務發現與負載平衡、彈性和失敗冗餘、API管理、安全服務、中央集中日誌、集中測量、分佈式跟蹤、調度部署和自動擴展self Healing等幾個方面。

根據這些觀點，得出Spring Cloud和Kubernetes兩個平臺映射：

1.配置管理：配置服務器、Consul和Netflix Archaius（Spring Cloud）；Kubernetes ConfigMap&Secrets ;

2.服務發現: Netflix Eureka,Hashicorp Consul(Spring Cloud);Kubernetes Service&Ingress Resource;

3.負載平衡：Netflix Ribbon（Spring Cloud）；Kubernetes Service

4.API網關：Netflix Zuul（SpringCloud）；Kubernetes Service&Ingress Resource

5.安全服務：SpringCloud Security

6.中央集中日誌：ELK Stack（LogStash）；EFKstack（Fluentd）。

7.集中測量：Netflix Spectator& Atlas；Heapster、Prometheus、Grafana。

8.分佈式跟蹤：SpringCloud Sleuth，Zipkin；OpenTracing、Zipkin

9.彈性和失敗冗餘：Netflix Hystrix、Turbine&Ribbon；Kubernetes Health Check&resource isolation

10.自動擴展self Healing：Spring Cloud無；Kubernetes Health Check、SelfHealing、Autoscaling

11.打包 部署和調度部署：Spring Boot；Docker／Rkt、Kubernetes Scheduler&Deployment

12.任務工做管理：Spring Batch；Kubernetes Jobs&Scheduled Jobs

13.單個應用：Spring Cloud Cluster ；Kubernetes Pods

Spring Cloud有一套豐富的集成良好的Java庫，做爲應用程序棧一部分解決全部運行時問題。 所以，微服務自己經過庫和運行時做爲代理來執行客戶端服務發現，負載平衡，配置更新，度量跟蹤等。諸如單例集羣服務和批處理做業的模式也在JVM中進行管理。

Kubernetes是多語言的，不只針對Java平臺，並以通用的方式爲全部語言解決 分佈式 計算的挑戰。 它提供應用程序棧外部的配置管理，服務發現，負載平衡，跟蹤，度量，單例，平臺調度做業等平臺級別功能。 該應用系統不須要任何庫或代理程序用於客戶端邏輯，它能夠用任何語言編寫。

在某些方面，這兩個平臺都依賴相似的第三方工具。例如，ELK和EFK堆棧，跟蹤庫等一些庫，如Hystrix和Spring Boot，在這兩種環境中一樣有用。

有些狀況下這兩個平臺是互補的，而且能夠結合在一塊兒，創造一個更增強大的解決方案,例如，Spring Boot提供了用於構建單個JAR應用程序包的Maven插件。結合Docker和Kubernetes的聲明性部署和調度功能，使微服務運行變得垂手可得。 相似地，Spring Cloud具備應用程序庫，用於使用Hystrix（斷路器）和Ribbon（用於負載平衡）建立彈性的，容錯的微服務。 可是單單這是不夠的，當它與Kubernetes的健康檢查，進程從新啓動和自動擴展功能相結合時，微服務成爲一個真正的抗脆弱的系統。

長處和短處

因爲兩個平臺不具備直接的可比性特徵，下面是逐項總結其優勢和缺點。

Spring Cloud爲開發人員提供了快速構建 分佈式 系統中的一些常見模式的工具，例如配置管理，服務發現，斷路器，路由等。它是爲Java開發人員使用，構建在Netflix OSS庫之上的。

優點

1.Spring Platform提供的統一編程模型和Spring Boot的快速應用程序建立能力爲開發人員提供了巨大的微服務開發體驗。 例如，使用不多的註釋，您能夠建立一個配置服務器，而且幾乎沒有更多的註釋，您能夠得到客戶端庫來配置您的服務。

2.有豐富的庫選擇，覆蓋大多數運行時關注。因爲全部庫都是用Java編寫的，它提供了多種功能，更好的控制和精細調整選項。

3.不一樣的Spring Cloud庫彼此徹底集成。例如，Feign客戶端還將使用Hystrix用於斷路器，而且Ribbon用於負載平衡請求。 一切都是註釋驅動的，使其易於爲Java開發人員開發。

弱點

1.Spring Cloud的一個主要優勢是它的缺點 - 它僅限於Java。MSA的強大動力是在須要時交換各類技術棧，庫，甚至語言的能力。 只是使用Spring Cloud是不可能的。 若是您想要使用Spring Cloud / Netflix OSS基礎架構服務（如配置管理，服務發現或負載平衡），那麼解決方案就不那麼優雅。 在Netflix的 Prana項目經過基於HTTP暴露Java客戶端實現了sidecar模式，使其可能讓非JVM語言運行在NetflixOSS生態系統中，但它不是很優雅。

2.Java開發人員關心Java應用程序並須要處理太多與開發無關的事情。每一個微服務須要運行各類客戶端以進行配置檢索，服務發現和負載平衡。雖然很容易設置，但這並不會下降對環境的構建時間和運行時依賴性。例如，開發人員可使用@EnableConfigServer建立一個配置服務器，但這只是開心的假象。 每當開發人員想要運行單個微服務時，他們須要啓動並運行Config Server。對於受控環境，開發人員必須考慮使Config Server高度可用，而且因爲它能夠由Git或Svn支持，所以它們須要一個共享文件系統。 相似地，對於服務發現，開發人員須要首先啓動Eureka服務器。 爲了建立一個受控的環境，他們須要在每一個AZ上使用多個實例實現集羣。像開發人員同樣，除了實現全部功能服務以外，Java開發人員還必須構建和管理一個非平凡的微服務平臺。

3.Spring Cloud在微服務發展過程只有很短歷程，開發人員還須要考慮自動化部署，調度，資源管理，過程隔離，自我修復，構建管道等，以得到完整的微服務體驗。 對於這點，我認爲這是不公平的比較，應該比較 Spring Cloud + Cloud Foundry (or Docker Swarm) 和Kubernetes。但這也意味着對於一個完整的端到端微服務體驗，Spring Cloud必須補充一個像Kubernetes自己這樣的應用程序平臺。

Kubernetes是一個用於自動化部署，擴展和管理容器化應用程序的開源系統。 它是多種語言而且提供用於供應，運行，擴展和管理 分佈式 系統的操做系統。

優點

1.Kubernetes是一個多語言和語言不可知的容器管理平臺，可以運行雲本地和傳統的容器化應用程序。其提供的服務（如配置管理，服務發現，負載平衡，測量指標收集和日誌聚合）可供各類語言使用。 這容許在一個組織中有一個平臺，能夠被多個團隊（包括使用Spring的Java開發人員）使用，並提供多種用途：應​​用程序開發，測試環境，構建環境（運行源代碼控制系統，構建服務器，工件存儲庫）等。

2.與Spring Cloud相比，Kubernetes解決了更普遍的MSA問題。 除了提供運行時服務，Kubernetes也可讓你規定的環境中，設置資源限制，RBAC，管理應用程序生命週期，啓用自動縮放和自我修復（幾乎表現得像一個抗脆弱平臺）。

3.Kubernetes技術基於Google 15年的研發經驗和管理容器的經驗。此外，有近1000個提交者，它是Github上最活躍的開源社區之一。

弱點

1. Kubernetes是多語言的，所以它的服務是通用的，並不針對不一樣的平臺（如Spring Cloud for JVM）進行優化。 例如，配置做爲環境變量或安裝的文件系統傳遞到應用程序。 它沒有Spring Cloud Config提供的奇特的配置更新功能。

2.Kubernetes不是一個以開發人員爲中心的平臺。 它旨在由DevOps的IT人員使用。所以，Java開發人員須要學習一些新的概念，並開放學習解決問題的新方法。手動安裝高度可用的Kubernetes集羣有一個顯著操做的開銷。

3.Kubernetes仍然是一個相對較新的平臺（2歲），它仍然積極發展和成長。所以，每一個版本都添加了不少新功能，可能很難跟上。 好消息是，這已經被考慮到，API將是可擴展和向後兼容的。

最好的兩個世界

正如你所看到的，這兩個平臺在某些領域有優點，在其餘領域有待改進。 Spring Cloud是一個快速開始的開發者友好平臺，而Kubernetes是DevOps友好的，具備更陡峭的學習曲線，但涵蓋了更普遍的微服務關注點。

這兩個框架涉及不一樣範圍的MSA關注，他們以一種根本不一樣的方式去實現。 Spring Cloud方法試圖解決JVM中的每一個MSA挑戰，而Kubernetes方法試圖經過在平臺層面解決爲開發人員解決問題。 Spring Cloud在JVM內部很是強大，Kubernetes在管理這些JVM方面功能強大。結合他們，並從兩個項目的最好的部分受益。

有了這樣的組合，Spring提供了應用程序打包，而Docker和Kubernetes提供了部署和調度。 Spring經過Hystrix線程池提供應用程序防火牆，Kubernetes經過資源，進程和命名空間隔離提供防火牆。Spring爲每一個微服務提供健康端點，Kubernetes執行健康檢查和流量路由到健康的服務。 Spring負責外部化和更新配置，Kubernetes將配置分發到每一個微服務。