9. 微服務理論與實踐-微服務架構的基本能力和優缺點
微服務理論與實踐-微服務架構的基本能力和優缺點
- 微服務理論與實踐-微服務架構的基本能力和優缺點
- 1 微服務架構模式方案
- 2 微服務架構的基本能力
- 3 微服務架構模式的優缺點
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重試。
通過以下方式設定
2.6 限流和降級
保證核心服務的穩定性。為了保證核心服務的穩定性，隨著訪問量的不斷增加，需要為系統能夠處理的服務數量設定一個極限閥值，超過這個閥值的請求則直接拒絕。同時，為了保證核心服務的可用，可以對否些非核心服務進行降級，通過限制服務的最大訪問量進行限流，通過管理控制檯對單個微服務進行人工降級
2.7 SLA
SLA：Service-LevelAgreement的縮寫，意思是服務等級協議。
是關於網路服務供應商和客戶間的一份合同，其中定義了服務型別、服務質量和客戶付款等術語。
典型的SLA包括以下專案：
分配給客戶的最小頻寬；
客戶頻寬極限；
能同時服務的客戶數目；
在可能影響使用者行為的網路變化之前的通知安排；
撥入訪問可用性；
運用統計學；
服務供應商支援的最小網路利用效能，如99.9%有效工作時間或每天最多為1分鐘的停機時間；
各類客戶的流量優先權；
客戶技術支援和服務；
懲罰規定，為服務供應商不能滿足 SLA需求所指定。
3 微服務架構模式的優缺點
優點
每個微服務相對較小、開發者易於理解、IDE處理效率快，利於提高勞動生產率、 Web容器壓力小，容器啟動速度快，易於提供勞動生產率和生產環境部署速度
每個微服務都可以獨立部署，簡化了部署新服務版本的流程
易於規模化開發，多個開發團隊可以並行開發，每個團隊負責一項服務
改善故障隔離。一個服務宕機不會影響其他的服務
每個服務可以獨立的進行開發和部署
無需長期使用同一套技術棧
缺點
- 開發者需要應對建立分散式系統所產生的額外的複雜因素
- 目前的IDE主要面對的是單體工程程式，無法顯示支援分散式應用的開發
- 測試工作更加困難
- 需要採用服務間的通訊機制
- 很難在不採用分散式事務的情況下跨服務實現功能
- 跨服務實現要求功能要求團隊之間的緊密協作
部署複雜
記憶體佔用量更高