SpringCloud 學習總結
學習回顧
1.Maven依賴管理
在微服務專案中，我們一般是先建立一個父專案模組對整個專案的依賴進行版本限定和依賴控制，子模組繼承父模組後，不需要再考慮版本和依賴問題，只需要引入相對應的依賴即可。那麼在父模組的pom檔案中我們可以使用以下標籤來對依賴進行管理和版本控制。
<properties></properties>
<dependencyManagement></dependencyManagement>
2.微服務中服務消費者和服務提供者的關係
概念：
-
服務提供者：被其他微服務的呼叫的微服務。
-
服務消費者：呼叫其他服務的微服務。
服務提供者就是指處理使用者需求業務，並且提供資料和反饋的微服務應用。而服務消費者就是接收使用者的需求後呼叫消費者來進行使用者的需求。
使用者->服務消費者->服務提供者 這樣一個流程。
3.服務註冊和服務發現
在微服務專案中，我們不再是指定某一個IP地址，某一個埠來進行服務呼叫，而是通過服務中心，來獲取能夠提供服務的機器的地址。舉個例子：我們可以拿服務中心比作我們的小區物管，拿微服務應用來比作便利店，假如便利店要進駐小區，那麼必須要先向物管註冊，然後才能夠正常營業。而我們想要找到便利店首先要先問物管，物管告訴你便利店在哪，你就能直接找到。
微服務提供者要先通過服務註冊向服務中心註冊，然後服務消費者通過服務名向服務中心獲取能夠提供服務的地址。
服務發現就是新註冊的這個服務模組能夠及時的被其他呼叫者發現。不管是服務新增和服務刪減都能實現自動發現。
服務註冊，就是將提供某個服務的模組資訊(通常是這個服務的ip和埠)註冊到1個公共的元件上去
4.服務呼叫
消費者通過註冊中心獲取服務提供者的資訊後呼叫提供者，那麼這種呼叫就是服務呼叫。目前常用的服務呼叫的工具有Ribbon和OpenFeign，Ribbon是一個客戶端負載均衡呼叫的工具。Ribbon預設的負載均衡的演算法為輪訓演算法，我們也能夠通過編寫自己的演算法來替代輪訓演算法，通過Ribbon，我們可以負載均衡的呼叫服務中心上已註冊的服務提供者。
5.服務降級，熔斷
服務降級：系統有限的資源的合理協調
概念：服務降級一般是指在伺服器壓力劇增的時候，根據實際業務使用情況以及流量，對一些服務和頁面有策略的不處理或者用一種簡單的方式進行處理，從而釋放伺服器資源的資源以保證核心業務的正常高效執行。
服務熔斷：應對雪崩效應的鏈路自我保護機制。可看作降級的特殊情況。
概念：應對微服務雪崩效應的一種鏈路保護機制，類似股市、保險絲
其實服務降級和熔斷不是很細分的話，可以看作一個整體，服務熔斷是機制，服務降級是手段。
設想一個情況，假如服務A呼叫B，服務B呼叫C，那麼如果服務C出現異常，那麼服務B的請求得不到響應，那麼服務B的資源會被消耗殆盡，導致服務A也出現問題，這種就是雪崩效應，由於上游的問題，導致下游壓力過大。那麼這種時候就需要類似於我們生活中的保險絲一樣的功能，當某個服務出現異常或響應慢等情況達到某個閾值，就會觸發熔斷，那麼所有的請求都將不可用，等正常了，再關閉"保險絲"，恢復正常的請求呼叫。
更細看的話，熔斷機制能夠執行起來，也是因為通過服務降級這個手段。
6.服務閘道器
由上圖可以看出，服務閘道器的作用是非常關鍵的，服務閘道器就像我們微服務的一扇大門，把一切不速之客都擋之門外。
服務閘道器通過一系列的過濾器和斷言匹配機制，保護著微服務的安全，同時也能夠有效隱藏真實的服務地址。我們也可以把服務閘道器看作我們和服務提供者的中間商。
7.配置中心
設想一下，假如我們現在有幾十個微服務應用，每一個微服務應用都配置了資料庫的地址，賬戶和密碼，那麼某一天資料庫的地址發生了改變，那我們豈不是要停止這幾十個微服務應用，然後逐一對配置檔案進行修改？這將是個災難，我相信如果要這麼做，那麼運維直接Say no不幹了。
那麼針對這個情況，我們引出一個元件----配置中心。
我們通過配置中心，把一些公有的配置發到伺服器上，然後當更新配置後，通過訊息佇列廣播到各個微服務應用上，這樣子就能解決以上問題了。當然我們也能夠通過配置中心來簡便的切換各個開發環境，如測試環境，開發環境和生產環境。
8.鏈路跟蹤
當我們需要對每一個微服務的健康狀況進行監控，甚至要細化到介面上的時候，我們就需要一個微服務元件----鏈路跟蹤。
什麼是鏈路跟蹤？鏈路跟蹤就像我們路口上一個個監控攝像頭，你的車子只要行駛過去，你的速度，駕駛人，車牌等等資訊都會被攝像頭所獲取，那麼我們的微服務也一樣，鏈路跟蹤能夠把我們每一次呼叫的各種資訊都獲取到，包括呼叫方法，呼叫類，呼叫時間等。
9.服務限流
服務限流這個詞顧名思義就是對微服務應用進行流量限制，常用的元件是阿里巴巴的Sentinel，服務限流細分有兩個策略，一個是QPS限流，一個執行緒數限流。那麼就說說QPS限流和執行緒數限流的區別。
每秒查詢率（QPS，Queries-per-second）是對一個特定的查詢伺服器在規定時間內所處理流量多少的衡量標準，在因特網上，作為域名系統伺服器的機器的效能經常用每秒查詢率來衡量。
通過以上文字，我們可以知道QPS就是每秒的請求量。那麼通過QPS限流的含義就很明顯了，就是設定一個QPS的閾值，然後當達到這個閾值後，請求將失敗，警告或者排隊。
執行緒數，當請求A過來訪問該介面，該請求處理的很慢，還沒有返回資料；此時請求B也過來訪問該介面，這個時候處理請求B需要額外開啟一個執行緒，請求B則會報錯；
我們可以通過一個小小舉例來認識QPS和執行緒數的區別。假設有一個銀行，銀行內只有一個視窗，外面有很多人想要辦理業務就必須通過該視窗來辦理，那麼QPS限流就是，不管業務視窗能處理多少個業務，他只管把人放進來，當人數超過閾值時，則會把所有人都趕出去，任何業務都無法辦理。而執行緒數限流就是，逐一的把人放進來，當排隊的人超過指定的執行緒閾值，則進行限流。
QPS單純的代表每秒的訪問次數，只要訪問次數到達一定的閾值，這進行限流操作。
執行緒數，代表的是每秒內訪問該api介面的執行緒數，如果該介面的操作比較長，當排隊的執行緒數到達閾值的時候，進行限流操作，相反的如果介面的操作很快，即是每秒內的QPS很大，同樣不會進行限流操作。
總結
一個完整的微服務包括的元件：註冊中心，配置中心，熔斷，限流，鏈路跟蹤，路由
在微服務中，有些元件為必須元件（必須啟動存在），客戶端才能正常呼叫
- 必須元件：註冊中心，後臺服務（Provider）
- 非必須元件：配置中心，熔斷，限流，鏈路跟蹤，路由