SpringCloud——學習筆記（二）

一.Hystrix斷路器

• 1.爲何須要 Hystrix斷路器?

  雪崩現象: 複雜的分佈式架構的應用程序有不少的依賴,當依賴的某個服務出現失敗時（線程池阻塞），很容易拖垮整個應用。

  解決辦法：

  對依賴作隔離,Hystrix就是處理依賴隔離的框架,同時也是能夠幫咱們作依賴服務的治理和監控

  hysrix（豪豬）:保證微服務羣的健壯，作了隔離，熔斷，降級，緩存等操做。

  ​ 最終達到不會因爲某個服務出問題而致使雪崩，讓整個集羣死掉。

  資源隔離（限流）：線程池隔離，信號量隔離。分配每一個服務的資源，互不影響。

  熔斷：失敗率達到閾值時自動觸發降級

  降級：超時降級，資源不足時降級，降級後配合降級接口返回託底數據。減小損失

  緩存：提供了請求緩存，請求合併實現。

  所謂降級，就是當某個服務熔斷以後，服務器將再也不被調用，此時客戶端能夠本身準備一個本地的fallback回調，返回一個缺省值。

  熔斷（服務提供方作）調用時不能用feign（有本身的機制），使用ribbon

  1.導jar包依賴

  2.啓動斷路器(@EnableHystrix)

  3.配置斷路註解(@HystrixCommand(fallbackMethod = "getUserFailBack") //出現短路(超時,異常,屢次訪問都失敗),託底數據訪問(經過方法調用獲取的))

  4.返回託底數據的方法(public User getUserFailBack(Long id){ return new User(id,"出現異常了親！");})

Feign實現

• 爲何使用Feign?

  每一個方法都要加回調而且耦合。

• 解決方案:

  可使用spring面向切面編程,爲feign的接口建立一個代理對象,完成對服務調用,當發現熔斷後就調用同名託底方法。

• 若是咱們服務消費者實現的技術爲ribbon,必須在服務提供者方經過Hystrix的斷路器.

• 若是咱們服務消費者實現的技術爲feign,必須在服務消費者經過feign的斷路器,feign斷路器底層仍是Hystrix的斷路器.

二.Zuul路由網關

​ Zuul 是netflix開源的一個API Gateway 服務器, 本質上是一個web servlet應用。

• Zuul 在雲平臺上提供動態路由，監控，彈性，安全等邊緣服務的框架。Zuul 至關因而設備和 Netflix 流應用的 Web 網站後端全部請求的前門，也要註冊入Eureka。

• 路由訪問映射規則 ：

  安全加固：不用服務名,映射路徑

  忽略原來訪問：原來模式不能夠訪問

  加上統一前綴

• yml配置

  zuul:
    routes:
       myUser.serviceId: user-provider
       myUser.path: /user/**  #以/user/開頭的全部路徑都轉發給user-provider
    ignored-services:  "*" #能夠一個一個配置,可是很麻煩,用*來通配
    prefix: "/services" #加上統一前綴

三.SpringCloud Config分佈式配置中心

• 微服務架構中，每一個項目都有一個yml配置，管理起來麻煩。要使用spring cloud config來統一管理。

• 在整個項目中須要一個config-server 全部的其餘項目都對應一個config-clent,不管是provider consumer eureka等。

• 實現

  gitjhub上面的數據就用yhptest的 服務端:能經過url訪問配置 客戶端:可以經過服務端最終訪問配置信息 注意：config-server、和Eureka-sever的配置文件不能交給spring cloud config。注意前後

四.分佈式事務

• 事務: 指做爲單個邏輯工做單元執行的一系列操做，要麼徹底地執行，要麼徹底地不執行.

• 本地事務: SqlSessionfactory

  一個數據庫範圍類事務管理.

• 分佈式事務:

  跨了多個數據庫事務管理,在微服務架構每一個服務都有本身數據庫,在微服務架構中必然要用到分佈式事務.

  • 爲何須要？

    微服務架構所必須

• 實現方案

  二階段提交(耗時耗資源)

  tcc(強一致性)

  異步確保型(最終一致性-不實時)