譯文，原文地址：https://developers.redhat.com/blog/2016/12/09/spring-cloud-for-microservices-compared-to-kubernetes/
Spring Cloud
和
Kubernetes
都聲稱是開發和運行微服務的最佳環境，但它們在本質上都是非常不同的，並且解決了不同的問題。在本文中，我們將了解每個平台如何幫助提供基於微服務的架構（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在這兩種環境中同樣有用。在某些領域， 兩個平台都是互補的，可以組合在一起 以創建更強大的解決方案（ KubeFlix 和 Spring 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仍然是一個相對較新的平台（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提供的多語言原語。
