溪源的Java筆記—微服務

前言

微服務架構是一種架構風格和架構思想，它提倡將系統業務按照功能拆分為更加細粒度的服務，即每一個服務都是一個獨立的應用，這些應用對外提供公共API用于應用調度，本篇博客從服務治理、微服務網關、Netty等方面介紹微服務，

分布式可參考我的博客溪源的Java筆記—分布式

正文

服務治理

服務注冊發現

• 服務注冊就是維護一個登記簿，它管理系統內所有的服務地址，當新的服務啟動后，它會向登記簿交待自己的地址資訊，
• 服務的依賴方直接向登記簿要 Service Provider 地址就行了，
• 當下用于服務注冊的工具非常多 ZooKeeper，Consul，Nacos, Eureka等，

分布式的服務治理，其背后的邏輯其實就是分布式資料一致性，

Eureka
Eureka是一項基于REST（代表性狀態轉移）的服務，主要在AWS云中用于定位服務，以實作負載均衡和中間層服務器的故障轉移，它是微服務框架中最核心和最基礎的模塊，它主要用來實作微服務實體的自動化注冊與發現，

Eureka由2個部分組成：服務端 和 客戶端：

• 客戶端通過注解的方式嵌入程式中，服務器和客戶端之間會進行周期性心跳檢測 ，如果心跳不存在時，該服務節點會從服務注冊表中移除，并且我們要知道Eureka的心跳檢測是基于SpringBoot Actuator來實作的，
• 各個服務節點 通過注冊中心得注冊資訊以Rest方式來實作呼叫，

Eureka的三種角色：服務注冊中心、服務提供者、服務消費者，事實上一個結點既可以是服務提供者 、也可以是服務消費者，

微服務節點之間通過續約和續期地方式實作服務清單的一致性：

• 續約：Eureka Client會周期（默認30秒）地向Eureka Server發送心跳以續約（Renew）自己的資訊，
• 續期：Eureka Server會定期（默認60秒）執行一次失效服務檢測功能，它一會檢查超過一定時間（默認是60秒）沒有續約的Eureka Client，發現并注銷該節點，

Consul
Consul是一個spring cloud 中集成好的開源的分布式的服務注冊發現中心，
由Go語言撰寫，支持健康檢查，多資料中心還支持k-v存盤，采用RAFT一致性演算法，保證強一致性，可用性，并且和docker完美兼容，

Consul本身也是一種服務治理中心，相對于Eureka而言：

• Consul犧牲了部分的性能，保證了服務的強一致性，
• Eureka只要服務注冊到主節點，就認為服務注冊成功，不關其他節點是否可以正常呼叫，

Nacos
Nacos提供了四個主要功能

• 服務發現和服務運行狀況檢查(服務治理)：Nacos使服務易于注冊自己并通過DNS或HTTP介面發現其他服務，Nacos還提供服務的實時運行狀況檢查，以防止向不正常的主機或服務實體發送請求，
• 動態配置管理：動態配置服務使您可以在所有環境中以集中和動態的方式管理所有服務的配置，Nacos消除了在更新配置時重新部署應用程式和服務的需求，這使配置更改更加有效和敏捷，
• 動態DNS服務：Nacos支持加權路由，使您可以更輕松地在資料中心內的生產環境中實施中間層負載平衡，靈活的路由策略，流控制和簡單的DNS決議服務，它可以幫助您輕松實作基于DNS的服務發現，并防止應用程式耦合到特定于供應商的服務發現API，
• 服務和元資料管理（分布式配置）：Nacos提供了易于使用的服務儀表板，可幫助您管理服務元資料，配置，kubernetes DNS，服務運行狀況和指標統計資訊，

Nacos 既支持AP也支持CP:

• 作為服務治理中心（替代 Spring Cloud Eureka）：采用的是AP模式，犧牲強一致性,從而保證存在節點宕機也不會影響正常的服務節點提供服務，
• 作為配置中心（替代Spring Cloud Config）:采用的是CP模式，犧牲資料可用性,確保分布式下配置引數的強一致性，

