微服務相關原理與治理

微服務架構沒有公認的技術標準和規範或者草案，但業界已經有一些頗有影響力的開源微服務架構框架提供了微服務的關鍵思路，例如 Dubbo 和 Spring Cloud。

目前微服務實現方式主要有兩種Dubbo和SpringCloud：

1、Dubbo：(https://www.cnblogs.com/liangblog/p/6165070.html）

      Dubbo是一個分佈式服務框架，致力於提供高性能透明化RPC遠程調用方案，提供SOA服務治理解決方案。

      Dubbo使用 RPC 通信協議。

      架構原理：（http://dubbo.apache.org/zh-cn/docs/user/preface/architecture.html）

 

      

 

0. 服務容器負責啓動，加載，運行服務提供者。
1. 服務提供者在啓動時，向註冊中心註冊本身提供的服務。
2. 服務消費者在啓動時，向註冊中心訂閱本身所需的服務。
3. 註冊中心返回服務提供者地址列表給消費者，若是有變動，註冊中心將基於長鏈接推送變動數據給消費者。
4. 服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，若是調用失敗，再選另外一臺調用。
5. 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。

       zookeeper註冊中心：

• 註冊中心，服務提供者，服務消費者三者之間均爲長鏈接，監控中心除外
• 註冊中心經過長鏈接感知服務提供者的存在，服務提供者宕機，註冊中心將當即推送事件通知消費者
• 註冊中心和監控中心所有宕機，不影響已運行的提供者和消費者，消費者在本地緩存了提供者列表
• 註冊中心和監控中心都是可選的，服務消費者能夠直連服務提供者

• 數據庫宕掉後，註冊中心仍能經過緩存提供服務列表查詢，但不能註冊新服務
• 註冊中心對等集羣，任意一臺宕掉後，將自動切換到另外一臺
• 註冊中心所有宕掉後，服務提供者和服務消費者仍能經過本地緩存通信
• 服務提供者無狀態，任意一臺宕掉後，不影響使用
• 服務提供者所有宕掉後，服務消費者應用將沒法使用，並沒有限次重連等待服務提供者恢復

流程說明：

• 服務提供者啓動時: 向 /dubbo/com.foo.BarService/providers 目錄下寫入本身的 URL 地址
• 服務消費者啓動時: 訂閱 /dubbo/com.foo.BarService/providers 目錄下的提供者 URL 地址。並向 /dubbo/com.foo.BarService/consumers 目錄下寫入本身的 URL 地址
• 監控中心啓動時: 訂閱 /dubbo/com.foo.BarService 目錄下的全部提供者和消費者 URL 地址。

支持如下功能：

• 當提供者出現斷電等異常停機時，註冊中心能自動刪除提供者信息
• 當註冊中心重啓時，能自動恢復註冊數據，以及訂閱請求
• 當會話過時時，能自動恢復註冊數據，以及訂閱請求
• 當設置 <dubbo:registry check="false" /> 時，記錄失敗註冊和訂閱請求，後臺定時重試
• 可經過 <dubbo:registry username="admin" password="1234" /> 設置 zookeeper 登陸信息
• 可經過 <dubbo:registry group="dubbo" /> 設置 zookeeper 的根節點，不設置將使用無根樹
• 支持 * 號通配符 <dubbo:reference group="*" version="*" />，可訂閱服務的全部分組和全部版本的提供者

 dubbo服務治理：

       服務治理主要做用是改變運行時服務的行爲和選址邏輯，達到限流，權重配置等目的；主要配置有：條件路由(包括黑白名單)，動態配置(包括權重，負載均衡）

       動態配置是和路由規則平行的一類服務治理治理功能，主要做用是在不重啓服務的狀況下，動態改變調用行爲。

       權重調節是動態配置的子功能，主要做用是改變服務端的權重，更大的權重會有更大的概率被客戶端選中做爲服務提供者，從而達到流量分配的目的：

        負載均衡也是動態配置的子功能，主要做用是調整客戶端的選址邏輯，目前可選的負載均衡策略有隨機，輪訓和最小活躍；

 

2、SpringCloud: （https://www.cnblogs.com/liangblog/p/9566525.html）

     Spring Cloud 是一套完整的微服務解決方案，基於 Spring Boot 框架，準確的說，它不是一個框架，而是一個大的容器，是一系列框架的有序集合，它利用 Spring Boot 的開發便利性簡化了分佈式系統的開發，好比服務發現、服務網關、服務路由、鏈路追蹤等。Spring Cloud 並不重複造輪子，而是將市面上開發得比較好的模塊集成進去，進行封裝，從而減小了各模塊的開發成本。   

Spring Cloud 使用 HTTP 協議的 REST API。

整體架構：

 

• Service Provider： 暴露服務的提供方。
• Service Consumer：調用遠程服務的服務消費方。
• EureKa Server： 服務註冊中心和服務發現中心。

Spring Cloud運行基礎組件：

　　服務治理： Spring Cloud Eureka

             Eureka是微服務架構中的註冊中心，專門負責服務的註冊與發現

　　客戶端負載均衡： Spring Cloud Ribbon

            Ribbon做用是負載均衡，會幫你在每次請求時選擇一臺機器，均勻的把請求分發到各個機器上。默認使用的最經典的Round Robin輪詢算法。

　　服務容錯保護： Spring Cloud Hystrix

           Hystrix是隔離、熔斷以及降級的一個框架。經過Hystrix的線程池來發起請求，不一樣的服務走不一樣的線程池，實現了不一樣服務調用的隔離，避免了服務雪崩的問題

　　聲明式服務調用： Spring Cloud Feign　　                      

　　Feign的一個關鍵機制就是使用了動態代理：

• 首先，若是你對某個接口定義了@FeignClient註解，Feign就會針對這個接口建立一個動態代理

• 接着你要是調用那個接口，本質就是會調用 Feign建立的動態代理，這是核心中的核心

• Feign的動態代理會根據你在接口上的@RequestMapping等註解，來動態構造出你要請求的服務的地址

• 最後針對這個地址，發起請求、解析響應

　　API 網關服務：Spring Cloud Zuul

                 若是前端、移動端要調用後端系統，統一從Zuul網關進入，網關會根據請求中的一些特徵，將請求轉發給後端的各個服務。

               好處是能夠作統一的降級、限流、認證受權、安全，

　大體流程以下：

• 全部請求都統一經過 API 網關（Zuul）來訪問內部服務。
• 網關接收到請求後，從註冊中心（Eureka）獲取可用服務。
• 由 Ribbon 進行均衡負載後，分發到後端的具體實例。
• 微服務之間經過 Feign 進行通訊處理業務。
• Hystrix負責處理服務超時熔斷

 

        SpringCloud相較於Dubbo來講更爲全面，擁有服務治理，配置服務，網關路由，異常處理等，比Dubbo更全面，尤爲是在結合SpringBoot框架時只需添加依賴，使用方便，簡化配置文件。在集羣中各功能組件協調工做時使用SpringCloud架構項目能承受更高併發量，具備更強大的容錯高可用性。

3、服務降級：（服務治理時配置服務降級，或代碼級別設置）

服務降級就是當服務響應超時或鏈接請求超時，不用繼續等下去，而採用降級措施，意思就是返回一個planB，返回一個咱們本身定義好的提示。

而爲何要使用服務降級，這是防止分佈式服務發生雪崩效應，什麼是雪崩？就是蝴蝶效應，當一個請求發生超時，一直等待着服務響應，那麼在高併發狀況下，不少請求都是由於這樣一直等着響應，直到服務資源耗盡產生宕機，而宕機以後會致使分佈式其餘服務調用該宕機的服務也會出現資源耗盡宕機，這樣下去將致使整個分佈式服務都癱瘓，這就是雪崩。若是你要問爲何不作集羣？集羣固然作，可是一臺服務宕機以後，其餘流量分發到其餘集羣機器上，壓力也會隨之加大，時間久了整個集羣也會垮了，這只是個時間問題。爲了防止產生了雪崩效應那麼就該對服務配置降級，一旦請求超過規定時間當即返回自定義好的提示，無需繼續等待。

     幾種服務降級方式：

• 服務接口拒絕服務：無用戶特定信息，頁面能訪問，可是添加刪除提示服務器繁忙。頁面內容也可在CDN內獲取。
• 頁面拒絕服務：頁面提示因爲服務繁忙此服務暫停。跳轉到nginx的一個靜態頁面。
•  延遲持久化：頁面訪問照常，可是涉及記錄變動，會提示稍晚能看到結果，將數據記錄到異步隊列或log，服務恢復後執行。
•  隨機拒絕服務：服務接口隨機拒絕服務，讓用戶重試，目前較少有人採用。由於用戶體驗不佳。

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------