Spring Cloud for Microservices與Kubernetes的比較

Spring Cloud for Microservices與Kubernetes的比較

和都聲稱是開發和運行微服務的最佳環境，但是它們本質上截然不同並且解決了不同的問題。在本文中，我們將研究每個平臺如何幫助交付基於微服務的體系結構（MSA），它們擅長的領域，以及如何兼顧兩者，才能成功實現微服務之旅。

背景故事

最近，我讀了關於建立微服務架構隨著春季雲和碼頭工人由A. Lukyanchikov。如果您還沒有閱讀它，則應該閱讀，因為它全面概述了使用Spring Cloud創建基於簡單微服務的系統所需要的工作。為了構建可擴展到數十個或數百個服務的可伸縮且具有彈性的微服務系統，必須藉助具有廣泛構建時間和運行時功能的工具集來對其進行集中管理和控制。使用Spring Cloud，它既要實現功能服務（例如統計服務，帳戶服務和通知服務），又要支持基礎架構服務（例如日誌分析，配置服務器，服務發現，身份驗證服務）。下圖描述了使用Spring Cloud的此類MSA：

帶有Spring Cloud的MSA（作者：A。Lukyanchikov）

該圖涵蓋了系統的運行時方面，但沒有涉及打包，持續集成，可伸縮性，高可用性，自我修復方面，這在MSA領域中也非常重要。假設大多數Java開發人員都熟悉Spring Cloud，在本文中，我們將得出一個類似的結論，並通過解決這些額外的問題來了解Kubernetes與Spring Cloud的關係。

使用Red Hat最有價值的產品進行開發

您的會員資格可解鎖有關企業雲應用程序開發的Red Hat產品和技術培訓。

微服務問題

與其進行逐個功能的比較，不如讓我們看一下更廣泛的微服務問題，並瞭解Spring Cloud和Kubernetes如何解決這些問題。如今，關於MSA的一件好事是它是一種具有公認的的建築風格。微服務可實現強大的模塊邊界，獨立部署和技術多樣性，但它們開發分佈式系統和。因此，押寶並被工具包圍是成功的關鍵因素，這些工具將幫助您解決儘可能多的MSA問題。快速簡便的開始很重要，但是生產過程很漫長，要達到就必須要有。

微服務問題

在上圖中，我們可以看到一個清單，其中包含最常見的技術問題（我們未涵蓋組織結構，文化等非技術問題），必須在MSA中解決。我的觀點是不同的組織會有所不同，但是在大多數情況下，它應該適用於每個人。

技術映射

這兩個平臺非常不同，它們之間沒有直接的功能奇偶校驗。如果我們將每個MSA問題映射到用於在兩個平臺上解決該問題的技術/項目，我們將得出下表。

Spring Cloud和Kubernetes技術

上表的主要內容是：

· Spring Cloud具有一組豐富的，高度集成的Java庫，可以解決所有運行時問題，並將其作為應用程序堆棧的一部分。結果，微服務本身具有庫和運行時代理，可以執行客戶端服務發現，負載平衡，配置更新，指標跟蹤等。單例集群服務，批處理作業等模式也可以在JVM中進行管理。

· Kubernetes是多語言的，不僅針對Java平臺，而且以通用的方式針對所有語言解決了分佈式計算難題。它在應用程序堆棧之外的平臺級別提供用於配置管理，服務發現，負載平衡，跟蹤，指標，單例，計劃作業的服務。該應用程序不需要任何用於客戶端邏輯的庫或代理，並且可以用任何語言編寫。

· 在某些領域，兩個平臺都依賴於類似的第三方工具。例如ELK和EFK堆棧，跟蹤庫等。

· 諸如Hystrix，Spring Boot之類的某些庫在兩種環境下都同樣有用。在某些領域中，

微服務要求

