天天看點

Spring Cloud 的微服務架構

Spring Cloud 的微服務架構

    • Spring Cloud 的微服務架構
      • 前言
      • 什麼是微服務(Microservice)
        • 微服務架構需要的功能或使用場景
        • SpringCloud項目簡介
        • SpringCloud特點
          • Fegin(接口調用)
          • Netflix eureka(注冊發現)
          • Ribbon(負載均衡)
          • Hystrix(熔斷器)
          • Zuul(微服務網關)
          • Spring cloud bus( 統一配置服務)
          • Sleuth+ZipKin(跟蹤服務)

Spring Cloud 的微服務架構

前言

Spring Cloud 微服務總體架構圖

Spring Cloud 的微服務架構

名詞了解:

  • Sleuth-鍊路跟蹤:

    為服務之間調用提供鍊路追蹤。通過Sleuth可以很清楚的了解到一個服務請求經過了哪些服務,每個服務處理花費了多長。進而讓我們可以很友善的理清各微服務間的調用關系。

  • 熔斷器(Hystrix):

    在微服務架構中,根據業務來拆分成一個個的服務,服務與服務之間可以互相調用(RPC),在Spring Cloud可以用RestTemplate+Ribbon和Feign來調用。為了保證其高可用,單個服務通常會叢集部署。由于網絡原因或者自身的原因,服務并不能保證100%可用,如果單個服務出現問題,調用這個服務就會出現線程阻塞,此時若有大量的請求湧入,Servlet容器的線程資源會被消耗完畢,導緻服務癱瘓。服務與服務之間的依賴性,故障會傳播,會對整個微服務系統造成災難性的嚴重後果,這就是服務故障的

    雪崩

    效應。Netflix開源了Hystrix元件,實作了斷路器模式,SpringCloud對這一元件進行了整合。
  • Turbine叢集監控 :

    Turbine 是聚合伺服器發送事件流資料的一個工具,用來監控叢集下 hystrix 的 metrics 情況。 通過turbine可以監控叢集的請求量,可以知道系統的請求高峰期,進而更好的知道系統的短闆在哪裡。

  • Consul服務治理 和Eureka服務治理 :

    由于Spring Cloud為服務治理做了一層抽象接口,是以在Spring Cloud應用中可以支援多種不同的服務治理架構,比如:Netflix Eureka、Consul、Zookeeper。

    Spring Cloud Consul

    項目是針對 Consul 的服務治理實作。Consul 是一個分布式高可用的系統,它包含多個元件,但是作為一個整體,在微服務架構中為我們的基礎設施提供服務發現和服務配置的工具。它包含了下面幾個特性:

    服務發現、 健康檢查、 Key/Value存儲、 多資料中心。

    由于Consul自身提供了服務端,是以我們不需要像之前實作Eureka的時候建立服務注冊中心,直接通過下載下傳consul的服務端程式就可以使用。Consul比Eureka注冊支援的更多一些。
  • config配置管理 :

    引入spring cloud config後,我們的外部配置檔案就可以集中放置在一個git倉庫裡,再建立一個config server,用來管理所有的配置檔案,維護的時候需要更改配置時,隻需要在本地更改後,推送到遠端倉庫,

    所有的服務執行個體都可以通過config server來擷取配置檔案,

    這時每個服務執行個體就相當于配置服務的用戶端config client,為了保證系統的穩定,配置服務端config server可以進行叢集部署。
  • Nginx負載均衡 :

    Nginx用來做

    反向代理

    負載均衡

    ,當有請求的時候,根據配置的排程政策(權重輪詢、IP哈希、最少連接配接數、一緻性哈希)給請求者傳回相應的伺服器IP。
  • Zuul服務網關 :

    zuul的核心是一系列的filters, 其作用可以類比Servlet架構的Filter, Zuul的主要功能是

    路由

    過濾器

    。是各種服務的統一入口,同時還會用來提供監控、授權、安全、排程等等;可以通過擴充ZuulFilter,在執行方法之前,做各種檢查工作。

什麼是微服務(Microservice)

微服務英文名稱Microservice,Microservice架構模式就是

将整個Web應用組織為一系列小的Web服務。這些小的Web服務可以獨立地編譯及部署,并通過各自暴露的API接口互相通訊。它們彼此互相協作,作為一個整體為使用者提供功能,卻可以獨立地進行擴充

微服務架構需要的功能或使用場景

  • 負載均衡 : 把整個系統根據業務拆分成幾個子系統,每個子系統可以部署多個應用,多個應用之間使用負載均衡。
  • 服務注冊中心 : 所有的服務都在注冊中心注冊,負載均衡也是通過在注冊中心注冊的服務來使用一定政策來實作。
  • 網關 : 所有的用戶端都通過同一個網關位址通路背景的服務,通過路由配置和網關來判斷一個 URL 請求由哪個服務處理。請求轉發到服務上的時候也使用負載均衡。
  • 互相通路 : 服務之間有時候也需要互相通路。例如有一個使用者子產品,其他服務在處理一些業務的時候,要擷取使用者服務的使用者資料。
  • 熔斷器 : 及時處理服務調用時的逾時和錯誤,防止由于其中一個服務的問題而導緻整體系統的癱瘓。
  • 監控功能 : 監控每個服務調用花費的時間等。

