SpringCloud & Dubbo

微服務

SOA: 面向服務的架構，將服務拆分後註冊到企業總線統一對外提供服務

微服務：業務系統完全組件化，將應用拆分爲多個小的應用，這些應用從web UI到服務api都是獨立的完整的一個總體。

微服務特色：單一職責，自治。

微服務與SOA的區別：微服務再也不強調傳統SOA架構裏面比較重的ESB企業服務總線，微服務將業務系統完全的組件化。

微服務優勢：
一、邏輯清晰，每一個服務只負責本身的那部分業務
二、擴展方便，只需修改當前的微服務，且部署的時候也不會影響其餘模塊
三、高可用，分佈式部署提升了總體應用的吞吐量，對某些訪問量比較高的服務能夠單獨擴充節點 四、技術異構，不一樣的團隊維護不一樣的服務時，能夠根據本身熟悉的技術棧去實現並不會影響其餘人。

微服務缺點：
一、相對於單體應用，複雜度相對較高
二、維護成本較高，應用拆分出大量的微服務必定程度上也會增長運維的成本
三、相對單體應用的本地調用，微服務之間相互調用須要使用Rest、RPC等方式，必定程度上影響了性能。

springcloud

Spring Cloud Netflix Eureka 與服務治理：
服務發現與調用流程圖

三個服務A,B,C都是多實例部署在集羣環境中，都須要到註冊中心註冊，B,C做爲A的服務提供者，A須要經過負載均衡器找到B，C完成服務調用，負載均衡器從註冊中心獲取服務的定義信息。

服務治理涉及的角色主要有三種：
註冊中心：提供服務的註冊和發現
服務提供者：服務提供者將自身服務註冊到註冊中心，從而使消費者可以找到
服務消費者：從註冊中心獲取註冊服務列表，從而完成消費

服務治理的策略：
輪詢機制：消費者定時去註冊中心拉取最新的服務列表並更新本地緩存
監聽和通知機制：註冊中心註冊服務列表發生變化時，觸發回調通知消費者更新本地緩存。

服務治理實現工具：Zookeeper(Java)、Consul(Go)、Eureka(Java)

搭建一個Eureka服務很是簡單，引入spring-cloud-starter-eureka-server依賴，在啓動類上添加@EnableEurekaServer就完成了。Euraka能夠經過相互註冊（eureka.client.serviceUrl.defaultZone:多個eureka-url）的方式造成一個集羣。

Eureka客戶端的搭建也很是簡單，引入依賴spring-cloud-starter-eureka，在啓動類上添加註解@EnableEurekaClient，配置文件中添加配置eureka.client.serviceUrl.defaultZone:eureka-server-url
獲取註冊到Eureka服務器上的具體某一個服務實例的詳細信息能夠經過訪問http:eureka-service-url/eureka/apps/appid(servername)

Eureka基本架構

Spring cloud Netflix Ribbon 負載均衡

全部的服務實例註冊到註冊中心後，Ribbon從註冊中心獲取服務列表實現負載均衡。

負載均衡的類型：
一、服務端負載均衡，在客戶端與服務端之間加一個代理，訪問代理，代理將請求轉發到某個微服務節點上
二、客戶端負載均衡，負載均衡器與客戶端爲一個總體，客戶端在發起請求時首先根據負載均衡器定位到本次訪問的目的節點，而後發起請求

Ribbon是一種客戶端負載均衡方案

負載均衡的算法：
一、靜態負載均衡算法：隨機算法，使用JDK自帶的隨機算法或者改進後的加權隨機算法;輪詢算法：輪詢或者加權輪詢
二、動態負載均衡算法：最少鏈接數算法，統計每一個節點的被調用次數，調用次數較少的優先調用；服務調用延時算法，根據各節點響應的平均時間來調整調用優先級；源IP Hash算法，計算源IPde Hash值決定調用哪一個節點，能夠保證同一個客戶端每次調用的都是同一個服務節點。

