6.1 Dubbo算法
6.1.1 Dubbo概述數據庫
服務間基於RPC的方式調用。緩存
6.1.2 核心流程服務器
Dubbo中必有的核心概念只有服務提供者、服務消費者和註冊中心這三個,治理中心以及監控中心並不是必需品。網絡
服務提供者初始化後會向註冊中心註冊服務;服務消費者啓動時向註冊中心訂閱服務。註冊中心在服務提供者列表發生變化時將變化的內容主動通知給服務消費者。服務提供者和服務消費者在初次連通後,持有長鏈接,經過透明化的遠程調用進行通訊。併發
6.1.3 註冊中心負載均衡
大多數狀況,Dubbo都是配合Zookeeper註冊中心來使用的。框架
6.1.4 負載均衡運維
Dubbo採用客戶端負載均衡方式,由服務消費者一方決定當前通訊發送至哪一個服務提供者。高併發
服務消費者啓動時會從註冊中心同步一份有效的服務提供者列表,緩存起來,當服務列表變化時,會更新。每次調用服務時,根據合適的負載均衡算法選擇一個服務提供者。
Dubbo的服務發現和負載均衡機制,有以下三個特徵:
Dubbo支持隨機、輪詢(會致使大量請求阻塞在短板服務上)、最少活躍調用數和一致性哈希這四種負載均衡策略。
重點說一下一致性哈希:爲了解決因特網中的熱點(Hot spot)問題。
好比:有4個服務器,每一個都緩存圖片,當定位一個圖片時,爲了不訪問四次,能夠用取模運算的方式來決定圖片的位置。可是問題是:當服務器增長或減小時,取模運算會致使全部的圖片位置都不對,緩存在短期內所有失效,叫緩存雪崩。爲了不這種狀況,提出一致性哈希算法,目的是當服務器數量增長和減小時,圖片緩存的位置不變,不會發生雪崩。
6.1.5 遠程通訊
Dubbo通訊協議採用的是Java NIO實現的多路複用。對於每個服務消費者來講,Dubbo協議的服務提供者會建立固定數量的長鏈接傳輸消息,有效減小握手次數,Dubbo通訊協議使用線程池併發處理請求來增長併發效率。因爲鏈接複用,傳輸大文件時帶寬佔用率高可能會成爲系統瓶頸,所以Dubbo通訊協議適合處理高併發的小數據量互聯網請求,不適合處理視頻、高清照片。
6.1.6 限流
Dubbo服務提供者能夠設置限流。
6.1.7 治理中心
提供一個可視化中心,輔助作運維工做。提供了分組查詢、配置更改、加權降權、禁用啓用、權限控制、負責人管理等運維功能。
6.1.8 監控中心
6.1.9 DubboX的擴展
DubboX由噹噹網開源,X是extensions一詞,是對Dubbo的擴展。
Rest協議:Dubbo缺少對RESTful風格支持。 DubboX彌補了這一缺憾。
高新能序列化:序列化對遠程調用的響應速度、吞吐量、網絡帶寬影響大。Dubbo支持的不算太好,DubboX進行了擴展。
6.2 Spring Cloud
提供了一套雲原生開發組件。
6.2.1 概述
Spring Cloud是基於Spring boot的嵌入式服務治理框架,創建在工程師熟悉約定的前提下。
6.2.2 開發腳手架Spring Boot
自動裝配:
Spring boot對Spring 進行封裝,經過約定優於配置以及元註解驅動的設計理念。
Spring Boot提供了內嵌的Web服務器並簡化了Spring MVC配置,提供了對數據庫、NOSQL、緩存、消息中間件、REST訪問、郵件發送等第三方服務的高度整合。
啓動Spring boot的入口應用僅須要一個註解和一行代碼。
@SpringBootApplication是@Configuration 、 @EnableAutoConfiguration 、@ComponentScan這三個註解的組合。
暴露端點:
Spring boot提供了Actuator模塊用於方便地暴露應用自身的信息,以便監控與管理。
6.2.3 服務發現
6.2.4 負載均衡
Ribbon: 提供了客戶端負載均衡的解決方案。自動的從Eureka中獲取服務提供者列表,將負載均衡與服務發現結合起來。
6.2.5 熔斷
Hystrix作爲熔斷器,並經過它實現熔斷後的業務降級。
6.2.6 遠程通訊
Spring cloud採用當前較爲流行的RESTful API進行服務之間交互。Feign。