一文帶你瞭解微服務架構和設計（多圖）

最近幾年微服務很火，大家都在建設微服務，如果不懂點微服務相關的技術，都不好意思跟同行打招呼了，也見過身邊很多人在微服務踩過很多坑，我從 16 年開始接觸微服務，有多家大型企業的微服務分散式系統的架構經驗，所以就打算跟大家做一期關於微服務的分享，不過微服務和涉及的分散式計算非常的複雜，絕非是一篇文章就可以講清楚的，本文只是從最簡單的概念的基本使用帶你入門，如果後續還有興趣的話，可以查閱相關的文獻和技術書籍去深入學習

本文的微服務分享以下三部分，總體大綱如下：

• 微服務的概念和原則（理論）
• Spring Cloud 如何低成本的實現微服務（實現）
• Spring Cloud 大型專案的架構方案（真實案例）

微服務的概念和原則

什麼是微服務？

簡單舉例：看軍事新聞的同學應該都知道，一艘航空母艦作戰能力雖然很強，但是弱點太明顯，就是防禦能力太差，單艘的航空母艦很少單獨行動，通常航空母艦戰鬥群才是主要軍事力量，你可以把單艘航母理解為的單體應用（防禦差，機動性不好），把航母戰鬥群（排程複雜，維護費用高）理解為微服務。

簡單講特徵就是：

• 單體應用：簡單，脆弱（某個模組出問題，整個系統不可用），戰鬥力弱，維護成本低
• 微服務架構：複雜，健壯（某個模組出問題，不會影響系統整體的可用性），戰鬥力強，維護成本高

單體作戰的應用（圖）

微服務戰鬥群（圖）

大部分的開發者經歷和開發過單體應用，無論是傳統的 SSM，還是現在的 SpringBoot/Rails，它們都是單體應用，那麼長期陪伴我們的單體應用有什麼弊端？我們是面臨了什麼問題，導致我們要拋棄單體應用轉向微服務架構？個人總結主要問題如下：

• 部署成本高（無論是修改1行程式碼，還是10行程式碼，都要全量部署替換）
• 改動影響大，風險高，測試成本高（不論程式碼改動多小，成本都相同）
• 因為成本高，風險高，所以導致部署頻率低（無法滿足快速交付客戶需求）

當然還有例如無法滿足快速擴容，彈性伸縮，無法適應雲環境特性等問題

但我們不一一詳談了，以上的問題，都是微服務架構要解決的問題，至於具體是怎麼解決的，我們先放到後面再聊

歷代應用程式的架構變遷（圖）

解決什麼問題，又引入了什麼問題？

我們先看看微服務能帶給我們什麼？微服務架構的特點：

• 針對特定服務釋出，影響小，風險小，成本低
• 頻繁釋出版本，快速交付需求
• 低成本擴容，彈性伸縮，適應雲環境

我們知道一個樸素的理念，沒有任何事物是完美的，任何東西都有兩面性，有得必有失

那麼在選擇微服務在解決了快速響應和彈性伸縮的問題同時，它又給我們帶來了什麼問題？個人總結如下：

• 分散式系統的複雜性
• 部署，測試和監控的成本問題
• 分散式事務和 CAP 的相關問題

系統應用由原來的單體變成幾十到幾百個不同的工程，會所產生例如包括服務間的依賴，服務如何拆封，內部介面規範，資料傳遞等等問題，尤其是服務拆分，需要團隊熟悉業務流程，懂得取捨，要保證拆分的粒度服務既符合“高內聚，低耦合”的基本原則，還要兼顧業務的發展以及公司的願景，要還要說服團隊成員為之努力，並且積極投入，在多方中間取得平衡。

對於分散式系統，部署，測試和監控都需要大量的中介軟體來支撐，而且中介軟體本身也要維護，原先單體應用很簡單的事務問題 ，轉到分散式環境就變得很複雜，分散式事務是採用簡單的重試+補償機制，還是採用二階段提交協議等強一致性方法來解決，就要取決對業務場景的熟悉加上反覆的權衡了，相同問題還包括對 CAP 模型的權衡，總之微服務對團隊整體的技術棧水平整體要求更高

