最近幾年微服務很火，大家都在建設微服務，如果不懂點微服務相關的技術，都不好意思跟同行打招呼了。

[[342308]]

圖片來自 Pexels

 

我也見過身邊很多人在微服務踩過很多坑，我從 2016 年開始接觸微服務，有多家大型企業的微服務分布式系統的架構經驗，不過微服務和涉及的分布式計算非常的復雜，絕非是一篇文章就可以講清楚的。

本文只是從最簡單的概念的基本使用帶你入門，如果后續還有興趣的話，可以查閱相關的文獻和技術書籍去深入學習。

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

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

微服務的概念和原則

什么是微服務?

簡單舉例：看軍事新聞的同學應該都知道，一艘航空母艦作戰能力雖然很強，但是弱點太明顯，就是防御能力太差，單艘的航空母艦很少單獨行動，通常航空母艦戰斗群才是主要軍事力量。

你可以把單艘航母理解為的單體應用(防御差，機動性不好)，把航母戰斗群(調度復雜，維護費用高)理解為微服務。

簡單講特征就是：

• 單體應用：簡單，脆弱(某個模塊出問題，整個系統不可用)，戰斗力弱，維護成本低。
• 微服務架構：復雜，健壯(某個模塊出問題，不會影響系統整體的可用性)，戰斗力強，維護成本高。

[[342309]]

 

單體作戰的應用(圖)

[[342310]]

 

微服務戰斗群(圖)

大部分的開發者經歷和開發過單體應用，無論是傳統的 SSM，還是現在的 Spring Boot/Rails，它們都是單體應用。

那么長期陪伴我們的單體應用有什么弊端?我們是面臨了什么問題，導致我們要拋棄單體應用轉向微服務架構?

個人總結主要問題如下：

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

當然還有例如無法滿足快速擴容，彈性伸縮，無法適應云環境特性等問題，但我們不一一詳談了，以上的問題，都是微服務架構要解決的問題，至于具體是怎么解決的，我們先放到后面再聊。

歷代應用程序的架構變遷(圖)

 

解決什么問題，又引入了什么問題?

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

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

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

那么在選擇微服務在解決了快速響應和彈性伸縮的問題同時，它又給我們帶來了什么問題?

個人總結如下：

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

系統應用由原來的單體變成幾十到幾百個不同的工程，會所產生例如包括服務間的依賴，服務如何拆封，內部接口規范，數據傳遞等等問題。

尤其是服務拆分，需要團隊熟悉業務流程，懂得取舍，要保證拆分的粒度服務既符合“高內聚，低耦合”的基本原則，還要兼顧業務的發展以及公司的愿景，要還要說服團隊成員為之努力，并且積極投入，在多方中間取得平衡。

對于分布式系統，部署，測試和監控都需要大量的中間件來支撐，而且中間件本身也要維護。

原先單體應用很簡單的事務問題 ，轉到分布式環境就變得很復雜，分布式事務是采用簡單的重試+補償機制，還是采用二階段提交協議等強一致性方法來解決，就要取決對業務場景的熟悉加上反復的權衡了。

相同問題還包括對 CAP 模型的權衡，總之微服務對團隊整體的技術棧水平整體要求更高。

[[342311]]

 

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

古人云：兵馬未動，糧草先行。建設微服務是需要建立長遠規劃，不是像寫 CMS 那樣建好數據庫表，然后就開始干活，這樣十有八九是會失敗的。

我們要進行微服務改造前，架構師要提前做好規劃，我們把這里分為三步，前期階段，設計階段，技術階段。

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

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

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

• 標準的 REST 風格接口(基于 HTTP 和 JSON 格式)。
• 獨立部署，避免共享數據庫(避免因為數據庫而影響整個分布式系統)。
• 業務上的高內聚，減少依賴(從設計上要避免服務過大或者太小)。

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

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

說了那么多，那什么樣的情況下，你的團隊不適合建設微服務?(請勿對號入座)

