部署微服務：Spring Cloud vs. Kubernetes

Spring Cloud vs. Kubernetes，誰才是部署微服務的最佳拍檔？
Spring Cloud和Kubernetes都聲稱自己是開發和運行微服務的最佳環境，但兩者在特性上並不相同，解決的問題點也不一樣。本文將探討這兩種平台對於微服務架構的交付有何作用、兩者在哪些方面表現更好以及如何利用這兩種平台在微服務架構的路上取得成功。

背景故事

我最近拜讀了A.Lukyanchikov關於如何利用Spring Cloud和Docker搭建微服務的文章68，推薦大家也看一看。
想要搭建一個可以十倍、百倍擴展服務的彈性伸縮微服務系統，需要藉助具有寬泛構建時間和運行時能力的工具集進行集中的管理和治理。
Spring Cloud包括了各種功能性服務（如統計服務，帳戶服務和通知服務）和支持基礎設施服務（如日誌分析，配置服務器，服務發現，授權服務）。
下圖展示使用Spring Cloud的微服務架構：

MSA%20with%20Spring%20Cloud%20-by%20A.%20Lukyanchikov-.png1600x1402

（Spring Cloud微服務架構，by A. Lukyanchikov )
該圖展示了運行時的方方面面，但沒有包括打包、持續集成、伸縮、高可用和自我修復等在微服務架構中重要點。本文假設大多數JAVA開發者熟悉Spring Cloud，採用類比的形式，通過解決以上要點問題，帶大家了解Kubernetes和Spring Cloud之間的關係。

微服務要點

我們在此不進行特性的逐個對比，而是從大面上看一看微服務的要點並聊一聊Spring Cloud和Kubernetes如何實現。
微服務架構的一大優勢是易於理解的架構風格，可實現強大的模塊邊界，並且具有獨立的部署和技術多樣性，但需要付出的代價也是顯而易見的——開發分佈式系統的成本和運維開銷。
而微服務架構能否成功實踐，利用各種工具解決潛在問題是關鍵。把啟動過程變得快速簡單很重要，但通往生產環境的旅程是漫長的，你需要不斷進步才能成功。

Microservices%20concerns%20%20.png1086x1044

上圖是需要在微服務架構中最常見的技術要點（在這裡，我們不涉及那些非技術要點，比如組織結構、公司文化等等）

技術對比

Spring Cloud和Kubernetes有很大的不同，並沒有直接可比的特性，如果對照微服務架構的要點，可以得出如下的技術對比圖表：

從上表我們可以得知：
  • Spring Cloud有一套豐富且集成良好的JAVA庫，作為應用棧的一部分解決所有運行時問題。因此，微服務本身可以通過庫和運行時代理解決客戶端服務發現、負載均衡、配置更新、統計跟踪等。工作模式就像单实例服务集群（譯者註：集群中master節點工作，當master掛掉後，slave節點被選舉頂替。）並且一批工作也是在JVM中被管理。
  • Kubernetes是多語言的，不僅僅針對Java平台，而是以通用的方式為所有語言解決分佈式計算問題。Kubernetes提供了配置管理、服務發現、負載均衡、跟踪、統計、單實例、平台級和應用棧之外的調度工作。該應用不需要任何客戶端邏輯的庫或代理程序，可以用任何語言編寫。
  • 兩個平台依靠相似的第三方工具，如ELK和EFK stacks, tracing libraries等。Hystrix和Spring Boot等庫，在兩個環境中都表現良好。很多情況下，Spring Cloud和Kubernetes可以形成互補，組建出更強大的解決方案（例如KubeFlix 31和Spring Cloud Kubernetes 41）。

微服務需求

想要進一步理解Spring Cloud和Kubernetes的適用範圍，可以參考下圖微服務架構需求。

Microservices%20requirements%20%20.png998x1512