目前主流的微服務架構:Dubbo、 SpringCloud、thrift、Hessian等,目前國内的中小企業用的大多數都是Dubbo,SpringCloud。

SpringCloud項目簡介

springCloud 是基于 SpringBoot 的一整套實作微服務的架構。

提供了微服務開發所需的配置管理、服務發現、斷路器、智能路由、微代理、控制總線、全局鎖、決策競選、分布式會話和叢集狀态管理等元件

。最重要的是,跟spring boot架構一起使用的話,會讓你開發微服務架構的雲服務非常好的友善。

SpringBoot 旨在簡化建立産品級的 Spring 應用和服務,簡化了配置檔案,使用嵌入式web伺服器,含有諸多開箱即用的微服務功能。

spring cloud子項目包括:

  • Spring Cloud Config : 配置管理開發工具包,可以讓你把配置放到遠端伺服器,目前支援本地存儲、Git以及Subversion。
  • Spring Cloud Bus : 事件、消息總線,用于在叢集(例如,配置變化事件)中傳播狀态變化,可與Spring Cloud Config聯合實作熱部署。
  • Spring Cloud Netflix : 針對多種Netflix元件提供的開發工具包,其中包括Eureka、Hystrix、Zuul、Archaius等。
  • Netflix Eureka : 雲端負載均衡,一個基于 REST 的服務,用于定位服務,以實作雲端的負載均衡和中間層伺服器的故障轉移。
  • Netflix Hystrix : 容錯管理工具,旨在通過控制服務和第三方庫的節點,進而對延遲和故障提供更強大的容錯能力。
  • Netflix Zuul : 邊緣服務工具,是提供動态路由,監控,彈性,安全等的邊緣服務。
  • Netflix Archaius : 配置管理API,包含一系列配置管理API,提供動态類型化屬性、線程安全配置操作、輪詢架構、回調機制等功能。
  • Spring Cloud for Cloud Foundry : 通過Oauth2協定綁定服務到CloudFoundry,CloudFoundry是VMware推出的開源PaaS雲平台。
  • Spring Cloud Sleuth : 日志收集工具包,封裝了Dapper,Zipkin和HTrace操作。
  • Spring Cloud Data Flow : 大資料操作工具,通過指令行方式操作資料流。
  • Spring Cloud Security : 安全工具包,為你的應用程式添加安全控制,主要是指OAuth2。
  • Spring Cloud Consul : 封裝了Consul操作,consul是一個服務發現與配置工具,與Docker容器可以無縫內建。
  • Spring Cloud Zookeeper : 操作Zookeeper的工具包,用于使用zookeeper方式的服務注冊和發現。
  • Spring Cloud Stream : 資料流操作開發包,封裝了與Redis,Rabbit、Kafka等發送接收消息。
  • Spring Cloud CLI : 基于 Spring Boot CLI,可以讓你以指令行方式快速建立雲元件。

SpringCloud特點

1:約定優于配置 2:開箱即用、快速啟動 3:适用于各種環境 4:輕量級的元件 5:元件支援豐富,功能齊全

Spring cloud作為當下主流的微服務架構,讓我們實作微服務架構簡單快捷,Spring cloud中各個元件在微服務架構中扮演的角色如下圖所示,黑線表示注釋說明,藍線由A指向B,表示B從A處擷取服務。

Spring Cloud 的微服務架構
Fegin(接口調用)

微服務之間通過Rest接口通訊,Spring Cloud 提供 Feign 架構來支援 Rest 的調用,Feign 使得不同程序的 Rest 接口調用得以用優雅的方式進行,這種優雅表現得就像同一個程序調用一樣。

Netflix eureka(注冊發現)

微服務模式下,一個大的Web應用通常都被拆分為很多比較小的web應用(服務),這個時候就需要有一個地方儲存這些服務的相關資訊,才能讓各個小的應用彼此知道對方,這個時候就需要在注冊中心進行注冊。每個應用啟動時向配置的注冊中心注冊自己的資訊(ip位址,端口号, 服務名稱等資訊),注冊中心将他們儲存起來,服務間互相調用的時候,通過服務名稱就可以到注冊中心找到對應的服務資訊,進而進行通訊。注冊與發現服務為微服務之間的調用帶來了友善,解決了寫死的問題。服務間隻通過對方的服務id,而無需知道其ip和端口即可以擷取對方方服務。

Ribbon(負載均衡)

Ribbon是Netflix釋出的負載均衡器,它有助于控制HTTP和TCP用戶端的行為。為Ribbon,配置服務提供者的位址清單後,Ribbon就可基于某種負載均衡算法,自動地幫助服務消費者去請求。Ribbon預設為我們提供了很多的負載均衡算法,例如輪詢、随機等。當然,我們也可為Ribbon實作自定義的負載均衡算法。在SpringCloud中,當Ribbon與Eureka配合使用時,Ribbon可自動從EurekaServer擷取服務提供者的位址清單,并基于負載均衡算法,請求其中一個服務提供者的執行個體(為了服務的可靠性,一個微服務可能部署多個執行個體)。