微服務有應該遵循哪些原則？

古人云：兵馬未動，糧草先行。建設微服務是需要建立長遠規劃，不是像寫 CMS 那樣建好資料庫表，然後就開始幹活，這樣十有八九是會失敗的。我們要進行微服務改造前，架構師要提前做好規劃，我們把這裡分為三步，前期階段，設計階段，技術階段

前期階段，大致要做好如下事情：

• 和多方充分溝通，確保能符合客戶和組織的需求，並且得到認同
• 和團隊溝通，讓隊友（開發/測試/運維）理解，並且積極投入
• 和業務部門溝通，指定版本計劃和上線時間

設計階段，參考 Sam Newman 的著作《微服務設計》，單微服務必須要滿足以下的條件，才符合微服務的基本要求：

• 標準的 REST 風格介面（基於 HTTP 和 JSON 格式）
• 獨立部署，避免共享資料庫（避免因為資料庫而影響整個分散式系統）
• 業務上的高內聚，減少依賴（從設計上要避免服務過大或者太小）

龐大的分散式系統，需要強大基礎設施來支撐，微服務涉及哪些基礎設施？

• CI/CD和自動化（分散式系統幾乎不可能通過人工手動釋出）
• 虛擬化技術（要保證微服務執行環境隔離，目前行業主流的是使用 Docker 容器）
• 日誌聚合，全鏈路監控（高度可觀察和分析診斷問題）

說了那麼多，那什麼樣的情況下，你的團隊不適合建設微服務？（請勿對號入座）

1. 開發團隊不具備自主性，所在組織對開發團隊限制非常多（具體請參考 康威定律）
2. 團隊不熟悉業務，無法識別出服務的邊界，進行合理的拆分（請參考 DDD 領域驅動設計）

微服務設計其實是很早就有的設計思想，因為隨著虛擬化技術的崛起，微服務可以低成本的實現，所以也開始流行和興起。

微服務的內涵很深，其中就包括，自動化，去中心化，獨立性等等，其中細節無法用一篇文章概述清楚，我們在做技術選型或者方案的時候，儘可能多去了解技術的本身和起源再結合我們業務的特點，進行更好的選擇。

如何低成本的實現微服務的 ？

Spring Cloud 為什麼是國內最流行的微服務框架，它提供哪些開箱即用的元件 ？概覽如下：

• Srping Boot 服務應用
• Spring Cloud Config 配置中心
• Spring Cloud Eureka 服務發現
• Spring Cloud Hystrix 熔斷保護
• Spring Cloud Zuul 服務閘道器
• Spring Cloud OAuth 2 服務保護
• Spring Cloud Stream 訊息驅動
• 分散式全鏈路跟蹤
• 部署微服務

建議參考資料：微服務架構整合，雲端計算最佳實踐

Spring Boot 微服務基石

SpringBoot是構建微服務的理想框架，主要得益於 SpringBoot 可以打包成為單個可執行JAR檔案交付服務，Spring Actuator 公開服務健康資訊都是微服務的基石，為甚麼這麼說 ？

我們先看看構建微服務的 4 個重要原則

• 服務應該是獨立和可獨立部署的
• 應該從中央（配置中心）讀取配置
• 對客戶端是透明的
• 傳達健康資訊

微服務有優點和缺點，並非所有應用都適合用微服務架構，架構師需要能做到以下要求：

• 分解業務問題：描述業務問題，注意動詞，尋找資料內聚
• 建立服務粒度：講大服務重構到更小的服務，重點關注服務如何相互互動，服務職責隨時間改變
• 定義服務介面：擁抱REST的理念，使用URI來傳達意圖，使用HTTP狀態碼傳達結果

糟糕的微服務有哪些特徵？

• 過於粗粒度：服務承擔過多的職責，服務跨大量表來管理資料，測試用例太多
• 過於細粒度：服務彼此依賴嚴重，服務內部沒有邏輯

何時不應該使用微服務 ？