微服務網關

網關是系統的唯一對外的入口，介于客戶端和服務器端之間的中間層，處理非業務功能提供路由請求、鑒權、監控、快取、限流等功能，

網關的存在體現了設計模式中的外觀模式：

• 外觀模式要求一個子系統的外部與其內部的通信必須通過一個統一的門面(Facade)物件進行，
• 外觀模式提供一個高層次的介面，使得子系統更易于使用，

微服務使用網關的意義
不同的微服務一般會有不同的網路地址，而客戶端可能需要呼叫多個服務介面才能完成一個業務需求，若讓客戶端直接與各個微服務通信，會有以下問題：

1. 客戶端會多次請求不同微服務，增加了客戶端復雜性
2. 存在跨域請求，處理相對復雜
3. 認證復雜，每個服務都需要獨立認證
4. 難以重構，多個服務可能將會合并成一個或拆分成多個

微服務網關介于服務端與客戶端的中間層，所有外部服務請求都會先經過微服務網關客戶只能跟微服務網關進行互動，無需呼叫特定微服務介面，使得開發得到簡化，

微服務使用的網關主要有兩種Zuul和Gateway,這里簡單做一下對比：

• 從性能方面比較，兩種產品在流量小的場景下性能表現差不多；
• 并發高的場景下Gateway性能要好很多，從開發方面比較，Zuul1編程模型簡單，易于擴展；
• Gateway編程模型稍難，代碼閱讀難度要比Zuul高不少，擴展也稍復雜一些，

某種意義上GateWay被作為Zuul的取代品，

Netty原理

BIO的阻塞問題

• 當用戶執行緒發出 IO請求之后，內核會去查看資料是否就緒，如果沒有就緒就會等待資料就緒，而用戶執行緒就會處于阻塞狀態，用戶執行緒交出CPU，當資料就緒之后,內核會將資料拷貝到用戶執行緒,并回傳結果給用戶執行緒，用戶執行緒才解除block 狀態，如果資料沒有就緒,就會一直阻塞在read方法，
• 無論是客戶端還是服務器，同一時間只能發送或者接受一個資訊，處于等待回復的間隔，便是"阻塞"問題，即使使用多執行緒的方式服務器端的accept()、read()方法依舊會被阻塞，

NIO同步非阻塞

• NIO本身采用的是多路復用IO模型：通過一個執行緒不斷去輪詢多個 socket的狀態，只有當socket真正有讀寫事件時，才真正呼叫實際的IO讀寫操作，并且這種輪詢是采用內核的方式，效率比直接使用用戶執行緒高很多，
• 傳統 IO 基于位元組流和字 符流進行操作，而 NIO 基于 Channel 和 Buffer(緩沖區)進行操作，資料總是從通道讀取到緩沖區中，或者從緩沖區寫入到通道中，

NIO的非阻塞性

• 非阻塞讀：使一個執行緒從某通道發送請求讀取資料，但是它僅能得到目前可用的資料，如果目前沒有資料可用時，就什么都不會獲取，而不是保持執行緒阻塞，所以直至資料變的可以讀取之前，該執行緒可以繼續做其他的事情，
• 非阻塞寫：一個執行緒請求寫入一些資料到某通道，但不需要等待它完全寫入，這個執行緒同時可以去做別的事情，

執行緒通常將非阻塞IO的空閑時間用于在其它通道上執行IO操作，所以一個單獨的執行緒現在可以管理多個輸入和輸出通道，

Channel通道
Channel通道，是用于應用程式與作業系統進行互動的渠道，
NIO的Channel的是主要實作類：

• FileChannel:用于傳輸檔案IO的通道
• DatagramChannel：用于傳輸UDP資料的通道
• SocketChannel：客戶端使用SocketChannel來與服務器建立連接
• ServerSocketChannel: 服務器ServerSocketChannel 來等待客戶端的連接

