聊一聊微服務元件區別

1、建立一個訂單之後，如果使用者立刻支付了這個訂單，我們需要將訂單狀態更新為“已支付”

2、扣減相應的商品庫存

3、通知倉儲中心，進行發貨

4、給使用者的這次購物增加相應的積分

如上，微服務的應用場景和核心競爭力：

 

降低耦合：每一個微服務專注於單一功能，並通過定義良好的介面清晰表述服務邊界。由於體積小、複雜度低，每個微服務可由一個小規模開發團隊完全掌控，易於保持高可維護性和開發效率。

 

獨立部署：由於微服務具備獨立的執行程式，所以每個微服務也可以獨立部署。當某個微服務發生變更時無需編譯、部署整個應用。由微服務組成的應用相當於具備一系列可並行的釋出流程，使得釋出更加高效，同時降低對生產環境所造成的風險，最終縮短應用交付週期。

 

選型靈活：微服務架構下，技術選型是去中心化的。每個團隊可以根據自身服務的需求和行業發展的現狀，自由選擇最適合的技術棧。由於每個微服務相對簡單，故需要對技術棧進行升級時所面臨的風險就較低，甚至完全重構一個微服務也是可行的。

 

容錯機制：當某一組建發生故障時，在單一程式的傳統架構下，故障很有可能在程式內擴散，形成應用全域性性的不可用。在微服務架構下，故障會被隔離在單個服務中。若設計良好，其他服務可通過重試、平穩退化等機制實現應用層面的容錯。

 

靈活擴充套件：單塊架構應用也可以實現橫向擴充套件，就是將整個應用完整的複製到不同的節點。當應用的不同元件在擴充套件需求上存在差異時，微服務架構便體現出其靈活性，因為每個服務可以根據實際需求獨立進行擴充套件。

 

Dubbo對標Spring Cloud微服務

 

背景分析：Dubbo，是阿里巴巴服務化治理的核心框架，並被廣泛應用於中國各網際網路公司；Spring Cloud是知名的Spring家族的產品。阿里巴巴是一個商業公司，雖然也開源了很多的頂級的專案，但從整體戰略上來講，仍然是服務於自身的業務為主。Spring專注於企業級開源框架的研發，不論是在中國還是在世界上使用都非常廣泛，開發出通用、開源、穩健的開源框架就是他們的主業。

 

活躍度對比：Dubbo是一個非常優秀的服務治理框架，並且在服務治理、灰度釋出、流量分發這方面做的比Spring Cloud還好，除過當當網在基礎上增加了rest支援外，已有兩年多的時間幾乎都沒有任何更新了。在使用過程中出現問題，提交到GitHub的Issue也少有回覆。相反Spring Cloud自從發展到現在，仍然在不斷的高速發展，從GitHub上提交程式碼的頻度和釋出版本的時間間隔就可以看出，現在Spring Cloud即將釋出2.0版本，到了後期會更加完善和穩定。

 

平臺架構：Dubbo框架只是專注於服務之間的治理，如果我們需要使用配置中心、分散式跟蹤這些內容都需要自己去整合，這樣無形中使用Dubbo的難度就會增加。Spring Cloud幾乎考慮了服務治理的方方面面，更有Spring Boot這個大將的支援，開發起來非常的便利和簡單。

 

技術前景：Dubbo在各中小公司也從中受益不少。經過了這麼多年的發展，網際網路行業也是湧現了更多先進的技術和理念，Dubbo有點可惜。Spring 推出Spring Boot/Cloud也是因為自身的很多原因。

 

Spring最初推崇的輕量級框架，隨著不斷的發展也越來越龐大，隨著整合專案越來越多，配置檔案也越來越混亂，慢慢的背離最初的理念。隨著這麼多年的發展，微服務、分散式鏈路跟蹤等更多新的技術理念的出現，Spring急需一款框架來改善以前的開發模式，因此才會出現Spring Boot/Cloud專案，我們現在訪問Spring官網，會發現Spring Boot和Spring Cloud已經放到首頁最重點突出的三個專案中的前兩個，可見Spring對這兩個框架的重視程度。Dubbo實現如下：

 

Spring Cloud實現思路

Eureka

 

原理：主管服務註冊與發現，也就是微服務的名稱註冊到Eureka，就可以通過Eureka找到微服務，而不需要修改服務呼叫的配置檔案。

 

