Spring Cloud基礎知識有哪些

本篇內容介紹了“Spring Cloud基礎知識有哪些”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

Spring Cloud 之“出身名門望族”

作為當下最火熱的微服務框架，Spring Cloud的名字可以說是無人不知、無人不曉，憑借之前Spring Framework的良好群眾基礎和Cloud這個具有時代感的名字，Spring Cloud一出現(xiàn)便被大家認知。

提到Spring Cloud，便會讓人想起剛剛發(fā)布了2.0版本的Spring Boot。Spring Boot和Spring Cloud都是出自Pivotal公司，Spring Boot和Spring Cloud雖然火熱，但是了解Pivotal公司的人在國內卻是不多。實際上Pivotal公司在云計算、大數(shù)據(jù)、虛擬化等領域都有所建樹，這里先給大家簡單八卦下Pivotal的情況。

Pivotal公司是由EMC和VMware聯(lián)合成立的一家公司，GE（通用電氣）也對Pivotal進行了股權收購，同時GE也是Pivotal的一個重要大客戶。除了Spring Framework、Spring Boot和Spring Cloud之外，我們日常開發(fā)中經(jīng)常使用的Reids、RabbitMQ、Greenplum、Gemfire、Cloud Foundry等，目前都是歸屬于Pivotal公司的產品。其中Gemfire也是被中國鐵路總公司12306使用的分布式內存數(shù)據(jù)庫，也就是說你過年回家買不到火車票，這個鍋Pivotal的Gemfire也會跟著一起背（開個小玩笑，哈哈）。

Spring Cloud 之“入門”

Spring Cloud作為一個微服務的開發(fā)框架，其包括了很多的組件，包括：Spring Cloud Netflix（Eureka、Hystrix、Zuul、Archaius）、Spring Cloud Config、Spring Cloud Bus、Spring Cloud Cluster、Spring Cloud Consul、Spring Cloud Security、Spring Cloud Sleuth、Spring Cloud Data Flow、Spring Cloud Stream、Spring Cloud Task、Spring Cloud Zookeeper、Spring Cloud Connectors、Spring Cloud Starters、Spring Cloud CLI等。

在上述組件中，Spring Cloud Netflix是一套微服務的核心框架，由互聯(lián)網(wǎng)流媒體播放商Netflix開源后并入Spring Cloud大家庭，它提供了的微服務最基礎的功能：服務發(fā)現(xiàn)（Service Discovery）、動態(tài)路由（Dynamic Routing）、負載均衡（Load Balancing），和邊緣服務器（Edge Server）等。

Spring Boot是Spring的一套快速配置腳手架，可以基于Spring Boot快速開發(fā)單個微服務。Spring Boot簡化了基于Spring的應用開發(fā)，通過少量的代碼就能創(chuàng)建一個獨立的、生產級別的Spring應用。由于Spring Cloud是基于Spring Boot進行的開發(fā)，因此使用Spring Cloud就必須使用到Spring Boot。

下圖是一個常見的關于Spring Cloud的架構圖。下面此圖為例，對Spring Cloud最常用的幾個組件做一個簡單的介紹：

l Eureka：服務注冊中心，一個基于REST的服務，用于定位服務，以實現(xiàn)微服務架構中服務發(fā)現(xiàn)和故障轉移。

l Hystrix：熔斷器，容錯管理工具，旨在通過熔斷機制控制服務和第三方庫的節(jié)點,從而對延遲和故障提供更強大的容錯能力。

l Turbine：Turbine是聚合服務器發(fā)送事件流數(shù)據(jù)的一個工具，用來監(jiān)控集群下Hystrix的Metrics情況。

l Zuul：API網(wǎng)關，Zuul是在微服務中提供動態(tài)路由、監(jiān)控、彈性、安全等邊緣服務的框架。

l Ribbon：提供微服務中的負載均衡功能，有多種負載均衡策略可供選擇，可配合服務發(fā)現(xiàn)和斷路器使用。

l Feign：Feign是一種聲明式、模板化的HTTP客戶端。

