Spring Cloud微服務全家桶主要組件及簡要介紹

1、微服務簡介

微服務是最近的一兩年的時間裏是很火的一個概念。感受不學習一下都快跟不上時代的步伐了，下邊作一下簡單的總結和介紹。

何爲微服務？簡而言之，微服務架構風格這種開發方法，是以開發一組小型服務的方式來開發一個獨立的應用系統的。其中每一個小型服務都運行在本身的進程中，並常常採用HTTP資源API這樣輕量的機制來相互通訊。這些服務圍繞業務功能進行構建，並能經過全自動的部署機制來進行獨立部署。這些微服務可使用不一樣的語言來編寫，而且可使用不一樣的數據存儲技術。對這些微服務咱們僅作最低限度的集中管理。

一個微服務通常完成某個特定的功能，好比下單管理、客戶管理等等。每個微服務都是微型六角形應用，都有本身的業務邏輯和適配器。一些微服務還會發布API給其它微服務和應用客戶端使用。其它微服務完成一個Web UI，運行時，每個實例多是一個雲VM或者是Docker容器。

好比，一個前面描述系統可能的分解以下：

總的來講，微服務的主旨是將一個本來獨立的系統拆分紅多個小型服務，這些小型服務都在各自獨立的進程中運行，服務之間經過基於HTTP的RESTful API進行通訊協做，而且每一個服務都維護着自身的數據存儲、業務開發、自動化測試以及獨立部署機制。

2、微服務的特徵

一、每一個微服務可獨立運行在本身的進程裏；

二、一系列獨立運行的微服務共同構建起了整個系統；

三、每一個服務爲獨立的業務開發，一個微服務通常完成某個特定的功能，好比：訂單管理、用戶管理等；

四、微服務之間經過一些輕量的通訊機制進行通訊，例如經過REST API或者RPC的方式進行調用。

3、微服務的優缺點

一、易於開發和維護

二、啓動較快

三、局部修改容易部署

四、技術棧不受限

五、按需伸縮

六、DevOps

4、常見微服務框架

一、服務治理框架

（1）Dubbo（http://dubbo.io/）、Dubbox（噹噹網對Dubbo的擴展）

最近的好消息是Dubbo已近從新開始進行運維啦！

（2）Netflix的Eureka、Apache的Consul等。

spring Cloud Eureka是對Netflix的Eureka的進一步封裝。

二、分佈式配置管理

（1）百度的Disconf

（2）360的QConf

（3）Spring Cloud組件中的Config

（3）淘寶的Diamond

三、批量任務框架

（1）Spring Cloud組件中的Task

（2）LTS

5、Spring Cloud全家桶組件

在介紹Spring Cloud 全家桶以前，首先要介紹一下Netflix ，Netflix 是一個很偉大的公司，在Spring Cloud項目中佔着重要的做用，Netflix 公司提供了包括Eureka、Hystrix、Zuul、Archaius等在內的不少組件，在微服務架構中相當重要，Spring在Netflix 的基礎上，封裝了一系列的組件，命名爲：Spring Cloud Eureka、Spring Cloud Hystrix、Spring Cloud Zuul等，下邊對各個組件進行分別得介紹：

（1）Spring Cloud Eureka

咱們使用微服務，微服務的本質仍是各類API接口的調用，那麼咱們怎麼產生這些接口、產生了這些接口以後如何進行調用那？如何進行管理哪？

答案就是Spring Cloud Eureka，咱們能夠將本身定義的API 接口註冊到Spring Cloud Eureka上，Eureka負責服務的註冊於發現，若是學習過Zookeeper的話，就能夠很好的理解，Eureka的角色和 Zookeeper的角色差很少，都是服務的註冊和發現，構成Eureka體系的包括：服務註冊中心、服務提供者、服務消費者。

上圖中描述了（圖片來源於網絡）：

一、兩臺Eureka服務註冊中心構成的服務註冊中心的主從複製集羣；

二、而後服務提供者向註冊中心進行註冊、續約、下線服務等；

三、服務消費者向Eureka註冊中心拉去服務列表並維護在本地（這也是客戶端發現模式的機制體現！）；

四、而後服務消費者根據從Eureka服務註冊中心獲取的服務列表選取一個服務提供者進行消費服務。

（2）Spring Cloud Ribbon

在上Spring Cloud Eureka描述了服務如何進行註冊，註冊到哪裏，服務消費者如何獲取服務生產者的服務信息，可是Eureka只是維護了服務生產者、註冊中心、服務消費者三者之間的關係，真正的服務消費者調用服務生產者提供的數據是經過Spring Cloud Ribbon來實現的。

在（1）中提到了服務消費者是將服務從註冊中心獲取服務生產者的服務列表並維護在本地的，這種客戶端發現模式的方式是服務消費者選擇合適的節點進行訪問服務生產者提供的數據，這種選擇合適節點的過程就是Spring Cloud Ribbon完成的。

Spring Cloud Ribbon客戶端負載均衡器由此而來。

（3）Spring Cloud Feign

上述（1）、（2）中咱們已經使用最簡單的方式實現了服務的註冊發現和服務的調用操做，若是具體的使用Ribbon調用服務的話，你就能夠感覺到使用Ribbon的方式仍是有一些複雜，所以Spring Cloud Feign應運而生。