分析：Spring Cloud封裝了Netflix公司開發的Eureka模組來實現服務的註冊與發現，採用的c-s的設計架構，Eureka Server作為服務註冊功能的伺服器，他是服務註冊中心。而系統的其他微服務，使用Eureka的客戶端連線到Eureka Server並維持心跳。這樣系統的維護人員可以通過Eureka Server來監控系統中的各個微服務是否正常執行。Spring Cloud的一些其他模組（比如Zuul）就可以通過Eureka Server來發現系統其他的微服務，並執行相關邏輯。

 

Eureka Server

 

Eureka Server提供服務註冊服務，各個節點啟動後，會在Eureka Server中進行註冊， 這樣Eureka Server中的服務登錄檔中將會儲存所有可用服務節點的資訊，服務節點的資訊可以在介面中直觀的看到。

 

Eureka Client

 

Eureka Client是一個Java客戶端， 用於簡化Eureka Server的互動，客戶端同時也具備一個內建的、 使用輪詢（round-robin）負載演算法的負載均衡器。在應用啟動後，將會向Eureka Server傳送心跳（預設週期為30秒），以證明當前服務是可用狀態。如果Eureka Server在一定的時間（預設90秒）未收到客戶端的心跳，Eureka Server將會從服務登錄檔中把這個服務節點移除。

 

Eureka Server的自我保護機制

 

如果在15分鐘內超過85%的節點都沒有正常的心跳，那麼Eureka就認為客戶端與註冊中心出現了網路故障，此時會出現以下幾種情況：

Eureka不再從註冊列表中移除因為長時間沒收到心跳而應該過期的服務

Eureka仍然能夠接受新服務的註冊和查詢請求，但是不會被同步到其它節點上（即保證當前節點依然可用）

當網路穩定時，當前例項新的註冊資訊會被同步到其它節點中

因此， Eureka可以很好的應對因網路故障導致部分節點失去聯絡的情況，而不會像ZooKeeper那樣使整個註冊服務癱瘓。

 

Eureka和ZooKeeper

 

著名的CAP理論指出，一個分散式系統不可能同時滿足C（一致性）、A（可用性）和P（分割槽容錯性）。由於分割槽容錯性在是分散式系統中必須要保證的，因此我們只能在A和C之間進行權衡。

 

ZooKeeper保證CP

 

當向註冊中心查詢服務列表時，我們可以容忍註冊中心返回的是幾分鐘以前的註冊資訊，但不能接受服務直接down掉不可用。也就是說，服務註冊功能對可用性的要求要高於一致性。但是ZooKeeper會出現這樣一種情況，當Master節點因為網路故障與其他節點失去聯絡時，剩餘節點會重新進行leader選舉。

 

問題在於，選舉leader的時間太長，30 ~ 120s，且選舉期間整個ZooKeeper叢集都是不可用的，這就導致在選舉期間註冊服務癱瘓。在雲部署的環境下，因網路問題使得ZooKeeper叢集失去Master節點是較大概率會發生的事，雖然服務能夠最終恢復，但是漫長的選舉時間導致的註冊長期不可用是不能容忍的。

 

Eureka保證AP

 

Eurek在設計時就優先保證可用性。Eureka各個節點都是平等的，幾個節點掛掉不會影響正常節點的工作，剩餘的節點依然可以提供註冊和查詢服務。而Eureka的客戶端在向某個Eureka註冊或時如果發現連線失敗，則會自動切換至其它節點，只要有一臺Eureka還在，就能保證註冊服務可用（保證可用性），只不過查到的資訊可能不是最新的（不保證強一致性）。

除此之外，Eureka還有一種自我保護機制，見上。

 

總結

 

Eureka可以很好的應對因網路故障導致部分節點失去聯絡的情況，而不會像ZooKeeper那樣使整個註冊服務癱瘓。

 

Eureka作為單純的服務註冊中心來說要比ZooKeeper更加“專業”，因為註冊服務更重要的是可用性，我們可以接受短期內達不到一致性的狀況。

Ribbon和Feign

 

在微服務架構中，業務都會被拆分成一個獨立的服務，服務與服務的通訊是基於HTTP RESTful的。Spring Cloud有兩種服務呼叫方式，一種是Ribbon+RestTemplate，另一種是Feign。

 

概念

 

基於Netflix Ribbon用過輪詢策略實現的一套客戶端負載均衡的工具。