l Spring Cloud Config：配置管理工具包，讓你可以把配置放到遠程服務器，集中化管理集群配置，目前支持本地存儲、Git以及Subversion。

l Spring Cloud Security：基于Spring Security的安全工具包，為微服務的應用程序添加安全控制。

l Spring Cloud Sleuth：日志收集工具包，封裝了Dapper和log-based追蹤以及Zipkin和HTrace操作，為SpringCloud應用實現(xiàn)了一種分布式追蹤解決方案。

除了上面介紹的基礎組件外，常見的Spring Cloud組件還有非常多種，涉及到了微服務以及應用開發(fā)的方方面面：

l Spring Cloud Starters：Spring Boot式的啟動項目，為Spring Cloud提供開箱即用的依賴管理。

l Archaius：配置管理API，包含一系列配置管理API，提供動態(tài)類型化屬性、線程安全配置操作、輪詢框架、回調機制等功能。

l Consul：封裝了Consul操作，Consul是一個服務發(fā)現(xiàn)與配置工具，與Docker容器可以無縫集成。

l Spring Cloud Stream：數(shù)據(jù)流操作開發(fā)包，封裝了與Redis,Rabbit、Kafka等發(fā)送接收消息。

l Spring Cloud CLI：基于 Spring Boot CLI，可以讓你以命令行方式快速建立云組件。

l Spring Cloud Task：提供云端計劃任務管理、任務調度。

l Spring Cloud Bus：事件、消息總線，用于在集群（例如，配置變化事件）中傳播狀態(tài)變化，可與Spring Cloud Config聯(lián)合實現(xiàn)熱部署。

l Spring Cloud Data Flow：大數(shù)據(jù)操作工具，作為Spring XD的替代產品，它是一個混合計算模型，結合了流數(shù)據(jù)與批量數(shù)據(jù)的處理方式。

l Spring Cloud Zookeeper：操作Zookeeper的工具包，用于使用zookeeper方式的服務發(fā)現(xiàn)和配置管理。

l Spring Cloud Connectors：便于云端應用程序在各種PaaS平臺連接到后端，如：數(shù)據(jù)庫和消息代理服務。

Spring Cloud 之“精通”

Spring Cloud雖然集成了眾多組件，可以構建一個完整的微服務應用，但是其中的各個組件卻并非完美無缺，很多組件在實際應用中都存在諸多不足和缺陷。因此，需要我們對其中的一些組件進行替換和修改，方能構建一個強大、靈活、健壯的微服務架構應用。

l 配置中心：

Spring Cloud Config可以說是Spring Cloud家族中實現(xiàn)最Low的一個組件，直接采用了本地存儲/SVN/Git的方式進行存儲。同時，Spring Cloud Config也缺乏一個完整的可視化管理查詢后臺，當存在比較復雜的權限管理和版本管理需求時，Spring Cloud Config會顯得非常力不從心。如果需要在配置修改后，能自動進行配置信息推送的話，使用Spring Cloud Config也無法滿足要求，需要自行編寫代碼進行實現(xiàn)。

目前開源社區(qū)中，已經(jīng)有了很多的開源配置中心實現(xiàn)方案，同時很多公司也自研了自己的配置中心方案。包括淘寶的統(tǒng)一配置中心Diamond（已經(jīng)多年未更新）、百度的分布式配置管理平臺Disconf、攜程的開源分布式配置中心Apollo、360的分布式配置管理工具QConf等等。目前，筆者公司采用的是自己公司自研的配置中心，沒有采用開源實現(xiàn)的主要原因是因為需要同時適配Spring Cloud和Dubbo等多種場景的應用。

l 注冊中心

作為Spring Cloud的服務注冊中心，從分布式CAP理論來看，Eureka采用是AP型設計，強調的是注冊中心的高可用性。和Dubbo常用的服務注冊中心Zookeeper相比，Zookeeper則是采用的CP型設計，強調的是注冊中心數(shù)據(jù)的一致性。