• 不願投入（需要高度成熟的運維，伸縮，複雜性問題）
• 管理 / 監控散亂的伺服器也需要很高的成本
• 小型應用不適合，太昂貴
• 資料事務（分散式系統處理事務非常困難）

Spring Cloud Config 配置服務

Spring Config 是 Spring 提供的配置中心輕量級實現，基於 Git 儲存，

國內使用者大多推薦使用 Alibaba 開源的 Nacos （整合配置中心和註冊中心）都是非常不錯的配置中心的實現

微服務程式對於配置中心的幾點管理原則：

• 應用程式的配置和部署的實際程式碼分離（配置中心和應用程式分離）
• 集中（將配置中心集中在少量的儲存庫中）
• 穩定（配置中心要保證高可用）

Spring Config 這款配置中心提供的核心功能：

• 配置伺服器允許使用環境特定值
• 使用Spring Profile區分環境值
• 可以使用基於檔案或基於Git儲存屬性
• 允許對稱加密和非對稱加密

Spring Cloud Eureka 服務發現

服務發現是微服務架構中非常重要的概念，也稱註冊中心，類似我們生活中的房地產中介的角色，買房賣房都要通過它，所以是所有微服務上線/下線的必經之路，也掌握微服務的生殺大權，註冊中心會根據 CAP 策略和對微服務的健康檢查，作出對具體服務剔除，下線，恢復上線等操作，主要還有以下幾個核心功能：

• 快速對環境中服務數量水平伸縮（功能和 k8s 有些重合，不過也可以設定具體服務的執行時數量）
• 抽象服務的物理位置（微服務通常執行在 Docker 容器內，沒有固定 IP，只能通過註冊中心才能找到它）
• 提高程式的彈性，自動伸縮
• 資訊共享， 健康檢測

微服務架構裡面要實現註冊中心，需要達到哪些基本要求？

• 高可用，註冊資訊共享（註冊中心叢集部署），不可能因為註冊中心掛了，導致所有叢集不可用
• 負載均衡（對服務間的動態請求負載均衡），合理在服務間分配流量
• 有彈性（客戶端快取服務資訊）
• 容錯，健康檢查（檢測壞掉的服務自動移除，無需人工干預）

Spring Eureka 提供的服務發現實現，具備哪些特點 ？

• 服務發現抽象服務的物理位置
• 無感知新增和移除服務
• 為服務間呼叫提供負載均衡
• 使用 3種不同機制來呼叫服務：DiscoveryClient，支援Ribbon的RestTemplate，Netflix的FeignClient

Spring Cloud Hystrix 熔斷保護

熔斷的概念非常好理解，比如當我們家裡的消耗電量負載太高，到達設定的閾值的時候，電路系統就會啟動熔斷機制，也叫過載保護，通過跳閘，強行斷電的方式，來保護整體電路的穩定，熔斷在微服務中的概念也是一樣，是保護是微服務穩定的防火牆，避免單個服務潰崩或者異常導致出現整個叢集系統的雪崩和連鎖反應現場

為什麼微服務進行熔斷 ？當一個服務出現問題：

• 通常都是從小部分開始，到耗盡執行緒徹底崩潰
• 服務間呼叫會長時間阻塞
• 服務未關閉就會一直被呼叫，導致連鎖效應
• 一個效能不佳的服務可以迅速拖垮整個應用

為什麼熔斷很重要 ？

• 每個節點（呼叫服務和資料庫）實現斷路器，可以避免服務崩潰的連鎖效應
• 實現只有出問題的服務受影響，其餘的服務功能都是完整的（影響範圍降到最小）
• 熔斷是伺服器的靈活的基礎

斷路器提供的關鍵能力

• 快速失敗
• 功能降級（替代方案）
• 無縫恢復（斷路器定期檢查，自動恢復服務）

Netflix 研發和出品的 Hystrix 實現是一款成熟穩定的熔斷實現，在 Netflix 在生產實踐和執行多年，非常可靠，後面加入 Spring Cloud 體系，成為 Spring Cloud 微服務生態鏈的一員，使用起來也非常的簡單和方便