有些需求，Spring Cloud表現更好，有需求則是Kubernetes，也有些需求，兩者可以用不同的方式滿足。好消息是，Spring Cloud和Kubernetes在使用上並不衝突。例如，Spring Cloud提供Maven插件來創建單獨JAR應用程序包。結合Docker、Kubernetes的聲明式部署和調度能力，輕鬆運行微服務。同樣，Sring Cloud以應用程序內的包裝庫的形式來支持彈性伸縮，微服務容錯使用Hystrix（bulkhead和斷路器模式）與Ribbon（負載均衡）。但這些是不夠的，當組合Kubernetes健康檢查、程序重啟和自動伸縮能力，微服務才真正變成一個強壯的系統。

優缺點

Spring Cloud
Spring Cloud為開發者提供了快速構建分佈式系統中的一些常見模式的工具，例如配置管理，服務發現，斷路器，路由等。它是為Java開發人員使用，構建在Netflix OSS庫之上的。
優點
  1. Spring Platform提供的統一編程模型和Spring Boot的快速應用程序創建能力，為開發人員提供了很好的微服務開發體驗。使用很少的註解，就可以創建一個配置服務器或獲得客戶端庫來配置您的服務。
  2. 豐富的庫支持，覆蓋大多數運行時需求。Spring Cloud的所有庫均由JAVA編寫，提供多特性、高控制和易配置。
  3. 不同的Spring Cloud庫彼此完全兼容。例如，Feign客戶端還將使用Hystrix用於斷路器、Ribbon用於負載均衡請求。一切都是註解驅動的，易於Java開發者開發。
缺點
  1. 僅使用JAVA，既是Spring Cloud的優點，也是一大缺陷。微服務架構之所以吸引人，在於按需交換各種技術棧、庫，甚至語言的能力。這一點，Spring Cloud做不到。如果你想使用Spring Cloud/Netflix OSS基礎設置服務，例如配置管理、服務發現或者負載均衡，解決方案是不優雅的。雖然Netflix Prana項目實現了sidecar模式，顯示基於Java客戶類庫越過HTTP，使得用non-JVM語言編寫的應用程序存在於NetflixOSS生態系統變得可能，但它仍然不是很優雅。
  2. 除了JAVA應用程序，還有太多與開發無關的事情需要Java開發人員處理。每個微服務需要運行各種客戶端以進行配置檢索、服務發現和負載均衡。雖然很容易設置，但這並不會降低對環境的構建時間和運行的依賴性。例如，開發人員可以使用@EnableConfigServer創建一個配置服務器，但這只是開心的假象。每當開發人員想要運行單個微服務時，他們需要啟動並運行Config Server。對於受控環境，開發人員必須考慮使Config Server高度可用，並且由於它可以由Git或SVN支持，因此它們需要一個共享文件系統。同樣，對於服務發現，開發人員也是需要首先啟動Eureka服務器。為了創建一個受控的環境，他們需要在每個AZ上使用多個實例實現集群。可以說，開發人員除了實現所有功能外，還需要額外管理一個複雜的微服務平台。
  3. Spring Cloud目前在微服務方面覆蓋的面相對有限，開發人員還需要考慮自動化部署、調度、資源管理、過程隔離、自我修復、構建流水線等，以獲得完整的微服務體驗。對於這點，我認為拿Spring Cloud和Kubernetes比較是不公平的，應該比較Spring Cloud + Cloud Foundry (or Docker Swarm)和Kubernetes。但這也意味著對於一個完整的端到端微服務體驗，Spring Cloud必須補充一個像Kubernetes這樣的應用程序平台。
Kubernetes
Kubernetes是一個用於自動化部署、擴展和管理容器化應用程序的開源系統。支持多種語言並且提供用於支持、運行、擴展和管理分佈式系統的操作系統。
優點
  1. Kubernetes是多語言且語言不敏感的容器管理平台，能夠運行雲原生和傳統的容器化應用程序。Kubernetes提供的服務（如配置管理、服務發現、負載均衡、測試指標收集和日誌聚合）可供各種語言使用。這意味著一個平台可以被多個團隊（包括使用Spring的Java開發人員）使用，並提供多種用途：應​​ 用程序開發、測試環境、構建環境（源碼運行、構建服務、依賴倉庫）等。
  2. 與Spring Cloud相比，Kubernetes解決了更廣的微服務架構問題。除了提供運行時服務，Kubernetes也可以讓你制定環境、設置資源限制、RBAC、管理應用程序生命週期、允許自動擴容和自我修復（幾乎表現得像一個抗脆弱平台）。
  3. Kubernetes技術基於Google十五年的研發和容器管理經驗。此外，Kubernetes有近1000個貢獻者，是Github上最活躍的開源社區之一。
