第一章 基礎知識

什麼是微服務架構？

　　微服務架構其實是一種設計風格，它的核心主旨是將一個獨立的系統拆分爲一個個的小型服務，每一個小服務在各自的進程中運行，服務之間經過基於HTTP協議的restful API進行通訊合做。各個小服務都圍繞系統中的某一個或某一項耦合度較高的業務功能進行部署，每一個小服務都維護自身的開發和部署機制。

 

與單體系統的區別

　　在傳統的企業中，針對一些複雜的業務功能一般使用對象或業務類來構建一個單體項目。在項目中，一般將業務需求分爲：數據庫、服務端處理、前端展示。在發展初期，全部的業務功能在一個項目中，部署發佈都還比較簡單。隨着企業的發展，業務需求不斷的擴張，不斷的爲該項目增長業務模塊；同時隨着移動端的發展，後端的接口須要提供更多的接口來知足不一樣的展示形式。此時，單體項目變得愈來愈臃腫，愈來愈很差維護，每每修改了一個很小的功能就會影響其餘的業務功能運行。隨着這些問題的出現，微服務架構的做用逐漸凸顯出來，將不一樣的業務功能模塊拆分爲不一樣的服務，每一個服務之間獨立運行，一個業務功能的修改不會影響其餘服務的運行，並且還能更爲準確的定位爲題，爲每一個服務評估性能容量等。

 

如何實施微服務

　　通過多年的發展，Martion Fowler在Microservices一文中，提煉出了微服務的九大特性，用於指導你們設計架構。

 

服務組件化

　　組件是一個能夠獨立更換和升級的單元。在微架構中，須要對服務進行組件化的分解。服務，是一種進程外的組件，它經過HTTP協議等進行協做，而不像傳統組件同樣以嵌入的方式進行協做。每一個服務都是獨立運行和部署，有效的避免了因一個服務的修改致使整個項目從新部署的局面。

 

按業務組織團隊

　　當決定要劃分微服務時，每每還須要對業務團隊進行從新規劃和組織。按照以往的方式，咱們會將業務團隊分爲DBA、運維、後端、前端等，若是咱們繼續按照這種方式，那麼一個小小的改動可能會讓整個團隊都參與進來，增長了時間消耗和預算。好比：須要在數據庫增長一個字段，須要從數據庫到前端全面的修改。

　　因此，在進行微架構時，須要按照不一樣的方式劃分。因爲每一個微服務都是針對特定的業務進行全棧操做。所以建議對微服務的團隊也按照業務線進行劃分。

 

作「產品」的態度

　　在實施微服務的每一個小團隊中，都要以作產品的方式，對其產品的整個生命週期負責，而不是像作項目同樣，以開發和交付成果爲最終目的。

 

智能端點與啞管道

　　在單體應用中，組件間直接經過函數調用的方式進行交互協做。而在「微服務」架構中，服務因爲不在一個進程中，組件間的通訊模式發生了改變，若僅僅將本來在進程內的方法調用改爲RPC方式的調用，會致使微服務之間產生繁瑣的通訊，使得系統表現更爲糟糕，因此，咱們須要更粗粒度的通訊協議。

　　在「微服務」架構中，一般會使用這兩個服務調用方式：

• 第一種，使用HTTP協議的RESTful API或輕量級的消息發送協議，來實現信息傳遞與服務調用的觸發。
• 第二種，經過在輕量級消息總線上傳遞消息，相似RabbitMQ等一些提供可靠異步交換的結構。

 

去中心化治理

　　在採用集中化的結構去治理方案時，一般會在平臺上指定統一的標準以知足不一樣的平臺，但不一樣平臺都有其短板，當彙集在一塊兒時有可能會形成一些瓶頸問題，採用微架構處理時就沒必要擔憂這些問題，每一個服務都是輕量級的，能夠根據不一樣的服務採用不一樣的技術平臺，不會形成濫用的狀況。

 

去中心化管理數據

　　在微架構中，每一個服務都獨自管理其自有的數據庫，這就是數據管理的去中心化。

