【Java勸退師】Spring Cloud 知識腦圖 - 微服務規範

Spring Cloud

Spring Cloud

○ 是一套規範,而非框架web

○ 規範應該要有哪些功能組件,各組件間如何配合,共同完成什麼事情算法

微服務規範spring

1、核心目標

  • 簡化分佈式系統【基礎設施】的開發 - 將經得起考驗的服務框架組合起來,透過 Spring Boot 風格封裝,屏蔽底層 複雜配置 與原理

2、概念

  • 服務註冊 : 服務提供者 將 IP、端口、訪問協議 登記到 註冊中心數據庫

  • 服務發現 : 服務消費者 從 註冊中心 獲取到較爲實時的服務列表,根據訪問策略進行訪問編程

  • 負載均衡 : 將請求壓力分散到多個服務器,以提升服務的性能、可靠性緩存

  • 雪崩效應 : 服務的扇出鏈路上,某個服務響應時間過長或不可用,致使該服務佔用愈來愈多系統資源,進而引發系統崩潰服務器

    ○ 扇入 : 服務被調用的次數。扇入大,該服務複用性高,好事markdown

    ○ 扇出 : 服務調用其餘服務的個數。扇出大,該服務業務邏輯複雜,不必定是好事架構

  • 限流 : 限制請求服務提供者的數量 - 問題發生前app

  • 熔斷 : 上游服務爲了保護下游服務,暫時切斷對下游服務的調用 - 問題發生後

  • 降級 : 返回兜底數據(默認值) - 問題發生後

    熔斷、降級 一般一塊兒使用

  • 鏈路追蹤 : 對一次請求涉及到的多個服務鏈路進行 日誌紀錄、性能監控

3、應用架構演進

1. 單體 應用架構

  • 將全部功能模塊都放在一個工程中
  • 優勢
    • 開發快
    • 架構簡單
    • 易測試
    • 易佈署
  • 缺點
    • 對海量用戶處理能力有限
    • 程序複雜度越高,開發效率越低
    • 生產環境發生重大 BUG,或單一功能負載太重,將致使服務全數停擺
    • 代碼量增長,編譯、啓動 效率降低

2. 垂直 應用架構

  • 對應用模塊作垂直劃分 - 【劃分目標】業務之間儘可能互不影響

  • 優勢

    • 實現 流量分擔

    • 能夠針對不一樣功能模塊進行優化

    • 方便 水平擴展

      ○ 水平擴展 : 增長服務器數量,擴充系統性能

      ○ 垂直擴展 : 提高單機處理能力

    • 提升 容錯率

    • 提升 功能迭代效率

    • 不一樣服務可採用不一樣的編程語言

  • 缺點

    • 當服務 IP 或 端口 改變,調用方需手動更新
    • 服務間調用 方式、協議 不統一 - HttpClient、WebService
    • 服務監控不到位 - 服務狀態、調用成功率、調用失敗率、調用耗時

3. SOA 應用架構(微服務)

Service-Oriented Architecture 面向服務架構

  • 根據實際業務,將系統 水平、垂直 拆分紅各自 獨立佈署 的模塊,模塊間相互獨立

  • 優勢

    • 擁有 垂直應用架構 的優勢
    • 耦合度更低
    • 底層模塊可重用
    • 適合敏捷開發
  • 缺點

    • 對架構師能力要求高
    • 服務管理困難
    • 程序調試、鏈路追蹤困難

4、核心組件

image-20201206132153812

  • 註冊中心 - Eureka - Nacos

  • 客戶端負載均衡 - Ribbon - Spring Cloud Loadbalancer

  • 熔斷器 - Hystrix - Sentinel

  • 網關 - Zuul - Spring Cloud Gateway

  • 配置中心 - Spring Cloud Config - Nacos

  • 服務調用 - Feign - Dubbo RPC

  • 消息驅動 - Spring Cloud Stream

  • 鏈路追蹤 - Spring Cloud Sleuth/Zipkin

  • 分佈式事務 - Seata

5、Eureka 註冊中心

基於 AP 模式設計,使用二級緩存機制提升響應速度,可能致使服務發現緩慢問題,Eureka Server 30秒、Eureka Client 30 秒、Ribbon 30 秒

image-20201206134722065

1. 功能

  • 解偶服務 提供者 與 消費者
  • 動態管理 服務提供者 數量、狀態、地址