通道類似于流，但是有區別：

1. 通道既可以讀資料，也可以寫資料，但是流的讀寫操作是單向的，
2. 通道可以異步讀取
3. 通道的資料總是要經過緩沖區

Buffer緩沖區
緩沖區，實際上是一個容器，是一個連續陣列，Channel 提供從檔案、 網路讀取資料的渠道，但是讀取或寫入的資料都必須經由 Buffer，

Selector

• Selector 能夠檢測多個注冊的通道上是否有事件發生，如果有事件發生，便獲取事件然后針對每個事件進行相應的回應處理，
• 用一個單執行緒就可以管理多個通道，也就是管理多個連接，新建的通道都要向選擇器注冊，
• 這樣使得只有在連接真正有讀寫事件發生時，才會呼叫函式來進行讀寫，就大大地減少了系統開銷，并且不必為每個連接都創建一個執行緒，不用去維護多個執行緒，并且避免了多執行緒之間的背景關系切換導致的開銷，
• selector進行select()操作可能會產生阻塞，但是可以設定阻塞時間，并且可以用wakeup()喚醒selector，所以NIO是非阻塞IO，
• 一個SelectionKey鍵表示了一個特定的通道物件和一個特定的選擇器物件之間的注冊關系，

AIO異步非阻塞
異步的體現：

• 同步的I/O流 服務器端不會"主動"聯系客戶端 ，但是AIO在資料準備完成后，會主動通知”客戶端“
• 異步的I/O是交給OS處理，而異步應用自己會處理，

AIO與NIO的區別：

• AIO與NIO都是通過管道的方式進行I/O操作，但是AIO每一個處理器與通道都是獨立的、一一對映，NIO是通過選擇器進行匹配，

Netty
Netty是一個NIO客戶端服務器框架：

• 它可快速輕松地開發網路應用程式，例如協議服務器和客戶端，
• 它極大地簡化和簡化了網路編程，例如TCP和UDP套接字服務器，
• 提供了Future-Listener機制，用戶可以方便的主動獲取或者通過通知機制獲得IO操作結果，
• Netty 采用了串行無鎖化設計，在 IO 執行緒內部進行串行操作，避免多執行緒競爭導致的性能下降，

Netty執行緒模型
Netty 的執行緒模型是基于NIO的Selector構建的，純粹的selector存在半包問題，

半包問題

• TCP/IP在發送訊息的時候，可能會拆包，這就導致接收端無法知道什么時候收到的資料是一個完整的資料，
• 在傳統的BIO中在讀取不到資料時會發生阻塞，但是NIO不會，為了解決NIO的半包問題，Netty提供了兩種方式解決閉包問題： 包定長FixedLengthFrameDecoder和包分隔符DelimiterBasedFrameDecoder，

Netty模型Reactor模式
Reactor模式(反應器模式)是一種處理一個或多個客戶端并發交付服務請求的事件設計模式，當請求抵達后，服務處理程式使用I/O多路復用策略，然后同步地派發這些請求至相關的請求處理程式，

Reactor模式又可以被細分為：

• Reactor單執行緒模型
• Reactor多執行緒模型
• 主從Reactor多執行緒模型

Reactor單執行緒模型
Reactor單執行緒模型，指的是所有的 IO操作都在同一個NIO執行緒上面完成，Reactor模式使用的是異步非阻塞IO，所有的IO操作都不會導致阻塞，理論上一個執行緒可以獨立處理所有IO相關的操作，這些操作包括：

• 建立TCP連接
• 接受或者發送訊息

Reactor多執行緒模型
Reactor多執行緒模型與單執行緒模型大的區別就是有一組 NIO 執行緒處理 IO操作：