Eureka的設計確實簡單易用，但是默認沒有實現(xiàn)對注冊中心數(shù)據(jù)的持久化。同時，在極端場景下，也會出現(xiàn)多個Eureka注冊中心節(jié)點數(shù)據(jù)不一致，甚至服務注冊數(shù)據(jù)丟失的情況。當然，從分布式CAP理論來看，理論上是沒辦法做到同時兼顧CAP三點的。目前也有一些互聯(lián)網(wǎng)公司對Eureka進行了改造，支持了數(shù)據(jù)的持久化，但是尚不能完整的支持CAP的全部要求。

l API網(wǎng)關

API網(wǎng)關可以說是微服務需求最多，也是最有難點的一個組件。Spring Cloud中集成的Zuul應該說更多的是實現(xiàn)了服務的路由功能，對于負載均衡等其他功能，需要結合Ribbon等組件來實現(xiàn)。對于很多個性化的需求，需要開發(fā)者自己來進行編碼實現(xiàn)。

和大部分基于Java的Web應用類似，Zuul也采用了Servlet架構，因此Zuul處理每個請求的方式是針對每個請求是用一個線程來處理。同時，由于Zuul是基于JVM的實現(xiàn)，因此性能也會在高并發(fā)訪問場景下成為瓶頸。雖然網(wǎng)上一些文章評測Zuul和Nginx性能接近，但是在性能要求較高的場景下，JVM的內存管理和垃圾回收問題，仍然是一個很大的問題。所以在實際的應用場景中，通常會采用在多個Zuul幾點前面再添加一層Nginx或者OpenResty來進行代理。

為了解決Zuul的性能問題，Netflix將自己的網(wǎng)關服務Zuul進行了升級，新的Zuul 2將HTTP請求的處理方式從同步變成了異步，并且新增諸如HTTP/2、websocket等功能。但是遺憾的是，開源版本的Zuul 2一直處于難產狀態(tài)中，始終沒有和大家正式見面。

l 熔斷器

微服務中對于服務的限流、降級、熔斷的需求是多種多樣的，需要在API網(wǎng)關和各個具體服務接口中分別進行控制，才能滿足復雜場景下微服務架構的應用需求。

單獨使用Spring Cloud中的Hystrix無法完整的滿足上述的復雜需求，需要結合API網(wǎng)關，并通過Kubernetes對資源、進程和命名空間來提供隔離，并通過部分自定義編碼方能實現(xiàn)對全部服務的限流、降級、熔斷等需求。

l 監(jiān)控系統(tǒng)

無論是Spring Cloud中集成的Spring Cloud Sleuth，還是集成經(jīng)典的ELK，都只是對日志級別的追蹤和監(jiān)控。在大中型微服務應用架構中，尤其是基于JVM的項目，還需要添加APM的監(jiān)控機制，才能保證及時發(fā)現(xiàn)各種潛在的性能問題。

APM整體上主要完成3點功能：1.日志追蹤、2.監(jiān)控報警、3.性能統(tǒng)計。目前，國內外商業(yè)版本的APM方案已經(jīng)有很多，開源版本的APM方案也開始豐富起來。國內開源的APM方案主要有：大眾點評的CAT和Apache孵化中的SkyWalking。這里給大家重點推薦下SkyWalking，SkyWalking是針對分布式系統(tǒng)的應用性能監(jiān)控系統(tǒng)，特別針對微服務、Cloud Native和容器化(Docker, Kubernetes, Mesos)架構，項目的關注度和發(fā)展速度都很快，中文文檔資料也比較齊全。

Spring Cloud 之“放棄”

Spring Cloud可以說是一個完美的微服務入門框架，如果你是在一個中小型項目中應用Spring Cloud，那么你不需要太多的改造和適配，就可以實現(xiàn)微服務的基本功能。但是如果是在大型項目中實踐微服務，可能會發(fā)現(xiàn)需要處理的問題還是比較多，尤其是項目中老代碼比較多，沒辦法全部直接升級到Spring Boot框架下開發(fā)的話，你會非常希望能有一個侵入性更低的方案來實施微服務架構。在這種場景下，Service Mesh將會成為你的最佳選擇，經(jīng)過一段時間的發(fā)展，目前Service Mesh這個概念已經(jīng)開始逐步被大家了解和認知。同時，一些Service Mesh的實現(xiàn)方案也逐步成熟和落地，例如Istio、Linkerd、Envoy等。在本系列文章的下一篇中，將為大家對Service Mesh概念做一個系統(tǒng)的介紹。但是在了解Service Mesh概念之前，還是建議大家先對微服務和Spring Cloud這些概念和框架有一個深入的了解，這樣才能體會到應用Service Mesh的價值和意義。