Hystrix 支援 4 種斷路模式：

• 客戶端負載均衡模式（檢測服務出錯，移除服務）
• 斷路器模式（出現超時丟擲異常強行失敗，超過閾值強行失敗所有呼叫）
• 後備模式（不是丟擲異常而是執行替代方案，例如排隊，稍後再試等）
• 艙壁模式（把遠端呼叫的資源分配到獨立的執行緒池中，呼叫出問題只是執行緒池飽和並停止請求）

跳閘會導致的3種結果：

• 服務B立即知道服務C有問題，不必等待，立即失敗
• 服務B執行服務C的替代程式碼來採取行動（後備模式）
• 服務C可以再跳閘後，檢查問題，快速恢復

熔斷的幾個處理原則：

• 設計分散式應用必須考慮彈性
• 服務的徹底故障是很容易檢測和處理，只是需要時間，斷路器給了這個時間視窗
• 一個服務效能不佳，可能導致叢集崩潰，因為相互呼叫會阻塞執行緒，耗盡資源
• Hystrix支援兩種隔離模型，即 THREAD 和 SEMAPHORE

Spring Cloud Zuul 閘道器

閘道器是整個微服務分散式叢集的入口，對於使用者來說，使用者無需知道你每個服務的地址，只需要記住閘道器地址就可以了，這樣理解可能比較抽象，舉一個生活的例子，微服務叢集是一個大型公司，公司內部有很多個不同的職能部門（對應每個微服務），但是你如果要訪問具體的職能部門，你必須先到前臺登記，再由前臺帶你到你想訪問的具體職能部門去辦理實際的業務（智慧路由）

微服務對於閘道器實現的規範：

• 一個獨立負責所有服務呼叫過濾和路由的服務
• 服務和客戶端的中間人，簡化客戶端開發

閘道器通常要做哪些事情：

• 靜態路由，從註冊中心獲取每個微服務的具體位置
• 動態路由（根據引數特點，呼叫特定服務，少量使用者體驗新功能，通常用於灰度釋出）
• 驗證和授權：驗證訪客的身份資訊（統一驗證，服務只需要關注業務邏輯）
• 資料收集和日誌（收集呼叫次數和響應時間等）

Zuul 閘道器的具體執行參考圖：

Spring Cloud Zuul 是初期版本的 API 閘道器實現，提供以下功能：

• 結合 Spring Cloud Eureka 將服務發現的註冊地址加入到 Zuul 路由
• Zuul 可以給所有服務輕鬆的新增 /api 之類的字首路由地址
• 在全域性上定製 Zuul 的 Spring Cloud Hystrix 和 Spring Cloud Ribbon （排程策略）的超時
• 實現動態路由，不同版本進行A/B測試
• 檢查引數合法性等，例如 JWT，時間戳等等

Spring Cloud OAuth 2 服務保護

Oauth 2 是用於保證請求的合法和正確性，為了讓微服務本身更加專注於業務，所以 OAuth 2 類似配置中心被單獨抽離出來作為基礎元件的統一認證中心來使用，OAuth 2 的作用類似我們生活中的公安局的角色，當我們需要去正規機構辦理業務的時候，我們需要提供有效的身份證（合法的身份認證標示），如果沒有你就需要去公安局（OAuth）申請一張在有效期內的身份證（Token），然後帶著這張身份證我們才能去購買機票，酒店等其他社會服務（微服務），社會服務機構在拿到你提供的身份證（Token）後，也會向公安局（OAuth）聯網傳送資訊，來驗證你的身份證的合法性（Token 合法性校驗），身份認證不通過就會被拒絕服務，合法的身份才能進行業務的辦理，關於 OAuth 的工作流程，可以結合下圖來理解：

微服務對於 OAuth2 規範的4中型別授權：密碼/客戶端憑據/授權碼/隱式

Spring Cloud OAuth 2 為我們提供哪些便利？

• 安全框架，提供令牌生成，驗證等邏輯
• 開箱即用，和其他服務無縫整合
• 行業標準，輕鬆與雲服務商整合