客戶端負載均衡：負載均衡Zuul閘道器將一個請求傳送給某一個服務的應用的時候，如果一個服務啟動了多個例項，就會通過Ribbon來通過一定的負載均衡策略來傳送給某一一個服務例項。Spring Cloud中的Ribbon，客戶端會有一個伺服器地址列表，在傳送請求前通過負載均衡演算法（如簡單輪詢，隨機連線等）選擇一個伺服器，然後進行訪問。

 

負載均衡

 

負載均衡：用於將工作負載分佈到多個伺服器來提高網站、應用、資料庫或其他服務的效能和可靠性。

 

使用負載均衡帶來的好處很明顯：當叢集裡的1臺或者多臺伺服器down的時候，剩餘的沒有down的伺服器可以保證服務的繼續使用；將訪問壓力分配到各個伺服器，不會由於某一高峰時刻導致系統cpu急劇上升。

 

負載均衡有好幾種實現策略，常見的有：隨機（Random），輪詢（RoundRobin），一致性雜湊（ConsistentHash），雜湊（Hash），加權（Weighted）

 

Ribbon的預設策略是輪詢

 

RestTemplate

 

傳統情況下在Java程式碼裡訪問RESTful服務，一般使用Apache的HttpClient，不過此種方法使用起來太過繁瑣。Spring提供了一種簡單便捷的模板類來進行操作，這就是RestTemplate。

 

Feign是一個宣告式http客戶端。使用Feign能讓編寫http客戶端更加簡單，它的使用方法是定義一個介面，然後在上面新增註解，避免了呼叫目標微服務時，需要不斷的解析/封裝json資料的繁瑣。Spring Cloud中Feign預設整合了Ribbon，並和Eureka結合，預設實現了負載均衡的效果。

 

Ribbon和Feign的區別

 

Feign目標使編寫Java Http客戶端變得更容易

在使用Ribbon+ RestTemplate時，Ribbon需要自己構建http請求，模擬http請求然後使用RestTemplate傳送給其他服務，步驟相當繁瑣。利用RestTemplate對http請求的封裝處理，形成了-套模版化的呼叫方法。但是在實際開發中，由於對服務依賴的呼叫可能不止一處,往往一個介面會被多處呼叫，所以通常都會針對每個微服務自行封裝一些客戶端類來包裝這些依賴服務的呼叫。所以，Feign在此基礎上做了進一步封裝，由他來幫助我們定義和實現依賴服務介面的定義。

 

在Feign的實現下，我們只需建立一個介面並使用註解的方式來配置它（以前是Dao介面上面標註Mapper註解，現在是一個微服務介面上面標註一個Feign註解即可）， 即可完成對服務提供方的介面繫結，簡化了使用Spring Cloud Ribbon時，自動封裝服務呼叫客戶端的開發量。

 

Feign整合了Ribbon

 

Ribbon通過輪詢實現了客戶端的負載均衡，而與Ribbon不同的是，Feign是一個宣告式的Web服務客戶端， 使得編寫Web服務客戶端變得非常容易，只需要建立一個介面， 然後在上面新增註解，像呼叫本地方法一樣呼叫它就可以，而感覺不到是呼叫遠端方法。SpringCloud中Feign預設整合了Ribbon，並和Eureka結合，預設實現了負載均衡的效果。

 

Ribbon和Nginx的區別

 

Nginx是客戶端所有請求統一交給Nginx，由Nginx進行實現負載均衡請求轉發，屬於伺服器端負載均衡。既請求由Nginx伺服器端進行轉發。客戶端負載均衡Ribbon，Ribbon是從Eureka註冊中心伺服器端上獲取服務註冊資訊列表，快取到本地，然後在本地實現輪詢負載均衡策略。既在客戶端實現負載均衡。

 

應用場景的區別

 

Nginx適合於伺服器端實現負載均衡，比如：Tomcat，Ribbon適合與在微服務中RPC遠端呼叫實現本地服務負載均衡，比如：Dubbo、Spring Cloud中都是採用本地負載均衡。

 

Zuul

 

應用場景

 

假如當前有十幾個微服務服務，訂單，商品，使用者等等，顯然是客戶端不需要和每個服務逐一打交道，這就需要有一個統一入口，它就是服務閘道器。API閘道器所有的客戶端請求通過這個閘道器訪問後臺的服務。他可以使用一定的路由配置來判斷某一個URL由哪個服務來處理。並從Eureka獲取註冊的服務來轉發請求。

 