• 有一個 NIO執行緒Acceptor執行緒用于監聽服務端，接收客戶端的TCP連接請求，
• 一個NIO執行緒池：處理請求，負責訊息的讀取、解碼、編碼和發送等，

主從Reactor多執行緒模型
接收客戶端連接的不再是個1個單獨的 NIO線程，而是一個獨立的 NIO執行緒池，即mainReactor執行緒池，

主從Reactor多執行緒模型可以理解為是一種"boss接活，讓work干"的模式：

• mainReactor執行緒池用來接收請求，與客戶端進行握手驗證
• subReactor執行緒池用來處理請求，不直接與客戶端進行連接
• 這種模式下只有mainReactor池接受到完整的資料后，subReactor池才會處理，這樣就避免了半包的問題，

Spring Cloud

Dubbo與Spring Cloud的差異：

• Dubbo 是一個分布式服務框架，致力于提供高性能和透明化的 RPC 遠程服務呼叫方案，以及 SOA 服務治理方案，
• Spring Cloud 基于 Spring Boot，為微服務體系開發中的架構問題，提供了一整套的解決方案：包括服務注冊與發現，服務消費，服務保護與熔斷，網關，分布式呼叫追蹤，分布式配置管理等，

Dubbo性能優于 Spring Cloud 的原因：

• 因為 Dubbo 采用單一長連接和 NIO 異步通訊（保持連接/輪詢處理），使用自定義報文的 TCP 協議，
• 序列化使用定制 Hessian2框架，適合于小資料量大并發的服務呼叫，以及服務消費者機器數遠大于服務提供者機器數的情況，但不適用于傳輸大資料的服務呼叫，
• Dubbo的兼容性比較好，可以根據實際業務選擇其他的通訊協議或序列化協議，
• Spring Cloud 直接使用 HTTP 協議的REST，（REST為表述性狀態傳遞），

SpringCloud的子專案
1.Spring Cloud Starters:Spring Cloud的基礎組件，

2.Spring Cloud Config:配置管理工具，支持使用Git存盤配置內容，可以使用它實作應用配置的外部化存盤， 支持客戶端配置資訊重繪、加密和解密等配置內容

3.Spring Clond Netflix:其中包括了：

• Eureka：服務發現框架
• Ribbon：客戶端負載均衡
• Hystrix：熔斷機制
• Zuul：服務端負載均衡
• Feign：宣告式呼叫框架

Eureka 服務發現框架（服務治理）

Eureka高可用注冊中心

• 單節點時注冊中心不需要注冊自己，但是高可用注冊中心，節點要向出自己以外的服務中心進行注冊

• 不需要重新創建新專案 只要多配制application.properties 運行時 java -jar xxx.jar--spring.profiles.active=ek8761 (命令列配置優先級最高)

Eureka客戶端的實作

• 啟動類@EnableEurekaClient中的@EnableDiscoveryClient用來實作發現服務，幫助與Eureka Server相互協作
• 客戶端在加載程序中 首先會加載Region，接著會加載Zone,一個應用只有一個Region,但是可以有多個Zone(適用于跨機房、跨地區配置)
• Ribbon的默認策略會優先訪問通客戶端處于一個Zone中的服務端實體，只有當同一個Zone中沒有可用服務端實體才會訪問其他Zone的實體

Eureka框架與負載均衡
Ribbon是一個基于HTTP和TCP的客戶端負載均衡器：

• 只使用ribbon時需要在客戶端配置ribbonServerList服務端串列去輪詢以達到負載均衡的作用，
• 當與Eureka結合，擴展成從Eureka注冊中心獲取服務端串列，ribbon將確認服務端是否啟動的職責委托給Eureka，
• Eureka服務端中保存著所有的服務的實體清單，當新的客戶端進行注冊時，會從服務端獲取該份清單，
• 微服務對請求進行負載均衡時，便會從該份清單中以某種輪詢策略選取一個組價進行請求的處理，