2. 角色

  • Eureka Server
    • 保存 服務提供者 數量、狀態、地址
    • 定時將失效服務進行剃除 - 【默認】60 秒
    • 必定時間內沒收到 Eureka Client 的心跳,則認爲該服務失效 - 【默認】90 秒
    • Eureka Server 之間透過複製方式完成 服務註冊列表 同步
    • 當 15 分鐘內,有超過 85% 的 Client 沒有正常發送心跳,則進入自我保護模式
  • Eureka Client
    • 服務啓動時,向 Eureka Server 註冊本身
    • 定時向 Eureka Server 發送心跳 - 【默認】30 秒
    • 定時向 Eureka Server 獲取 服務註冊列表 - 【默認】30 秒
    • 會緩存 服務提供者 信息,來保證即便 Eureka Server 皆當機,也能正常調用服務提供者
    • 當服務正常關閉時,會發送服務下線的 REST 請求給 Eureka Server

3. 元數據

  • 標準元數據
    • 發佈在服務註冊表中,用於服務間調用
    • 主機名
    • IP 地址
    • 端口號
  • 自定義元數據
    • 能夠在 Client 端中訪問
    • 符合 Key / Value 的存儲格式,使用 eureka.instance.metadata-map 定義

4. 自我保護模式

  • 不會剔除任何服務實例
  • 接受新服務的 註冊、查找 請求,但不會同步到其餘節點上
  • 使用 eureka.server.enable-self-preservation 設置
    • 【默認】開啓
    • 【建議】開啓

6、Ribbon 客戶端負載均衡

【原理】給 RestTemplate 添加攔截器,將服務名替換成 IP 地址

1. 概念

  • 服務端負載均衡

    • 請求到達負載均衡器,根據算法將請求路由到目標服務器
    • 負載均衡算法在 服務端 運行
    • Nginx、F5
  • 客戶端負載均衡

    • 客戶端擁有服務器地址列表,請求在客戶端根據負載均衡算法選擇一個服務器進行訪問,註冊中心僅負責

      提供服務端地址

    • 負載均衡算法在 客戶端 運行

    • Ribbon

2. 負載均衡策略

  • 【默認】RoundRobinRule 輪詢 - 默認超過 10 次獲取到的 Server 都不可用,將返回一個空 Server
  • RandomRule 隨機 - 若是隨機到的 Server 爲 null 或 不可用,則不斷循環選取
  • RetryRule 重試 - 時限內輪詢重試
  • BestAvailableRule 最小鏈接數 - 選取可用且鏈接數最小的
  • AvailabilityFilteringRule 可用過濾 - 輪詢 Server,並判斷是否超時、鏈接數是否超限
  • ZoneAvoidanceRule 區域權衡 - 輪詢 Server,並判斷是否超時、鏈接數是否超限、區域是否符合

7、Hystrix 熔斷器

1. 功能

  • 資源隔離 : 對每一個管理的資源都維護一個小型的線程池(艙壁模式),若是該資源對應的線程池已滿,則發往該資源的請求馬上被拒絕,而非排隊,以加速失敗斷定

  • 回退機制 : 當請求 失敗、超時、被拒絕、斷路器啓動 時,運行回退邏輯

    回退邏輯由開發人員定義,如 : 返回缺省值

  • 跳閘機制 : 當某服務的錯誤率超過閾值,則中止請求該服務一段時間,以後進入自我修復階段

    超時時間應大於 Ribbon 的超時時間,避免 Ribbon 還在重試,但 Hystrix 已超時

  • 自我修復 : 當斷路器啓動一段時間後,會自動進入半開狀態(少許測試服務是否正常)

  • 監控 : 近乎實時地監控運行指針與配置變化 - 成功、失敗、超時、拒絕

8、Feign 遠程調用組件

Fegin = RestTemplate (簡化HTTP請求發送) + Ribbon (客戶端負載均衡) + Hystrix (熔斷器)

  • 【默認】請求超時處理時長 1 秒
  • 只要達到 Feign 或 Hystrix 其中一個超時時長,將會進行熔斷
  • 能夠自定義降級處理類,返回默認值
  • 能夠設置超時時間,但若是 Ribbon 已配置則以 Ribbon 爲準,故建議設置 Ribbon、Hystrix 超時時間便可
  • 請求日誌
    • 【默認】NONE : 不顯示任何日誌,性能最佳
    • BASIC : 僅記錄 請求方法、URL、響應狀態碼、運行時間 - 生產問題追蹤
    • HEADERS : 在 BASIC 級別上,紀錄請求和響應的 Header
    • FULL : 在 HEADERS 級別上,紀錄 Body 和 元數據

9、GateWay 網關組件

○ 異步非阻塞,基於 Reactor 模型

○ 高可用 : 透過 Nginx 實現

