1.微服務架構模式方案

微服務架構采用Scale Cube方法設計應用架構，將應用服務按功能拆分成一組相互協作的服務。每個服務負責一組特定、相關的功能。每個服務可以有自己獨立的數據庫，從而保證與其他服務解耦。

2.微服務架構的基本能力

2.1 Restful 輕量級通訊的首選方式

在微服務架構下，推崇使用輕量級的方式進行通訊。我們選擇Restful的進行通訊。每個微服務都統一對外提供rest服務。無論前端調用後端服務還是後端之間的服務調用都統一走restful，這樣就統一了協議棧。微服務架構可以支持各種異構系統服務間的交互。

2.2 RPC通訊

統一的RPC框架是服務化首先要解決的問題，它為團隊提供了一整套序列化，反序列化，網絡框架，連接池，線程池超時處理等業務處理之外的能力。目前的RPC框架包括dubbo/dubbox，motan，thrift，grpc，Karyon/Ribbon

2.3 服務的註冊與發現

服務之間需要創建一種服務發現機制，用於幫助服務之間互相感知彼此的存在。服務啟動時會將自身的服務信息註冊到註冊中心，並訂閱自己需要消費的服務。

2.4 負載均衡

服務高可用的保證手段，為了保證高可用，每一個微服務都需要部署多個服務實例來提供服務。此時客戶端進行服務的負載均衡。

2.4.1負載均衡的常見策略

2.4.1.1隨機

把來自網絡的請求隨機分配給內部中的多個服務器。

2.4.1.2輪詢

每一個來自網絡中的請求，輪流分配給內部的服務器，從1到N然後重新開始。此種負載均衡算法適合服務器組內部的服務器都具有相同的配置並且平均服務請求相對均衡的情況。

2.4.1.3加權輪詢

根據服務器的不同處理能力，給每個服務器分配不同的權值，使其能夠接受相應權值數的服務請求。例如：服務器A的權值被設計成1，B的權值是3，C的權值是6，則服務器A、B、C將分別接受到10%、30％、60％的服務請求。此種均衡算法能確保高性能的服務器得到更多的使用率，避免低性能的服務器負載過重。

2.4.1.4 IP Hash

這種方式通過生成請求源IP的哈希值，並通過這個哈希值來找到正確的真實服務器。這意味著對於同一主機來說他對應的服務器總是相同。使用這種方式，你不需要保存任何源IP。但是需要註意，這種方式可能導致服務器負載不平衡。

2.4.1.5最少連接數

客戶端的每一次請求服務在服務器停留的時間可能會有較大的差異，隨著工作時間加長，如果采用簡單的輪循或隨機均衡算法，每一臺服務器上的連接進程可能會產生極大的不同，並沒有達到真正的負載均衡。最少連接數均衡算法對內部中需負載的每一臺服務器都有一個數據記錄，記錄當前該服務器正在處理的連接數量，當有新的服務連接請求時，將把當前請求分配給連接數最少的服務器，使均衡更加符合實際情況，負載更加均衡。此種均衡算法適合長時處理的請求服務，如FTP。

2.5 容錯

在調用服務集群時，如果一個微服務調用異常，如超時，連接異常，網絡異常等，則根據容錯策略進行服務容錯。目前支持的服務容錯策略有快速失敗，失效切換。如果連續失敗多次則直接熔斷，不再發起調用。這樣可以避免一個服務異常拖垮所有依賴於他的服務。

2.5.1 容錯策略

2.5.1.1 快速失敗

服務只發起一次待用，失敗立即報錯。通常用於非冪等下性的寫操作

2.5.1.2 失效切換

服務發起調用，當出現失敗後，重試其他服務器。通常用於讀操作，但重試會帶來更長時間的延遲。重試的次數通常是可以設置的

2.5.1.3 失敗安全

失敗安全， 當服務調用出現異常時，直接忽略。通常用於寫入日誌等操作。

2.5.1.4 失敗自動恢復

當服務調用出現異常時，記錄失敗請求，定時重發。通常用於消息通知。

2.5.1.5 forking Cluster

並行調用多個服務器，只要有一個成功，即返回。通常用於實時性較高的讀操作。可以通過forks=n來設置最大並行數。

2.5.1.6 廣播調用

廣播調用所有提供者，逐個調用，任何一臺失敗則失敗。通常用於通知所有提供者更新緩存或日誌等本地資源信息。

2.5.2 熔斷

有一些異常比較頑固，突然發生，無法預測，而且很難恢復，並且還會導致級聯失敗（舉個例子，假設一個服務集群的負載非常高，如果這時候集群的一部分掛掉了，還占了很大一部分資源，整個集群都有可能遭殃）。如果我們這時還是不斷進行重試的話，結果大多都是失敗的。因此，此時我們的應用需要立即進入失敗狀態(fast-fail)，並采取合適的方法進行恢復。