我們通常所說的服務端負載均衡(硬體負載均衡和軟體負載均衡)和客戶端負載均衡的差異就在于這份清單的存盤位置:

• 服務端負載均衡只有服務器保存該份清單（如nginx），而客戶端負載均衡(ribbon)每一個客戶端組件都保存完整的服務清單，

通過設定nginx.conf的服務器端負載均衡的弊端在于:

• 通過這種靜態配置來維護這份清單會隨著業務增加而越來越困難，而通過Eureka注冊服務，服務的呼叫可以通過向服務名發起請求而實作，

RestTemplate

• 該物件會使用Ribbon的自動化配置，同時通過配置@LoadBalanced還能開啟客戶端負載均衡，
• @LoadBalanced會使用攔截器的方式來實作其負載均衡，如getForEntity（url,body型別，引數）會通過url從服務清單中獲取服務節點

GET請求

• 請求指定的頁面資訊，并回傳物體主體，
• getForEntity（url,body型別，引數）
• 該方法回傳的是ResponseEntity,該物件是Spring對Http請求回應的封裝，它包括：http請求狀態、請求頭、請求體物件

POST請求

• 向指定資源提交資料進行處理請求
• postForEntity(url,引數，回傳物件型別)

PUT請求

• 只提交資料，不會回傳結果
• put(url,引數，序列號)

DELETE請求

• 請求服務器洗掉指定的頁面
• delete(url,序列號)

Spring Eureka保護機制、重試機制

Eureka保護機制

• Eureka會在超過85%的實體失去心跳而出發保護機制，注冊中心會保留此時的所有節點，以實作服務間依然可以相互呼叫的場景，即時其中有部分故障節點，但這樣可以繼續保障絕大數服務可以正常使用，

重試機制在請求超時后進行重試：

• 借助Spring Retry實作重試
• 借助Ribbon實作重試
• 借助Zuul實作重試
• 借助Feign實作重試

Spring Cloud Hystrix 熔斷機制
Spring Cloud Hystrix,該框架的使用目標在于通過控制那些訪問遠程系統、服務和 第三方庫的節點，從而對延遲和故障提供更強大的容錯能力，

• Hystrix具有服務降級、服務熔斷、執行緒和信號隔離、請求快取、請求合并以及服務監控等強大功能，
• 將分布式業務的正向操作和逆向操作分離，并通過設定最長等待時間、拋出例外等方法讓逆向操作自動執行，解決事務補償機制中反向操作，導致其他業務無法執行，而造成的系統雪崩，
• 通過在啟動類添加 @EnableCircuitBreaker來開啟熔斷器功能

Hystrix的作業流程

1. 創建HystrixCommand（單個結果）或HystrixObservableCommand（多個結果）物件
   用來表示對依賴服務的操作請求，同時傳遞所有需要的引數；（這里使用了命令模式 將事件通過命令的形式 委派特定物件執行）
2. 命令執行 ：有異步執行、同步執行、回傳Observable事件源物件、回傳多個Observable事件源物件這四種事件源通常會被訂閱者所監控（這里的設計是觀察者-訂閱者模式）
3. 結果是否被快取 如果命中快取，會即刻回傳Observable事件源物件
4. 判斷斷路器是否被打開 如果斷路器被打開，執行fallback方法
5. 執行緒池/請求佇列/信號量是否占滿 Hystrix的執行緒池設計采用了“艙壁模式”
6. HystrixObservableCommand.construct() 回傳多個結果 或HystrixCommand.run()回傳單一的結果計算斷路器的健康程度
7. fallback處理：當服務執行失敗時，“服務降級”，執行fallback函式
8. 回傳成功的回應：當Hystrix命令執行成功之后，它會將處理結果直接回傳或者以Obervable的形式回傳，

斷路器健康程度
熔斷器熔斷服務的決定因素：
當前服務健康狀態=請求失敗數/請求總數 A設定閾值 當前請求數B

