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

時間 2020-09-14

原文原文鏈接

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

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

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

微服務的概念和原則

什麼是微服務？

簡單舉例：看軍事新聞的同窗應該都知道，一艘航空母艦做戰能力雖然很強，可是弱點太明顯，就是防護能力太差，單艘的航空母艦不多單獨行動，一般航空母艦戰鬥羣纔是主要軍事力量，你能夠把單艘航母理解爲的單體應用（防護差，機動性很差），把航母戰鬥羣（調度複雜，維護費用高）理解爲微服務。spring

簡單講特徵就是：數據庫

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

單體做戰的應用（圖）編程

微服務戰鬥羣（圖）api

大部分的開發者經歷和開發過單體應用，不管是傳統的 SSM，仍是如今的 SpringBoot/Rails，它們都是單體應用，那麼長期陪伴咱們的單體應用有什麼弊端？咱們是面臨了什麼問題，致使咱們要拋棄單體應用轉向微服務架構？我的總結主要問題以下：緩存

部署成本高（不管是修改1行代碼，仍是10行代碼，都要全量部署替換）
改動影響大，風險高，測試成本高（不論代碼改動多小，成本都相同）
由於成本高，風險高，因此致使部署頻率低（沒法知足快速交付客戶需求）

固然還有例如沒法知足快速擴容，彈性伸縮，沒法適應雲環境特性等問題安全

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

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

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

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

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

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

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

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

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

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

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

古人云：兵馬未動，糧草先行。建設微服務是須要創建長遠規劃，不是像寫 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 微服務基石

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 工做模型能夠簡單參考下圖：

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

同步：經過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 的工做流程：