Spring Cloud 雲服務深入理解

一.spring cloud的理解

1、微服務的特性

史上最簡單的 springcloud 教程 | 終章

2、微服務元件架構

圖中漏掉了 config server 和鏈路追蹤元件，config server 是乙個與所有服務相連的服務集群，鏈路追蹤元件則整合在每個服務中。

3、spring cloudvsbubbo的對比

點這裡《

二.微服務核心問題

假設服務 a 要呼叫服務 b，會有什麼問題？

1、服務在哪？（服務治理問題）

spring cloud 提供了 eureka、zookeeper、cloud foundry、consul 等服務治理框架的整合。它們的工作模式是將所有的微服務註冊到乙個 server 上，然後通過心跳進行服務健康監測。這樣服務 a 呼叫 b 時可以從註冊中心拿到可用的服務 b 的位址、埠進行呼叫。

2、怎麼呼叫？（服務呼叫問題）

一般人認為就是乙個簡單的 http 或者 rpc 呼叫，不是什麼問題。但是在分布式的場景下，服務呼叫需要考慮的因素會更多。比如乙個服務有多個例項，此時請求進來了交給誰處理，請求的負載怎麼平衡到各個例項，都是比較棘手的問題。spring cloud 提供了兩種服務呼叫的方式：一種是 ribbon + resttemplate，另一種是 feign。

spring cloud的負載均衡

既然兩個問題都得到了解決，我們就用乙個例子來進一步說明一下，例子包含了微服務中最基本的三個角色（註冊中心、服務提供者、服務消費者)：

（1）註冊中心

註解 @enableeurekaserver 表示該 spring boot 應用是乙個註冊中心。

@enableeurekaserver
public static void main(string args) 
}

eureka.client.registerwitheureka: false 和fetchregistry: false 來表明自己是乙個 eureka server。

（2）service-hello 服務註解 @enableeurekaclient 表示他是乙個 eureka 客戶端，它會在註冊中心註冊自己。

@enableeurekaclient

@restcontroller

public static void main(string args)

@value("$")

string port;

public string home(@requestparam string name) }

註冊中心的位址為 http://localhost:8080/eureka/，也就是上面我們定義的。服務名為 service-hello，將會被呼叫者使用。

（3）服務消費者 service-ribbon假設 service-ribbon 埠為 8082，當我們訪問 http://localhost:8080/hello 時，hellocontroler 接收到請求，並呼叫 helloservice 中的 helloservice 方法，helloservice 中通過定義的 resttemplate 去呼叫 http://service-hello/hello。此處要注意的是 @loadbalanced 註解，它表示啟用負載均衡。

@enablediscoveryclient

public static void main(string args)

@bean

@loadbalanced

resttemplate resttemplate() }

@service
public class helloservice 
}

@restcontroller
public class hellocontroler 
}

三.微服務的生命週期1、服務「雪崩」與斷路器

由於網路等原因，服務並不能保證 100% 可用，如果單個服務出現問題，呼叫這個服務就會出現執行緒阻塞，此時若有大量的請求湧入，servlet 容器的執行緒資源會被消耗殆盡，導致服務癱瘓。由於服務與服務之間存在依賴，基礎服務的故障可能會導致級聯故障，進而造成整個微服務系統崩潰，這就是服務故障的「雪崩」效應。

2、服務暴露與路由閘道器

微服務中的服務很多，直接暴露給使用者一是不安全，二是對使用者不友好。因此在微服務和面向服務的架構中，通常會有乙個路由閘道器的角色，來負責路由**和過濾。對應到 spring cloud 中有 zuul 和 gateway 兩個元件可用。

路由閘道器接收了所有的使用者請求，有著很高的負載，因此它通常是乙個集群。使用者的請求會先經過一層負載均衡被發到路由閘道器。

3、服務配置與配置中心

在微服務應用中，服務數量巨多，而每個服務不同環境都有著不同的配置，為了方便服務配置檔案統一管理，實時更新，所以需要分布式配置中心元件。需要注意的是此處的配置與註冊中心註冊的配置資訊是兩個概念，此處的配置是服務本身的一些配置資訊，如下圖：

spring cloud 提供了 spring cloud config 元件，它支援配置服務放在配置服務的記憶體中（即本地），也支援放在遠端 git 倉庫中，幫助我們管理服務的配置資訊。

4、資訊同步與訊息匯流排

前乙個問題講到了每個服務都有一些配置資訊，那麼配置資訊更新了我們該怎麼辦，手動乙個個去更新？當然不是，spring cloud 提供了 spring cloud bus 元件，它通過輕量訊息**連線各個分布的節點。當配置資訊更新的時候，我們只要更新乙個節點的配置，這個更新就會被廣播到這個分布式系統中。

5、問題定位與鏈路追蹤

在微服務系統中，服務之間可以相互呼叫，因此我們乙個請求可能會一條呼叫鏈，而整個系統會存在一張呼叫網，其中任意乙個服務呼叫失敗或網路超時都可能導致整個請求失敗。因為呼叫關係的複雜，這給問題的定位造成了極大的困難，這也是必須提供服務鏈路追蹤的原因。

spring cloud 為我們提供了 spring cloud sleuth 元件，它能夠跟進乙個請求到底有哪些服務參與，參與的順序是怎樣的，從而達到每個請求的步驟清晰可見。借助服務鏈路追蹤，我們可以快速定位問題。

Spring Cloud 雲服務深入理解

Spring Cloud分布式微服務雲架構簡介

SpringCloud服務調服務

springcloud 服務降級

Spring Cloud 雲服務深入理解

Spring Cloud分布式微服務雲架構 簡介

SpringCloud服務調服務

springcloud 服務降級

相關推薦

Spring Cloud分布式微服務雲架構簡介