SpringCloud PK K8s 誰更勝一籌

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

背景

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

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

微服務關(guān)注點

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

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

對比圖

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

從上表可以得出的主要結(jié)論是:

• Spring Cloud 有一組豐富的集成良好的 Java 庫，可以作為應用程序堆棧的一部分解決所有運行時問題。因此，微服務本身就有庫和運行時代理來進行客戶端服務發(fā)現(xiàn)、負載均衡、配置更新、指標檢測等功能。但這些服務都是在 JVM 中進行管理。

• Kubernetes 支持多種語言，它不僅針對 Java 平臺，而且以通用的方式解決了分布式計算的挑戰(zhàn)。它在應用程序堆棧之外的平臺層上提供了配置管理、服務發(fā)現(xiàn)、負載均衡、跟蹤、度量、代理、調(diào)度作業(yè)等服務。應用程序不需要添加任何客戶端邏輯庫或代理，也可以用任何語言編寫。

• 在某些領(lǐng)域，兩個平臺都依賴于類似的第三方工具。例如，ELK 和 EFK 棧，鏈路跟蹤庫等等。

• 有一些組件，如 Hystrix、Spring Boot，在這兩種環(huán)境中都很有用。在一些領(lǐng)域，這兩個平臺是互補的，可以結(jié)合在一起創(chuàng)建一個更強大的解決方案(KubeFlix 和 Spring Cloud Kubernetes 就是這樣的例子)。

微服務必要條件

為了說明每個項目的范圍，這里有一個(幾乎)端到端的 MSA 需求表，從底部硬件開始，到頂部的 DevOps 和自助化部署服務，以及它與 Spring Cloud 和 Kubernetes 平臺的關(guān)系。

在某些情況下，兩個項目使用不同的方法來處理相同的需求，在某些領(lǐng)域，這一個可能比另一個更強。但這兩個平臺也有一個互補點，可以結(jié)合在一起提供更優(yōu)質(zhì)的微服務體驗。例如，Spring Boot 為構(gòu)建單個 jar 應用程序包提供了 Maven 插件。Docker 和 Kubernetes 的聲明式部署和調(diào)度功能使運行微服務變得非常容易。類似地，Spring Cloud 內(nèi)有豐富的應用程序類庫，用于創(chuàng)建彈性、容錯等功能，使用 Hystrix(帶有熔斷、限流和斷路器模式)和 Ribbon(用于負載均衡)。但光有這些是不夠的，當它與 Kubernetes 健康檢查、進程重啟和自動擴展等功能相結(jié)合才能將微服務變成一個真正的抗脆弱系統(tǒng)。

優(yōu)點和缺點

由于這兩種平臺并不是直接按功能進行比較，而是技術(shù)層面對比，以下是每種平臺的優(yōu)缺點總結(jié)。

Spring Cloud

Spring Cloud 為開發(fā)人員提供工具，以快速構(gòu)建分布式系統(tǒng)中的一些常見模式，如配置管理、服務發(fā)現(xiàn)、斷路器、路由等。它建立在 Netflix oss 庫之上，用 Java 編寫，供 Java 開發(fā)人員使用。

優(yōu)點

• Spring 平臺本身提供的統(tǒng)一編程模型，以及 Spring Boot 的快速應用程序開發(fā)能力，為開發(fā)人員提供了良好的微服務開發(fā)體驗。例如，用很少的注解就可以完成配置中心服務，用很少的注解就可以讓客戶端庫使用您的后臺服務。

• 有豐富的庫可供選擇，涵蓋了大多數(shù)運行時問題。由于所有的庫都是用 Java 編寫的，所以它提供了多種特性、更大的控制和微調(diào)選項。

• 不同的 Spring cloud 庫彼此很好地集成在一起。例如，一個 Feign 客戶端也能使用 Hystrix 來做斷路器，使用 Ribbon 來做請求的負載。一切都是注解驅(qū)動的，易于開發(fā)，感覺就像 Java 開發(fā)人員的天堂。

缺點