• 熔斷器關閉 請求安全通過
• A>B 請求安全通過
• A<B 請求禁止通過

服務降級

• 如果設定fallback方法，進入fallback方法
• 通過fallback給用戶一個友好的提示結果

“艙壁模式”
“艙壁模式”：Hystrix使用該模式實作執行緒池的隔離：

• 它會為每一個依賴服務創建一個獨立的執行緒池，這樣就算某個依賴服務出現延遲過高的情況（執行緒被長時間掛起），也只會對該依賴服務的呼叫產生影響，而不會拖慢其他的依賴服務，這樣的設計模式提高了應用的健壯性，
• 使用執行緒隔離為系統在穩定性和靈活性帶來了巨大的提升，但是增加了執行緒池一定的額外開銷，Hystrix在部分地方使用信號量的方式來控制單個依賴服務的并發度，但這種方式不支持設定超時和實作異步訪問，

Hystrix的請求快取

• @CacheResult:該注解來標記請求命令回傳的結果應該被快取，它必須與@HystrixCommand注解結合使用
• @CacheRemove:該注解來讓請求命令的快取失效，失效的定義根據KEY來設定@CacheRemove(commadKey="請求的函式名")
• @CacheKey:用來在請求命令的引數上做標記，作為快取的key值，如果沒有標注則會使用所有的引數，
• @cacheKeyMethod:配置一個方法來指定Key生成方式 優先級高于CacheKey

請求合并

• 在高并發的情況下，會出現通訊消耗嚴重、排隊和回應延遲的情況
• Hystrix提供了HystrixCollapser來實作請求的合并，以減少通訊的消耗好執行緒的占用，
• HystrixCollapser將使用一個合并處理器，將處于一個很短的時間窗（默認10毫秒）內對同一依賴服務的多個請求進行整合并以批量的方式發起請求的功能，

使用場景：

• 該請求本身就是一個高延遲的命令
• 一個時間視窗下會有很多請求（高并發）

@HystrixCollapser(batchMethod = "helloService",collapserProperties = {@HystrixProperty(name ="timerDelayInMilliseconds",value = "100")})

@HystrixCommand
@Override public List<User> helloService(List<String> ids) {
    ResponseEntity<List> responseEntity =restTemplate.getForEntity("http://springcloud-eureka-client-user/hello?id={1}",List.class,StringUtils.join(ids,","));
  return   responseEntity.getBody();
}

Hystrix配置
Hystrix根據不同業務場景提供了非常豐富和靈活的配置方法，@HystrixCommand(commandProperties = {@HystrixProperty(name="屬性1",value = "值1"),@HystrixProperty(name="屬性名2",value = "值2")})

提供了5類配置屬性：

• execution配置：控制的是HystrixCommand.run()的執行，
• fallback配置：用來控制HystrixCommand.getFallback()的執行，這些屬性同時適用于執行緒池的信號量的隔離策略，
• circuitBreaker配置：斷路器的屬性配置，用來控制HystrixCircuitBreaker的行為，
• metrics配置:HystrixCommand和HystrixObservableCommand執行中的指標資訊，
• requestContext配置：涉及HystrixCommand使用的HystrixRequestContext的設定，

宣告式服務呼叫：Spring Cloud Feign

• Feign整合了Spring Cloud Ribbon 與Spring Cloud Hystrix，同時提供了一種宣告式的Web服務客戶端定義方式，

• 所有通過Feign我們可以通過注解的方式 快速的呼叫服務，并且自動回開啟客戶端負載均衡，

簡單地說 Feign能夠對RestTemplate進行進步封裝，

Dubbo

Dubbo來自于阿里巴巴，它是一個分布式服務框架，致力于提供高性能和透明化的PRC遠程呼叫服務呼叫方案，

Dubbo的的特點

