我設計了一套微服務系統，可是上了生產環境直接崩潰…
?今天給大家分享一個話題，是關于微服務架構的服務治理的，很多小伙伴可能都覺得自己玩兒過微服務架構，然后可能也聽說過服務治理，但是服務治理到底是什么，有哪些東西，服務治理到底應該怎么來做，這個可能就一頭霧水了。
所以今天就給大家聊聊這個微服務架構下的服務治理。
單體架構
首先，要說到微服務架構，那么先來講講，大家平時玩兒微服務架構到底是怎么來弄的。
其實說來也特簡單，以前沒有上微服務的時候，可能直接就是 SpringBoot+SSM 這一套架構就直接寫一個單塊新系統就 ok 了，用 SpringBoot 打一個 jar 包，然后 jar 包部署到線上系統以后，直接用 java -jar 命令啟動 JVM 進程運行咱們的代碼就行了。
用 SpringBoot 的時候一般對外接收 Http 請求的 Web 服務器是內嵌的 Tomcat，就是 SpringBoot 基于 main 方法啟動之后，內嵌啟動一個 Tomcat，Tomcat 會對外監聽一個端口號，然后我們就針對那個端口號發起 Http 請求就可以了。
如下圖：
微服務架構
所以這個時候咱們的系統從本質上來說，他就是一個單塊系統，那如果升級到微服務架構的話，應該是怎么樣的呢？
微服務的話，意思就是說把原來一個單塊系統拆分成很多個服務，服務跟服務之間是通過 Nacos+Dubbo 這種服務注冊中心和 RPC 框架來進行調用的。
5 年以前一般業內常用的微服務基礎框架是 Dubbo+Zookeeper 的組合，但是 3 年以前基本都過渡到了 SpringCloud 技術棧做微服務架構。
一兩年前開始業內基本慢慢過渡到了 SpringCloud Alibaba 技術棧，就是說，用 Nacos 作為服務注冊中心，用 Dubbo 作為 RPC 框架，所以我們就以 SpringCloud Alibaba 的 Nacos+Dubbo 組合來舉例。
搞微服務的話，就是說，讓各個服務都注冊到 Nacos 里去，然后服務要調用別的服務，就通過 Nacos 進行服務發現，接著通過 Dubbo 進行 RPC 調用。
如下圖：
就跟這個圖一樣，其實很多服務互相之間調用，大致可以就先理解為一個微服務的架構了，因為我們的單塊系統已經被拆分為了很多的服務了。那么接著來說，我們對于這種微服務架構如何進行服務治理呢？
服務治理之注冊與發現和負載均衡
首先要跟大家說的一點是，服務治理的第一個事兒，其實就是服務注冊和發現，所以說，通過 Nacos 實現服務注冊和發現，就已經干了服務治理的第一個事兒了。
好，那么服務治理的第二個事兒是什么呢？其實就是負載均衡，這個負載均衡是什么意思呢？其實就是說，我們每個服務都可以部署多臺機器，就有多個服務實例。
那么一個服務可以發現另外一個服務實例的多臺機器，到底應該調用哪一臺呢？
這個時候就得用負載均衡算法了，用算法找到一臺機器，然后就可以針對那臺機器發起一次 RPC 調用。這個負載均衡的活兒，就是 Dubbo 給我們干的。
如下圖：
服務治理之限流熔斷
接著呢，這個服務治理里面第三個事兒，就是限流熔斷，分兩塊來說，因為限流是用來防止系統被壓垮的，熔斷是用來防止系統被拖垮的。
先說限流，假設你的系統正常最多只能抗每秒 1000 個請求，結果此時來了每秒 2000 個請求，會如何？
當然會壓垮你的系統了，所以此時我們就必須做一個限流，如果每秒超過了 1000 個請求，后續的請求全部都直接返回禁止訪問。
如下圖：
然后來說熔斷，熔斷的意思是說，如果你調用一個系統，結果那個系統掛了，然后你每次調用他都是失敗失敗失敗，而且每次失敗還得阻塞一會兒那不就把你自己給拖垮了嗎？
所以這個時候就必須上熔斷，如果一旦發現要是在一段時間內頻繁調用別人失敗，此時就觸發熔斷，熔斷之后，就每次請求過來直接報錯返回。
如下圖：
那么這個限流和熔斷是靠誰給你干呢？SpringCloud Alibaba 里的 Sentinel 就可以把這個事兒給你干了，所以限流熔斷這塊工作是他給干的。
服務治理的下一個活兒是配置中心，就是說，平時咱們系統的配置是不是都是放在 src/main/rsource 目錄下的各種 properties 和 xml 文件。
但是如果你要是系統部署上線了，你要修改配置，就只能修改代碼里的配置，然后重新打包部署上線，這太麻煩了，對不對。
所以如果引入一個配置中心，系統的一些核心配置直接從配置中心里動態加載，然后如果要修改配置直接在配置中心里修改。
接著線上系統直接就感知到最新配置運用就可以了，那就不用每次修改配置都打包重新部署了，這個配置中心的活兒是 Nacos 給我們干的。
如下圖：
服務治理之服務監控
然后服務治理的最后一個環節，就是服務監控，這個監控包括了很多內容，比如說對線上系統部署的各個服務器的 CPU、內存、磁盤、網絡、IO 進行監控，以及對線上系統的 JVM GC 進行監控，包括對線上系統的各個接口的 QPS 和延遲進行監控。
同時還可以對線上微服務系統的各個服務之間進行調用的調用鏈路進行監控，這些事情通常是用 Prometheus 和 Skywalking 兩個監控系統配合完成的。
Skywalking 通常可以追蹤我們的微服務調用鏈路，Prometheus 可以對我們的線上系統的服務器、JVM 以及接口各個層次進行監控。
如下圖：
好了，今天給大家介紹的微服務治理的內容到這里就結束了。