OAuth 2：/auth/oauth/token的返回資訊

• access_token（OAuth2令牌，每次呼叫出示）
• token_type（令牌型別，常用bearer token）
• refresh_token（續約令牌）
• expires_in（過期描述，預設12H）
• scope（令牌有效作用域）

OAuth 2 支援 JWT （JSON Web Token）的規範，關於 JWT 的原理就不特別解釋了，簡單的 JWT 有以下幾個特點

• 小巧（Base64編碼）
• 密碼簽名（防篡改）
• 自包含（不需要呼叫驗證服務確認內容，通過相同的金鑰進行對稱解密）
• 可擴充套件（可在令牌內包含額外的資訊）

OAuth 2 的簡單總結：

• OAuth2 是一個令牌驗證框架
• 使用OAuth2 需要建立OAuth2驗證服務
• 呼叫受保護的資源都要通過OAuth2驗證

Spring Cloud Stream 訊息驅動

我們和世界的互動不是同步的，很多時候是基於訊息非同步驅動模型，比如郵件，點餐，訂票等等，想要了解 Spring Cloud Stream，必須先要理解基於事件（MQ）程式設計的模型，基於訊息驅動有利於開發構建高度解耦的系統，因為 Spring Cloud Stream 並不是自己實現了訊息中介軟體，而是對於市場上主流（例如 RabbitMQ，KafKa）的 MQ 產品做了一層封裝和抽象，Spring Cloud Stream 做的事情並不是什麼新鮮的事情，非常類似 ORM 所做的事情，瞭解 ORM 框架的同學應該都熟悉對於多種資料庫（MySQL，Oracle，SQL Server）產品的抽象是何等重要，面向 ORM 進行資料庫訪問，可以讓你脫離對於指定資料庫產品的深度依賴和繫結，而且可以不用特意去學習不同資料庫的本地化特性和方言，降低學習成本，假如你想從 Oracle 遷移到 MySQL 上面，幾乎是不需要改動一行程式碼，只需要改動 ORM 的配置就可以實現了，參考下圖簡單瞭解一下 ORM：

Spring Cloud Stream 類似 ORM，你只需要基於 Spring Cloud Stream 提供的訊息模型進行程式設計，至於底層的訊息元件是用的 RabbitMQ 還是 kafka 還是其他的訊息中介軟體產品，都沒有關係，甚至更換底層訊息元件也不會對你的應用產生任何影響，這就是標準化所帶來的收益，關於如何更好的理解 Spring Cloud Stream 工作模型可以簡單參考下圖：

微服務中使用的的兩種服務通訊方式對比：

1. 同步：通過REST端點介面進行請求：服務之間緊耦合（強依賴），服務之間的脆弱性（連鎖效應），增加新的消費者不靈活

2. 非同步：基於訊息中介軟體通訊：鬆耦合（無介面直接呼叫的依賴），耐久性（服務重啟後可以消費歷史訊息），可伸縮性（訊息過多可啟動多服務來處理訊息），靈活性（輕鬆新增新的消費者）

訊息傳遞架構的缺點：

1. 訊息處理語義：訊息順序處理，訊息異常處理
2. 訊息可見性：訊息不會立刻被處理，事務關聯ID在訊息中的傳遞

訊息中放置什麼資料 ？

1. 訊息體要儘可能的小，減少傳輸成本：通常只返回action型別和id，然後用id獲取最新資料
2. 只使用訊息傳遞狀態：在訊息中包含版本號和時間戳，處理資料服務可以檢查資料的版本號

Spring Cloud Stream 的訊息模型和概念：

• 發射器（Source）：接收物件（物件表示要釋出的訊息），序列化物件，將訊息釋出到通道
• 通道（Channel）：佇列的抽象，通道寫在配置檔案，更改配置切換通道（讀取和寫入佇列）
• 繫結器（Binder）：與訊息平臺對話的 Spring 程式碼，不必依賴特定的API來發布和消費訊息
• 接收器（Sink）：從佇列接收訊息，將訊息反序列化為POJO

