從SpringCloud看一個微服務框架的「五臟六腑」

Spring Cloud 是一個基於 Spring Boot 實現的微服務框架，它包含了實現微服務架構所需的各種元件。

注：Spring Boot 簡單理解就是簡化 Spring 專案的搭建、配置、組合的框架。因為與構建微服務本身沒有直接關係，所以本文不對 Spring Boot 進行展開。另外本文有一些例子涉及到 Spring 和 Spring Boot，建議先了解一下 Spring 和 Spring Boot 再閱讀本文。

本文的閱讀物件主要是沒有接觸過服務架構，想對其有一個巨集觀的瞭解的同學。

本文將從 Spring Cloud 出發，分兩小節講述微服務框架的「五臟六腑」：

第一小節「服務架構」旨在說明的包括兩點，一服務架構是什麼及其必要性；二是服務架構的基本組成。為什麼第一節寫服務架構而不是微服務架構呢？原因主要是微服務架構本身與服務架構有著千絲萬縷的關係，服務架構是微服務架構的根基。

第二小節「五臟六腑」則將結合 Spring Cloud 這個特例來介紹一個完整的微服務框架的組成。

「服務架構」

為了方便理解，我先講一個小故事：（改編自一知乎答主）

Martin（微服務提出者也叫 Martin）剛來到公司時是一個基層員工，它上面有經理、老闆，那個時候所有人都聽老闆的指揮。

但是過了兩年，公司的人越來越多，原來的模式下整個公司的運作效率太低，管理也很混亂。

於是已經踏上中層崗位的 Martin 建議老闆進行部門劃分（服務化），專門的部門只做專門的事情（單一職責）。例如研發部門只做研發，人事部門只做招聘。

老闆聽取了 Martin 的意見，對公司的組織架構進行了調整。

有一天，Martin 發現公司的部門越來越多，各個部門並不能完全知道對方所做的事情，這對跨部門協作（服務呼叫）帶來了困難。

行政部門會（註冊中心）來記錄所有的部門，每當有新的部門行政都會記錄下來（服務註冊），然後公佈出來讓所有部門知道（服務發現）。

在新的組織架構下，公司的效率逐步提高。老闆也給 Martin 發了大量獎金作為獎勵，Martin 從此贏取白富美走向了人生巔峰。

這是一個公司組織架構演變的故事，主要講的是隨著公司規模的擴大，組織從集中化管理到分佈化管理的過程。

對映到我們的資訊系統裡來也是一樣的，隨著我們的系統越來越複雜，變得難以管理，也有人想到去拆分然後治理。在解決複雜問題上，分治可以說是一個屢試不爽的辦法。

服務化即是拆解的一種手段。而上面圓括號裡面的內容其實就對應了一個服務化架構的最小組成元素，分別是服務、服務呼叫、註冊中心、服務註冊、服務發現。有了這些基本的組成要素，就可以實現一個最簡單的服務架構。

面向服務的架構和微服務架構

面向服務的架構（SOA）和微服務架構是目前兩種主流的服務化架構，都符合上面的例子，也有上面提到的所有元件。這兩種服務架構有很多可以講的，但是與本文的相關性不大，本文不做會過多展開，只簡單介紹一下兩者的區別。

準確地說微服務是去 ESB（企業服務匯流排）的 SOA。ESB 借鑑了計算機組成原理中的通訊模型 —— 匯流排，所有需要和外部系統通訊的系統，通過 ESB 進行標準化地轉換從而消除協議、異構系統之間的差異，這樣就可以利用現有的系統構建一個全新的鬆耦合的異構的分散式系統。微服務架構去掉 ESB，本質上是一種去中心化的思想。

「五臟六腑」

「心臟」

順著上一節的思路，從最簡單、最核心的問題出發，假設服務 A 要呼叫服務 B，會有什麼問題？

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

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

這兩個是最核心的問題，也是任何微服務框架首要解決的兩個問題。

為了解決第一個問題 Spring Cloud 提供了 Eureka、Zookeeper、Cloud Foundry、Consul 等服務治理框架的整合。它們的工作模式是將所有的微服務註冊到一個 Server 上，然後通過心跳進行服務健康監測。這樣服務 A 呼叫 B 時可以從註冊中心拿到可用的服務 B 的地址、埠進行呼叫。