缺點
  1. Kubernetes是多語言的，因此它的服務是通用的，並不針對不同的平台（如Spring Cloud for JVM）進行優化。例如，配置會作為環境變量傳遞給應用程序或掛載的文件系統。它沒有像Spring Cloud Config提供的配置更新功能。
  2. Kubernetes不是一個以開發者為中心的平台，更偏向於DevOps的IT人員使用。因此，Java開發人員需要學習一些新的概念，需要學習解決問題的新方法。儘管通過MiniKuber開始一個Kubernetes開發實例很簡單，但手動安裝一個高可用的Kubernetes集群仍顯得有些複雜。
  3. Kubernetes是一個相對較新的平台（2歲），仍然在發展和成長，每個版本都添加了很多新功能，可能很難跟上。好消息是，這一點已經被考慮到了，Kubernetes的API將是可擴展和向後兼容的。

Spring Cloud和Kubernetes的最佳實踐

如你所見，Spring Cloud和Kubernetes在核心領域都很強，並且正在其他領域努力改進。Spring Cloud可以快速使用，對開發者比較友好；而Kubernetes是DevOps的絕配，雖然學起來可能有點難，但是覆蓋了更廣泛的微服務技術要點。

Strengths%20and%20weaknesses.png1600x489

Spring Cloud和Kubernetes處理了不同範圍的微服務架構技術點，而且是用了不同的方法。Spring Cloud方法是試圖解決在JVM中的微服務架構要點，而Kubernetes方法是試圖讓問題消失，為開發者在平台層解決。Spring Cloud在JVM中非常強大，Kubernetes管理那些JVM很強大。看起來各取所長，充分利用這兩者的優勢是自然而然的趨勢了。

Spring%20Cloud%20backed%20by%20Kubernetes%20%20.png1600x933

結合使用Spring Cloud和Kubernetes，用Spring Cloud提供應用程序打包，Docker和Kubernetes提供部署和調度；Spring通過Hystrix線程池提供應用程序內隔離，Kubernetes通過資源、進程和命名空間隔離；Spring為每個微服務提供健康終端，Kubernetes執行健康檢查並且為健康服務的通信提供路由；Spring外部化且升級配置，Kubernetes給每個微服務分配配置......這樣的例子還有很多。
作者：Bilgin Ibryam 
原文：https://dzone.com/articles/deploying-microservices-spring-cloud-vs-kubernetes 52
搬運：好雨科技
為方便閱讀原文略有刪改

留言

張貼留言

這個網誌中的熱門文章

Json概述以及python對json的相關操作

圖片
什麼是json： JSON(JavaScript Object Notation) 是一種輕量級的數據交換格式。易於人閱讀和編寫。同時也易於機器解析和生成。它基於JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999的一個子集。JSON採用完全獨立於語言的文本格式，但是也使用了類似於C語言家族的習慣（包括C, C++, C#, Java, JavaScript, Perl, Python等）。這些特性使JSON成為理想的數據交換語言。 JSON建構於兩種結構： “名稱/值”對的集合（A collection of name/value pairs）。不同的語言中，它被理解為對象（object），紀錄（record），結構（struct），字典（dictionary），哈希表（hash table），有鍵列表（keyed list），或者關聯數組（associative array）。 值的有序列表（An ordered list of values）。在大部分語言中，它被理解為數組（array）。 這些都是常見的數據結構。事實上大部分現代計算機語言都以某種形式支持它們。這使得一種數據格式在同樣基於這些結構的編程語言之間交換成為可能。 jso官方說 ​​明參見：http://json.org/ Python操作json的標準api庫參考：http://docs.python.org/library/json.html 對簡單數據類型的encoding 和decoding： 使用簡單的json.dumps方法對簡單數據類型進行編碼，例如： import json obj = [[ 1 , 2 , 3 ], 123 , 123.123 , 'abc' ,{ 'key1' :( 1 , 2 , 3 ), 'key2' :( 4 , 5 , 6 )}] encodedjson = json.dumps(obj) print repr (obj) print encodedjson 輸出： [[1, 2, 3], 123, 123.123, 'abc', {'ke...
閱讀完整內容