Spring Cloud Stream 的簡單總結：

• 使用訊息傳遞的非同步通訊是微服務架構的關鍵部分
• 使用訊息傳遞可以使服務能夠伸縮並且更具有容錯性
• Spring Cloud Stream 通過簡單的註解抽象底層的訊息平臺細節

Sleuth 和 Zipkin 分散式跟蹤

微服務分散式架構帶來了複雜度，成本最高的就是跟蹤檢查和運維，分散式意味要在多個服務，機器跟蹤一個事務，Sleuth 和 Zipkin 都是用於 Spring Cloud 服務體系的分散式跟蹤技術，先直接看下最終效果，下圖一個簡單的視覺化鏈路跟蹤呼叫，ZipKin 可以清晰的看到一個客戶端請求在每個服務上面處理所消耗的事情，點選進去可以看到具體的事務執行內容，方便排查錯誤

Spring Cloud Sleuth 的工作流程：

1. 透明地建立並注入一個關聯ID到服務呼叫中
2. 管理關聯ID到出站服務呼叫的傳播
3. 將關聯資訊新增到Spring的MDC日誌記錄（應用/跟蹤ID/跨度ID/資料傳送）
4. 將服務呼叫中的跟蹤資訊釋出到Zipkin跟蹤平臺

Open Zipkin 的簡單概述：

1. 呼叫鏈使用一張乾淨簡潔的圖片，比一百萬條日誌要好看的多
2. 分散式跟蹤平臺，用於跟蹤多個服務呼叫的事務
3. 圖形的方式檢視事務佔用的時間量，分解每個服務所用的時間
4. 4種不同的資料儲存：記憶體資料/MySQL/Cassandra/Elasticsearch

關於微服務全鏈路跟蹤的總結：

• SpringCloudSleuth 可以無縫將關聯ID新增到微服務中
• 可以使用關聯ID檢視事務涉及的所有服務行為
• 關聯ID需要與日誌聚合結合使用
• 日誌平臺很重要，但是視覺化跟蹤事務也是有價值的工具

部署微服務

構建和部署管道是微服務架構重最要的部分，微服務的主要特點是快速構建，修改，釋出

符合微服務特徵的部署要達到以下幾個要求：

1. 自動的（自動構建和部署程式碼
2. 完整的（軟體成品是映象），不可變（釋出過程不可人為干預）
3. 良好的微服務部署管道應該允許在幾分鐘部署新功能和修復bug

Spring Cloud 大型專案的架構方案

真實案例講解

這是一個真實用於國內某大型企業的微服務架構體系，支撐日均百萬訂單的專案，因為已經過了2年的保密期，所以可以拿出來分享

剛好可以結合前面凌亂的知識點，看看 Spring Cloud 這套元件是如何搭建起來的，整套微服務就是下面這張架構圖：

具體每個元件的作用就不在這裡詳細說明了，在這套架構方案裡面

我們沒有完全照搬 Spring Cloud 全家桶的組建，還是根據自己的需求對其中元件進行的更換例如：

• 配置中心從 Spring Cloud Config 更換為 Apollo ，除了有更好的效能，還有更加簡化的操作頁面，修改配置檔案毫秒級響應
• 服務發現 Eureka 官網已經停止維護，我們後面更換為 Alibaba Nacos，服務註冊和心跳檢測都提升到毫秒級，Eureka 是90秒輪詢
• 分散式任務排程引入了 XXL-JOB，這是國內主流的分散式任務排程平臺，沒有特別需要說明的地方
• 日誌聚合也是用了主流的 ELK 技術方案，用於收集和檢索日誌

PS：另外在值得補充的是，在寫這篇文章的時候 Spring Cloud Zuul 已經不被官方推薦使用了，替代品是效能更好的 Spring Cloud Gateway ，大家可以在瞭解的時候需要注意一下

最後總結：

微服務是未來大型企業的必經之路，雖然成本很高，但是可以提升 IT 系統的健壯性和提升技術人員的廣度和深度都還是很有幫助的