第二個服務呼叫有人可能認為就是一個簡單的 HTTP 或者 RPC 呼叫，不是什麼問題。但是在分散式的場景下，服務呼叫需要考慮的因素會更多。比如一個服務有多個例項，此時請求進來了交給誰處理，請求的負載怎麼平衡到各個例項，都是比較棘手的問題。Spring Cloud 提供了兩種服務呼叫的方式：一種是 Ribbon + restTemplate，另一種是 Feign。

其中 Ribbon 是基於 HTTP 和 TCP 客戶端的負載均衡器，restTemplate 是 Spring 提供的 Restful 遠端呼叫的模板，兩者結合就可以達到遠端呼叫的負載均衡。

而 Feign 是一個更加宣告式的 HTTP 客戶端，開發者可以像呼叫本地方法一樣呼叫它，完全感覺不到是遠端呼叫，結合 Ribbon 也可以做負載均衡。

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

註冊中心

註解 @EnableEurekaServer 表示該 Spring Boot 應用是一個註冊中心。

 

eureka.client.registerWithEureka: false 和fetchRegistry: false 來表明自己是一個 eureka server。

 

service-hello 服務

註解 @EnableEurekaClient 表示他是一個 Eureka 客戶端，它會在註冊中心註冊自己。

註解 @RestController 表示這是一個控制器，@RequestMapping(“/hello”) 表示匹配到請求 `/hello` 時會呼叫該方法進行響應。

 

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

 

假設 service-ribbon 埠為 8082，當我們訪問 http://localhost:8080/hello 時，HelloControler 接收到請求，並呼叫 HelloService 中的 helloService 方法，HelloService 中通過定義的 restTemplate 去呼叫 http://service-hello/hello。此處要注意的是 @LoadBalanced 註解，它表示啟用負載均衡。

 

至此其實一個微服務應用的雛形已經搭建出來了，服務治理、服務呼叫可以說是「五臟六腑」中的「心臟」。

「心臟」的依託

接下來我們要進一步思考的是「五臟六腑」中其餘的部分，因為少了它們人也是活不久的。下面通過一個問題或需求對應一個元件的方式進行介紹。

服務“雪崩”與斷路器

由於網路等原因，服務並不能保證 100% 可用，如果單個服務出現問題，呼叫這個服務就會出現執行緒阻塞，此時若有大量的請求湧入，Servlet 容器的執行緒資源會被消耗殆盡，導致服務癱瘓。

由於服務與服務之間存在依賴，故障會在呼叫鏈路上傳播，導致整個微服務系統崩潰，這就是服務故障的“雪崩”效應。

為了解決這個問題，Spring Cloud 提供了對 Hystrix 斷路器的整合，當服務呼叫失敗的頻次達到一定閾值，斷路器將被開啟，降級的策略可以開發者制定，一般是返回一個固定值。這樣就能夠避免連鎖故障。

此外 Spring Cloud 還提供 Hystrix Dashboard 和 Hystrix Turbine，幫助我們進行監控和聚合監控。

服務暴露與路由閘道器

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

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

服務配置與配置中心

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

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

資訊同步與訊息匯流排

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

問題定位與鏈路追蹤

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

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

至此，Spring Cloud 的所有基礎元件都介紹完了。但是目前所有的元件介紹都是分散的，它們組合起來，完整的樣子是什麼樣的？如下圖：

偷懶偷了張圖，圖中漏掉了 Config Server 和鏈路追蹤元件。但是結合上文的介紹，我們大致可以腦補出這兩個東西在圖中的位置。Config Server 是一個與所有服務相連的服務叢集，鏈路追蹤元件則整合在每個服務中。

小結

服務治理為心臟，路由閘道器、訊息中心、斷路器、鏈路追蹤、配置中心等為依託，構造了整個微服務框架的「五臟六腑」。當然，一個微服務系統遠比本文所寫的複雜得多，尤其是在不同的業務場景之下，因此想要更深入地瞭解它就需要我們不斷地去實踐。而作為前端，我瞭解這些內容一是為了更好地瞭解整個請求的流程，二是為了後續在 SOA 中接入 Node 子服務積累相關知識。

最後分享一句有趣的調侃 Spring 的話：在 Spring 中沒有什麼是一個註解解決不了的，如果有，那麼就用兩個註解。

歡迎工作一到五年的Java工程師朋友們加入Java填坑之路：860113481

群內提供免費的Java架構學習資料（裡面有高可用、高併發、高效能及分散式、Jvm效能調優、Spring原始碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用自己每一分每一秒的時間來學習提升自己，不要再用”沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！