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

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

單體架構(gòu)

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

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

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

如下圖：

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

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

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

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

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

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

如下圖：

就跟這個(gè)圖一樣，其實(shí)很多服務(wù)互相之間調(diào)用，大致可以就先理解為一個(gè)微服務(wù)的架構(gòu)了，因?yàn)槲覀兊膯螇K系統(tǒng)已經(jīng)被拆分為了很多的服務(wù)了。那么接著來(lái)說(shuō)，我們對(duì)于這種微服務(wù)架構(gòu)如何進(jìn)行服務(wù)治理呢？

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

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

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

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

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

如下圖：

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

接著呢，這個(gè)服務(wù)治理里面第三個(gè)事兒，就是限流熔斷，分兩塊來(lái)說(shuō)，因?yàn)橄蘖魇怯脕?lái)防止系統(tǒng)被壓垮的，熔斷是用來(lái)防止系統(tǒng)被拖垮的。

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

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

如下圖：

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

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

如下圖：

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

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

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

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

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

如下圖：

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

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

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

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

如下圖：

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