SpringCloud和Kubernetes在微服務(wù)層面對(duì)比是怎樣的

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

背景

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

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

微服務(wù)關(guān)注點(diǎn)

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

 

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

對(duì)比圖

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

 

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

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

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

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

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

微服務(wù)必要條件

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

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

優(yōu)點(diǎn)和缺點(diǎn)

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

Spring Cloud

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

優(yōu)點(diǎn)

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

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

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

缺點(diǎn)

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

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

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

Kubernetes

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

優(yōu)點(diǎn)

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

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

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

缺點(diǎn)

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

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

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

兩者完美結(jié)合

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

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

 

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

微服務(wù)技術(shù)棧

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