使用Ribbon實現負載均衡：
Ribbon做爲一種客戶端負載均衡的實現方案，不須要獨立部署，而是直接嵌入在服務消費者的代碼中。
有兩種使用方式：一、使用@LoadBalanced和RestTemplate 二、使用@RibbonClient註解

使用：
引入依賴spring-boot-starter-ribbon，經過@LoadBalanced註解建立RestTemplate，而後經過RestTemplate調用http://serverName(服務生產者的服務名稱)/api(調用的接口),其實是Ribbon跟據serverName從註冊中心獲取對應的Ip和port信息列表，按照負載均衡算法獲得當前應該訪問的服務節點，將url替換掉進行訪問。

Spring Cloud Netflix Hystrix 服務容錯

Hystrix提供三種容錯處理：
一、隔離（線程隔離和信號量隔離）線程隔離至關於維護多個線程池
二、熔斷 維護一個請求失敗的計數器，當一個請求異常調用次數到達一個閾值，觸發熔斷器開啓，開後後到達必定時間，進入半開啓狀態，容許部分請求進入，若所有成功，或者成功達到必定比例，關閉熔斷器。
三、回退 服務回退指調用失敗後不是直接拋出異常而是用另外的代碼去處理

Spring Cloud Netflix Zuul Api網關

解耦服務調用：服務消費者只須要關注網關而不須要關注服務自己的提供者
優化Api：爲不一樣的調用者產生不用的響應，例如用戶查詢pc一次性查詢所有數據而App分頁查詢。
簡化調用過程：能夠將一些須要多個微服務結合才能實現的接口整合
服務路由：提供統一的服務路由供客戶端訪問
安全性控制：統一的認證權限處理
訪問控制：控制客戶端訪問次數和訪問頻率 負載均衡：提供前置的負載均衡功能

zuul使用內部的ZuulFilter鏈處理

Spring Cloud Config 配置中心

提供統一的配置信息管理

實現的兩種方式：基於本地文件系統，文件名稱要跟各個服務的名稱一致；基於中央倉庫（GIT）實現

Dubbo

Dubbo+Zookeeper

將接口抽象出來定義好，發佈到倉庫，服務提供者依賴api模塊，實現接口，添加@Service註冊到zk上，服務消費者只須要引用Api模塊，使用@Reference引用就能夠了。 服務提供者和服務消費者都須要依賴dubbo的相關依賴和Zookeeper的相關依賴，都須要註冊到Zookeeper上。

Dubbo是阿里巴巴開發的一款Java服務平臺框架以及SOA治理方案，主要功能包括：高性能NIO通訊以及多協議集成、服務動態尋址與路由、軟負載均衡與容錯、依賴分析、降級等

注意Dubbo註冊的@Service註解爲Dubbo提供的，消費者使用@Reference

RPC: 遠程過程調用，可使消費者服務像調用本地方法同樣調用遠程服務提供的方法。
總體流程爲：肯定遠程服務地址（ip,port等），創建鏈接（Tcp）,調用方法以及參數信息序列化經過tcp傳輸給遠程服務，遠程服務接收後本地調用產生結果再返回給消費者。

Dubbo基本原理（我的猜想暫未認證）：識別@Reference註解，生成代理類，從註冊中心或者本地緩存定位遠程訪問得服務列表，根據負載算法肯定遠程調用者，使用Netty與遠程服務創建TCP鏈接，封裝調用信息得消息體，發送給遠程服務，遠程服務解析消息體完成本地調用，返回調用結果，調用可能爲異步得，由客戶端生成惟一得請求id。

SpringCloud和Dubbo的區別

一、SpringCloud使用Rest api通訊，Dubbo採用RPC通訊，服務之間調用得性能會更好 二、springcloud相關組件多，有本身得註冊中心網關等，集成方便，Dubbo須要本身額外去集成。 三、Dubbo相對更容易上手