　　在去中心化的過程當中，咱們除了將原數據庫中的存儲內容拆分到新的平臺的其餘數據庫中（如將本來存儲在MySQL中的表拆分後，存儲到多個不一樣的MySQL實例中），也能夠將一些具備特殊結構或業務特性的數據存儲到一些其餘技術的數據庫中（如：把日誌信息存儲到MongoDB中、把用戶登陸信息存儲到Redis中）。

　　雖然，數據管理的去中心化可讓數據管理更加細緻化，經過採用更合適的技術來讓數據存儲和性能達到最優。可是，因爲數據存儲於不一樣的數據庫實例中後，數據一致性也成爲「微服務」架構中急需解決的問題之一。分佈式事務的實現，自己難度就很是大，因此在「微服務」架構中，咱們更強調在各服務之間進行「無事務」的調用，而對於數據一致性，只要求數據在最後的處理狀態是一致的效果；若在過程當中發現錯誤，經過補償機制來進行處理，使得錯誤數據可以達到最終的一致性。

 

基礎設施自動化

　　近年來雲計算服務與容器化技術的不斷成熟，運維基礎設施的工做變得愈來愈不那麼難了。可是，當咱們實施「微服務」架構時，數據庫、應用程序的個頭雖然都變小了，可是由於拆分的緣由，數量成倍的增加。這使得運維人員須要關注的內容也成倍的增加，而且操做性任務也會成倍的增加，這些問題若沒有獲得妥善的解決，必將成爲運維人員的噩夢。

因此，在「微服務」架構中，請務必從一開始就構建起「持續交付」平臺來支撐整個實施過程，該平臺須要兩大內容，不可或缺：

• 自動化測試：每次部署前的強心劑，儘量的得到對正在運行軟件的信心。
• 自動化部署：解放繁瑣枯燥的重複操做以及對多環境的配置管理。

 

容錯設計

　　在單體應用中，通常不存在單個組件故障而其餘還在運行的狀況，一般是一掛全掛。而在「微服務」架構中，因爲服務都運行在獨立的進程中，因此是存在部分服務出現故障，而其餘服務都正常運行的狀況，好比：當正常運做的服務B調用到故障服務A時，因故障服務A沒有返回，線程掛起開始等待，直到超時才能釋放，而此時若觸發服務B調用服務A的請求來自服務C，而服務C頻繁調用服務B時，因爲其依賴服務A，大量線程被掛起等待，最後致使服務A也不能正常服務，這時就會出現故障的蔓延。

因此，在「微服務」架構中，快速的檢測出故障源並儘量的自動恢復服務是必需要被設計和考慮的。一般，咱們都但願在每一個服務中實現監控和日誌記錄的組件，好比：服務狀態、斷路器狀態、吞吐量、網絡延遲等關鍵數據的儀表盤等。

 

演進式設計

　　經過上面的幾點特徵，咱們已經可以體會到，要實施一個完美的「微服務」架構，須要考慮的設計與成本並不小，對於沒有足夠經驗的團隊來講，甚至要比單體應用發付出更多的代價。

因此，不少狀況下，架構師們都會以演進的方式進行系統的構建，在初期系統以單體系統的方式來設計和實施，一方面系統體量初期並不會很大，構建和維護成本都不高。另外一方面，初期的核心業務在後期一般也不會發生巨大的改變。隨着系統的發展或者業務的須要，架構師們會將一些常常變更或是有必定時間效應的內容進行「微服務」處理，並逐漸地將原來在單體系統中多變的模塊逐步拆分出來，而穩定不太變化的就造成了一個核心「微服務」存在於整個架構之中。

 

爲何選擇Spring Cloud

 

　　近幾年不少人對微架構的熱情很是高，可是回頭看微架構被說起也有不少年了。無數的架構師和開發者在實際項目中實踐該設計理念並付出了諸多的努力。同時也分享了在微架構服務中針對不一樣場景出現的各類問題的各類解決方案和開源框架。如：

服務治理：阿里巴巴開源的Dubbo和噹噹網在其基礎上擴展的DubboX、Netflix的Eureka、Apache的Consul等。