為了演示每個項目的範圍，下表列出了（幾乎）端到端的MSA需求，從底部的硬件開始，到頂部的DevOps和自助服務經驗以及它與Spring的關係如何。Spring Cloud和Kubernetes platforms。

微服務要求

在某些情況下，兩個項目都使用不同的方法滿足相同的要求，並且在某些方面，一個項目可能比另一個項目更強大。但是，兩個平臺可以相互補充，並且可以組合使用，以提供卓越的微服務體驗，這也是一個最佳選擇。例如，Spring Boot提供了用於構建單個jar應用程序包的Maven插件。結合使用Docker和Kubernetes的聲明式部署和調度功能，使運行微服務變得輕而易舉。同樣，Spring Cloud具有應用程序內庫，可使用Hystrix（具有隔板和斷路器模式）和Ribbon（用於負載平衡）來創建彈性的，容錯的微服務。但是，僅憑這一點還不夠，當與Kubernetes健康檢查結合使用時，

長處和短處

由於這兩個平臺不是逐個特徵地直接可比，而不是逐項研究，因此這裡總結了每個平臺的優缺點。

Spring Cloud為開發人員提供了工具，可在分佈式系統中快速構建一些常見模式，例如配置管理，服務發現，斷路器，路由等。它基於Java編寫的Netflix OSS庫（面向Java開發人員）構建。

長處

· Spring平臺本身提供的

· 有很多庫可以解決大多數運行時問題。而且，由於所有庫都是用Java編寫的，因此它提供了多種功能，更好的控制和微調選項。

· 不同的Spring Cloud庫相互之間很好地集成在一起。例如，Feign客戶端還將使用Hystrix進行斷路，並使用Ribbon來平衡請求。一切都是註釋驅動的，易於開發，感覺就像Java開發人員的天堂。

弱點

· Spring Cloud的主要優點之一就是它的缺點- 它僅限於Java。MSA的強大動力是能夠在需要時更改技術堆棧，庫甚至語言。Spring Cloud無法做到這一點。如果您想使用Spring Cloud / Netflix OSS基礎架構服務（例如配置管理，服務發現，負載平衡），則該解決方案並不理想。在項目實現了跨鬥模式，以公開的基於Java的客戶端庫通過HTTP，使其可能寫在非JVM語言應用在NetflixOSS生態系統中存在，但它是不是很優雅。此外，自從我撰寫本文以來，Pivotal宣佈了一個名為項目，這也允許從.Net客戶端使用服務發現和Config Server服務。

· Java開發人員要負責處理Java應用程序，這要承擔太多責任。每個微服務都需要運行各種客戶端以進行配置檢索，服務發現和負載平衡。設置起來很容易，但是並不能掩蓋運行時對環境的依賴的構建時間。例如，我可以使用@EnableConfigServer創建一個配置服務器。註釋很容易。每次我想運行一個微服務時，都需要啟動並運行Config Server。對於受控環境，我必須考慮使Config Server高度可用，並且由於它可以由Git或Svn支持，因此我需要共享文件系統。同樣，對於服務發現，我需要首先啟動Eureka Server。對於受控環境，我需要將其與每個AZ上的多個實例進行集群。感覺像Java開發人員，除了實現所有功能服務之外，我還必須構建和管理一個不平凡的Microservices平臺。

· 僅Spring Cloud 在Microservices旅程中的範圍更短，並且您還需要考慮自動化部署，調度，資源管理，進程隔離，自我修復，構建管道等，以獲取完整的Microservices體驗。就這一點而言，我認為將Spring Cloud與Kubernetes單獨進行比較是不公平的，而更合理的比較應該是Spring Cloud + 。但這也意味著，要獲得完整的端到端微服務體驗，必須為Spring Cloud補充Kubernetes本身。

Kubernetes是一個開源系統，用於自動化容器化應用程序的部署，擴展和管理。它是多語言的，並提供了用於配置，運行，擴展和管理分佈式系統的原語。

長處

