背景：學習材料《227-Spring Cloud 微服務專案實戰》

227-Spring Cloud 微服務專案實戰

簡介

 

 

在上面這幅圖中，我們可以看到有幾個 Spring Boot Apps 的應用叢集，這就是經過拆分 後的微服務。Spring Cloud 和 Spring Boot 達成了一種默契的配合：Spring Boot 主內， 通過自動裝配和各種開箱即用的特性，搞定了資料層訪問、RESTful 介面、日誌元件、內 置容器等等基礎功能，讓開發人員不費吹灰之力就可以搭建起一個應用；Spring Cloud 主 外，在應用叢集之外提供了各種分散式系統的支援特性，幫助你輕鬆實現負載均衡、熔斷 降級、配置管理等諸多微服務領域的功能。 從 Spring Boot 和 Spring Cloud 的分工中我們可以看出，Spring Boot 忙活的是底層的 柴米油鹽醬醋茶，Spring Boot 後勤保障做得好，才能讓 Spring Cloud 毫無顧慮地投身於 微服務的星辰大海，兩者合二為一完整構建了微服務領域的全家桶解決方案。

元件歷史

在我們開始瞭解 Spring Cloud 元件庫之前，我得先介紹在 Spring Cloud 歷史上舉足輕重 的兩家公司 Netflix 和 Alibaba，以及它們的恩怨情仇。這兩家公司分別為開源社群貢獻了 Spring Cloud Netflix 元件庫和 Spring Cloud Alibaba 元件庫。 Netflix 是一家美國的流媒體巨頭，它靠著自己強 大的技術實力，開發沉澱了一系列優秀的元件，這些元件經歷了 Netflix 線上龐大業務規模 的考驗，功能特性和穩定性過硬。如 Eureka 服務註冊中心、Ribbon 負載均衡器、 Hystrix 服務容錯元件等。後來發生的故事可能你已經猜到了，Netflix 將這些元件貢獻給 了 Spring 開源社群，構成了 Netflix 元件庫。可以這麼說，在 Spring Cloud 的早期階 段，是 Netflix 打下了的半壁江山。   Spring Cloud Alibaba 是由 Alibaba 貢獻的元件庫，隨著阿里在開源路線上的持續投入， 近幾年阿里系在開源領域的聲音非常響亮。Spring Cloud Alibaba 凝聚了阿里系在電商 領域超高併發經驗的重量級元件，保持了旺盛的更新活力，成為了 Spring Cloud 社群的 一股新生代力量，逐漸取代了舊王 Netflix 的江湖地位。

Spring Cloud 全家桶元件庫

 

 

03 | 初窺門徑：我們要搭建一個怎樣的微服務實戰專案？

上圖是優惠券的微服務模組

下圖是使用的相關元件

 

 

 

根據微服務學習的路徑以及各個元件的難易程度，我把整個微服務框架由淺入深分為了三 個不同的階段： 第一階段：搭建基礎的微服務功能，實現微服務之間的通訊； 第二階段：為各個模組構建服務容錯、分散式配置中心、分散式鏈路追蹤能力； 第三階段：進一步實現微服務閘道器、訊息驅動和分散式事務。

第一階段

在第一階段，我們主要實現微服務之間的通訊，將使用者微服務、優惠券模板服務和訂單優 惠計算服務拆分為獨立部署的業務系統，通過註冊中心來實現服務註冊和服務發現，讓各 個微服務之間可以互相呼叫。這個階段涉及的關鍵技術是 Nacos 註冊中心、 Loadbalancer 客戶端負載均衡元件和 OpenFeign 服務間呼叫元件。 我們知道，微服務之間的服務通訊有一個前提條件，就是你要知道將要呼叫的伺服器地址 是什麼。這個定址的任務是交由 Nacos 註冊中心和 Loadbalancer 負載均衡器共同來完成 的。 Nacos 是 Alibaba 出品的服務治理元件，它作為一個註冊中心元件，負責收集所有服務節 點的地址資訊並維護服務登錄檔，所有服務上線之後都會向它彙報狀態。Loadbalancer 則 承擔了負載均衡的任務，在客戶端發起服務呼叫的時候，它會負責從 Nacos 的登錄檔中挑 選一臺目標伺服器。而 OpenFeign 元件是一個“錦上添花”的元件，它能夠簡化基於 HTTP 的遠端服務呼叫，讓我們就像使用本地介面一樣方便地發起遠端服務呼叫。 為什麼我會選擇 Nacos+Loadbalancer 作為選型方案呢？其實，在早期版本的 Spring Cloud 微服務架構選型中，Eureka + Ribbon 是一個使用最為廣泛的組合，它們是 Netflix 公司貢獻給 Spring Cloud 專案的服務治理 + 負載均衡元件。 我們在上節課中講過，Netflix 正在退出 Spring Cloud 的歷史舞臺。Eureka 和 Ribbon 已 經進入了維護狀態。其中，Ribbon 更是在 Spring Cloud I 版之後，就從官方元件庫中被 移除了。這意味著 Eureka 和 Ribbon 已經進入了“暮年”，不會再有重大的功能更新， 如果你在專案中使用 Netflix 元件庫，那麼在未來將無法享受 Spring Cloud 社群釋出的新 功能。 因此，在考慮技術選型的時候，我選擇了後勁更足、功能更為強大的 Nacos 和 Spring Cloud 官方開源的 Loadbalancer 元件。大致來講，在第一階段，我會分為三個部分來帶 你搭建起微服務之間的通訊： 1 服務治理：服務治理的重點是搭建基礎的跨服務呼叫功能。我會把使用者服務、優惠計算 服務和訂單服務改造成可以獨立啟動的微服務，並藉助 Nacos 的服務發現功能，通過 Webflux 元件中的 WebClient 實現基於 HTTP 的跨服務間的呼叫； 2.負載均衡：在這部分，我們將在服務治理的基礎上，引入 Loadbalancer 元件為跨服務 呼叫新增負載均衡的能力。除此之外，我會對 Loadbalancer 元件的擴充套件介面做自定義 開發，實現一個金絲雀測試的負載均衡場景； 3.簡化服務呼叫：我將使用 OpenFeign 元件對使用者服務進行改造，將原先複雜的 WebClient 呼叫替換為簡潔的 OpenFeign 呼叫。 