Docker容器日誌查看與清理

1. 問題 docker容器日誌導致主機磁盤空間滿了。 docker logs -f container_name 劈裡啪啦一大堆，很佔用空間，不用的日誌可以清理掉了。  2. 解決方法 2.1 找出Docker容器日誌 在linux上，容器日誌一般存放在 /var/lib/docker/containers/container_id/ 下面，查看各個日誌文件大小的腳本docker_log_size.sh，內容如下： #!/bin/sh echo "======== docker containers logs file size ========" logs=$(find /var/lib/docker/containers/ -name *-json.log) for log in $logs do ls -lh $log done # chmod +x docker_log_size.sh # ./docker_log_size.sh 2.2 清理Docker容器日誌（治標） 如果docker容器正在運行，那麼使用 rm -rf 方式刪除日誌後，通過 df -h 會發現磁盤空間並沒有釋放。 原因是在Linux或者Unix系統中，通過 rm -rf 或者文件管理器刪除文件，將會從文件系統的目錄結構上解除鏈接（unlink）。 如果文件是被打開的（有一個進程正在使用），那麼進程將仍然可以讀取該文件，磁盤空間也一直被佔用。 正確姿勢是 cat /dev/null > *-json.log ，當然你也可以通過 rm -rf 刪除後重啟docker。 接下來，提供一個日誌清理腳本 clean_docker_log.sh ，內容如下： #!/bin/sh echo "======== start clean docker containers logs ========" logs=$(find /var/lib/docker/containers/ -name *-json.log) for log in $logs d...
閱讀完整內容

利用 Keepalived 提供 VIP

Keepalived 是一種基於 VRRP 協定實現的高可靠 Web 服務方案，用於防止單點故障問題。因此一個 Web 服務運作至少會擁有兩台伺服器執行 Keepalived，一台作為 master，一台作為 backup，並提供一個虛擬 IP（VIP），master 會定期發送特定訊息給 backup 伺服器，當 backup 沒收到 master 訊息時，表示 master 已故障，這時候 backup 會接管 VIP，繼續提供服務，來確保服務的高可靠性。 VRRP VRRP（Virtual Router Redundancy Protocol，虛擬路由器備援協定），是一個提供備援路由器來解決單點故障問題的協定，該協定有兩個重要概念： * VRRP 路由器與虛擬路由器：VRRP 路由器是表示運作 VRRP 的路由器，是一個實體裝置，而虛擬路由器是指由 VRRP 建立的邏輯路由器。一組 VRRP 路由器協同運作，並一起構成一台虛擬路由器，該虛擬路由對外提供一個唯一固定的 IP 與 MAC 位址的邏輯路由器。 * 主控制路由器（master）與備援路由器（backup）：主要是在一組 VRRP 中的兩種互斥角色。一個 VRRP 群組中只能擁有一台是 master，但可以有多個 backup 路由器。 VRRP 協定使用選擇策略從路由器群組挑選一台作為 master 來負責 ARP 與轉送 IP 封包，群組中其他路由器則作為 backup 的角色處理等待狀態。當由於某種原因造成 master 故障時，backup 會在幾秒內成為 master 繼續提供服務，該階段不用改變任何 IP 與 MAC 位址。 Keepalived 節點配置 IP ADDRESS ROLE 172.16.1.101 vip 172.16.1.102 master 172.16.1.103 backup 安裝與設定 這 ubuntu 14.04 LTS Server 中已經內建了 Keepalived 可以透過 apt-get 來安裝： $ sudo apt-get install -y keepalived 也可以透過 source code 進行安裝，流程如下： $ sudo apt-get install build-essential libssl-dev $ wge...
閱讀完整內容