核心功能

 

Zuul包含了對請求的路由和過濾兩個最主要的功能，是各種服務的統一入口，同時還會用來提供監控、授權、安全、排程等等。

 

路由功能：負責將外部請求轉發到具體的微服務例項上，是實現外部訪問統一入口的基礎。

 

過濾器功能：則負責對請求的處理過程進行干預，是實現請求校驗、服務聚合等功能的基礎。

 

Zuul和Eureka進行整合：將Zuul自身註冊為Eureka服務治理下的應用，同時從Eureka中獲得其他微服務的訊息,也即以後的訪問微服務都是通過Zuul跳轉後獲得。

 

注意：Zuul服務最終還是會註冊進Eureka，提供代理+路由+過濾三大功能。

 

核心原理

 

Zuul的核心是一系列的filters，其作用可以類比Servlet框架的Filter，或者AOP。

 

過濾器之間沒有直接進行通訊,而是通過Request Context（上下文）進行資料傳遞。

 

Zuul的過濾器是由Groovy寫成，這些過濾器檔案被放在Zuul Server上的特定目錄下面，Zuul會定期輪詢這些目錄，修改過的過濾器會動態的載入到Zuul Server中以便過濾請求使用。

 

Zuul負載均衡：Zuul攔截對應的API字首請求做轉發，轉發到對應的serverId上，在Eureka服務上同一個serverId可以對應多個服務，也就是說用同一個服務節點不同的埠註冊兩個例項，但是serverId是一樣Zuul做轉發的時候會結合eureka-server起到負載均衡的效果。

 

過濾器的種類

 

PRE（前置）：這種過濾器在請求被路由之前呼叫。我們可利用這種過濾器實現鑑權、限流、引數校驗調整等。

ROUTING（路由）：這種過濾器將請求路由到微服務。這種過濾器用於構建傳送給微服務的請求，並使用Apache HttpClient或Netfilx Ribbon請求微服務。

POST（後置）：這種過濾器在路由到微服務以後執行。這種過濾器可用來為響應新增標準的HTTP Header、收集統計資訊和指標、將響應從微服務傳送給客戶端、日誌等。

ERROR（錯誤）：在其他階段發生錯誤時執行該過濾器。

 

Zuul和Nginx

 

Zuul雖然在效能上和Nginx沒法比，但它也有它的優點。Zuul提供了認證鑑權，動態路由，監控，彈性，安全，負載均衡等邊緣服務，在團隊規模不大的情況下，沒有專門負責路由開發時，使用Zuul當閘道器是一個快速上手的好方案。

Nginx和Zuul是可以配合使用的，發揮各自的優點，使用Nginx作為負載均衡實現高併發的請求轉發，Zuul用作閘道器。

 

Zuul和Ribbon實現負載均衡

 

Zuul支援Ribbon和Hystrix，也能夠實現客戶端的負載均衡。我們的Feign不也是實現客戶端的負載均衡和Hystrix的嗎？既然Zuul已經能夠實現了，那我們的Feign還有必要嗎？

 

可以這樣理解：

Zuul是對外暴露的唯一介面相當於路由的是controller的請求，而Ribbonhe和Fegin路由了service的請求。

Zuul做最外層請求的負載均衡，而Ribbon和Fegin做的是系統內部各個微服務的service的呼叫的負載均衡。

 

Hystrix

 

介紹

Hystrix是一個用於處理分散式系統的延遲和容錯的開源庫,在分散式系統裡,許多依賴不可避兔的會呼叫失敗，比如超時、異常等，Hystrix能夠保證在一個依賴出問題的情況下，不會導致整體服務失敗，避免級聯故障，以提高分散式系統的彈性。Hystrix的出現就是為了解決雪崩效應。

 

服務雪崩

 

多個微服務之間呼叫的時候，假設微服務A呼叫微服務B和微服務C,微服務B和微服務C又呼叫其它的微服務，這就是所謂的“扇出”。如果扇出的鏈路上某個微服務的呼叫響應時間過長或者不可用，對微服務A的呼叫就會佔用越來越多的系統資源，進而引起系統崩潰，所謂的”雪崩效應”。

 

服務熔斷

 