2.5.2.1 Circuit Breaker（熔斷器）原理

我們可以用狀態機來實現CircuitBreaker，它有以下三種狀態：

· 關閉( Closed )：默認情況下Circuit Breaker是關閉的，此時允許操作執行。CircuitBreaker內部記錄著最近失敗的次數，如果對應的操作執行失敗，次數就會續一次。如果在某個時間段內，失敗次數（或者失敗比率）達到閾值，CircuitBreaker會轉換到開啟( Open )狀態。在開啟狀態中，Circuit Breaker會啟用一個超時計時器，設這個計時器的目的是給集群相應的時間來恢復故障。當計時器時間到的時候，CircuitBreaker會轉換到半開啟( Half-Open )狀態。

· 開啟( Open )：在此狀態下，執行對應的操作將會立即失敗並且立即拋出異常。

· 半開啟( Half-Open )：在此狀態下，Circuit Breaker會允許執行一定數量的操作。如果所有操作全部成功，CircuitBreaker就會假定故障已經恢復，它就會轉換到關閉狀態，並且重置失敗次數。如果其中 任意一次 操作失敗了，Circuit Breaker就會認為故障仍然存在，所以它會轉換到開啟狀態並再次開啟計時器（再給系統一些時間使其從失敗中恢復）

2.5.3 Dubbo的集群容錯

當我們的系統中用到Dubbo的集群環境,因為各種原因在集群調用失敗時，Dubbo提供了多種容錯方案，缺省為failover重試。

通過以下方式設置

<dubbo:servicecluster="failsafe"/>

或：

<dubbo:referencecluster="failsafe"/>

集群容錯模式：

FailoverCluster

失敗自動切換，當出現失敗，重試其它服務器。(缺省)

通常用於讀操作，但重試會帶來更長延遲。

可通過retries="2"來設置重試次數(不含第一次)。正是文章剛開始說的那種情況.

FailfastCluster

快速失敗，只發起一次調用，失敗立即報錯。

通常用於非冪等性的寫操作，比如新增記錄。

FailsafeCluster

失敗安全，出現異常時，直接忽略。

通常用於寫入審計日誌等操作。

FailbackCluster

失敗自動恢復，後臺記錄失敗請求，定時重發。

通常用於消息通知操作。

Forking Cluster

並行調用多個服務器，只要一個成功即返回。

通常用於實時性要求較高的讀操作，但需要浪費更多服務資源。

可通過forks="2"來設置最大並行數。

BroadcastCluster

廣播調用所有提供者，逐個調用，任意一臺報錯則報錯。(2.1.0開始支持)

通常用於通知所有提供者更新緩存或日誌等本地資源信息。

重試次數配置如：(failover集群模式生效)

2.6 限流和降級

保證核心服務的穩定性。為了保證核心服務的穩定性，隨著訪問量的不斷增加，需要為系統能夠處理的服務數量設置一個極限閥值，超過這個閥值的請求則直接拒絕。同時，為了保證核心服務的可用，可以對否些非核心服務進行降級，通過限制服務的最大訪問量進行限流，通過管理控制臺對單個微服務進行人工降級

2.7 SLA

SLA：Service-LevelAgreement的縮寫，意思是服務等級協議。

是關於網絡服務供應商和客戶間的一份合同，其中定義了服務類型、服務質量和客戶付款等術語。

典型的SLA包括以下項目：

分配給客戶的最小帶寬；

客戶帶寬極限；

能同時服務的客戶數目；

在可能影響用戶行為的網絡變化之前的通知安排；

撥入訪問可用性；

運用統計學；

服務供應商支持的最小網絡利用性能，如99.9%有效工作時間或每天最多為1分鐘的停機時間；

各類客戶的流量優先權；

客戶技術支持和服務；

懲罰規定，為服務供應商不能滿足 SLA需求所指定。

3.微服務架構模式的優缺點

（1）優點

1. 每個微服務相對較小

l 開發者易於理解

l IDE處理效率快，利於提高勞動生產率

l Web容器壓力小，容器啟動速度快，易於提供勞動生產率和生產環境部署速度

2. 每個微服務都可以獨立部署，簡化了部署新服務版本的流程

3. 易於規模化開發，多個開發團隊可以並行開發，每個團隊負責一項服務

4. 改善故障隔離。一個服務宕機不會影響其他的服務

5. 每個服務可以獨立的進行開發和部署

6. 無需長期使用同一套技術棧

（2）缺點

1.開發者需要應對創建分布式系統所產生的額外的復雜因素

l 目前的IDE主要面對的是單體工程程序，無法顯示支持分布式應用的開發

l 測試工作更加困難

l 需要采用服務間的通訊機制

l 很難在不采用分布式事務的情況下跨服務實現功能

l 跨服務實現要求功能要求團隊之間的緊密協作

2.部署復雜

3.內存占用量更高

微服務理論與實踐(三)-微服務架構的基本能力和優缺點