• 通過spring配置的方式即可完成服務化，對于應用無入侵，（SpringCloud有一定的入侵）
• 通過maven的install &deploy命令把interface和Model層發布到倉庫中，服務呼叫方只需要依賴interface和model層即可，
• 通過zookeeper設定達到注冊服務和心跳檢測，通過GateWay前置網關（Spring Cloud使用Zuul實作負載均衡將請求轉向Eureka服務器）隔絕外部直接呼叫原子服務的風險
• 它是基于Dubbo SPI來實作的，其基本原理是Java SPI機制，

Dubbo支持的通信協議和序列化協議
通訊協議：（10種）

1. Dubbo 默認協議：議采用單一長連接和 NIO異步通訊，適合于小資料量大并發的服務呼叫，以及服務消費者機器數遠大于服務提供者機器數的情況，
2. REST 協議： 基于標準的Java REST API實作的REST呼叫支持
3. Hessian 協議：Hessian 協議用于集成 Hessian 的服務，Hessian 底層采用 Http 通訊，采用Servlet 暴露服務，Dubbo 預設內嵌 Jetty 作為服務器實作
4. HTTP 協議：需同時給應用程式和瀏覽器 JS 使用的服務，
5. dubbo rpc jsonrpc:json-rpc是基于json的跨語言遠程呼叫協議
6. WebService 協議：系統集成，跨語言呼叫
7. RMI 協議：RMI 協議采用 JDK 標準的 java.rmi.* 實作，采用阻塞式短連接和 JDK 標準序列化方式，
8. Thrift 協議：使用Thrift實作PRC協議
9. Redis 協議：基于redis實作RPC協議
10. Memcached 協議：基于Memcached實作RPC協議
    

序列化協議：（6種）

• dubbo-hessian-lite：是官方 hessian 的一個 Apache Dubbo 私有版本
• Apache Avro：是一個資料序列化系統，
• Jdk 序列化：Java自帶的序列號工具
• JSON - fastjson：一個Java版本內的 JSON 決議器/生成器
• FST: 一個快速的Java序列化工具
• Kryo:是一個Java版本的快速有效的二進制物件序列化框架
  

Dubbo 核心部件:

• Provider： 暴露服務的提供方，可以通過jar或者容器的方式啟動服務（需要啟動 使用Docker容器）
• Consumer：呼叫遠程服務的服務消費方，
• Registry： 服務注冊中心和發現中心，（zookeeper）
• Monitor： 統計服務和呼叫次數，呼叫時間監控中心，（dubbo的控制臺頁面中可以顯示，目前只有一個簡單版本）
• Container：服務運行的容器，

Dubbo呼叫的流程

Provider

1. start 啟動服務，
2. register 注冊服務到注冊中心，

Consumer

1. subscribe 向注冊中心訂閱服務，只訂閱使用到的服務，
2. 首次會拉取訂閱的服務串列，快取在本地，notify 當服務發生變化時，獲取最新的服務串列，更新本地快取，

invoke呼叫

• Consumer 直接發起對 Provider 的呼叫，無需經過注冊中心，而對多個 Provider 的負載均衡，Consumer 通過cluster 組件實作，

count監控

• Consumer 和 Provider 都異步通知監控中心，

dubbo與Apache Thrift的區別

1. dubbo 本身是一個綜合的SOA解決方案，thrift僅是一個rpc服務框架；

2. dubbo當前主要用作java, thrift可以用作目前所熟知的各種語言；

3. dubbo可以使用thrift作為rpc服務組件，dubbo也有自帶的rpc組件

Dubbo服務高可用機制
Dubbo 容錯機制
容錯機制值得是服務容忍錯誤的能力，當系統出現網路延遲、網路中斷、服務例外等原因，造成當前服務暫時不可用，Dubbo提供了容錯機制來優雅地幫助服務呼叫者處理這類錯誤，

Dubbo默認提供了6種容錯模式