image-20201207120510134

1. 功能

  • 反向代理

    • 路徑重寫
    • 動態路由 - 從註冊中心獲取服務列表並訪問
  • 過濾器

    • 鑑權

    • 流量控制

    • 日誌輸出

2. 角色

  • 路由 Route
    • 網關基礎的工做單元,將請求轉發到對應的服務上
    • 由 ID、斷言、過濾器 組成
    • 若是 斷言 爲 true 則匹配該路由
  • 斷言 Predicates
    • 是否符合路由的判斷條件
    • 匹配條件
      • 路徑
      • 時間
      • Cookie
      • Header
      • Host
      • Method
      • 請求參數
      • 遠程地址
  • 過濾器 Filter
    • 在 請求前 或 請求後 運行業務邏輯
    • 範圍
      • GateWayFilter : 應用到單個路由上
      • GlobalFilter : 應用到全部路由上 - 黑名單
    • 類型
      • Pre
        • 參數校驗
        • 權限校驗
        • 流量監控
        • 日誌輸出
        • 協議轉換
      • Post
        • 響應頭、響應內容 修改
        • 日誌輸出
        • 流量監控

10、Spring Cloud Config 配置中心

image-20201207133645647

1. 功能

  • 集中配置管理 - 讓配置一次更改,到處生效
  • 爲不一樣環境提供不一樣配置 - 開發、測試、生產
  • 運行期間動態調整配置 - 鏈接池大小

2. 概念

  • 【默認】使用 Git 存儲配置文檔內容

  • 配置文檔命名規則

    • {application}-{profile}.yml

    • {application}-{profile}.properties

      ○ application 爲應用名稱

      ○ profile 爲環境 - 開發、測試、生產

  • 刷新

    • 手動刷新
    • 自動刷新

11、Spring Cloud Stream 消息驅動組件

○ 屏蔽底層不一樣 MQ 間的差別,下降學習、開發、維護 成本

○ 支持 RabbitMQ、Kafka

1. 概念

  • 內置信道默認名稱爲 input、output,能夠透過自定義信道方式擴展
  • 消費分組 : 一個消息只能被組內的其中一個成員消費 - 能夠避免重複消費

2. 註解

  • @Output 生產者 : 輸出信道,消息將透過該信道 離開 應用進程
  • @Input 消費者 : 輸入信道,消息將透過該信道 進入 應用進程
  • @StreamListener 消費者監聽器 : 監聽消費者隊列的消息
  • @EnableBinding 綁定 : 將 Exchange 與 Channel 進行綁定

12、Spring Cloud Sleuth + Zipkin 鏈路追蹤

image-20201207175456628

image-20201207174022345

1. 功能

  • 瞭解各個服務之間的調用關係
  • 紀錄 鏈路、處理單元 時間,用於分析瓶頸節點
  • 進行故障發現

2. 概念

  • Trace : 請求 從抵達系統邊界 到 離開系統邊界 的過程 - 由多個 Span 組成
  • Trace ID : 整個請求鏈路的 ID
  • Span ID : 處理單元的 ID
  • Parent ID : 上游處理單元的 ID

十3、Spring Cloud OAuth2 + JWT 統一認證方案

image-20201207183510841

1. 認證方案

  • Session 共享
    • 缺點 - 基於 Cookie,移動端不能有效使用
  • Token
    • 優勢
      • 服務端不用存儲數據
      • 擴展性強
      • Web、App 皆可以使用
    • 缺點
      • 佔用帶寬
      • 驗籤操做增長 CPU 負擔

2. OAuth2

容許用戶受權第三方應用訪問他們存儲在另外的服務提供者上的信息

image-20201207181455145

角色

  • 資源擁有者 Resource Owner : 用戶本身
  • 客戶端 Client : 公司網站
  • 認證服務器 Authorization Server : Google 公司
  • 資源服務器 Resource Server : Google 公司

運行流程

  1. 客戶端 向 資源擁有者 請求受權 (彈出受權登陸頁面)
  2. 資源擁有者 確認受權 (輸入賬號密碼)
  3. 認證服務器 收到受權許可
  4. 認證服務器 向 客戶端 頒發 Access Token(訪問令牌)
  5. 客戶端攜帶 Access Token 訪問 資源服務器
  6. 資源服務器 向 認證服務器 驗證 Access Token 的有效性
  7. 資源服務器 返回 受保護資源 給 客戶端

受權模式

  • 受權碼 authorization-code - 用於 第三方登陸,使用起來最麻煩
  • 密碼 password
    • 提供 賬號、密碼 換取 令牌
    • 用於 單點登陸
  • 隱藏式 implicit
  • 客戶端憑證 client credentials