• Spring Cloud 的一個主要優(yōu)點同時也是它的缺點——它僅限于 Java。MSA 的一個強大動機是在需要時能夠改變技術(shù)棧、庫甚至語言。這些對 Spring Cloud 來說是不可能的。如果你想消費 Spring Cloud/Netflix OSS 基礎(chǔ)設施服務，比如配置管理、服務發(fā)現(xiàn)、負載均衡，這個解決方案并不能完美解決。Netflix Prana 項目實現(xiàn)了 sidecar 模式，以在 HTTP 上公開基于 Java 的客戶端庫，使用非 java 語言編寫的應用程序可能存在于 Netflix 生態(tài)系統(tǒng)中，但它不是很優(yōu)雅。此外，自從我寫了這篇文章以來，Pivotal 還宣布了一個名為 SteelToe 的新項目，它允許使用 net 客戶端的服務發(fā)現(xiàn)和配置 Java 服務調(diào)用。

• Java 開發(fā)人員有太多的責任去關(guān)心和處理 Java 應用程序。每個微服務都需要運行各種客戶端，以進行配置檢索、服務發(fā)現(xiàn)和負載平衡。設置這些很容易，但這并不會隱藏構(gòu)建時間和對環(huán)境的運行時依賴關(guān)系。例如，我可以很容易地創(chuàng)建一個帶有@EnableConfigServer 注解的配置服務器，但這只是一個簡單的方法。每次我想運行一個微服務時，我都需要啟動配置服務器并運行它。對于受控環(huán)境，我必須考慮使配置服務器高度可用，因為它可以由 Git 或 Svn 支持，所以我需要為它共享文件系統(tǒng)。類似地，對于服務發(fā)現(xiàn)，我需要首先啟動 Eureka 服務器。對于受控環(huán)境，我需要在每個 AZ 上使用多個實例對其進行多副本部署等等。作為一名 Java 開發(fā)人員，除了實現(xiàn)所有功能性服務之外，我還必須構(gòu)建和管理一個重要的微服務平臺。

• 僅僅 Spring Cloud 在微服務領(lǐng)域的應用范圍就比較局限，為了獲得完整的微服務體驗，您還需要考慮自動部署、調(diào)度、資源管理、進程隔離、自愈、構(gòu)建管道等問題。就此而言，我認為將 Spring Cloud 單獨與 Kubernetes 進行比較是不公平的，更公平的比較應該是將 Spring Cloud + Cloud Foundry(或 Docker Swarm)與 Kubernetes 進行比較。但這也意味著，要想獲得完整的端到端微服務體驗，Spring Cloud 必須輔之以 Kubernetes 之類的平臺。

Kubernetes

Kubernetes 是一個用于自動化部署、擴展和管理容器化應用程序的開源系統(tǒng)。它是支持多種語言的，并為配置、運行、擴展和管理分布式系統(tǒng)提供了了良好的支持。

優(yōu)點

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

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

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

缺點

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

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

• Kubernetes 仍然是一個相對較新的平臺，它仍然在積極開發(fā)和成長。因此，每個版本都會增加很多新特性，可能很難跟上。好消息是，它設計思想超前，而且 API 是可擴展和向后兼容的。

兩者完美結(jié)合

正如你所看到的，這兩個平臺在某些領(lǐng)域都有優(yōu)勢，并在其他領(lǐng)域有所改進。Spring Cloud 是一個快速起步的、對開發(fā)者友好的平臺，而 Kubernetes 是對 DevOps 友好的，具有陡峭的學習曲線，但涵蓋了更廣泛的微服務關(guān)注點。以下是這些觀點的總結(jié)。

這兩個框架處理不同范圍的 MSA 關(guān)注點，而且它們采用的是完全不同的方式。Spring Cloud 方法試圖通過讓開發(fā)人員更容易地解決 JVM 中的每個 MSA 挑戰(zhàn)，而 Kubernetes 方法則試圖通過在平臺級別解決問題，讓開發(fā)人員的問題消失。Spring Cloud 在 JVM 中非常強大，而 Kubernetes 在管理這些 JVM 方面非常強大。因此，將它們結(jié)合起來并從兩個項目的最佳部分中獲益是一種自然而然的方式。

通過這樣的組合，Spring 提供了應用程序打包，而 Docker 和 Kubernetes 提供了部署和調(diào)度。Spring 通過 Hystrix 線程池提供了應用程序內(nèi)部的隔離，Kubernetes 通過資源、進程和名稱空間方式提供了隔離。Spring 為每個微服務提供運行狀況接口，Kubernetes 執(zhí)行運行健康狀態(tài)檢查并根據(jù)健康狀況將流量暴露到外部。Spring 將配置外部化并更新，Kubernetes 將配置分發(fā)給每個微服務。這樣的例子不勝枚舉。

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

后臺回復?學習資料?領(lǐng)取學習視頻

如有收獲，點個在看，誠摯感謝