1. Failover Cluster（默認）：失敗自動切換，當服務呼叫失敗后，會切換到集群中的其他機器進行重試，默認重試次數為2，通過屬性retries=2可以修改次數，但是重試次數增加會帶來更長的回應延遲，（這種容錯模式通常用于讀操作）
2. Failfast Cluster:快速失敗，當服務呼叫失敗后，立即報錯，也就是指發起一次呼叫，（這種模式通常用于寫操作，這種模式可以防止網路等問題導致資料重復新增，它等同于Failover Cluster retries=0）
3. Failsafe Cluster:失敗安全，出現例外時，直接忽略例外，（這種模式處理的資料相對而言不太重要）
4. Failback Cluster:失敗后自動回復，服務呼叫出現例外時，在后臺記錄這條失敗的請求定時重發，（這種模式適合用于訊息通知操作，保證這個請求一定發送成功，可以解決短期網路擁塞導致請求的丟失）
5. Forking Cluster:并行呼叫集群中的多個服務，只要其中一個成功就回傳，可以通過forks=2來設定最大并行數，（這種模式要保證請求的冪等性）
6. Broadcast Cluster:廣播呼叫所有的服務提供者，任意一個服務報錯則表示服務呼叫失敗，（這種模式需要所有節點都是正常的才能被呼叫）

服務呼叫者容錯機制的配置方式容錯機制既可以在服務呼叫者中配置或在服務提供者中配置

1. 在服務呼叫者中配置只對該呼叫者起作用（其他呼叫節點采用默認的）
2. 在服務服務者中配置對所有呼叫者起作用
3. 呼叫者的配置優先級高于服務者

Dubbo 負載均衡機制
在Dubbo提供了4種負載均衡策略，分別是:

1. Random LoadBalance隨機演算法(默認)：可以針對性能較好的服務器設定較大的權重值，權重值越大，隨機的概率越大，

2. RoundRobin LoadBalance輪詢：安裝公約后的權重設定輪詢比例，

3. LeastActive LoadBalance最少活躍呼叫數：處理較慢的節點將會收到更少的請求，

4. ConsistentHash LoadBalance一致性Hash:相同引數的請求總是發送到同一個服務提供者，

Dubbo服務降級機制
服務降級是一種系統保護策略，當服務器訪問壓力較大時，可以根據當前業務情況對不重要的服務降級，以保證核心服務的正常進行，服務降級可以分為兩類：

• 人工降級：具有一定的前置性，比如在電商大促之前，關閉某些非核心服務，比如評價等
• 自動降級：當系統出現某些例外時自動觸發“補償性回應”

Dubbo 提供了Mock配置來實作服務降級，它會在一下情況觸發：

• Dubbo服務者不提供服務
• Dubbo服務超時

Mock本身是一種模擬失敗的行為，服務降級mock的級別：

• false，不呼叫mock服務
• true，當服務呼叫失敗時，使用mock服務，
• default，當服務呼叫失敗時，使用mock服務，
• force，強制使用Mock服務(不管服務能否呼叫成功)，

SpringCloud Alibaba

Spring Cloud Alibaba主要為微服務開發提供一站式的解決方案，使開發者通過SpringCloud編程模型輕松地解決微服務架構下的
各種問題，

• 流量控制和服務降級：使用阿里巴巴Sentinel進行流量控制，斷路和系統自適應保護
• 服務注冊和發現：實體可以在Alibaba Nacos上注冊，客戶可以使用Spring管理的bean發現實體，通過Spring Cloud Netflix支持Ribbon，客戶端負載均衡器
• 分布式配置：使用阿里巴巴Nacos作為資料存盤
• 事件驅動：構建與Spring Cloud Stream RocketMQ Binder 連接的高度可擴展的事件驅動微服務
• 訊息總線：使用Spring Cloud Bus RocketMQ鏈接分布式系統的節點
• 分布式事務：支持高性能且易于使用的Seata分布式事務解決方案
• Dubbo RPC：通過Apache Dubbo RPC擴展Spring Cloud服務間呼叫的通信協議