3. 類

認證服務器

  • 受權配置類
    • @EnableAuthorizationServer : 開啓認證服務器功能
    • extends AuthorizationServerConfigurerAdapter : 繼承受權配置類適配器
    • configure(AuthorizationServerSecurityConfigurer security) : 設置接口訪問權限
    • configure(ClientDetailsServiceConfigurer clients) : 設置客戶端相關信息
    • configure(AuthorizationServerEndpointsConfigurer endpoints) : 設置令牌相關信息
    • 令牌存儲方式
      • 【默認】InMemoryTokenStore : 存儲在內存中
      • JdbcTokenStore : 存儲在關係型數據庫
      • JwtTokenStore : 使用 JWT 令牌,服務端不存儲
  • 用戶配置類
    • extends WebSecurityConfigurerAdapter : 繼承用戶配置類適配器
    • configure(AuthenticationManagerBuilder auth) : 驗證用戶賬號密碼
    • PasswordEncoder : 用戶密碼統一加密方式

資源服務器

  • 配置類
    • @EnableWebSecurity : 開啓資源服務器功能
    • extends ResourceServerConfigurerAdapter : 繼承配置類適配器
    • configure(ResourceServerSecurityConfigurer resources) : 配置認證服務器信息
    • configure(HttpSecurity http) : 設置不一樣接口是否須要驗證

4. JWT

○ Json Web Token

○【核心目的】防止竄改

結構

中間使用 "." 分割

  • Header
    • 令牌類型
    • 加密算法
  • Payload
    • 將有效信息進行 Base64 編碼 - 不建議存放敏感信息
  • Signature
    • 將 Header、Payload 進行加密,做爲簽名

十4、Nacos 註冊中心 + 配置中心

可選擇使用 AP 模式 或 CP 模式

1. 功能

  • 服務發現、健康檢查
  • 動態配置管理 - @RefreshScope
  • 動態 DNS 管理
  • 服務、元數據 管理

2. 概念

  • 保護域值 : 健康實例數 / 總實例數

    當保護域值低於設置時,說明健康實例很少,將把全部的實例(健康 + 不健康) 都返回給消費者

  • 臨時實例 : 由客戶端發送心跳

  • 持久實例 : 由 Nacos 發送心跳,且不會下線,僅作健康檢測 - MySQL

  • 領域模型

    • Namespace 命名空間
      • 環境 : 開發、測試、生產
      • 不一樣命名空間不能互相訪問
    • Group 組
      • 項目
    • Service 服務 / DataId 配置文檔
  • 配置文檔格式

    • ${prefix}-${spring.profile.active}.${file-extension}
    • prefix : 默認爲 spring.application.name 的值
    • spring.profile.active : 爲當前對應環境的 profile
    • file-extension : 數據格式 - yaml、properties

十5、Sentinel 流量防衛兵

可利用 Nacos 持久化數據

1. 組成

  • 核心庫 : Java 客戶端,不依賴任何 框架/庫,對 Dubbo、Spring Cloud 有較好的支持
  • 控制檯 : 基於 Spring Boot 開發,能夠直接運行

2. 限流方式

  • 按照 資源名稱
  • 按照 URL

3. 閾值類型

  • QPS : 當調用該資源的 QPS 達到閾值時,進行限流

    QPS : 每秒鐘請求量

  • 線程數 : 當調用該資源的 線程數 達到閾值時,進行限流 - 適用業務運行時間長的狀況

4. 流控模式

  • 直接 : 當資源達到限流條件,直接限流
  • 關聯 : 當關聯資源調用達到閾值時,限流本身,兩資源間無調用關係
  • 鏈路 : 只針對特定的上游鏈路流量,限流本身,兩資源間有調用關係

5. 流控效果

  • 快速失敗
    • 直接失敗,拋出異常
    • 用於 通常場景
  • Warm Up
    • 從 閾值 / 冷加載因子(默認 3),通過預熱時長,才達到設置的 QPS
    • 用於 秒殺場景
  • 排隊等待
    • 讓請求勻速經過,閾值必須設置爲 QPS - QPS 爲 5,200 ms 放行一個請求
    • 用於 削峯填谷

6. 降級規則

只有當 QPS >= 5,纔會觸發降級規則,時間窗口內拒絕請求,時間窗口後直接恢復

  • RT 平均響應時間 - 上限 4900 ms
  • 異常比例
  • 異常數 - 以分鐘級別統計
相關文章
相關標籤/搜索