?今天給大家分享一個話題，是關(guān)于微服務(wù)架構(gòu)的服務(wù)治理的，很多小伙伴可能都覺得自己玩兒過微服務(wù)架構(gòu)，然后可能也聽說過服務(wù)治理，但是服務(wù)治理到底是什么，有哪些東西，服務(wù)治理到底應(yīng)該怎么來做，這個可能就一頭霧水了。

所以今天就給大家聊聊這個微服務(wù)架構(gòu)下的服務(wù)治理。

單體架構(gòu)

首先，要說到微服務(wù)架構(gòu)，那么先來講講，大家平時玩兒微服務(wù)架構(gòu)到底是怎么來弄的。

其實說來也特簡單，以前沒有上微服務(wù)的時候，可能直接就是 SpringBoot+SSM 這一套架構(gòu)就直接寫一個單塊新系統(tǒng)就 ok 了，用 SpringBoot 打一個 jar 包，然后 jar 包部署到線上系統(tǒng)以后，直接用 java -jar 命令啟動 JVM 進程運行咱們的代碼就行了。

用 SpringBoot 的時候一般對外接收 Http 請求的 Web 服務(wù)器是內(nèi)嵌的 Tomcat，就是 SpringBoot 基于 main 方法啟動之后，內(nèi)嵌啟動一個 Tomcat，Tomcat 會對外監(jiān)聽一個端口號，然后我們就針對那個端口號發(fā)起 Http 請求就可以了。

如下圖：

微服務(wù)架構(gòu)

所以這個時候咱們的系統(tǒng)從本質(zhì)上來說，他就是一個單塊系統(tǒng)，那如果升級到微服務(wù)架構(gòu)的話，應(yīng)該是怎么樣的呢？

微服務(wù)的話，意思就是說把原來一個單塊系統(tǒng)拆分成很多個服務(wù)，服務(wù)跟服務(wù)之間是通過 Nacos+Dubbo 這種服務(wù)注冊中心和 RPC 框架來進行調(diào)用的。

5 年以前一般業(yè)內(nèi)常用的微服務(wù)基礎(chǔ)框架是 Dubbo+Zookeeper 的組合，但是 3 年以前基本都過渡到了 SpringCloud 技術(shù)棧做微服務(wù)架構(gòu)。

一兩年前開始業(yè)內(nèi)基本慢慢過渡到了 SpringCloud Alibaba 技術(shù)棧，就是說，用 Nacos 作為服務(wù)注冊中心，用 Dubbo 作為 RPC 框架，所以我們就以 SpringCloud Alibaba 的 Nacos+Dubbo 組合來舉例。

搞微服務(wù)的話，就是說，讓各個服務(wù)都注冊到 Nacos 里去，然后服務(wù)要調(diào)用別的服務(wù)，就通過 Nacos 進行服務(wù)發(fā)現(xiàn)，接著通過 Dubbo 進行 RPC 調(diào)用。

如下圖：

就跟這個圖一樣，其實很多服務(wù)互相之間調(diào)用，大致可以就先理解為一個微服務(wù)的架構(gòu)了，因為我們的單塊系統(tǒng)已經(jīng)被拆分為了很多的服務(wù)了。那么接著來說，我們對于這種微服務(wù)架構(gòu)如何進行服務(wù)治理呢？

服務(wù)治理之注冊與發(fā)現(xiàn)和負載均衡

首先要跟大家說的一點是，服務(wù)治理的第一個事兒，其實就是服務(wù)注冊和發(fā)現(xiàn)，所以說，通過 Nacos 實現(xiàn)服務(wù)注冊和發(fā)現(xiàn)，就已經(jīng)干了服務(wù)治理的第一個事兒了。

好，那么服務(wù)治理的第二個事兒是什么呢？其實就是負載均衡，這個負載均衡是什么意思呢？其實就是說，我們每個服務(wù)都可以部署多臺機器，就有多個服務(wù)實例。

那么一個服務(wù)可以發(fā)現(xiàn)另外一個服務(wù)實例的多臺機器，到底應(yīng)該調(diào)用哪一臺呢？

這個時候就得用負載均衡算法了，用算法找到一臺機器，然后就可以針對那臺機器發(fā)起一次 RPC 調(diào)用。這個負載均衡的活兒，就是 Dubbo 給我們干的。

如下圖：

服務(wù)治理之限流熔斷

接著呢，這個服務(wù)治理里面第三個事兒，就是限流熔斷，分兩塊來說，因為限流是用來防止系統(tǒng)被壓垮的，熔斷是用來防止系統(tǒng)被拖垮的。

先說限流，假設(shè)你的系統(tǒng)正常最多只能抗每秒 1000 個請求，結(jié)果此時來了每秒 2000 個請求，會如何？

當(dāng)然會壓垮你的系統(tǒng)了，所以此時我們就必須做一個限流，如果每秒超過了 1000 個請求，后續(xù)的請求全部都直接返回禁止訪問。

如下圖：

然后來說熔斷，熔斷的意思是說，如果你調(diào)用一個系統(tǒng)，結(jié)果那個系統(tǒng)掛了，然后你每次調(diào)用他都是失敗失敗失敗，而且每次失敗還得阻塞一會兒那不就把你自己給拖垮了嗎？

所以這個時候就必須上熔斷，如果一旦發(fā)現(xiàn)要是在一段時間內(nèi)頻繁調(diào)用別人失敗，此時就觸發(fā)熔斷，熔斷之后，就每次請求過來直接報錯返回。

如下圖：

那么這個限流和熔斷是靠誰給你干呢？SpringCloud Alibaba 里的 Sentinel 就可以把這個事兒給你干了，所以限流熔斷這塊工作是他給干的。

服務(wù)治理的下一個活兒是配置中心，就是說，平時咱們系統(tǒng)的配置是不是都是放在 src/main/rsource 目錄下的各種 properties 和 xml 文件。

但是如果你要是系統(tǒng)部署上線了，你要修改配置，就只能修改代碼里的配置，然后重新打包部署上線，這太麻煩了，對不對。

所以如果引入一個配置中心，系統(tǒng)的一些核心配置直接從配置中心里動態(tài)加載，然后如果要修改配置直接在配置中心里修改。

接著線上系統(tǒng)直接就感知到最新配置運用就可以了，那就不用每次修改配置都打包重新部署了，這個配置中心的活兒是 Nacos 給我們干的。

如下圖：

服務(wù)治理之服務(wù)監(jiān)控

然后服務(wù)治理的最后一個環(huán)節(jié)，就是服務(wù)監(jiān)控，這個監(jiān)控包括了很多內(nèi)容，比如說對線上系統(tǒng)部署的各個服務(wù)器的 CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)、IO 進行監(jiān)控，以及對線上系統(tǒng)的 JVM GC 進行監(jiān)控，包括對線上系統(tǒng)的各個接口的 QPS 和延遲進行監(jiān)控。

同時還可以對線上微服務(wù)系統(tǒng)的各個服務(wù)之間進行調(diào)用的調(diào)用鏈路進行監(jiān)控，這些事情通常是用 Prometheus 和 Skywalking 兩個監(jiān)控系統(tǒng)配合完成的。

Skywalking 通?？梢宰粉櫸覀兊奈⒎?wù)調(diào)用鏈路，Prometheus 可以對我們的線上系統(tǒng)的服務(wù)器、JVM 以及接口各個層次進行監(jiān)控。

如下圖：

好了，今天給大家介紹的微服務(wù)治理的內(nèi)容到這里就結(jié)束了。