分佈式配置管理：百度的Disconf、Netflix的Archaius、360的Qconf、Spring Cloud的Config、淘寶的Diamond等。

…………

　　Spring Cloud不像上述框架一些只解決服務中的某一個問題，而是一個解決微服務架構實施的綜合性框架。

 

Spring Cloud簡介

 

　　spring cloud是一個基於spring boot實現的微服務架構開發工具。它爲微服務架構中涉及的配置管理、服務治理、斷路器、智能路由、微代理、控制總線、全局鎖、決策競選、分佈式回話和集羣狀態管理等操做提供了一種簡單的開發方式。

Spring Cloud包含了多個子項目，以下所述：

• Spring Cloud Config：配置管理工具，支持使用Git存儲配置內容，可使用它實現應用配置的外部化存儲，並支持客戶端配置信息刷新、加密/解密配置內容等。
• Spring Cloud Netflix：核心組件，對多個Netflix OSS開源套件進行整合。

1. Eureka：服務治理組件，包含服務註冊中心、服務註冊與發現機制的實現。
2. Hystrix：容錯管理組件，實現斷路器模式，幫助服務依賴中出現的延遲和爲故障提供強大的容錯能力。
3. Ribbon：客戶端負載均衡的服務調用組件。
4. Feign：基於Ribbon和Hystrix的聲明式調用組件。
5. Zull：網關組件，提供智能路由、訪問過濾等功能。
6. Archaius：外部化配置組件。

• Spring Cloud Bus：事件、消息總線，用於傳播集羣中的狀態變化或事件，以觸發後續的處理，好比用來動態刷新配置等。
• Spring Cloud Cluster：針對Zookeeper、Redis、Hazelcast、Consul的選舉算法和通用狀態模式的實現。
• Spring Cloud Cloudfoundry：與Pivotal Cloudfoundry的整合支持。
• Spring Cloud Consul：服務發現與配置管理工具。
• Spring CLoud Stream：經過Redis、Rabbit或者Kafka實現的消費微服務，能夠經過簡單的聲明式模型來發送和接收消息。
• Spring Cloud AWS：用於簡化整合Amazon Web Service的組件。
• Spring Cloud Security：安全工具包，提供在Zuul代理中對OAuth2客戶端請求的中斷器。
• Spring Cloud Sleuth：Spring Cloud應用的分佈式跟蹤實現，能夠完美整合Zipkin。
• Spring Cloud Zookeeper：基於Zookeeper的服務發現與配置管理組件。
• Spring Cloud Starters：Spring Cloud的基礎組件，它是基於Spring Boot風格項目的基礎依賴模塊。
• Spring Cloud CLI：用於在Groovy中快速建立Spring Cloud應用的Spring Boot CLI插件
• …………

 

版本說明

版本名與版本號

　　因爲Spring Cloud不像Spring社區其餘一些項目那樣相對獨立，它是一個擁有諸多子項目的大型綜合項目，其包含的各個子項目也都獨立進行內容更新和迭代，各自都維護着本身的發佈版本號。所以每個Spring Cloud的版本都包含多個不一樣版本的子項目，爲了管理每一個版本的子項目清單，避免Spring Cloud的版本號與其子項目的版本號相混淆，沒有采用版本號的方式，而是經過命名的方式。

　　這些版本的名字採用了倫敦地鐵站的名字，根據字母表的順序來對應版本時間順序，好比最先的Release版本爲Angel，第二個Release版本爲Brixton……

　　當一個版本的Spring Cloud項目的發佈內容積累到臨界點或者一個嚴重bug解決可用後，就會發佈一個「service release」版本，簡稱SRX版本，其中X是一個遞增的數字，因此Brixton.SR5就是Rrixton的第5個Release版本。

 

版本區別

 

　　從上圖可知，Angel擁有的子項目較少，Brixton、Camden擁有更全的子項目，而Brixton的發佈子項目更爲穩定且包含了大部分的Spring Cloud子項目，因此後續的示例以及講解內容都採用Brixton.SR5版本，基於Spring boot 1.3.7以上版本。