SpringCloud微服務學習筆記

SpringCloud微服務學習筆記

項目地址： https://github.com/taoweidong/Micro-service-learning

單體架構(Monolithic架構)

Monolithic比較適合小項目

單體架構優勢：

• 開發簡單直接，集中式管理, 基本不會重複開發功能都在本地，沒有分佈式的管理開銷和調用開銷。

單體架構缺點：

• 開發效率低：全部的開發在一個項目改代碼，遞交代碼相互等待，代碼衝突不斷
• 代碼維護難：代碼功能耦合在一塊兒，新人不知道何從下手
• 部署不靈活：構建時間長，任何小修改必須從新構建整個項目，這個過程每每很長
• 穩定性不高：一個微不足道的小問題，能夠致使整個應用掛掉
• 擴展性不夠：沒法知足高併發狀況下的業務需求

微服務架構

​ 微服務是指開發一個單個小型的但有業務功能的服務，每一個服務都有本身的處理和輕量通信機制，能夠部署在單個或多個服務器上。微服務也指一種種鬆耦合的、有必定的有界上下文的面向服務架構。也就是說，若是每一個服務都要同時修改，那麼它們就不是微服務，由於它們緊耦合在一塊兒；若是你須要掌握一個服務太多的上下文場景使用條件，那麼它就是一個有上下文邊界的服務，這個定義來自DDD領域驅動設計。

​ 微服務架構模式（MicroservicesArchitecture Pattern）的目的是將大型的、複雜的、長期運行的應用程序構建爲一組相互配合的服務，每一個服務均可以很容易得局部改良。Micro這個詞意味着每一個服務都應該足夠小，可是，這裏的小不能用代碼量來比較，而應該是從業務邏輯上比較——符合SRP原則的才叫微服務。

相對於單體架構和SOA，它的主要特色是組件化、鬆耦合、自治、去中心化，體如今如下幾個方面：

• 一組小的服務
  服務粒度要小，而每一個服務是針對一個單一職責的業務能力的封裝，專一作好一件事情。
• 獨立部署運行和擴展
  每一個服務可以獨立被部署並運行在一個進程內。這種運行和部署方式可以賦予系統靈活的代碼組織方式和發佈節奏，使得快速交付和應對變化成爲可能。
• 獨立開發和演化
  技術選型靈活，不受遺留系統技術約束。合適的業務問題選擇合適的技術能夠獨立演化。服務與服務之間採起與語言無關的API進行集成。相對單體架構，微服務架構是更面向業務創新的一種架構模式。
• 獨立團隊和自治
  團隊對服務的整個生命週期負責，工做在獨立的上下文中，本身決策本身治理，而不須要統一的指揮中心。團隊和團隊之間經過鬆散的社區部落進行銜接。

​ 咱們能夠看到整個微服務的思想就如咱們如今面對信息爆炸、知識爆炸是同樣的：經過解耦咱們所作的事情，分而治之以減小沒必要要的損耗，使得整個複雜的系統和組織可以快速的應對變化。

微服務優勢

• 每一個微服務都很小，這樣能聚焦一個指定的業務功能或業務需求。
• 微服務可以被小團隊單獨開發，這個小團隊是2到5人的開發人員組成。
  
• 微服務是鬆耦合的，是有功能意義的服務，不管是在開發階段或部署階段都是獨立的。
  
• 微服務能使用不一樣的語言開發。
• 微服務容許容易且靈活的方式集成自動部署，經過持續集成工具，如Jenkins, bamboo 。
• 一個團隊的新成員可以更快投入生產。
• 微服務易於被一個開發人員理解，修改和維護，這樣小團隊可以更關注本身的工做成果。無需經過合做才能體現價值。
  
• 微服務容許你利用融合最新技術。
• 微服務只是業務邏輯的代碼，不會和HTML,CSS 或其餘界面組件混合。
• 微服務可以即時被要求擴展。
• 微服務能部署中低端配置的服務器上。
• 易於和第三方集成。
• 每一個微服務都有本身的存儲能力，能夠有本身的數據庫。也能夠有統一數據庫。

微服務架構的缺點

