用於微服務的Spring Cloud與Kubernetes相比
阿新 • • 發佈:2018-12-19
譯文,原文地址:https://developers.redhat.com/blog/2016/12/09/spring-cloud-for-microservices-compared-to-kubernetes/
Spring Cloud和Kubernetes都聲稱是開發和執行微服務的最佳環境,但它們在本質上都是非常不同的,並且解決了不同的問題。在本文中,我們將瞭解每個平臺如何幫助提供基於微服務的架構(MSA),以及他們擅長的領域,以及如何在微服務之旅中取得成功。背景故事
我隊最近讀了一篇關於用A. Lukyanchikov構建Spring Cloud和Docker微服務架構的文章。如果您還沒有閱讀它,那麼您應該,因為它全面概述了使用Spring Cloud建立基於微服務的簡單系統所需的內容。為了構建可擴充套件且具有彈性的微服務系統,該系統可以增長到數十或數百個服務,它必須在具有廣泛構建時間和執行時功能的工具集的幫助下進行集中管理和管理。使用Spring Cloud,涉及實現功能服務(例如統計服務,帳戶服務和通知服務)和支援基礎結構服務(例如日誌分析,配置伺服器,服務發現,身份驗證服務)。使用Spring Cloud描述此類MSA的圖表如下:微服務問題
我們不是通過功能比較來做一個功能,而是讓我們看看更廣泛的微服務問題,看看Spring Cloud和Kubernetes如何解決這些問題。今天MSA的一個好處是,它是一種具有良好理解效益和權衡的建築風格。微服務實現了強大的模組邊界,獨立部署和技術多樣性,它們但技術製圖
這兩個平臺非常不同,它們之間沒有直接的特徵奇偶性。如果我們將每個MSA關注點對映到用於在兩個平臺中解決它的技術/專案,我們會提出下表。 Spring Cloud和Kubernetes Technologies- Spring Cloud具有豐富的整合良好的Java庫,可以解決作為應用程式堆疊一部分的所有執行時問題。因此,微服務本身具有庫和執行時代理,可以進行客戶端服務發現,負載平衡,配置更新,度量跟蹤等。單例叢集服務,批處理作業等模式也在JVM中進行管理。
- Kubernetes是多語言,不僅僅針對Java的平臺,而是針對所有語言方式解決通用的分散式計算挑戰。它在應用程式堆疊之外的平臺級別上提供配置管理,服務發現,負載平衡,跟蹤,度量,單例,預定作業的服務。應用程式不需要任何用於客戶端邏輯的庫或代理,它可以用任何語言編寫。
- 在某些領域,兩個平臺都依賴於類似的第三方工具。例如ELK和EFK堆疊,跟蹤庫等。
- 一些庫如Hystrix,Spring Boot在這兩種環境中同樣有用。在某些領域,兩個平臺都是互補的,可以組合在一起以建立更強大的解決方案(KubeFlix和Spring Cloud Kubernetes就是這樣的例子)。
微服務要求
為了演示每個專案的範圍,這裡有一個(幾乎)端到端MSA要求的表格,從底部的硬體開始,到最頂層的的DevOps和自助服務體驗以及它與Spring Cloud和Kubernetes平臺。 微服務要求 在某些情況下,兩個專案都使用不同的方法處理相同的要求,在某些領域,一個專案可能比另一個專案更強。但也有一個甜蜜點,兩個平臺互為補充,可以結合使用,提供卓越的微服務體驗。例如,Spring Boot提供了用於構建單個jar應用程式包的Maven外掛。結合Docker和Kubernetes宣告的部署和排程功能,可以輕鬆執行Microservice。同樣,Spring Cloud具有應用內彈性建立庫,使用Hystrix(帶隔離和斷路器模式)和 Ribbon(用於負載平衡)建立彈性,容錯的微服務。但僅憑這一點是不夠的,當他與Kubernetes的執行時狀況檢查結合使用時,程序重啟和自動擴充套件功能將微服務轉變為真正的防碎片系統。長處和短處
由於兩個平臺都沒有直接比較功能,而不是挖掘每個專案,這裡是每個平臺總結的優缺點。Spring Cloud
Spring Cloud為開發人員提供了工具,可以快速構建分散式系統中的一些常見模式,例如配置管理,服務發現,斷路器,路由等。它構建於用Java開發人員編寫的基於Java的Netflix OSS庫之之上。優勢
- Spring Platform自身提供的統一程式設計模型,以及Spring Boot的快速應用程式建立功能,為開發人員提供了出色的微服務開發體驗。例如,只需很少的註釋就可以建立一個配置伺服器,而更少的註釋可以讓客戶端庫配置您的服務。
- 有大量的庫可以解決大多數執行時問題。由於所有庫都是用的Java編寫的,因此它提供了多種功能,更好的控制和微調選項。
- 不同的Spring Cloud庫彼此很好地整合在一起。例如,Feign客戶端也將使用Hystrix進行電路中斷,而Ribbon則用於負載平衡請求。一切都是註釋驅動,易於開發,感覺像Java開發人員的天堂。
弱點
- Spring Cloud的一個主要優點也是它的缺點 - 它僅限於Java .MSA的強大動力是能夠需要時更改技術堆疊,庫甚至語言。Spring Cloud無法做到這一點。如果您想使用Spring Cloud / Netflix OSS基礎架構服務,例如配置管理,服務發現,負載平衡,那麼解決方案並不優雅。在Netflix的普拉納的專案實現了跨鬥模式,以公開的基於Java的的客戶端庫通過HTTP,使其可能寫在非JVM語言應用在NetflixOSS生態系統中存在,但它是不是很優雅。此外,由於我寫了這篇文章,匹維託宣佈了一個名為SteelToe的新酷專案,它也允許從淨客戶端使用服務發現和配置伺服器服務。
- 沒有為Java的人員開發責任太多關心Java的狀語從句:應用程式來處理。每個微服務都需要執行各種客戶端來進行配置檢索,服務發現和負載平衡。設定它們很容易,但這並不會將執行時依賴性的構建時間隱藏到環境中。例如,我可以使用@EnableConfigServer建立一個配置伺服器容易註釋,但這只是快樂的道路。每次我想執行單個微服務時,我都需要啟動並執行Config Server 。對於受控環境,我必須考慮使用配置伺服器高度可用,並且因為它可以由Git或Svn支援,所以我需要共享檔案系統。同樣,對於服務發現,我需要首先啟動Eureka Server。對於受控環境,我需要在每個AZ等上集中多個例項。感覺就像Java的開發人員一樣,除了實現所有功能服務之外,我還必須構建和管理一個不重要的微服務平臺。
- 單獨的Spring Cloud在微服務之旅中的範圍較短,您還需要考慮自動部署,排程,資源管理,流程隔離,自我修復,構建管道等,以獲得完整的微服務體驗。對於這一點,我認為將Spring Cloud單獨與Kubernetes進行比較是不公平的,Spring Cloud + Cloud Foundry(或Docker Swarm)和Kubernetes之間的比較更公平。但這也意味著,對於完整的端到端微服務體驗,Spring Cloud必須補充類似Kubernetes本身的東西。
Kubernetes
Kubernetes是一個開源系統,用於自動化容器化應用程式的部署,擴充套件和管理。它是多語言,提供配置,執行,擴充套件和管理分散式系統的原語。優勢
- Kubernetes的英文一個多語言狀語從句:通用容器管理平臺個人文庫,能夠運行雲原生和傳統的容器化應用程式。它提供的服務(如配置管理,服務發現,負載平衡,指標收集,日誌聚合)可以通過各種語言使用。這允許組織中的一個平臺可供多個團隊(包括使用彈簧框架的Java的開發人員)使用並用於多種目的:應用程式開發,測試環境,構建環境(執行原始碼控制系統,構建伺服器,工件儲存庫),等等
- 與Spring Cloud相比,Kubernetes 解決了更廣泛的MSA問題。除了提供執行時服務之外,Kubernetes還允許您配置環境,設定資源約束,RBAC,管理應用程式生命週期,啟用自動縮放和自我修復(行為就像幾乎反一個混亂平臺個人文庫)。
- 我無法抗拒自己提到Kubernetes技術是基於谷歌15年的研發和管理容器的經驗。此外,有近千個提交者,它是Github上上最活躍的開源社群之一。
弱點
- Kubernetes是多語言,因此它的服務和原語是通用的,並沒有針對不同的平臺進行優化,例如Spring Cloud for JVM。例如,配置作為環境變數或已安裝的檔案系統傳遞給應用程式。它沒有Spring Cloud Config提供的精美配置更新功能。
- Kubernetes 不是一個專注於開發人員的平臺。它旨在供的DevOps志同道合的IT人員使用。因此,Java的開發人員需要學習一些新概念,並開放學習解決問題的新方法。儘管使用MiniKube啟動Kubernetes的開發人員例項非常容易,但是手動安裝高可用性Kubernetes叢集會產生大量的操作開銷。
- Kubernetes仍然是一個相對較新的平臺(2歲),仍在它積極開發狀語從句:發展。因此,每個版本都添加了許多新功能,這些功能可能難以跟上。好訊息是,已經設想了這個,並且API是可擴充套件和向後相容的。