· Kubernetes是一個多語言和通用容器管理平臺，能夠運行雲原生和傳統容器化應用程序。它提供的服務（例如配置管理，服務發現，負載平衡，指標收集，日誌聚合）可以通過多種語言來使用。這允許在組織中擁有一個可以供多個團隊（包括使用Spring框架的Java開發人員）使用的平臺，並可以滿足多種目的：應用程序開發，測試環境，構建環境（運行源代碼控制系統，構建服務器，工件存儲庫），等等

· 與Spring Cloud相比，Kubernetes 解決了更多的MSA問題。除了提供運行時服務外，Kubernetes還允許您置備環境，設置資源約束，RBAC，管理應用程序生命週期，啟用自動縮放和自我修復（幾乎像一個平臺一樣）。

· 我不禁要提及Kubernetes技術是基於Google的15年研發經驗和容器管理經驗而建立的。此外，它擁有近1000個提交者，是Github上

弱點

· Kubernetes是多語言的，因此其服務和原語是通用的，並未針對諸如Spring Cloud for JVM之類的不同平臺進行優化。例如，配置作為環境變量或完整的文件系統傳遞給應用程序。它沒有Spring Cloud Config提供的高級配置更新功能。

· Kubernetes 不是以開發人員為中心的平臺。打算由具有DevOps意識的IT人員使用。因此，Java開發人員需要學習一些新概念，並樂於學習解決問題的新方法。儘管使用啟動Kubernetes的開發人員實例非常，但是手動安裝高度可用的Kubernetes集群仍然存在大量操作開銷。

· Kubernetes仍然是一個相對較新的平臺（已有2年的歷史了），並且仍在積極地開發和發展。因此，每個發行版中都添加了許多新功能，這些新功能可能很難跟上。好消息是，已經設想到了這一點，並且該API是可擴展的並且向後兼容。

如您所見，這兩個平臺在某些領域都有優勢，而在其他領域則有待改進。Spring Cloud是開發人員友好的平臺，可快速上手，而Kubernetes是DevOps友好的，具有陡峭的學習曲線，但涵蓋了更多的微服務問題。這是這些要點的摘要。

長處和短處

這兩個框架都解決了MSA的不同關注範圍，並且它們以根本不同的方式來處理。Spring Cloud方法試圖通過使開發人員易於解決來解決JVM內部的每個MSA挑戰，而Kubernetes方法試圖通過在平臺級別解決它來使開發人員解決該問題。Spring Cloud在JVM內部非常強大，而Kubernetes在管理這些JVM方面非常強大。因此，將它們結合起來並從兩個項目的最佳部分中受益似乎是一種自然的進步。

Kubernetes支持的Spring Cloud

通過這種組合，Spring提供了應用程序打包，而Docker和Kubernetes提供了部署和調度。Spring通過Hystrix線程池提供應用程序內隔離，而Kubernetes通過資源，進程和名稱空間隔離提供隔離。Spring為每個微服務提供運行狀況端點，而Kubernetes執行運行狀況檢查並將流量路由到運行狀況良好的服務。Spring外部化並更新配置，Kubernetes將配置分發給每個微服務。而且這個清單還在繼續。

我最喜歡的微服務堆棧

我最喜歡的微服務平臺如何？我倆喜歡。我喜歡Spring框架提供的開發人員經驗。它全部由註釋驅動，並且庫涵蓋了所有功能需求。我還喜歡Apache Camel（在這種情況下為Spring Integration），它與應用程序級的集成，連接器，消息傳遞，路由，彈性和容錯性有關。然後，對於與集群和管理多個應用程序實例有關的任何事情，我更喜歡Kubernetes功能。每當有功能重疊（例如服務發現，負載平衡，配置管理）時，我都會嘗試使用Kubernetes提供的多語言原語。

閱讀更多 愛上樹的程序猿 的文章

關鍵字: 比較 分佈式計算 Java虛擬機