Spring Cloud 和 Kubernetes 都聲稱自己是開發和運行微服務的最佳環境，但它們在本質上有很大的不同，解決的問題也不同。我們將看看每個平臺是如何交付基于微服務架構(MSA)的？它們擅長哪些領域？以及如何充分利用這兩個領域在微服務的旅程中取得成功。

背景

最近我讀了很多關于用 Spring Cloud 結合容器化構建微服務架構的文章。如果您還沒有閱讀它，那么您應該多看看，因為它全面概述了如何使用 Spring Cloud 創建一個簡單的基于微服務的系統。為了構建一個可擴展且具有彈性的微服務系統，甚至可以擴展到數十個或數百個服務，必須在具有廣泛構建時和運行時功能的工具集的幫助下對其進行集中管理和治理。使用 Spring Cloud 過程涉及到實現功能性服務(如統計服務、帳戶服務和通知服務)和支持基礎設施服務(如日志分析、配置服務器、服務發現、認證服務)。下面是描述這種使用 Spring Cloud 的 MSA 的圖表:

這張圖涵蓋了系統的運行時方面，但沒有涉及打包、持續集成、擴展、高可用性和自修復方面，這些方面在 MSA 世界中也非常重要。假設大多數 Java 開發人員都熟悉 Spring Cloud，我們將進行比較，通過解決這些額外的問題來了解 Kubernetes 與 Spring Cloud 之間的關系。

微服務關注點

我們不需要逐個特性進行比較，而是來看看更廣泛的微服務關注點，看看 Spring Cloud 和 Kubernetes 是如何解決這些問題的。當今 MSA 的一個優點是，它是一種架構風格，其優點和利弊都得到了很好的平衡。微服務支持強大的模塊邊界、獨立部署和技術多樣性，但它們的代價是開發分布式系統和顯著的運營、成本開銷。因此，這是一個關鍵的成功因素，關注周圍的工具，將幫助您解決盡可能多的 MSA 關注。快速且輕松的開始很重要，但學習研究過程是漫長的，所以你需要足夠耐心才能到達。

 

在上面的圖表中，我們可以看到一個包含最常見的技術關注點的列表(我們不包括非技術關注點，例如組織結構、文化等等)，這些都必須在 MSA 中解決。這是我個人的觀點，不同的組織會有不同的看法，但在大多數情況下，它應該適用于每個人。

對比圖

這兩個平臺非常不同，它們之間不存在直接的功能對等。如果我們將每個 MSA 關注點映射到用于在兩種平臺上解決它的技術/項目上，我們會得到下表。

 

從上表可以得出的主要結論是:

• 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 的聲明式部署和調度功能使運行微服務變得非常容易。類似地，Spring Cloud 內有豐富的應用程序類庫，用于創建彈性、容錯等功能，使用 Hystrix(帶有熔斷、限流和斷路器模式)和 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 模式，以在 HTTP 上公開基于 Java 的客戶端庫，使用非 java 語言編寫的應用程序可能存在于 Netflix 生態系統中，但它不是很優雅。此外，自從我寫了這篇文章以來，Pivotal 還宣布了一個名為 SteelToe 的新項目，它允許使用 net 客戶端的服務發現和配置 Java 服務調用。

• 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 是一個多語言的通用容器管理平臺，能夠運行本地云和傳統的容器化應用程序。它提供的服務，如配置管理、服務發現、負載平衡、指標收集、日志聚合，都可以被各種語言使用。這允許在組織中擁有一個平臺，可以被多個團隊使用(包括使用 Spring 框架的 Java 開發人員)，并服務于多種目的:應用程序開發、測試環境、構建環境(用于運行源代碼控制系統、構建服務)

• 與 Spring Cloud 相比，Kubernetes 解決了更廣泛的 MSA 問題。除了提供運行時服務外，Kubernetes 還允許您提供環境、設置資源約束、RBAC、管理應用程序生命周期、支持自動伸縮和自愈(行為幾乎像一個抗脆弱的平臺)。

• 我忍不住要提到 Kubernetes 技術是基于谷歌 15 年的研發和管理容器的經驗。此外，它擁有近 1000 名提交者，是 Github 上最活躍的開源社區之一。

缺點

• Kubernetes 支持多種語言，因此它提供的服務是通用的，并沒有針對不同的平臺或者語言進行優化，比如針對 JVM 的 Spring Cloud。例如，配置作為環境變量或文件系統傳遞給應用程序。它沒有 Spring Cloud Config 提供配置自動更新功能特性。

• Kubernetes 并不是一個專注于開發者的平臺。它的目的是讓有 DevOps 意識的 It 人員使用。因此，Java 開發人員需要學習一些新概念，并以開放的心態學習解決問題的新方法。盡管使用 MiniKube 啟動 Kubernetes 實例的開發人員非常容易，但是手動安裝高可用的 Kubernetes 集群會帶來很大的操作成本。

• Kubernetes 仍然是一個相對較新的平臺，它仍然在積極開發和成長。因此，每個版本都會增加很多新特性，可能很難跟上。好消息是，它設計思想超前，而且 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 將配置分發給每個微服務。這樣的例子不勝枚舉。

微服務技術棧

那我最喜歡的微服務平臺是什么呢? 實話說我兩個都喜歡。我喜歡 Spring 框架提供的開發人員體驗。它完全是由注解驅動的，并且涵蓋有各種功能需求的組件。我還喜歡 Apache Camel，因為它在應用程序級別上集成連接器、消息傳遞、路由、彈性和容錯等功能。然后可以解決對于集群管理多個應用程序實例有關的任何事情，我更喜歡神奇的 Kubernetes 能力。每當有功能重疊時，比如服務發現、負載均衡、配置管理，我當然會嘗試使用 Kubernetes 提供的能力。