• 開發團隊不具備自主性，所在組織對開發團隊限制非常多(具體請參考 康威定律)。
• 團隊不熟悉業務，無法識別出服務的邊界，進行合理的拆分(請參考 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 微服務基石

 

Spring Boot 是構建微服務的理想框架，主要得益于 Spring Boot 可以打包成為單個可執行JAR文件交付服務，Spring Actuator 公開服務健康信息都是微服務的基石，為什么這么說 ?

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

• 服務應該是獨立和可獨立部署的
• 應該從中央(配置中心)讀取配置
• 對客戶端是透明的
• 傳達健康信息

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

• 分解業務問題：描述業務問題，注意動詞，尋找數據內聚。
• 建立服務粒度：講大服務重構到更小的服務，重點關注服務如何相互交互，服務職責隨時間改變。
• 定義服務接口：擁抱 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 支持四種斷路模式：

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

跳閘會導致的三種結果：

• 服務 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(OAuth 2 令牌，每次調用出示)。
• token_type(令牌類型，常用 bearer token)。
• refresh_token(續約令牌)。
• expires_in(過期描述，默認 12H)。
• scope(令牌有效作用域)。

OAuth 2 支持 JWT (JSON Web Token)的規范，關于 JWT 的原理就不特別解釋了。

簡單的 JWT 有以下幾個特點：

• 小巧(Base64編碼)。
• 密碼簽名(防篡改)。
• 自包含(不需要調用驗證服務確認內容，通過相同的密鑰進行對稱解密)。
• 可擴展(可在令牌內包含額外的信息)。

OAuth 2 的簡單總結：

• OAuth 2 是一個令牌驗證框架。
• 使用 OAuth 2 需要建立 OAuth 2 驗證服務。
• 調用受保護的資源都要通過 OAuth 2 驗證。

⑦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 工作模型可以簡單參考下圖：

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

 

• 同步：通過 REST 端點接口進行請求：服務之間緊耦合(強依賴)，服務之間的脆弱性(連鎖效應)，增加新的消費者不靈活。
• 異步：基于消息中間件通信：松耦合(無接口直接調用的依賴)，耐久性(服務重啟后可以消費歷史消息)，可伸縮性(消息過多可啟動多服務來處理消息)，靈活性(輕松添加新的消費者)。

消息傳遞架構的缺點：

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

消息中放置什么數據 ?

• 消息體要盡可能的小，減少傳輸成本：通常只返回 action 類型和 id，然后用id獲取最新數據。
• 只使用消息傳遞狀態：在消息中包含版本號和時間戳，處理數據服務可以檢查數據的版本號。

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 的工作流程：

• 透明地創建并注入一個關聯 ID 到服務調用中。
• 管理關聯 ID 到出站服務調用的傳播。
• 將關聯信息添加到 Spring 的 MDC 日志記錄(應用/跟蹤 ID/跨度 ID/數據發送)。
• 將服務調用中的跟蹤信息發布到 Zipkin 跟蹤平臺。

Open Zipkin 的簡單概述：

• 調用鏈使用一張干凈簡潔的圖片，比一百萬條日志要好看的多。
• 分布式跟蹤平臺，用于跟蹤多個服務調用的事務。
• 圖形的方式查看事務占用的時間量，分解每個服務所用的時間。
• 4 種不同的數據存儲：內存數據/MySQL/Cassandra/Elasticsearch。

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

• Spring Cloud Sleuth 可以無縫將關聯 ID 添加到微服務中。
• 可以使用關聯 ID 查看事務涉及的所有服務行為。
• 關聯 ID 需要與日志聚合結合使用。
• 日志平臺很重要，但是可視化跟蹤事務也是有價值的工具。

⑨部署微服務

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

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

• 自動的(自動構建和部署代碼。
• 完整的(軟件成品是鏡像)，不可變(發布過程不可人為干預)。
• 良好的微服務部署管道應該允許在幾分鐘部署新功能和修復 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 系統的健壯性和提升技術人員的廣度和深度都還是很有幫助的。

作者：肖斌

編輯：陶家龍

出處：轉載自公眾號小二十七(ID：drak-phoenix)