spring cloud eureka 服務 註冊與發現 spring
eureka client 會對 eureka server 進行緩存,減低 eureka server 壓力 ,就算 eureka server 掛了,也是能夠從緩存 獲取註冊數據。api
eureka 緩存
eureka 進入保護模式,就不會再剔除 服務註冊信息服務器
而 zookeeper 在遇到 網絡分區故障,就會進行選舉, 致使服務不可用網絡
RestTemplate架構
restTemplate 是 訪問rest 服務的 客戶端 工具併發
Ribboncors
eureka 已經 引入了 ribbon . 也就是 默認已經實現了負載均衡
對服務提供者(當服務提供者提供了負載均衡的時候,也就是多個服務提供者的實例) 框架
的訪問的時候 會進行負載訪問 (也就是每次可能會訪問不一樣的 服務提供者的實例 )。
好比 服務提供者 的負載有兩個,以下配置
user.ribbon.listOfServers=127.0.0.1:8083,127.0.0.1:8082
其餘配置不變,仍是能夠 起到 訪問不一樣的 服務提供者的功能的。
ribbon 會 每10秒去 ping 服務提供者的 地址,若是存活就是可用的
上圖就是 ribbon 流程圖
擴展 Feign
GTW token
jwt token
有一個缺點,就是 發送出去的 token 在有效期內 沒法 做廢失效
swagger
cors
有些時候 post 請求也是會發送預檢請求,由於它並非普通的post 請求了。
微服務架構之可靠性
故障隔離
1, 艙壁隔離, 線程隔離
2, 不一樣服務,不一樣服務的不一樣超時控制,防止大量超時請求將線程給耗盡
3, 服務降級
4, 熔斷機制: 就算有了 超時控制和服務降級仍是可能會形成服務器雪崩。
好比: 大併發下, 或者 不少請求失敗或者超時,那麼啓動 熔斷機制: 斷路器開啓
hystrix 原理
全鏈路追蹤
目的
trace 即一次完整的 調用 全過程,(包括幾個span, 調用了幾個服務等),每一個trace ,
都有惟一的id 對應
span (跨度,每次調用一個微服務就有一個span, 每一個span 都有其id , 生成新的span的時候,都有其餘對應的父span)
初始時候, span id 和 trace id 一致
annotation
表明每次span 調用 的 標誌 事件: CS 即請求發送, SR 請求被服務端接收, SS 服務端響應發送, CR 響應被接收
從左往右看 , 就算 全鏈路調用 了。 開始時候 service1 時候 x=a
log4j2 引入
disruptor
無鎖化的,高性能併發框架 log4j2 能夠藉助其達到高性能的日誌輸出
spring cloud sleuth
sleuth 須要 用到 zipkin
api-gayway 和 服務都須要 引入 zipkin 和配置
1,
spring-cloud-starter-zipkin
2.同時 配置文件 加上 zipkin 配置
spring.zipkin.baseUrl=http://localhost:9411 #採樣的比例,默認是0 ,1 就是 100% 採樣 spring.sleuth.sampler.percentage=1
3. 搭建 zipkin server
sleuth 原理
sleuth 如何經過 trace id 和span id ,以及經過 zipkin server 查看到 調用狀況?
開始用戶請求的時候,經過攔截器進行攔截請求,進行處理。
而後 服務間調用的時候, 攔截 RestTeplate 請求和響應, 處理信息和放入 請求頭和從響應內容裏面獲取 信息,好比將 對應得 trace id 放入 請求頭裏面。
這樣下一個服務就知道了 是 那個 trace id 了。
trace id 和 span id 相關信息都是 放入在 對應線程的 threadlocal 裏面的, logj2 日誌會 將 對應線程裏面的 threadlocal 裏面的 調用信息給取出來,
記錄便可。
日誌檢索方案 ELK
kibana 可實化展現
elasticsearch 日誌搜索
logstash 日誌收集
也就是 經過 logstash 收集 微服務的 日誌文件,將內容給 存入 elasticsearch , 而後 經過 kibana 平臺去 搜索,分析和展現 elasticsearch 裏面的 數據
以上 來自 慕課網