Hystrix(熔斷器)

當服務提供者響應非常緩慢,那麼消費者對提供者的請求就會被強制等待,直到提供者響應或逾時。在高負載場景下,如果不做任何處理,此類問題可能會導緻服務消費者的資源耗竭甚至整個系統的崩潰(雪崩效應)。Hystrix正是為了防止此類問題發生。Hystrix是由Netflix開源的一個延遲和容錯庫,用于隔離通路遠端系統、服務或者第三方庫,防止級聯失敗,進而提升系統的可用性與容錯性。

Hystrix主要通過以下幾點實作延遲和容錯:

  • 包裹請求: 使用HystrixCommand(或HystrixObservableCommand)包裹對依賴的調用邏輯,每個指令在獨立線程中執行。這使用了設計模式中的“指令模式”。
  • 跳閘機制: 當某服務的錯誤率超過一定門檻值時,Hystrix可以自動或者手動跳閘,停止請求該服務一段時間。
  • 資源隔離: Hystrix為每個依賴都維護了一個小型的線程池(或者信号量)。如果該線程池已滿,發往該依賴的請求就被立即拒絕,而不是排隊等候,進而加速失敗判定。
  • 監控: Hystrix可以近乎實時地監控運作名額和配置的變化,例如成功、失敗、逾時和被拒絕的請求等。
  • 回退機制: 當請求失敗、逾時、被拒絕,或當斷路器打開時,執行回退邏輯。回退邏輯可由開發人員指定。
Zuul(微服務網關)

不同的微服務一般會有不同的網絡位址,而外部用戶端可能需要調用多個服務的接口才能完成一個業務需求。例如一個電影購票的手機APP,可能調用多個微服務的接口才能完成一次購票的業務流程,如果讓用戶端直接與各個微服務通信,會有以下的問題:

  • 用戶端會多次請求不同的微服務,增加了用戶端的複雜性。
  • 存在跨域請求,在一定場景下處理相對複雜。
  • 認證複雜,每個服務都需要獨立認證。
  • 難以重構,随着項目的疊代,可能需要重新劃分微服務。 例如,可能将多個服務合并成一個或者将一個服務拆分成多個。如果用戶端直接與微服務通信,那麼重構将很難實施。
  • 某些微服務可能使用了對防火牆/浏覽器不友好的協定,直接通路時會有一定的困難。

以上問題可借助微服務網關解決。

微服務網關是介于用戶端和伺服器端之間的中間層,所有的外部請求都會先經過微服務網關。

使用微服務網關後,微服務網關将封裝應用程式的内部結構,

用戶端隻用跟網關互動,而無須直接調用特定微服務的接口。

這樣,開發就可以得到簡化。不僅如此,使用微服務網關還有以下優點:

  • 易于監控 可在微服務網關收集監控資料并将其推送到外部系統進行分析。
  • 易于認證 可在微服務網關上進行認證,然後再将請求轉發到後端的微服務,而無須在每個微服務中進行認證。
  • 減少了用戶端與各個微服務之間的互動次數。
Spring cloud bus( 統一配置服務)

對于傳統的單體應用,常使用配置檔案管理所有配置。例如一個SpringBoot開發的單體應用,可将配置内容放在application.yml檔案中。如果需要切換環境,可設定多個Profile,并在啟動應用時指定spring.profiles.active={profile}。然而,在微服務架構中,微服務的配置管理一般有以下需求:

  • 集中管理配置。 一個使用微服務架構的應用系統可能會包含成百上千個微服務,是以集中管理配置是非常有必要的。
  • 不同環境,不同配置;例如,資料源配置在不同的環境(開發、測試、預釋出、生産等)中是不同的。
  • 運作期間可動态調整 ;例如可根據各個微服務的負載情況動态調整資料源連接配接池大小或熔斷門檻值,并且在調整配置時不停止微服務。
  • 配置修改後可自動更新 ;如配置内容發生變化,微服務能夠自動更新配置。

綜上所述,

對于微服務架構而言,一個通用的配置管理機制是必不可少的,常見做法是使用配置伺服器管理配置。Spring cloud bus利用Git或SVN 等管理配置、采用Kafka或者RabbitMQ等消息總線通知所有應用,進而實作配置的自動更新并且重新整理所有微服務執行個體的配置。

Sleuth+ZipKin(跟蹤服務)

Sleuth 和 Zipkin 結合使用可以通過圖形化的界面檢視微服務請求的延遲情況以及各個微服務的依賴情況。

需要注意的是Spring boot2及以上不在支援Zipkin的自定義,需要到官方網站下載下傳ZipKin相關的jar包。

另外需要提一點的是Spring boot actuator,提供了很多監控端點如/actuator/info、/actuator/health、/acutator/refresh等,可以檢視微服務的資訊、健康狀況、重新整理配置等。

轉載自微信公衆号:架構師日刊–《簡單了解 Spring Cloud 的微服務架構》