• 微服務架構可能帶來過多的操做。
• 須要DevOps技巧 (http://en.wikipedia.org/wiki/DevOps).
• 可能雙倍的努力。
• 分佈式系統可能複雜難以管理。
• 由於分佈部署跟蹤問題難。
• 當服務數量增長，管理複雜性增長。

技術介紹

服務註冊中心：Eureka

Eureka是Spring Cloud Netflix微服務套件中的一部分，能夠與Springboot構建的微服務很容易的整合起來。

Eureka包含了服務器端和客戶端組件。

服務器端，也被稱做是服務註冊中心，用於提供服務的註冊與發現。Eureka支持高可用的配置，當集羣中有分片出現故障時，Eureka就會轉入自動保護模式，它容許分片故障期間繼續提供服務的發現和註冊，當故障分片恢復正常時，集羣中其餘分片會把他們的狀態再次同步回來。

客戶端組件包含服務消費者與服務生產者。在應用程序運行時，Eureka客戶端向註冊中心註冊自身提供的服務並週期性的發送心跳來更新它的服務租約。同時也能夠從服務端查詢當前註冊的服務信息並把他們緩存到本地並週期性的刷新服務狀態。

參考：

https://www.cnblogs.com/demodashi/p/8509931.html

https://www.cnblogs.com/snowjeblog/p/8821325.html

做爲服務註冊中心，Eureka比Zookeeper好在哪裏

著名的CAP理論指出，一個分佈式系統不可能同時知足C(一致性)、A(可用性)和P(分區容錯性)。因爲分區容錯性在是分佈式系統中必需要保證的，所以咱們只能在A和C之間進行權衡。在此Zookeeper保證的是CP, 而Eureka則是AP。

Zookeeper保證CP

當向註冊中心查詢服務列表時，咱們能夠容忍註冊中心返回的是幾分鐘之前的註冊信息，但不能接受服務直接down掉不可用。也就是說，服務註冊功能對可用性的要求要高於一致性。可是zk會出現這樣一種狀況，當master節點由於網絡故障與其餘節點失去聯繫時，剩餘節點會從新進行leader選舉。問題在於，選舉leader的時間太長，30 ~ 120s, 且選舉期間整個zk集羣都是不可用的，這就致使在選舉期間註冊服務癱瘓。在雲部署的環境下，因網絡問題使得zk集羣失去master節點是較大機率會發生的事，雖然服務可以最終恢復，可是漫長的選舉時間致使的註冊長期不可用是不能容忍的。

Eureka保證AP

Eureka看明白了這一點，所以在設計時就優先保證可用性。Eureka各個節點都是平等的，幾個節點掛掉不會影響正常節點的工做，剩餘的節點依然能夠提供註冊和查詢服務。而Eureka的客戶端在向某個Eureka註冊或時若是發現鏈接失敗，則會自動切換至其它節點，只要有一臺Eureka還在，就能保證註冊服務可用(保證可用性)，只不過查到的信息可能不是最新的(不保證強一致性)。除此以外，Eureka還有一種自我保護機制，若是在15分鐘內超過85%的節點都沒有正常的心跳，那麼Eureka就認爲客戶端與註冊中心出現了網絡故障，此時會出現如下幾種狀況：

1. Eureka再也不從註冊列表中移除由於長時間沒收到心跳而應該過時的服務
2. Eureka仍然可以接受新服務的註冊和查詢請求，可是不會被同步到其它節點上(即保證當前節點依然可用)
3. 當網絡穩定時，當前實例新的註冊信息會被同步到其它節點中

所以， Eureka能夠很好的應對因網絡故障致使部分節點失去聯繫的狀況，而不會像zookeeper那樣使整個註冊服務癱瘓。

聲明式客戶端訪問：Fegin

​ Feign是一個聲明式的僞Http客戶端，它使得寫Http客戶端變得更簡單。使用Feign，只須要建立一個接口並用註解的方式來配置它，便可完成對服務提供方的接口綁定，簡化了在使用Ribbon時自行封裝服務調用客戶端的開發量。

​ Feign具備可插拔的註解特性，包括Feign 註解和JAX-RS註解，同時也擴展了對SpringMVC的註解支持。Feign支持可插拔的編碼器和解碼器，默認集成了Ribbon，並和Eureka結合，默認實現了負載均衡的效果。

主要功能：簡化服務消費者調用服務提供者接口

參考：https://www.cnblogs.com/senlinyang/p/8595489.html

客戶端負載均衡：Ribbon

​ Ribbon是Netflix發佈的負載均衡器，它有助於控制HTTP和TCP的客戶端的行爲。爲Ribbon配置服務提供者地址後，Ribbon就可基於某種負載均衡算法，自動地幫助服務消費者去請求。Ribbon默認爲咱們提供了不少負載均衡算法，例如輪詢、隨機等。固然，咱們也可爲Ribbon實現自定義的負載均衡算法。

​ 在Spring Cloud中，當Ribbon與Eureka配合使用時，Ribbon可自動從Eureka Server獲取服務提供者地址列表，並基於負載均衡算法，請求其中一個服務提供者實例。展現了Ribbon與Eureka配合使用時的架構。

參考：https://blog.csdn.net/chengqiuming/article/details/80711168

服務斷路器：Hystrix

所謂的熔斷機制和平常生活中見到電路保險絲是很是類似的，當出現了問題以後，保險絲會自動燒斷，以保護咱們的電器， 那麼若是換到了程序之中呢？

當如今服務的提供方出現了問題以後整個的程序將出現錯誤的信息顯示，而這個時候若是不想出現這樣的錯誤信息，而但願替換爲一個錯誤時的內容。

一個服務掛了後續的服務跟着不能用了，這就是雪崩效應

對於熔斷技術的實現須要考慮如下幾種狀況：

• 出現錯誤以後能夠 fallback 錯誤的處理信息；

• 若是要結合 Feign 一塊兒使用的時候還須要在 Feign（客戶端）進行熔斷的配置。

Hystrix如何解決依賴隔離

• Hystrix使用命令模式HystrixCommand(Command)包裝依賴調用邏輯，每一個命令在單獨線程中/信號受權下執行。
• 可配置依賴調用超時時間,超時時間通常設爲比99.5%平均時間略高便可.當調用超時時，直接返回或執行fallback邏輯。
• 爲每一個依賴提供一個小的線程池（或信號），若是線程池已滿調用將被當即拒絕，默認不採用排隊.加速失敗斷定時間。
• 依賴調用結果分:成功，失敗（拋出異常），超時，線程拒絕，短路。 請求失敗(異常，拒絕，超時，短路)時執行fallback(降級)邏輯。
• 提供熔斷器組件,能夠自動運行或手動調用,中止當前依賴一段時間(10秒)，熔斷器默認錯誤率閾值爲50%,超過將自動運行。
• 提供近實時依賴的統計和監控

Hystrix依賴的隔離架構,以下圖:

參考：https://www.cnblogs.com/leeSmall/p/8847652.html

https://www.cnblogs.com/yepei/p/7169127.html

斷路器聚合監控：Hystrix Turbine

​ 看單個的Hystrix Dashboard的數據並無什麼多大的價值，要想看這個系統的Hystrix Dashboard數據就須要用到Hystrix Turbine。Hystrix Turbine將每一個服務Hystrix Dashboard數據進行了整合。Hystrix Turbine的使用很是簡單，只須要引入相應的依賴和加上註解和配置就能夠了。

參考：https://www.cnblogs.com/allalongx/p/8383757.html

微服務網關：Zuul

zuul 是netflix開源的一個API Gateway 服務器, 本質上是一個web servlet應用。

Zuul 在雲平臺上提供動態路由，監控，彈性，安全等邊緣服務的框架。Zuul 至關因而設備和 Netflix 流應用的 Web 網站後端全部請求的前門。

zuul的工做原理

zuul的核心是一系列的filters, 其做用能夠類比Servlet框架的Filter，或者AOP。

zuul把Request route到 用戶處理邏輯 的過程當中，這些filter參與一些過濾處理，好比Authentication，Load Shedding等。

Zuul提供了一個框架，能夠對過濾器進行動態的加載，編譯，運行。

Zuul的過濾器之間沒有直接的相互通訊，他們之間經過一個RequestContext的靜態類來進行數據傳遞的。RequestContext類中有ThreadLocal變量來記錄每一個Request所須要傳遞的數據。

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

下面有幾種標準的過濾器類型：

Zuul大部分功能都是經過過濾器來實現的。Zuul中定義了四種標準過濾器類型，這些過濾器類型對應於請求的典型生命週期。

(1) PRE：這種過濾器在請求被路由以前調用。咱們可利用這種過濾器實現身份驗證、在集羣中選擇請求的微服務、記錄調試信息等。

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

(3) POST：這種過濾器在路由到微服務之後執行。這種過濾器可用來爲響應添加標準的HTTP Header、收集統計信息和指標、將響應從微服務發送給客戶端等。

(4) ERROR：在其餘階段發生錯誤時執行該過濾器。

參考：https://www.cnblogs.com/lexiaofei/p/7080257.html

https://www.cnblogs.com/xd03122049/p/6036318.html

配置中心：Spring Cloud Config

​ Spring Cloud Config爲分佈式系統中的外部配置提供服務器和客戶端支持。使用Config Server，您能夠爲全部環境中的應用程序管理其外部屬性。它很是適合spring應用，也可使用在其餘語言的應用上。隨着應用程序經過從開發到測試和生產的部署流程，您能夠管理這些環境之間的配置，並肯定應用程序具備遷移時須要運行的一切。服務器存儲後端的默認實現使用git，所以它輕鬆支持標籤版本的配置環境，以及能夠訪問用於管理內容的各類工具。

Spring Cloud Config服務端特性

• HTTP，爲外部配置提供基於資源的API（鍵值對，或者等價的YAML內容）
• 屬性值的加密和解密（對稱加密和非對稱加密）
• 經過使用@EnableConfigServer在Spring boot應用中很是簡單的嵌入。

Config客戶端的特性（特指Spring應用）

• 綁定Config服務端，並使用遠程的屬性源初始化Spring環境。
• 屬性值的加密和解密（對稱加密和非對稱加密）

參考：https://www.cnblogs.com/boboooo/p/8796636.html?utm_source=debugrun&utm_medium=referral

服務總線：spring cloud bus

​ 咱們若是要去更新全部微服務的配置，在不重啓的狀況下去更新配置，只能依靠spring cloud config了，可是，是咱們要一個服務一個服務的發送post請求，

​ 咱們能受的了嗎？這比以前的沒配置中心好多了，那麼咱們如何繼續避免挨個挨個的向服務發送Post請求來告知服務，你的配置信息改變了，須要及時修改內存中的配置信息。

​ 這時候咱們就不要忘記消息隊列的發佈訂閱模型。讓全部爲服務來訂閱這個事件，當這個事件發生改變了，就能夠通知全部微服務去更新它們的內存中的配置信息。這時Bus消息總線就能解決，你只須要在springcloud Config Server端發出refresh，就能夠觸發全部微服務更新了。

架構圖：

原理：

參考：https://www.cnblogs.com/huangjuncong/p/9077099.html

https://www.cnblogs.com/songxh-scse/p/7833963.html

構建異構平臺的服務註冊與通訊：sidecar

​ Spring Cloud是目前很是流行的微服務化解決方案，它將Spring Boot的便捷開發和Netflix OSS的豐富解決方案結合起來。如咱們所知，Spring Cloud不一樣於Dubbo，使用的是基於HTTP(s)的Rest服務來構建整個服務體系。
那麼有沒有可能使用一些非JVM語言，例如咱們所熟悉的Node.js來開發一些Rest服務呢？固然是能夠的。可是若是隻有Rest服務，還不能接入Spring Cloud系統。咱們還想使用起Spring Cloud提供的Eureka進行服務發現，使用Config Server作配置管理，使用Ribbon作客戶端負載均衡。這個時候Spring sidecar就能夠大顯身手了。
Sidecar起源於Netflix Prana。他提供一個能夠獲取既定服務全部實例的信息(例如host，端口等)的http api。你也能夠經過一個嵌入的Zuul，代理服務到從Eureka獲取的相關路由節點。Spring Cloud Config Server能夠直接經過主機查找或經過代理Zuul進行訪問。

​ 須要注意的是你所開發的Node.js應用，必須去實現一個健康檢查接口，來讓Sidecar能夠把這個服務實例的健康情況報告給Eureka。

理解：簡單來講sidecar就是可讓非java開發的微服務也能夠在SpringCloud組建中使用，利用Eureka，Config等功能。

參考：https://blog.csdn.net/shenzhen_zsw/article/details/81009238

https://www.jianshu.com/p/2788b7220407

微服務鏈路跟蹤：Zipkin

​ Zipkin是一款開源的分佈式實時數據追蹤系統（Distributed Tracking System），基於 Google Dapper的論文設計而來，由 Twitter 公司開發貢獻。其主要功能是彙集來自各個異構系統的實時監控數據。分佈式跟蹤系統還有其餘比較成熟的實現，例如：Naver的Pinpoint、Apache的HTrace、阿里的鷹眼Tracing、京東的Hydra、新浪的Watchman，美團點評的CAT，skywalking等。

如圖，在複雜的調用鏈路中假設存在一條調用鏈路響應緩慢，如何定位其中延遲高的服務呢？

• 日誌： 經過分析調用鏈路上的每一個服務日誌獲得結果
• zipkin：使用zipkin的web UI能夠一眼看出延遲高的服務

參考：https://blog.csdn.net/qq924862077/article/details/80285536

項目實際測試

測試：基本微服務測試

• 啓動微服務註冊中心Eureka：microservice-discovery-eureka 帳戶：admin 密碼：admin123

  訪問註冊中心地址：http://127.0.0.1:8761/

• 啓動服務提供者：microservice-provider-user

• 啓動服務消費者：microservice-consume-movie

• 打開註冊中心檢查服務是否註冊

• 訪問消費者接口1：http://127.0.0.1:9100/say 此時沒有進行服務間的調用，只是單純的訪問服務消費者

• 訪問消費者接口2：http://127.0.0.1:9100/say2 此時消費者調用提供者，進行服務間的通信，此時服務請求沒有參數而且返回數據爲字符串

• 訪問消費者接口3：http://127.0.0.1:9100/getUserInfo/1 此時進行服務間通信，而且請求帶有參數返回數據爲對象

• 對應腳本：microservice-test01.bat

測試：客戶端負載均衡服務測試

• 啓動微服務註冊中心Eureka：microservice-discovery-eureka 帳戶：admin 密碼：admin123

  訪問註冊中心地址：http://127.0.0.1:8761/

• 啓動服務提供者：microservice-provider-user1

• 啓動服務提供者：microservice-provider-user2

• 啓動服務消費者：microservice-consume-movie-feign

• 對應腳本：microservice-test02.bat

測試：Hystrix熔斷機制

• 啓動Eureka註冊中心：microservice-discovery-eureka
• 啓動服務提供者：microservice-provider-user
• 啓動服務消費者： microservice-consume-movie-feign-hystrix 其中包括Hystrix熔斷機制的方法回退

測試：Hystrix熔斷控制面板

• 啓動Eureka註冊中心：microservice-discovery-eureka
• 啓動服務提供者：microservice-provider-user
• 啓動服務消費者： microservice-consume-movie-feign-hystrix 其中包括Hystrix熔斷機制的方法回退
  注意：此項目必需要確保被監控的服務打開了Actuator（依賴spring-boot-starter-actuator），
  啓動程序開啓了斷路器（@EnableCircuitBreaker註解）。
• 啓動Hystrix DashBoard監控項目： microservice-hystrix-dashboard
  注意：此項目無需註冊到Eureka中
• 訪問註冊中心： http://127.0.0.1:8761/ 檢查服務是否啓動
• 訪問服務消費者： http://127.0.0.1:9103/say2
• 訪問監控面板： http://127.0.0.1:9090/hystrix
  填寫相應參數:http://127.0.0.1:9103/hystrix.stream

測試：路由規則

• 啓動服務註冊中心項目：microservice-discovery-eureka
• 啓動服務提供者項目：microservice-provider-user
• 啓動服務消費者項目：microservice-consume-movie-ribbon
• 啓動路由網關項目： microservice-getway-zuul
• 訪問：http://127.0.0.1:8761/ 檢查服務是否啓動成功
• 訪問：http://127.0.0.1:8040/microservice-consume-movie-ribbon/say2 檢查服務是否成功
• 訪問：http://127.0.0.1:8040/microservice-provider-user/getUser 檢查服務是否成功

Zuul路由規則：http://ZUUL_HOST:ZUUL_PORT/微服務在Eureka上的serviceId/會被轉發到serviceId對應的微服務上**

測試：負載均衡功能

• 啓動服務註冊中心：microservice-discovery-eureka
• 啓動多個服務提供者：microservice-provider-user(端口不一樣)
• 啓動路由網關項目：microservice-getway-zuul
• 訪問：http://127.0.0.1:8761/ 檢查服務是否啓動成功

屢次訪問192.168.224.1:8040/microservice-provider-user/hello，會發現兩個服務提供者循環顯示，說明Zuul可使用Ribbon達到負載均衡的效果

測試：Hystrix容錯與監控功能

1. 啓動服務註冊中心項目：microservice-discovery-eureka
2. 啓動服務提供者項目：microservice-provider-user
3. 啓動服務消費者項目：microservice-consume-movie-ribbon
4. 啓動路由網關項目： microservice-getway-zuul
5. 啓動服務監控項目： microservice-hystrix-dashboard
6. 訪問：http://127.0.0.1:8761/ 檢查服務是否啓動成功
7. 訪問：192.168.224.1:8040/microservice-consume-movie-feign-hystrix3/say2 得到預期效果
8. 訪問服務監控：http://127.0.0.1:9090/hystrix 輸入：http://192.168.224.1:8040/hystrix.stream(網關地址)，結果顯示