1. 程式人生 > >用於微服務的Spring Cloud與Kubernetes相比

用於微服務的Spring Cloud與Kubernetes相比

譯文,原文地址:https://developers.redhat.com/blog/2016/12/09/spring-cloud-for-microservices-compared-to-kubernetes/

Spring CloudKubernetes聲稱是開發和執行微服務的最佳環境,但它們在本質上都是非常不同的,並且解決了不同的問題。在本文中,我們將瞭解每個平臺如何幫助提供基於微服務的架構(MSA),以及他們擅長的領域,以及如何在微服務之旅中取得成功。

背景故事

我隊最近讀了一篇關於用A. Lukyanchikov構建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中解決。這是我的觀點,對於不同的組織而言會有所不同,但在大多數情況下,它應該適用於所有人。

技術製圖

這兩個平臺非常不同,它們之間沒有直接的特徵奇偶性。如果我們將每個MSA關注點對映到用於在兩個平臺中解決它的技術/專案,我們會提出下表。 Spring Cloud和Kubernetes Technologies
上表的主要內容是:
  • Spring Cloud具有豐富的整合良好的Java庫,可以解決作為應用程式堆疊一部分的所有執行時問題。因此,微服務本身具有庫和執行時代理,可以進行客戶端服務發現,負載平衡,配置更新,度量跟蹤等。單例叢集服務,批處理作業等模式也在JVM中進行管理。
  • Kubernetes是多語言,不僅僅針對Java的平臺,而是針對所有語言方式解決通用的分散式計算挑戰。它在應用程式堆疊之外的平臺級別上提供配置管理,服務發現,負載平衡,跟蹤,度量,單例,預定作業的服務。應用程式不需要任何用於客戶端邏輯的庫或代理,它可以用任何語言編寫。
  • 在某些領域,兩個平臺都依賴於類似的第三方工具。例如ELK和EFK堆疊,跟蹤庫等。
  • 一些庫如Hystrix,Spring Boot在這兩種環境中同樣有用。在某些領域,兩個平臺都是互補的,可以組合在一起以建立更強大的解決方案(KubeFlixSpring 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是可擴充套件和向後相容的。

兩全其美

正如您所看到的,這兩個平臺在某些領域都具有優勢,而在其他領域也有待改進.Spring Cloud是一個快速入門,開發人員友好的平臺,而Kubernetes是DevOps友好的,具有陡峭的學習曲線,但涵蓋了更廣泛的微服務問題。以下是這些要點的摘要。 長處和短處 這兩個框架都針對不同的MSA問題,他們以一種根本不同的方式來解決這個問題.Spring Cloud方法試圖通過讓開發人員輕鬆解決JVM內部的每個MSA挑戰,而Kubernetes方法試圖通過在平臺級別解決問題來使問問消失.Spring Cloud在JVM中非常強大,而Kubernetes在管理這些JVM方面非常強大。因此,將它們結合起來並從兩個專案的最佳部分中受益,感覺就像是一種自然的進步。 Spring Cloud由Kubernetes支援 通過這樣的組合,Spring提供了應用程式打包,Docker和Kubernetes提供了部署和排程.Spring通過Hystrix執行緒池提供應用程式內批量處理,Kubernetes通過資源,程序和名稱空間隔離提供批量處理.Spring為每個微服務提供健康端點,Kubernetes執行健康檢查和流量路由到健康服務.Spring外部化和更新配置,Kubernetes將配置分發給每個微服務。這個清單一直在繼續。 我最喜歡的微服務堆疊 我最喜歡的微服務平臺怎麼樣?我喜歡他們。我喜歡Spring框架提供的開發人員體驗。它是所有註釋驅動的,並且有涵蓋所有功能需求的庫。我也喜歡Apache Camel(在本例中)中是Spring Integration),它與應用程式級別的整合,聯結器,訊息傳遞,路由,彈性和容錯有關。然後,對於與群集和管理多個應用程式例項有關的任何事情,我更喜歡神奇的Kubernetes功能。每當功能重疊時,例如服務發現,負載平衡,配置管理,我都會嘗試使用Kubernetes提供的多語言原語。