Spring Cloud 與Dubbo

網(wǎng)上關于Spring Cloud和Dubbo對比的文章很多，大多數(shù)對比結果都是Spring Cloud壓倒性優(yōu)勢戰(zhàn)勝Dubbo，下表是對Dubbo和Spring Cloud做的一個基礎功能的對比：

實際上，Dubbo的關注點在于服務治理，并不能算是一個真正的微服務框架。包括目前在開發(fā)中的Dubbo 3.0，也不能完整覆蓋微服務的各項功能需求。而Spring Cloud一方面是針對微服務而設計，另外一方面Spring Cloud是通過集成各種組件的方式來實現(xiàn)微服務，因此理論上可以集成目前業(yè)內的絕大多數(shù)的微服務相關組件，從而實現(xiàn)微服務的全部功能。

而對Dubbo而言，如果一定要應用到微服務的使用場景中的話，上表中欠缺的大多數(shù)功能都可以通過集成第三方應用和組件的方式來實現(xiàn)，跟Spring Cloud相比主要的缺陷在于集成過程中的便利性和兼容性等問題。

Spring Cloud 與Docker

雖然網(wǎng)上也有很多文章寫到如何使用Docker來實現(xiàn)微服務，但是事實上單獨使用Docker是沒辦法完整的實現(xiàn)微服務的所有功能的。在實際上微服務架構中，Spring Cloud和Docker更多的是一種協(xié)作的關系，而不是一種競爭的關系。通過Docker容器化技術，可以更好的解決引入Spring Cloud微服務后帶來的部署和運維的復雜性。

Spring Cloud生態(tài)圈中的Pivotal Cloud Foundry (PCF)作為 PAAS 實現(xiàn)，也提供一些類似于Docker的功能支持，但是無論上功能上還是易用性上和Docker還是存在比較大的差異。Pivotal Cloud Foundry和Docker之間的關系更多的是一種兼容關系，而不是競爭關系，Pivotal Cloud Foundry的主要競爭對手是Red Hat的OpenShift。目前，Pivotal Cloud Foundry支持的IAAS包括：AWS、AZURE、GCP、vSphere、OpenStack等。

Spring Cloud 與Kubernetes

網(wǎng)上也有一些“Spring Cloud與Kubernetes哪個更好”，“當已經(jīng)有了Kubernetes之后，還需要使用Spring Cloud么”之類的文章。首先說筆者并不認為Spring Cloud與Kubernetes是競爭關系，但是也不否認二者確實在諸多功能上存在一些重合。下圖是對Spring Cloud與Kubernetes在微服務架構中的一些基礎功能上的對比。

通過對比可以看出，Spring Cloud和Kubernetes確實存在一些功能上的重合，但是二者的定位其實差別很大。Spring Cloud是一個基于Java語言的微服務開發(fā)框架，而Kubernetes是一個針對容器應用的自動化部署、伸縮和管理的開源系統(tǒng)，它兼容多種語言且提供了創(chuàng)建、運行、伸縮以及管理分布式系統(tǒng)的原語。Spring Cloud更多的是面向有Spring開發(fā)經(jīng)驗的Java語言開發(fā)者，而Kubernetes不是一個針對開發(fā)者的平臺，它的目的是供有DevOps思想的IT人員使用。

為了區(qū)分Spring Cloud和Kubernetes兩個項目的范圍，下面這張圖列出了幾乎是端到端的微服務架構需求，從最底層的硬件，到最上層的DevOps和自服務經(jīng)驗，并且列出了如何關聯(lián)到Spring Cloud和Kubernetes平臺。

“Spring Cloud基礎知識有哪些”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注億速云網(wǎng)站，小編將為大家輸出更多高質量的實用文章！