2. 微服務組件
2.1 微服務組件包括哪些
一個完整的微服務包括的組件：注冊中心，配置中心，熔斷，限流，鏈路跟蹤，路由
在微服務中，有些組件為必須組件（必須啟動存在），客戶端才能正常調用
- 必須組件：注冊中心，后台服務（Provider）
- 非必須組件：配置中心，熔斷，限流，鏈路跟蹤，路由
2.2 課程學習的組件
- 注冊中心 Nacos
- 配置中心 Nacos
- 網關 Spring Cloud Gateway
- 熔斷，限流 Sentinel
- 分布式追蹤系統 SkyWorking
2.3 注冊中心組件
2.3.1 什么是注冊中心
注冊中心可以說是微服務架構中的地址簿，它記錄了服務和服務地址的映射關系，在分布式架構中，服務會注冊到這里，當服務需要調用其他服務時，就在這里找到服務的地址，進行調用。
2.3.2 為什么需要注冊中心
服務注冊中心給客戶端提供可供調用的服務列表，客戶端在進行遠程服務調用時，根據服務列表然后選擇服務提供方的服務地址進行服務調用。服務注冊中心在分布式系統中大量應用，是分布式系統中不可獲取的組件。
注冊中心是整個服務調用的核心部分，如果服務不存在注冊中心，那么通過網關會調用不到，導致失敗。
2.3.3 注冊中心分類
注冊中心分兩大類
- 臨時實例：在nacos中Java客戶端自動注冊的服務實例一般為臨時實例，並且客戶端會間隔幾秒發送心跳到注冊中心，告訴注冊中心是否存活，如果不存在，那么注冊中心會自動從列表中去掉此節點。
- 永久實例：可以通過api的方式人工填寫客戶端信息，注冊中心不會去掉節點（不管是否在線）。注冊中心會主動檢查客戶端是否在線。
2.3.4 常見的注冊中心
Netflix Eureka
Nacos
Consul
Zookeeper
CoreDNS
2.3.4.1 consul，eureka，nacos對比
| 功能對比 | eureka | consul | nacos |
|---|---|---|---|
| 配置中心功能 | 不支持 | 支持，但是用起來偏麻煩，不太符合spring Boot框架的命名風格，支持動態刷新 | 支持，用起來簡單，符合springBoot的命名風格，支持動態刷新 |
| 依賴 | 依賴zookeeper | 不依賴其他組件 | 不依賴其他組件 |
| 應用內/外 | 直接集成到應用中，依賴於應用自身完成服務的注冊與發現 | 屬於外部應用，侵入性小 | 屬於外部應用，侵入性小 |
| ACP原則 | 遵循AP（可用性+分離容忍）原則，有較強的可用性，服務注冊塊，單犧牲了一定的一致性 | 遵循CP原則（一致性+分離容忍）服務注冊稍慢，由於其一致性導致了在leader掛掉重新選舉期間整個consul不可用 | 通知遵循CP原則（一致性+分離容忍）和AP原則（可用性+分離容忍） |
| 版本迭代 | 目前已經不進行升級 | 目前仍然進行版本迭代 | 目前仍然進行版本迭代 |
| 集成支持 | 只支持SpringCloud集成 | 支持SpringCloud K8S集成 | 支持Dubbo，SpringCloud，K8S集成 |
| 訪問協議 | HTPP | HTTP/DNS | HTTP/動態DNS/UDP |
| 雪崩保護 | 支持 | 不支持 | 支持 |
| 界面 | 英文界面 | 英文界面，不符合國人習慣 | 中文界面 |
| 上手 | 容易 | 復雜一點 | 極易，中文文檔，案例，社區活躍 |
2.4 配置中心組件
2.4.1 什么是配置中心
管理各個環境的配置文件參數，比如說數據庫，緩存，存儲，業務應用並且支持管理每個不同的環境的配置。
2.4.2 為什么需要配置中心
- 本地配置在服務啟動加載，修改配置不需要重啟服務
- 多個環境（dev，prod，sit，uat）容易混淆，會產生錯誤，導致服務運行異常
- 出現配置錯誤時，不容易回滾到指定的版本
2.4.3 配置中心演進
從單一的單機部署到多機的負載均衡，以及后來應用的微服務容器化，不可避免的使用多個環境的配置。
2.3.4 常見配置中心功能對比
| 功能 | Spring Cloud Config | Apollo | Nacos |
|---|---|---|---|
| 實效性 | SpringCloudBus | HTTP長輪詢 | HTTP長輪詢 |
| 權限控制 | 支持 | 支持 | 支持 |
| 灰度發布 | 支持 | 支持 | 不支持 |
| 版本管理 | 支持 | 支持 | 支持 |
| 版本回滾 | 支持 | 支持 | 支持 |
| 多環境支持 | 支持 | 支持 | 支持 |
2.5 API路由網關組件
2.5.1 什么是API網關
API網關是微服務架構中提供路由轉發與鑒權等功能，首先，它會提供最基本的路由服務，將客戶端請求轉發后台業務服務；其次，作為一個入口，它還可以進行認證，鑒權，限流等操作。
2.5.2 為什么需要API網關
- 客戶端訪問的統一對接接口
- 防止內部接口直接暴露給外部客戶端（隱藏內部服務）
- API網關通過提供一個額外的保護層來防止惡意攻擊，例如SQL注入，XML解析器漏洞和拒絕服務
- 服務網關的前置過濾器中，所有請求過來進行權限校驗
- 日志訪問與審計
2.5.3 網關架構說明
調用之前所有的客戶端通過7層負載均衡反向代理后台的服務
調用之后所有的客戶端通過微服務框架網關負載到后台的服務
2.5.4 常用的網關組件
- KONG是一個通過lua-nginx-module實現的在nginx中運行的lua應用程序
- Spring Cloud Gateway是由Spring官方基於Spring5.0等技術開發的網關，目的是代替原先版本中的Zuul
- Zuul
2.6 服務限流組件
2.6.1 什么是服務限流
- 服務限流：指當系統資源不夠的情況下，不足以應對大量的用戶與數據接口請求時，為了保證優先的資源能夠正常服務，因此對系統按照預設的規則進行流量限制或功能限制的一種方法。
2.6.2 為什么需要服務限流
- 發生錯誤或者超時，不讓調用接口，調用本地fallback（容錯）
- 解決高並發請求，一旦達到規定請求，熔斷，報錯
2.6.3 常用限流組件
Sentinel（阿里 哨兵）
Hystrix (Spring Cloud 豪豬)
2.6.4 圖解說明熔斷作用
- 如果未接入熔斷處理，在客戶端直接返回500錯誤，程序會拋異常，有可能會導致其他服務也不可用（消耗系統資源）
- 啟用熔斷處理，在客戶端返回200正常？？
2.7 鏈路跟蹤（調度鏈）組件
2.7.1 什么是調用鏈
調用鏈是整個分布式系統中跟蹤一個用戶請求的過程，包括數據采集，數據傳輸，數據存儲，數據分析和數據可視化展示工具，也是微服務中代碼的調試和服務監控的性能分析工具。
2.7.2 為什么需要調用鏈
分布式web系統中，客戶端的一次請求操作，可能需要經過系統中多個模塊，多個中間件，多台機器的相互協作才能完成，並且這一系列調用請求中，有些是串行處理的，有些是並發執行的，那么如何確定客戶端的一次操作背后調用了哪些應用，哪些模塊，經過了哪些節點，每個模塊的調用先后順序是怎樣的，每個模塊的性能問題如何？隨着業務系統模型的日趨復雜化，分布式系統中繼續一套鏈路追蹤（trace）系統來解決這些問題（快速定位）。
2.7.3 常見組件
- SkyWalking 用於追蹤，監控和診斷分布式系統，特別是使用微服務架構，雲原生或容積技術
- Zipkin的一個叫Brave的組件來實現對應用內部的性能分析數據采集，通過實現一系列的java攔截器，來做到對http請求，數據庫訪問的調用過程跟蹤。
- Pinpoint是開源在github上的一款APM監控工具，用java編寫，用於大規模分布式系統的監控，它對性能的影響最小（只增加約3%資源利用率），安裝agent是無侵入式的。
2.7.4 調用鏈調用過程
- 通過調用接口可以查看到每個接口所調用的層次，並且可以查看調用的方法名。
在本例中，客戶端訪問網關服務在調用系統中會顯示，服務端先啟動tomcat，如果程序調用auth方法，最后對外服務，也可以看到接口調用時間。
2.8 小結
- 本節講述了在微服務中涉及的5大組件，分類為必須組件和非必須組件
- 大致闡述每個組件的原由北京以及典型的組件代表
- 每個組件功能總結：
注冊中心 所有服務注冊與調用查詢
配置中心 微服務配置項集中管理
網關 自動路由與負載均衡至微服務
熔斷，限流 防止服務崩潰的保護機制
分布式追蹤系統 判斷程序性能與調用關系