Spring Cloud Feign 是一個聲明web服務客戶端，這使得編寫Web服務客戶端更容易，使用Feign 建立一個接口並對它進行註解，它具備可插拔的註解支持包括Feign註解與JAX-RS註解，Feign還支持可插拔的編碼器與解碼器，Spring Cloud 增長了對 Spring MVC的註解，Spring Web 默認使用了HttpMessageConverters, Spring Cloud 集成 Ribbon 和 Eureka 提供的負載均衡的HTTP客戶端 Feign。

簡單的能夠理解爲：Spring Cloud Feign 的出現使得Eureka和Ribbon的使用更爲簡單。

（4）Spring Cloud Hystrix

咱們在（1）、（2）、（3）中知道了使用Eureka進行服務的註冊和發現，使用Ribbon實現服務的負載均衡調用，還知道了使用Feign能夠簡化咱們的編碼。可是，這些還不足以實現一個高可用的微服務架構。

例如：當有一個服務出現了故障，而服務的調用方不知道服務出現故障，若此時調用放的請求不斷的增長，最後就會等待出現故障的依賴方 相應造成任務的積壓，最終致使自身服務的癱瘓。

Spring Cloud Hystrix正是爲了解決這種狀況的，防止對某一故障服務持續進行訪問。Hystrix的含義是：斷路器，斷路器自己是一種開關裝置，用於咱們家庭的電路保護，防止電流的過載，當線路中有電器發生短路的時候，斷路器可以及時切換故障的電器，防止發生過載、發熱甚至起火等嚴重後果。

（5）Spring Cloud Config

對於微服務還不是不少的時候，各類服務的配置管理起來還相對簡單，可是當成百上千的微服務節點起來的時候，服務配置的管理變得會複雜起來。

分佈式系統中，因爲服務數量巨多，爲了方便服務配置文件統一管理，實時更新，因此須要分佈式配置中心組件。在Spring Cloud中，有分佈式配置中心組件Spring Cloud Config ，它支持配置服務放在配置服務的內存中（即本地），也支持放在遠程Git倉庫中。在Cpring Cloud Config 組件中，分兩個角色，一是Config Server，二是Config Client。

Config Server用於配置屬性的存儲，存儲的位置能夠爲Git倉庫、SVN倉庫、本地文件等，Config Client用於服務屬性的讀取。

（6）Spring Cloud Zuul

咱們使用Spring Cloud Netflix中的Eureka實現了服務註冊中心以及服務註冊與發現；而服務間經過Ribbon或Feign實現服務的消費以及均衡負載；經過Spring Cloud Config實現了應用多環境的外部化配置以及版本管理。爲了使得服務集羣更爲健壯，使用Hystrix的融斷機制來避免在微服務架構中個別服務出現異常時引發的故障蔓延。

先來講說這樣架構須要作的一些事兒以及存在的不足：

一、首先，破壞了服務無狀態特色。爲了保證對外服務的安全性，咱們須要實現對服務訪問的權限控制，而開放服務的權限控制機制將會貫穿並污染整個開放服務的業務邏輯，這會帶來的最直接問題是，破壞了服務集羣中REST API無狀態的特色。從具體開發和測試的角度來講，在工做中除了要考慮實際的業務邏輯以外，還須要額外可續對接口訪問的控制處理。

二、其次，沒法直接複用既有接口。當咱們須要對一個即有的集羣內訪問接口，實現外部服務訪問時，咱們不得不經過在原有接口上增長校驗邏輯，或增長一個代理調用來實現權限控制，沒法直接複用原有的接口。
面對相似上面的問題，咱們要如何解決呢？下面進入本文的正題：服務網關！

爲了解決上面這些問題，咱們須要將權限控制這樣的東西從咱們的服務單元中抽離出去，而最適合這些邏輯的地方就是處於對外訪問最前端的地方，咱們須要一個更強大一些的均衡負載器，它就是本文未來介紹的：服務網關。

服務網關是微服務架構中一個不可或缺的部分。經過服務網關統一貫外系統提供REST API的過程當中，除了具有服務路由、均衡負載功能以外，它還具有了權限控制等功能。Spring Cloud Netflix中的Zuul就擔任了這樣的一個角色，爲微服務架構提供了前門保護的做用，同時將權限控制這些較重的非業務邏輯內容遷移到服務路由層面，使得服務集羣主體可以具有更高的可複用性和可測試性。

（7）Spring Cloud Bus

在（5）Spring Cloud Config中，咱們知道的配置文件能夠經過Config Server存儲到Git等地方，經過Config Client進行讀取，可是咱們的配置文件不多是一直不變的，當咱們的配置文件放生變化的時候如何進行更新哪？

一種最簡單的方式從新一下Config Client進行從新獲取，但Spring Cloud絕對不會讓你這樣作的，Spring Cloud Bus正是提供一種操做使得咱們在不關閉服務的狀況下更新咱們的配置。

Spring Cloud Bus官方意義：消息總線。

固然動態更新服務配置只是消息總線的一個用處，還有不少其餘用處。

6、總結

Spring Cloud 的組件還不止這些，經過上邊的口水話的介紹，應該能夠大體有必定的瞭解，可是每個組件的功能遠不止上述介紹的那些，每個組件還有不少其餘的功能點，這裏的介紹但願可以帶你們入個門，不要對微服務這個這麼大的概念有所畏懼。

如何一塊兒學習，有沒有免費資料？

本文由博客一文多發平臺 OpenWrite 發佈！