○ 是一套規範,而非框架web
○ 規範應該要有哪些功能組件,各組件間如何配合,共同完成什麼事情算法
微服務規範spring
服務註冊 : 服務提供者 將 IP、端口、訪問協議 登記到 註冊中心數據庫
服務發現 : 服務消費者 從 註冊中心 獲取到較爲實時的服務列表,根據訪問策略進行訪問編程
負載均衡 : 將請求壓力分散到多個服務器,以提升服務的性能、可靠性緩存
雪崩效應 : 服務的扇出鏈路上,某個服務響應時間過長或不可用,致使該服務佔用愈來愈多系統資源,進而引發系統崩潰服務器
○ 扇入 : 服務被調用的次數。扇入大,該服務複用性高,好事markdown
○ 扇出 : 服務調用其餘服務的個數。扇出大,該服務業務邏輯複雜,不必定是好事架構
限流 : 限制請求服務提供者的數量 - 問題發生前app
熔斷 : 上游服務爲了保護下游服務,暫時切斷對下游服務的調用 - 問題發生後
降級 : 返回兜底數據(默認值) - 問題發生後
熔斷、降級 一般一塊兒使用
鏈路追蹤 : 對一次請求涉及到的多個服務鏈路進行 日誌紀錄、性能監控
對應用模塊作垂直劃分 - 【劃分目標】業務之間儘可能互不影響
優勢
實現 流量分擔
能夠針對不一樣功能模塊進行優化
方便 水平擴展
○ 水平擴展 : 增長服務器數量,擴充系統性能
○ 垂直擴展 : 提高單機處理能力
提升 容錯率
提升 功能迭代效率
不一樣服務可採用不一樣的編程語言
缺點
Service-Oriented Architecture 面向服務架構
根據實際業務,將系統 水平、垂直 拆分紅各自 獨立佈署 的模塊,模塊間相互獨立
優勢
缺點
註冊中心 - 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
基於 AP 模式設計,使用二級緩存機制提升響應速度,可能致使服務發現緩慢問題,Eureka Server 30秒、Eureka Client 30 秒、Ribbon 30 秒
【原理】給 RestTemplate 添加攔截器,將服務名替換成 IP 地址
服務端負載均衡
客戶端負載均衡
客戶端擁有服務器地址列表,請求在客戶端根據負載均衡算法選擇一個服務器進行訪問,註冊中心僅負責
提供服務端地址
負載均衡算法在 客戶端 運行
Ribbon
資源隔離 : 對每一個管理的資源都維護一個小型的線程池(艙壁模式),若是該資源對應的線程池已滿,則發往該資源的請求馬上被拒絕,而非排隊,以加速失敗斷定
回退機制 : 當請求 失敗、超時、被拒絕、斷路器啓動 時,運行回退邏輯
回退邏輯由開發人員定義,如 : 返回缺省值
跳閘機制 : 當某服務的錯誤率超過閾值,則中止請求該服務一段時間,以後進入自我修復階段
超時時間應大於 Ribbon 的超時時間,避免 Ribbon 還在重試,但 Hystrix 已超時
自我修復 : 當斷路器啓動一段時間後,會自動進入半開狀態(少許測試服務是否正常)
監控 : 近乎實時地監控運行指針與配置變化 - 成功、失敗、超時、拒絕
Fegin = RestTemplate (簡化HTTP請求發送) + Ribbon (客戶端負載均衡) + Hystrix (熔斷器)
○ 異步非阻塞,基於 Reactor 模型
○ 高可用 : 透過 Nginx 實現
反向代理
過濾器
鑑權
流量控制
日誌輸出
【默認】使用 Git 存儲配置文檔內容
配置文檔命名規則
{application}-{profile}.yml
{application}-{profile}.properties
○ application 爲應用名稱
○ profile 爲環境 - 開發、測試、生產
刷新
○ 屏蔽底層不一樣 MQ 間的差別,下降學習、開發、維護 成本
○ 支持 RabbitMQ、Kafka
容許用戶受權第三方應用訪問他們存儲在另外的服務提供者上的信息
○ Json Web Token
○【核心目的】防止竄改
中間使用 "." 分割
可選擇使用 AP 模式 或 CP 模式
保護域值 : 健康實例數 / 總實例數
當保護域值低於設置時,說明健康實例很少,將把全部的實例(健康 + 不健康) 都返回給消費者
臨時實例 : 由客戶端發送心跳
持久實例 : 由 Nacos 發送心跳,且不會下線,僅作健康檢測 - MySQL
領域模型
配置文檔格式
可利用 Nacos 持久化數據
QPS : 當調用該資源的 QPS 達到閾值時,進行限流
QPS : 每秒鐘請求量
線程數 : 當調用該資源的 線程數 達到閾值時,進行限流 - 適用業務運行時間長的狀況
只有當 QPS >= 5,纔會觸發降級規則,時間窗口內拒絕請求,時間窗口後直接恢復