第二階段

在第二階段，我們的實戰重點有三個： 利用服務容錯提高微服務架構的可用性； 搭建全鏈路的分散式鏈路追蹤能力； 實現統一的配置管理和動態屬性推送 這個階段涉及的技術元件是 Nacos Config、Sentinel、Sleuth+Zipkin+ELK。 在微服務架構中，服務容錯是保障服務高可用的一個重要手段。在這個專案中，我們選擇 用 Sentinel 作為服務容錯元件，它也是 Alibaba 貢獻給 Spring Cloud 的。Sentinel 秉承 了阿里系“大而全”的傳統，只這一款元件就可以實現降級、熔斷、流量整形等多種服務 容錯途徑。 鏈路追蹤也是微服務架構中一個很重要的功能，線上異常排查全靠它提供線索。我使用了 Spring Cloud 官方開源的 Sleuth 實現了日誌打標功能，使用全域性唯一標記將一次跨微服 務呼叫鏈上的各個環節全部串聯起來。  光打標還沒用，我還結合了 Zipkin 元件實現呼叫鏈的視覺化檢索，將呼叫鏈上各個階段的 請求按順序顯示在頁面上，這樣，我們就可以一目瞭然定位到線上異常發生在哪個環節。 另外，我使用了目前業界主流的 ELK 組合（Elastic Search + Logstash + Kibana）作為 日誌檢索系統。 在配置項管理的技術選型方面，我使用了 Nacos Config 作為最終方案。藉助 Nacos Config 我們可以輕鬆實現配置項的遠端獲取和動態推送，在配置項的應用隔離和環境隔離 方面 Nacos 也是一把好手，我將會在配置管理的實戰環節講述更多的配置項花式玩法。相 比較 Spring Cloud 的另一款配置管理元件 Spring Cloud Config 來說，Nacos 的搭建更 加容易且更易於上手，而且可以更好地支援“配置項”回滾的功能。 在後面的課程中，我將按照下面的順序來實現這些能力： 1.配置管理：配置管理的重點是將三個微服務應用接入到 Nacos Config 配置中心，使用 遠端配置中心儲存部分配置項。 2.服務容錯：搭建 Sentinel Dashboard 控制檯，通過控制檯將降級規則和流量整形規則 應用到業務埋點中。 3. 鏈路追蹤：這部分的重點是搭建分散式鏈路追蹤與日誌系統。

第三階段

在第三階段，我們的實戰重點有三個： 搭建微服務閘道器作為統一流量入口； 使用訊息驅動元件對接 RabbitMQ； 通過分散式事務保證資料一致性。   這個階段涉及的技術元件是 Gateway、Stream 和 Seata。 微服務閘道器是架設在外部閘道器（如 Ngnix）和內部微服務之間的一座橋樑，我選用 Spring Cloud Gateway 作為閘道器元件。Gateway 不光擔任了路由轉發的重任，同時它提供了豐 富的謂詞組合實現複雜的路由判斷邏輯。除此以外，你還可以在閘道器層定義攔截器，對來 訪請求執行一段特殊的業務邏輯。  曾經微服務閘道器的頭把交椅是 Netflix 貢獻的 Zuul 元件，但 Zuul 2.0 的開源釋出一拖再 拖，且效能並未達到預期效果。Spring Cloud 官方迫不得已，還沒等到 Zuul 2.0 釋出， 就自己釋出了一款開源閘道器元件 Spring Cloud Gateway。基於這些原因，Gateway 當之 無愧成為了閘道器層的不二選擇。 訊息佇列和訊息驅動是老牌技術了，它並不是微服務特有的功能，我之所以在課程中加入 了訊息驅動這個內容，主要有兩個原因。一是我想讓你瞭解 Spring Cloud 開源的訊息驅 動元件“Stream”，它可以大幅降低應用系統和訊息元件之間的對接流程。二是訊息元件 在如今有非常豐富的使用場景，我希望將“訊息元件的應用場景”作為一個知識拓展點， 幫助你開闊眼界。 分散式事務是微服務環境下保證事務一致性的終極手段。在課程中我將主要介紹兩種比較 有代表性的 Seata 分散式事務解決方案，一種是沒有程式碼侵入的 Seata AT 方案，另一種 是螞蟻金服貢獻的資源鎖定 + 補償型的 Seata TCC 方案。 

總結

在整個專案中，我們先通過 Spring Boot 快速落地了優惠券平臺的三個業務模組，然後， 在 Spring Cloud 實戰階段，我們分為三個階段對 Spring Boot 專案進行微服務化改造： 第一個階段使用 Nacos、Loadbalancer 和 OpenFeign 實現了跨服務的呼叫； 第二階段使用 Sentinel、Nacos Config 和 Sleuth 實現了服務容錯、配置管理和分散式 鏈路追蹤； 第三階段使用 Gateway、Stream 和 Seata 實現了微服務閘道器、訊息事件驅動和分散式 事務。