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

所以今天就給大家聊聊這個微服務架構下的服務治理。

單體架構

首先，要說到微服務架構，那么先來講講，大家平時玩兒微服務架構到底是怎么來弄的。

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

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

如下圖：

微服務架構

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

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

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

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

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

如下圖：

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

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

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

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

那么一個服務可以發(fā)現(xiàn)另外一個服務實例的多臺機器，到底應該調用哪一臺呢?

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

如下圖：

服務治理之限流熔斷

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

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

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

如下圖：

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

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

如下圖：

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

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

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

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

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

如下圖：

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

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

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

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

如下圖：

好了，今天給大家介紹的微服務治理的內容到這里就結束了。