熔斷機制是應對雪崩效應的一種微服務鏈路保護機制。

當刪除鏈路的某個微服務不可用或者響應時間太長時，會進行服務的降級，進而熔斷該節點微服務的呼叫，快速返回”錯誤的響應資訊。當檢測到該節點微服務呼叫響應正常後恢復呼叫鏈路。在SpringCloud框架裡熔斷機制通過Hystrix實現。Hystrix會監控微服務間呼叫的狀況，當失敗的呼叫到一定閾值,預設是5秒內20次呼叫失敗就會啟動熔斷機制。熔斷機制的註解是@HystrixCommand。

 

服務降級

 

整體資源快不夠了，忍痛將某些服務先關掉，待渡過難關，再開啟回來。

 

Hystrix監控和斷路器

 

我們只需要在服務介面上新增Hystrix標籤，就可以實現對這個介面的監控和斷路器功能。

Hystrix Dashboard監控皮膚，提供了一個介面，可以監控各個服務上的服務呼叫所消耗的時間等。

 

Hystrix Turbine監控聚合

 

使用Hystrix監控，我們需要開啟每一個服務例項的監控資訊來檢視。而Turbine可以幫助我們把所有的服務例項的監控資訊聚合到一個地方統檢視。這樣就不需要挨個開啟一個個的頁面一個個檢視。

 

Zuul的安全機制

 

簽名機制，為防止介面資料篡改和重複呼叫，增加介面引數校驗機制，sig簽名演算法為MD5（appKey+appSecret+timestamp），appKey是分配給客戶端的ID，appSecret是分配給客戶端的金鑰，timestamp為unix時間戳，請求的URL有效時間為15分鐘。

 

Token機制，使用者在登入之後會返回一個access_ token，客戶端在訪問需要登入之後才能訪問的資源，需要在在Authorization頭部使用Bearer模式新增token，如head(“Authorization”,” Bearer token”)。

 

Hystrix的設計原則

 

資源隔離（執行緒池隔離和訊號量隔離）機制：限制呼叫分散式服務的資源使用，某一個呼叫的服務出現問題不會影響其它服務呼叫。

 

限流機制：限流機制主要是提前對各個型別的請求設定最高的QPS閾值，若高於設定的閾值則對該請求直接返回，不再呼叫後續資源。

 

熔斷機制：當失敗率達到閥值自動觸發降級（如因網路故障、超時造成的失敗率真高），熔斷器觸發的快速失敗會進行快速恢復。

 

降級機制：超時降級、資源不足時（執行緒或訊號量）降級、執行異常降級等，降級後可以配合降級介面返回託底資料。

 

快取支援：提供了請求快取、請求合併實現。

通過近實時的統計/監控/報警功能，來提高故障發現的速度。

通過近實時的屬性和配置熱修改功能，來提高故障處理和恢復的速度。

 

Config

 

介紹

 

Spring Cloud Config是一個解決分散式系統的配置管理方案。微服務意味著要將單體應用中的業務拆分成一個個子服務，每個服務的粒度相對較小，因此係統 中會出現大量的服務。由於每個服務都需要必要的配置資訊才能執行，所以一套集中式的、 動態的配置管理設施是必不可少的。Spring Cloud提供了ConfigServer來解決這個問題,我們每一個微服務自 己帶著一個application.yml 上百個配置檔案的管理。

 

應用場景

 

不方便維護，多人同時對配置檔案進行修改，衝突不斷，很難維護

配置內容安全和許可權，主要是針對線上的配置來說，一般不對開發公開，只有運維有許可權所以需要將配置檔案隔離，不放到專案程式碼裡

更新配置專案需要重啟，每次更新配置檔案都需要重啟專案，很耗時。使用了配置中心後，即可實現配置實時更新congfig Server和Config Client結合Spring Cloud Bus實現配置自動重新整理。

 

原理

 

配置檔案儲存在遠端Git（比如GitHub，Gitee等倉庫），config-server從遠端Git拉取配置檔案，並儲存到本地Git。

本地Git和config-server的互動是雙向的，因為當遠端Git無法訪問時，會從本地Git獲取配置檔案。

config-client（即各個微服務），從config-server拉取配置檔案。

 

角色

 

Config Server：提供配置檔案的儲存、以介面的形式將配置檔案的內容提供出去。

Config Client：通過介面獲取資料、並依據此資料初始化自己的應用。