❶ SpringCloud微服務組件介紹
Spring Cloud是一系列框架的有序集合（框架集），他利用Spring Boot的開發便利性巧妙的簡化了分布式系統基礎設施的開發，如服務發現注冊、配置中心、消息匯流排、負載均衡、斷路器、數據監控等。
SpringCloud利用SpringBoot的開發便利性巧妙地簡化了分布式系統基礎設施的開發，SpringCloud為開發人員提供了快速構建分布式系統的一些工具，包括配置管理、服務發現、斷路器、路由、微代理、事件匯流排、全局鎖、決策競選、分布式會話等等，它們都可以用SpringBoot的開發風格做到一鍵啟動和部署。
SpringCloud並沒有重復製造輪子，它只是將目前各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來，通過SpringBoot風格進行再封裝屏蔽掉了復雜的配置和實現原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分布式系統開發工具包
下面是Spring Cloud的整體架構圖：
注冊中心可以說是微服務架構中的「通訊錄」，他記錄了服務和服務地址的映射關系。在分布式架構中，服務會注冊到這里，當服務需要調用其他服務時，就在這里找到對應服務的地址，進行調用。
注冊中心的主要作用
Ribbon是Netflix發布的一個負載均衡，有助於控制HTTP和TCP客戶端行為。在Spring Cloud中，Eureka一般配合Ribbon進行使用，Ribbon提供了客戶端負載均衡的功能，Ribbon利用從Eureka中讀取到的服務信息，在調用服務節點提供的服務時，會合理的進行負載。
在Spring Cloud中可以將注冊中心和Ribbon配合使用，Ribbon自動的從注冊中心中獲取服務提供者的列表信息，並基於內置的負載均衡演算法，請求服務。
Ribbon原理
幾種負載均衡策略：
Hystrix是Netflix開源的一款容錯框架，包含常用的容錯方法。在高並發訪問下，系統所依賴的服務的穩定性對系統的影響非常大，依賴有很多不可控的因素，比如網路連接變慢，資源突然繁忙，暫時不可用，服務離線等。Hystrix利用熔斷、線程池隔離、信號量隔離、降級回退等方法來處理依賴隔離，使系統變得高可用。
Hystrix主要提供了以下幾種容錯方法：
Spring Cloud Gateway是Spring官方推出的服務網關的實現框架，相對於服務網關的概念有點類似於傳統的反向代理伺服器（如nginx），但反向代理一般都只是做業務無關的轉發請求，而服務網關與服務的整合程度更高，可以看作也是整個服務體系的組成部分，通過過濾器等組件可以在網關中集成一些業務處理的操作（比如許可權認證等）。
核心功能：
Spring Cloud Stream是一個用來為微服務應用構建消息驅動能力的框架。
特點：
屏蔽底層 MQ 實現細節，Spring Cloud Stream 的 API 是統一的。如果從 Kafka 切到 RocketMQ，可以直接修改配置。
與 Spring 生態整合更加方便。Spring Cloud Data Flow的流計算都是基於 Spring Cloud Stream；Spring Cloud Bus 消息匯流排內部也是用的 Spring Cloud Stream。
配置中心功能：
分布式鏈路追蹤，就是將一次分布式請求還原成調用鏈路，進行日誌記錄，性能監控並將一次分布式請求的調用情況集中展示。比如各個服務節點上的耗時，請求具體到達哪台機器上、每個服務節點的請求狀態等等。
分布式鏈路追蹤方案：
❷ 生產級基於SpringCloud微服務架構性能優化實戰，建議收藏
本文將從 Tomcat性能優化，SpringCloud開啟重試機制，Zuul網關性能參數優化，Ribbon性能參數優化，Feign與Hystrix性能優化等 五個方面分享在生產環境如何做好SpringCloud性能優化。
一般基於SpringCloud的微服務能夠脫離傳統的tomcat，獨立跑起來，SpringBoot功不可沒，其原理是SpringBoot內嵌了tomcat（當然可以換成其他servlet容器，如jetty），能夠以java -jar形式就能跑起來。
所以針對每個springboot服務，我們需要對tomcat的一些參數進行優化，以下是樓主項目組優化的tomcat參數配置，供大家參考。
tomcat參數說明：
maxThreads，acceptCount參數應用場景
場景一
場景二
場景三
maxThreads調優
一般說伺服器性能要從兩個方面說起：
1、cpu計算型指標
2、io密集型指標
所以大部分情況下，tomcat處理io型請求比較多，比如常見的連資料庫查詢數據進行介面調用。
另外，要考慮tomcat的並發請求量大的情況下，對於伺服器系統參數優化，如虛擬機內存設置和linux的open file限制。
maxThreads設置多大合適？
我們知道線程過多，會導致cpu在線程切換時消耗的時間隨著線程數量的增加越來越大；線程太少，伺服器的請求響應吞吐量會急劇下降，所以maxThreads的配置絕對不是越大越好。
實際情況是設置maxThreads大小沒有最優解，要根據具體的伺服器配置，實際的應用場景不斷的調整和優化。
acceptCount設置多大合適？
盡量與maxThreads的大小保持一致 ， 這個值應該是主要根據應用的訪問峰值與平均值來權衡配置的。
當使用URL進行路由時，則需要對zuul.host.connect-timeout-millis和zuul.host.socket-timeout-millis參數控制超時時間。
請求連接的超時時間
請求處理的超時時間
對所有操作請求都進行重試
對當前實例的重試次數，針對同一個服務實例，最大重試次數（不包括首次調用）
對下個實例的重試次數，針同其它的服務實例，最大重試次數（不包括首次server）
注意Hystrix斷路器的超時時間需要大於ribbon的超時時間，不然不會觸發重試
Feign和Ribbon在整合了Hystrix後，首次調用失敗的問題？
目前樓主的強烈做法是： 禁用Hystrix的超時時間，設為false
還有一種是官方提倡的是 設置超時時間。
在實際的項目中親測，這種方式也有不好的地方， 如請求時間超過5s會出現請求數據時有時無的情況 ，給用戶的感覺是 系統不穩定，要求整改 。
另外，禁用hystrix，官方不推薦 。
hystrix超時設置原則
問題：一個http請求，如果feign和ribbon都配置了重試機制，異常情況下一共會請求多少次？
請求總次數 n 為feignClient和ribbon配置參數的笛卡爾積：
n(請求總次數) = feign(默認5次) * (MaxAutoRetries+1) * (MaxAutoRetriesNextServer+1)
其中+1是代表ribbon本身默認的請求。
其實二者的重試機制相互獨立，並無聯系。但是因為用了feign肯定會用到ribbon，所以feign的重試機制相對來說比較雞肋，一般會關閉該功能。ribbon的重試機制默認配置為0，也就是默認是去除重試機制的，建議不要修改。
❸ Spring Cloud微服務體系的組成
Netflix Eureka是Spring Cloud服務注冊發現的基礎組件
Eureka提供RESTful風格(HTTP協議)的服務注冊與發現
Eureka採用C/S架構,Spring Cloud內置客戶端
啟用應用,訪問 http://localhost:8761
Eureka客戶端開發要點
maven依賴spring-cloud-starter-netflix-eureka-client application.yml
配置eureka.client.service-url.defaultZone
入口類增加@EnableEurekaClient
先啟動注冊中心,在啟動客戶端,訪問 localhost:8761查看eureka注冊中心,看到客戶端注冊
Eureka名詞概念
Register - 服務注冊, 向Eureka進行注冊登記
Renew - 服務續約,30秒/次心跳包健康檢查.90秒未收到剔除服務
Fetch Registries - 獲取服務注冊列表,獲取其他微服務地址
Cancel - 服務下線, 某個微服務通知注冊中心暫停服務
Eviction - 服務剔除,90秒未續約,從服務注冊表進行剔除
Eureka自我保護機制
Eureka在運行期去統計心跳失敗率在15分鍾之內是否低於 85%
如果低於 85%，會將這些實例保護起來，讓這些實例不會被剔除
關閉自我保護:eureka.服務實例.
enable-self-preservation: false
PS: 如非網路特別不穩定,建議關閉
Eureka高可用配置步驟
服務提供者defaultZone指向其他的Eureka
客戶端添加所有Eureka 服務實例 URL
Actuator自動為微服務創建一系列的用於監控的端點
Actuator在SpringBoot自帶，SpringCloud進行擴展
pom.xml依賴spring-boot-starter-actuator
RestTemplate + @LoadBalanced 顯式調用
OpenFeign 隱藏微服務間通信細節
Ribbon是RestTemplate與OpenFeign的通信基礎
Feign是一個開源聲明式WebService客戶端，用於簡化服務通信
Feign採用「介面+註解」方式開發，屏蔽了網路通信的細節
OpenFeign是SpringCloud對Feign的增強，支持Spring MVC註解
1.新建Spring boot Web項目，application name 為 proct-service
在pom.xml中引入依賴
spring-cloud-starter-alibaba-nacos-discovery作用為向Nacos server注冊服務。
spring-cloud-starter-openfeign作用為實現服務調用。
2.修改application.yml配置文件
3.在啟動類上添加@EnableDiscoveryClient、@EnableFeignClients註解
4.編寫OrderClient Interface
註：/api/v1/order/test 會在下面order-service聲明。
OrderClient.java
5.編寫Controller和service
ProctController.java
ProctService.java
1.OpenFeign開啟通信日誌
基於SpringBoot的logback輸出,默認debug級別
設置項：feign.client.config.微服務id.loggerLevel
微服務id：default代表全局默認配置
2.通信日誌輸出格式
NONE: 不輸出任何通信日誌
BASIC: 只包含URL、請求方法、狀態碼、執行時間
HEADERS：在BASIC基礎上，額外包含請求與響應頭
FULL：包含請求與響應內容最完整的信息
3.OpenFeign日誌配置項
LoggerLevel開啟通信日誌
ConnectionTimeout與ReadTimeout
利用httpclient或okhttp發送請求
1.OpenFeign通信組件
OpenFeign基於JDK原生URLConnection提供Http通信
OpenFeign支持Apache HttpClient與Square OkHttp
SpringCloud按條件自動載入應用通信組件
2.應用條件
Maven引入feign-okhttp或者feign-httpclient依賴
設置feign.[httpclient|okhttp].enabled=true
POST方式傳遞對象使用@RequestBody註解描述參數
GET方式將對象轉換為Map後利用@RequestParam註解描述
雪崩效應:服務雪崩效應產生與服務堆積在同一個線程池中，因為所有的請求都是同一個線程池進行處理，這時候如果在高並發情況下，所有的請求全部訪問同一個介面,這時候可能會導致其他服務沒有線程進行接受請求，這就是服務雪崩效應效應。
服務熔斷:熔斷機制目的為了保護服務，在高並發的情況下，如果請求達到一定極限(可以自己設置闊值)如果流量超出了設置閾值，讓後直接拒絕訪問，保護當前服務。使用服務降級方式返回一個友好提示，服務熔斷和服務降級一起使用。
1.Hystrix熔斷器
Hystrix（豪豬）是Netflix開源的熔斷器組件，用於為微服務提供熔斷機制預防雪崩，保護整體微服務架構的健康
2.Hystrix功能
預防微服務由於故障，請求長時間等待導致Web容器線程崩潰
提供故障備選方案，通過回退（fallback)機制提供」服務降級」
提供監控儀表盤,實時監控運行狀態
3.Hystrix 熔斷器工作原理
服務的健康狀況 = 請求失敗數 / 請求總數.
熔斷器開關由關閉到打開的狀態轉換是通過當前服務健康狀況和設定閾值比較決定的.
當熔斷器開關關閉時, 請求被允許通過熔斷器. 如果當前健康狀況高於設定閾值, 開關繼續保持關閉. 如果當前健康狀況低於
設定閾值, 開關則切換為打開狀態.
當熔斷器開關打開時, 請求被禁止通過.
當熔斷器開關處於打開狀態, 經過一段時間後, 熔斷器會自動進入半開狀態, 這時熔斷器只允許一個請求通過. 當該請求調用
成功時, 熔斷器恢復到關閉狀態. 若該請求失敗, 熔斷器繼續保持打開狀態, 接下來的請求被禁止通過.
熔斷器的開關能保證服務調用者在調用異常服務時, 快速返回結果, 避免大量的同步等待. 並且熔斷器能在一段時間後繼續偵測請求執行結果, 提供恢復服務調用的可能.
4.什麼情況下會觸發服務降級
FAILURE: 執行失敗，拋出異常
TIMEOUT:執行超時（默認1秒）
SHORT_CIRCUITED:熔斷器狀態為Open
THREAD_POOL_REJECTED:線程池拒絕
SEMAPHORE_REJECTED:信號量拒絕
5.使用Hystrix步驟
1.引入pom文件依賴
6.OpenFeign與Hystrix整合
OpenFeign中使用Hystrix
OpenFeign內置Hystrix，feign.hystrix.enable開啟即可
feign: hystrix: enabled: true
在@FeignClient增加fallback屬性說明Fallback類
@FeignClient(name="message-service",fallback = MessageServiceFallback.class) public interface MessageService { @GetMapping("/sendsms") public CallbackResult sendSMS(@RequestParam("mobile") String mobile , @RequestParam("message") String message); }
Fallback類要實現相同介面，重寫服務降級業務邏輯
@Component public class MessageServiceFallback implements MessageService { @Override public CallbackResult sendSMS(String mobile, String message) { return new CallbackResult("INVALID_SERVICE","消息服務暫時無法使用，簡訊發送失敗"); } }
7.Hystrix超時設置
8.部署Hystrix Dashboard監控
Hystrix Client依賴hystrix-metrics-event-stream
Hystrix Client注冊HystrixMetricsStreamServlet
監控微服務依賴spring-cloud-starter-netflix-hystrix-dashboard
監控微服務利用@EnableHystrixDashboard開啟儀表盤
9.Hystrix熔斷設置
產生熔斷的條件:
當一個Rolling Window(滑動窗口）的時間內（默認：10秒），最近20次調用請求，請求錯誤率超過50%，則觸發熔斷5秒，期間快速失敗。
TIPS: 如10秒內未累計到20次，則不會觸發熔斷
Hystrix熔斷設置項:
統一訪問出入口,微服務對前台透明
安全、過濾、流控等API管理功能
易於監控、方便管理
Netflix Zuul
Spring Cloud Gateway
Zuul 是Netflix開源的一個API網關, 核心實現是Servlet
Spring Cloud內置Zuul 1.x
Zuul 1.x 核心實現是Servlet，採用同步方式通信
Zuul 2.x 基於Netty Server，提供非同步通信
認證和安全
性能監測
動態路由
負載卸載
靜態資源處理
壓力測試
Spring Cloud Gateway，是Spring「親兒子」
Spring Cloud Gateway旨在為微服務架構提供一種簡單而有效的統一的API路由管理方式
Gateway基於Spring 5.0與Spring WebFlux開發，採用Reactor響應式設計
1.使用三部曲
依賴spring-cloud-starter-netflix-zuul
入口增加 @EnableZuulProxy
application.yml 增加微服務映射
2.微服務映射
Spring Cloud Zuul內置Hystrix
服務降級實現介面：FallbackProvider
1.微服務網關流量控制
微服務網關是應用入口，必須對入口流量進行控制
RateLimit是Spring Cloud Zuul的限流組件
https://github.com/marcosbarbero/spring-cloud-zuul-ratelimit
RateLimit採用「令牌桶」演算法實現限流
2.什麼是令牌桶
1.Zuul的執行過程
2.Http請求生命周期
1.需要實現ZuulFilter介面
shouldFilter() - 是否啟用該過濾器
filterOrder() - 設置過濾器執行次序
filterType() - 過濾器類型:pre|routing|post
run() - 過濾邏輯
2.Zuul內置過濾器
3.Zuul+JWT跨域身份驗證
1.Spring Cloud Config
2.攜程 Apollo
3.阿里巴巴Nacos
1.依賴"spring-cloud-starter-config"
2.刪除application.yml,新建bootstrap.yml
3.配置"配置中心"服務地址與環境信息
1、微服務依賴"spring-boot-starter-actuator";
2、動態刷新類上增加@RefreshScope註解
3、通過/actuator/refresh刷新配置
1、通過加入重試機制、提高應用啟動的可靠性;
2、重試觸發條件1:配置中心無法與倉庫正常通信
3、重試觸發條件2:微服務無法配置中心正常通信
❹ Spring Cloud之Eureka源碼分析2
本章主要介紹Eureka Client端源碼分析。
客戶端主要是向Server服務端發送Http請求，主要有注冊，心跳續約，獲取注冊信息等功能
在分析源碼之前，需要查看下客戶端配置文件
application.yml
訪問服務端localhost:8000的注冊信息
自動配置類，首先要從依賴包的spring.factories文件看起
其中最重要的是EurekaClientAutoConfiguration類
只要類中存在EurekaClientConfig類所在的依賴包eureka-client-xx.jar就可以載入這個類
2、 用來開啟定時任務
1、EurekaAutoServiceRegistration
實例化EurekaAutoServiceRegistration對象，並放到spring容器中
org.springframework.cloud.netflix.eureka.serviceregistry.EurekaAutoServiceRegistration
2、start
由於EurekaAutoServiceRegistration類實現了SmartLifecycle,SmartApplicationListener等介面，所以會在容器初始化完成之後調用EurekaAutoServiceRegistration#start方法。
調用ApplicationInfoManager應用信息管理設置實例初始化狀態信息initialStatus
4、setInstanceStatus
com.netflix.appinfo.ApplicationInfoManager#setInstanceStatus
設置實例狀態信息並調用監聽器notify方法
com.netflix.discovery.DiscoveryClient#register
這里就到了注冊客戶端的地方
包括緩存更新與心跳續約，通過類開始初始化，並最終通過initScheledTasks方法開啟定時調度器任務
EurekaClientAutoConfiguration.
這個類是程序實現定時刷新任務開始的地方，主要是通過new CloudEurekaClient()方法創建Cloud客戶端類（CloudEurekaClient）
下面主要查看CloudEurekaClient的調用鏈
1、CloudEurekaClient#CloudEurekaClient
org.springframework.cloud.netflix.eureka.CloudEurekaClient#CloudEurekaClient
調用CloudEurekaClient類的父類，和對applicationInfoManager、publisher、eurekaTransportField等屬性值賦值
2、DiscoveryClient#DiscoveryClient
com.netflix.discovery.DiscoveryClient#DiscoveryClient
4、DiscoveryClient#DiscoveryClient
定義調度器類、心跳執行器和緩存刷新執行器等的定義。
com.netflix.discovery.DiscoveryClient#DiscoveryClient
這個方法主要流程：
①、這個方法前半部分是初始化屬性值。
②、根據客戶端client配置文件，config.shouldFetchRegistry()是否獲取注冊表信息和
config.shouldRegisterWithEureka()是否注冊到eureka上來對屬性賦值，或直接返回
③、初始化調度器scheler、兩個線程池執行器heartbeatExecutor（心跳續約）和cacheRefreshExecutor（緩存刷新，定時獲取注冊信息表）
④、在獲取服務注冊信息條件下，沒有獲取到信息或異常即fetchRegistry(false)返回false。可以從備用伺服器獲取調用fetchRegistryFromBackup()方法，內部實現方法調用備用伺服器類的get方法backupRegistryProvider.get()
⑤、初始化調度器任務方法initScheledTasks()
調度器任務包括：
1、定時刷新緩存注冊表信息，分為全量獲取和增量獲取
2、定時向服務端發送心跳續約
3、狀態改變監聽器執行
這里不僅包括這些定時任務，注冊也是在這里調用狀態改變監聽器StatusChangeListener的notify方法
com.netflix.discovery.DiscoveryClient#initScheledTasks
1、initScheledTasks
com.netflix.discovery.DiscoveryClient#initScheledTasks
TimedSupervisorTask繼承了TimerTask，TimerTask實現了Runnable
TimedSupervisorTask類的構造方法
2、HeartbeatThread
執行TimedSupervisorTask的task任務，在給定的間隔內執行心跳續約任務
com.netflix.discovery.DiscoveryClient.HeartbeatThread
3、renew
續約任務，續約成功更新參數。通過REST方式進行續訂
com.netflix.discovery.DiscoveryClient#renew
服務端調用到renewLease方法續約，appName和id與客戶端傳過來的相同
com.netflix.eureka.resources.InstanceResource#renewLease
在定時刷新緩存實現獲取注冊信息，分為全量拉取和增量拉取
創建TimedSupervisorTask調度任務類，傳入cacheRefreshExecutor執行器、CacheRefreshThread任務類、從服務端獲取注冊信息的時間間隔RegistryFetchIntervalSeconds等參數信息
全量拉取條件（任意一個）
①、disable-delta屬性值是true 關閉增量拉取
②、registry-refresh-single-vip-address 屬性vip地址的值不為空
③、forceFullRegistryFetch 為true 傳過來的變數值
④、localRegionApps的applications是null 當前區域應用
⑤、applications的數量是0
⑥、applications的版本是-1
實現增量拉取的條件是不符合全量拉取，調用getAndUpdateDelta方法
com.netflix.discovery.DiscoveryClient#getAndUpdateDelta
這個方法實現了增量拉取的請求實現，及對拉取增量結果的處理
1、getDelta
eurekaTransport.queryClient.getDelta(remoteRegionsRef.get())的具體實現是通過類實現的
com.netflix.discovery.shared.transport.jersey.#getDelta
這個方法主要是遍歷recentlyChangedQueue存在的數據放入到Applications對象中。所以recentlyChangedQueue隊列中存在什麼數據就很重要，因此我們需要了解最新更新隊列recentlyChangedQueue是如何放入的及放入那些數據，及其的移除的原理。
在這個方法最後 apps.setAppsHashCode設置了當前服務端所有注冊信息的HashCode，所以這個增量對象存儲了最新的狀態HashCode值。
7、客戶端獲取增量數據的處理
還是在getAndUpdateDelta方法內，對服務端傳輸過來數據，獲取當前服務端的增量數據部分
com.netflix.discovery.DiscoveryClient#getAndUpdateDelta
這個方法的主要過程是：
如果增量數據部分為空，則執行全量拉取。
對當前服務的注冊信息表執行updateDelta(delta)方法，對當前注冊實例的增加刪除或修改操作
當前更新後的服務注冊表的HashCode值與增量對象存儲的最新的狀態HashCode值比較，如果不相等 則執行全量拉取
最新更新隊列ConcurrentLinkedQueue<RecentlyChangedItem> recentlyChangedQueue
com.netflix.eureka.registry.AbstractInstanceRegistry#AbstractInstanceRegistry類在構建創建注冊表時創建了recentlyChangedQueue隊列，並創建了一個增量調度任務方法getDeltaRetentionTask方法
com.netflix.eureka.registry.AbstractInstanceRegistry#getDeltaRetentionTask
對recentlyChangedQueue隊列中對最近改變的隊列在一定時間范圍retentionTimeInMSInDeltaQueue=180000ms(3分鍾)外的進行定時清除(30s清除一次)
3、statusUpdate
4、deleteStatusOverride
getDeltaRetentionTask進行定時清除
全量拉取與增量拉取過程類似
全量拉取調用getAndStoreFullRegistry方法
1、getAndStoreFullRegistry
com.netflix.discovery.DiscoveryClient#getAndStoreFullRegistry
2、getApplications
com.netflix.discovery.shared.transport.EurekaHttpClient#getApplications
❺ SpringCloud升級之路2020.0.x版-29.SC OpenFeign 的解析(2)
在使用雲原生的很多微服務中，比較小規模的可能直接依靠雲服務中的負載均衡器進行內部域名與服務映射，通過 健康 檢查介面判斷實例 健康 狀態，然後直接使用 OpenFeign 生成對應域名的 Feign Client。Spring Cloud 生態中，對 OpenFeign 進行了封裝，其中的 Feign Client 的各個組件，也是做了一定的定製化，可以實現在 OpenFeign Client 中集成服務發現與負載均衡。在此基礎上，我們還結合了 Resilience4J 組件，實現了微服務實例級別的線程隔離，微服務方法級別的斷路器以及重試。
我們先來分析下 Spring Cloud OpenFeign
Spring Cloud 中的任何組件，都是基於 Spring Boot 而實現的。由於 Spring Boot 中已經有了 HTTP 編碼解碼器，就可以不用單獨給 OpenFeign 單獨再實現 HTTP 編碼解碼器了，而是考慮將 OpenFeign 的編碼解碼器介面用 Spring Boot 的 HTTP 編碼解碼器實現。
在 FeignClientsConfiguration 中，提供了默認的實現：
通過源碼可以看出，默認的 Decoder 是經過幾層包裝的 Decoder，分別包括：
傳入 SpringDecoder 的 HttpMessageConverters 對象，是 spring-web 的所有 HttpMessageConverter 集合。HttpMessageConverter 是 spring-web 中對於 HTTP 請求和響應的 body 進行編碼解碼的工具。其介面結構是：
spring boot 內置了很多 HttpMessageConverter，我們也可以實現自己的 HttpMessageConverter，去實現我們自定義 MediaType，例如我們這里定義一個 ：
之後，與前面類似，將其配置到 spring boot 兼容 MVC 配置中：
編寫 Controller，測試：
使用 postman 類似的工具，指定 HTTP 請求頭：
Body 是：
請求後，就會走到 的 read 解析成 Student 對象，之後響應的 student 也會被 的 write 寫入響應 Body
由此可見， 由於 SpringEncoder 的存在，我們可以復用 Spring 內置的 HttpMessageConverter，同時也能擴展自定義我們自己的 HttpMessageConverter，非常方便 。
ResponseEntityDecoder 的代碼比較簡單，實現的效果就是解碼的時候，忽略 HttpEntity 這個 spring-web 對於 HTTP 響應的包裝類：
這個其實為了和 RestTemplate 的響應兼容，RestTemplate 可以返回 HttpEntity，但是底層 HTTP 請求返回的 body 其實並沒有包裝這個類型。
同理，JDK 中的 Optional 包裝類，也需要做同樣的事情，這個就是通過 OptionalDecoder 實現的。
SpringEncoder 編碼器也非常簡單，也是基於 spring 中的 HttpMessageConverter。這里我們就不再贅述。
❻ 微服務框架之Spring Cloud簡介
在了解 Spring Cloud 之前先了解一下微服務架構需要考量的核心關鍵點，如下圖：
對於以上等核心關鍵點的處理，不需要我們重復造車輪， Spring Cloud 已經幫我們集成了，它使用 Spring Boot 風格將一些比較成熟的微服務框架組合起來，屏蔽掉了復雜的配置和實現原理，為快速構建微服務架構的應用提供了一套基礎設施工具和開發支持。
Spring Cloud 所提供的核心功能包含：
Spring Cloud架構圖
Spring Cloud子項目
Spring Cloud 旗下的子項目大致可以分為兩類：
如下：
1. Spring Cloud 與 Spring Boot
Spring Boot 可以說是微服務架構的核心技術之一。通過在 Spring Boot 應用中添加 Spring MVC 依賴，就可以快速實現基於 REST 架構的服務介面，並且可以提供對 HTTP 標准動作的支持。而且 Spring Boot 默認提供 JackJson 序列化支持，可以讓服務介面輸入、輸出支持 JSON 等。因此，當使用 Spring Cloud 進行微服務架構開發時，使用 Spring Boot 是一條必經之路。
2. Spring Cloud 與服務治理( Eureka )
服務治理是 Spring Cloud 的核心，在實現上其提供了兩個選擇，即 Consul 和 Netflix 的 Eureka 。
Eureka 提供了服務注冊中心、服務發現客戶端，以及注冊服務的 UI 界面應用。
在 Eureka 的實現中，節點之間相互平等，有部分注冊中心「掛掉」也不會對整個應用造成影響，即使集群只剩一個節點存活，也可以正常地治理服務。即使所有服務注冊節點都宕機， Eureka 客戶端中所緩存的服務實例列表信息，也可讓服務消費者能夠正常工作，從而保障微服務之間互相調用的健壯性和應用的彈性。
3. Spring Cloud 與客戶端負載均衡( Ribbon )
Ribbon 默認與 Eureak 進行無縫整合，當客戶端啟動的時候，從 Eureka 伺服器中獲取一份服務注冊列表並維護在本地，當服務消費者需要調用服務時， Ribbon 就會根據負載均衡策略選擇一個合適的服務提供者實例並進行訪問。
Spring Cloud 通過集成 Netflix 的 Feign 項目，為開發者提供了聲明式服務調用，從而簡化了微服務之間的調用處理方式。並且默認 Feign 項目集成了 Ribbon ，使得聲明式調用也支持客戶端負載均衡功能。
4. Spring Cloud 與微服務容錯、降級( Hystrix )
為了給微服務架構提供更大的彈性，在 Spring Cloud 中，通過集成 Netflix 下子項目 Hystrix ，通過所提供的 @HystrixCommand 註解可以輕松為我們所開發的微服務提供容錯、回退、降級等功能。此外， Hystrix 也默認集成到 Feign 子項目中。
Hystrix 是根據「斷路器」模式而創建。當 Hystrix 監控到某服務單元發生故障之後，就會進入服務熔斷處理，並向調用方返回一個符合預期的服務降級處理（ fallback ），而不是長時間的等待或者拋出調用異常，從而保障服務調用方的線程不會被長時間、不必要地佔用，避免故障在應用中的蔓延造成的雪崩效應。
而 Hystrix 的儀表盤項目（ Dashboard ）可以監控各個服務調用所消耗的時間、請求數、成功率等，通過這種近乎實時的監控和告警，可以及時發現系統中潛在問題並進行處理。
5. Spring Cloud 與服務網關( Zuul )
Spring Cloud 通過集成 Netflix 中的 Zuul 實現 API 服務網關功能，提供對請求的路由和過濾兩個功能
路由功能負責將外部請求轉發到具體的微服務實例上，是實現外部訪問統一入口的基礎。
過濾器功能則負責對請求的處理過程進行干預，是實現請求校驗、服務聚合等功能的基礎。
通過 Zuul ，可以將細粒度的服務組合起來提供一個粗粒度的服務，所有請求都導入一個統一的入口，對外整個服務只需要暴露一個 API 介面，屏蔽了服務端的實現細節。通過 Zuul 的反向代理功能，可以實現路由定址，將請求轉發到後端的粗粒度服務上，並做一些通用的邏輯處理。此外， Zuul 默認會與 Eureka 伺服器進行整合，自動從 Eureka 伺服器中獲取所有注冊的服務並進行路由映射，實現 API 服務網關自動配置。
6. Spring Cloud 與消息中間件( Stream )
Spring Cloud 為簡化基於消息的開發，提供了 Stream 子項目，通過建立消息應用抽象層，構建了消息收發、分組消費和消息分片等功能處理，將業務應用中的消息收發與具體消息中間件進行解耦，使微服務應用開發中可以非常方便地與 Kafka 和 RabbitMQ 等消息中間件進行集成。
Spring Cloud Bus 基於 Stream 進行擴展，可以作為微服務之間的事件、消息匯流排，用於服務集群中狀態變化的傳播。
比如 Spring Cloud Config 藉助 Bus ，可以實現配置的動態刷新處理。
7. Spring Cloud 與分布式配置中心( Config )
針對微服務架構下的配置文件管理需求， Spring Cloud 提供了一個 Config 子項目。 Spring Cloud Config 具有中心化、版本控制、支持動態更新和語言獨立等特性。
在 Config 子項目中將微服務應用分為兩種角色：配置伺服器（ Config Server ）和配置客戶端（ Config Client ）。使用配置伺服器集中地管理所有配置屬性文件，配置服務中心可以將配置屬性文件存儲到 Git 、 SVN 等具有版本管理倉庫中，也可以存放在文件系統中。默認採用 Git 的方式進行存儲，因此可以很容易地對配置文件進行修改，並實現版本控制。
8. Spring Cloud 與微服務鏈路追蹤( Sleuth )
Spring Cloud 中的 Sleuth 子項目為開發者提供了微服務之間調用的鏈路追蹤。
Sleuth 核心思想就是通過一個全局的 ID 將分布在各微服務服務節點上的請求處理串聯起來，還原了調用關系，並藉助數據埋點，實現對微服務調用鏈路上的性能數據的採集。
因此，通過 Sleuth 可以很清楚地了解到一個用戶請求經過了哪些服務、每個服務處理花費了多長時間，從而可以對用戶的請求進行分析。此外，通過將採集的數據發送給 Zipkin 進行存儲、統計和分析，從而可以實現可視化的分析和展示，幫助開發者對微服務實施優化處理。
9. Spring Cloud 與微服務安全( Security )
Spring Cloud Security 為我們提供了一個認證和鑒權的安全框架，實現了資源授權、令牌管理等功能，同時結合 Zuul 可以將認證信息在微服務調用過程中直接傳遞，簡化了我們進行安全管控的開發。
Spring Cloud Security 默認支持 OAuth 2.0 認證協議，因此單點登錄也可以非常容易實現，並且 OAuth2.0 所生成的令牌可以使用 JWT 的方式，進一步簡化了微服務中的安全管理。
10. Spring Cloud 的其他子項目
❼ SpringCloud服務網關Zuul分析①分發
在SpringCloud中充當服務網關的角色，它包含了鑒權、流量轉發、請求統計等等功能
Filter是Zuul的核心，用來實現對外服務的控制。Filter的生命周期有4個，分別是 「PRE」、「ROUTING」、「POST」、「ERROR」 ，整個生命周期可以用下圖來表示。
PRE： 這種過濾器在請求被路由之前調用。我們可利用這種過濾器實現身份驗證、在集群中選擇請求的微服務、記錄調試信息等。
ROUTING： 這種過濾器將請求路由到微服務。這種過濾器用於構建發送給微服務的請求，並使用Apache HttpClient或Netfilx Ribbon請求微服務。
POST： 這種過濾器在路由到微服務以後執行。這種過濾器可用來為響應添加標準的HTTP Header、收集統計信息和指標、將響應從微服務發送給客戶端等。
ERROR： 在其他階段發生錯誤時執行該過濾器。 除了默認的過濾器類型，Zuul還允許我們創建自定義的過濾器類型。例如，我們可以定製一種STATIC類型的過濾器，直接在Zuul中生成響應，而不將請求轉發到後端的微服務。
根據場景需要,我們也可以自定義一些filter,穿插在整個過程的某個階段,只需要繼承ZuulFilter,並且覆蓋裡面的4個方法就可以了.
application.properties中配置:
# 禁用一些Filter的配置:
zuul.FormBodyWrapperFilter.pre.disable= true
# 路由的配置：
# 配置需要被跳轉的地址，/user/**的網址將被分發
zuul.routes.user.path=/user/**
# 重定向的地址：
zuul.routes.user.url=http://127.0.0.1:8081/
❽ SpringCloud入門簡述
微服務，是一個小型的服務，也是一種設計理念，將一個大型繁雜的系統拆分為多個小型的服務，進行獨立部署，這些服務在獨立進程中運行，通過特定的協議進行通信
優點：
缺點：
在服務通信性能上RPC更強，但是Rest更為靈活
SpringCloud是基於SpringBoot實現的微服務框架，為開發人員提供了很多快速構建分布式系統中常見模式的工具，包括配置管理、服務發現、斷路器、智能路由、微代理，控制匯流排等。
Spring Cloud專注於為典型的用例提供良好的開箱即用體驗，並為其他用例提供擴展性機制。
參考地址：
Eureka是Netflix開發的基於Rest的服務發現框架，SpringCloud基於此進行二次封裝，實現服務的管理。
創建一個Eureka服務：https://www.cnblogs.com/william-m/p/15991511.html
如果沒有Eureka，如何進行服務之間的調用?
使用Rest進行調用，先將RestTemplate注冊到Bean，然後：
Eureka遵循的是AP原則，Eureka各個節點都是平等的，部分服務節點的下線不會影響正常服務的調用，只要該服務還剩下一個節點在線就可以進行正常的服務訪問，即保證了服務可用，但是並不能保證查詢到的信息是最新的。Zookeeper的CP原則與之不同，Zookeeper會有一個master節點來保證一致性，一旦master節點掛掉，剩餘的節點會重新選舉一個leader，而選擇的過程需要時間，這期間會使得該服務癱瘓，所以需要滿足高可用的話該情況是不能夠容忍的。
Spring Cloud Ribbon是一個基於HTTP和TCP的 客戶端負載均衡 工具，基於Netflix Ribbon實現，通過輪詢、隨機等演算法選擇一個可用服務。
目的：將用戶的請求平攤的分配到多個服務上，實現高可用
最大區別：服務清單所存儲的位置
客戶端先發送請求到負載均衡伺服器，然後由負載均衡伺服器通過負載均衡演算法，在眾多可用的伺服器之中選擇一個來處理請求。
客戶端自己維護一個可用伺服器地址列表，在發送請求前先通過負載均衡演算法選擇一個將用來處理本次請求的伺服器，然後再直接將請求發送至該伺服器。
邏輯時序：RestTemplate發起請求 負載均衡器攔截器攔截 LoadBalanceClient獲取ILoadBalance 獲取服務列表 根據負載均衡器選擇一個server 發起請求 記錄調用信息
Ribbon基於HTTP和TCP客戶端的負載均衡器可以自己構建HTTP請求，使用RestTemplate發送服務
Feign基於Ribbon進行改進，採用介面的方式，將需要調用的服務的方法定義成抽象方法
Consumer應用
啟動類
為了調用Proct應用服務的介面類
Proct應用
controller
Hystrix是一個服務容錯與保護的組件，用於 服務降級 、 服務熔斷 、 服務限流 等等，能夠保證在其中一個服務出現問題的時候，不會出現級聯故障，防止雪崩，提高分布式服務的健壯性。
將某些服務停掉會i這不進行業務處理，釋放資源來維持主要服務的功能。
應對服務雪崩的一種保險措施，是微服務的鏈路保護機制，是服務降級的一種特殊處理方式。
為了應對某個服務故障的情況，保證系統的整體可用性，熔斷器會切斷對該服務的請求，返回一個比較友好的錯誤響應，直到服務恢復正常
熔斷機制的三種狀態：
示例：
熔斷：直接切斷服務的調用
降級：犧牲非核心業務保證核心服務的正常
限流：服務訪問量達到閾值後拒絕多餘的調用
Zuul是一個微服務網關。網關：是一個網路系統的前置入口。也就是說要想訪問一個有網關的網路系統請求相應的服務，需要先進入網關，然後路由到相應的服務。
通常是組成一個系統的微服務很多、或者有許可權要求時需要用到網關。
Zuul提供一個過濾器，父類為ZuulFilter，用來過濾代理請求，提供額外的功能邏輯（這點類似於AOP），包括前置過濾、路由後過濾、後置過濾、異常過濾。
ZuulFilter包含的抽象方法：filterType、filterOrder、shouldFilter、run
當微服務眾多的時候，想要管理各個服務的配置時過於繁雜，SpringCloud Config則可以用來對每個微服務的配置進行集中的管理。可以實現許可權管控、灰度發布、版本管理、格式檢驗、安全配置等。
作用：
特點：
文章來自https://www.cnblogs.com/william-m/p/16153557.html
❾ 關於Spring Cloud Alibaba，看這篇文章就夠了！（附教程資料）
首先我們需要了解一下Spring Cloud，然後再來了解Spring Cloud Alibaba；
源自官方描述：
Spring Cloud為開發人員提供了一些工具用來快速構建分布式系統中的一些常見模式和解決一些常見問題（例如配置管理、服務發現、斷路器、智能路由、微代理、控制匯流排、一次性令牌、全局鎖、領導選舉、分布式會話、群集狀態）。分布式系統的協調導致了很多樣板式的代碼（很多固定套路的代碼），使用Spring Cloud開發人員可以快速建立實現這些模式的服務和應用程序。它們在任何分布式環境中都能很好地運行，包括開發人員自己的筆記本電腦、裸機數據中心和雲計算等託管平台；
Spring Cloud為分布式系統開發的典型應用場景提供良好的開箱即用的功能:
Spring Cloud Alibaba是Spring Cloud下的一個子項目，Spring Cloud Alibaba為分布式應用程序開發提供了一站式解決方案，它包含開發分布式應用程序所需的所有組件，使您可以輕松地使用Spring Cloud開發應用程序，使用Spring Cloud Alibaba，您只需要添加一些註解和少量配置即可將Spring Cloud應用程序連接到Alibaba的分布式解決方案，並使用Alibaba中間件構建分布式應用程序系統；
Spring Cloud Alibaba 是阿里巴巴開源中間件跟 Spring Cloud 體系的融合:
動力節點的Spring Cloud Alibaba學習教程，將帶你深入掌握基於Spring Cloud Alibaba技術棧的微服務開發技術，包括nacos、sentinel、seata、gateway、skywalking等，培養獨立進行企業微服務項目架構的能力;
Spring Cloud Alibaba視頻教程
https://www.bilibili.com/video/BV1nK4y
Spring Cloud Alibaba資料下載
http://www.bjpowernode.com/?toutiao
•001.視頻導讀
•002.Spring家族產品梳理
•003.What is Spring-Cloud-Alibaba？
•004.Nacos運行環境部署
•005.向Nacos注冊中心注冊服務
•006.從Nacos發現服務並負載均衡調用
•007.從Nacos發現服務並負載均衡調用
•008.Nacos客戶端信息緩存
•009.Nacos客戶端信息緩存
•010.Nacos Config配置中心啟動讀取外部配置
•011.Nacos Config配置中心自動刷新
•012.Nacos Config配置中心yaml配置
•013.Nacos Config配置中心多環境配置
•014.問答交流
•015.內容回顧-配置中心數據模型
•016.配置中心三層結構數據配置隔離
•017.配置中心三層結構數據配置隔離
•018.配置版本回滾-服務注冊分組
•019.Nacos管控台用戶許可權管理
•020.Nacos數據持久化
•021.Nacos數據持久化
•022.Nacos集群環境部署
•023.Nacos集群環境測試
•024.Nacos集群統一入口Nginx
•025.快速回顧
•026.RestTemplate無參數Get調用返回String
•027.RestTemplate無參數Get調用返回User
•028.RestTemplate有參數Get調用返回User
•029.RestTemplate有參數Get調用返回User
•030.RestTemplate有參數Post調用返回User
•031.RestTemplate有參數Post調用返回User
•032.RestTemplate傳輸User對象參數Post調用返回User
•033.RestTemplate傳輸JSON參數Post調用返回User
•034.RestTemplate有參數Put調用
•035.RestTemplate有參數Delete調用
•036.RestTemplate方法調用梳理總結
•037.RestTemplate結合Ribbon實現負載均衡
•038.RestTemplate結合Ribbon實現負載均衡
•039.Ribbon負載均衡實現策略
•040.自定義Ribbon負載均衡實現策略
•041.更改Ribbon負載均衡實現策略
•042.Ribbon的核心介面組成
•043.Ribbon負載均衡策略個性化配置
•044.Ribbon結合Nacos實現權重負載均衡策略
•045.Ribbon結合Nacos負載均衡策優先調用同名集群
•046.Ribbon結合Nacos基於版本負載均衡策略
•047.Ribbon結合Nacos基於命名空間負載均衡策略
•048.What is Feign？
•049.Spring Cloud Alibaba基於Feign的遠程調用
•050.Spring Cloud Alibaba基於Feign+Ribbon負載均衡遠程調用
•051.Spring Cloud Alibaba基於Feign的相關配置
•052.脫離Ribbon的Feign的遠程調用
•054.微服務的級聯故障服務雪崩
•055.Spring Cloud Alibaba集成Sentinel
•056.Spring Cloud Alibaba基於Sentinel管理後台數據測試
•057.Spring Cloud Alibaba基於Sentinel實現限流
•058.Spring Cloud Alibaba基於Sentinel實現限流自定義返回結果
•059.Spring Cloud Alibaba基於Sentinel實現限流自定義跳轉頁面
•060.Spring Cloud Alibaba基於Sentinel線程數限流
•061.Spring Cloud Alibaba基於Sentinel資源關聯限流
•062.Spring Cloud Alibaba基於Sentinel流控規則和流控效果
•063.問答交流
•064.快速回顧和演示環境預備
•065.Spring Cloud Alibaba Sentinel 服務降級RT
•066.Spring Cloud Alibaba Sentinel 服務降級異常比例和異常數
•067.Spring Cloud Alibaba Sentinel 熱點參數規則
•068.Spring Cloud Alibaba Sentinel 熱點參數規則小細節
•069.Spring Cloud Alibaba Sentinel 系統保護規則
•070.Spring Cloud Alibaba Sentinel 授權規則
•071.Spring Cloud Alibaba Sentinel Dashboard控制台通信原理
•072.Spring Cloud Alibaba Sentinel 對Controller請求url埋點
•073.Spring Cloud Alibaba Sentinel 手寫代碼實現埋點
•074.Spring Cloud Alibaba Sentinel 採用註解實現埋點
•075.Spring Cloud Alibaba Sentinel 對RestTemplate流控和熔斷
•076.Spring Cloud Alibaba Sentinel 對Feign流控和熔斷
•077.問答交流
•078.Sentinel規則持久化-拉模式持久化到本地文件
•079.Sentinel規則持久化-拉模式持久化到本地文件
•080.Sentinel規則持久化-推模式持久化到Nacos
•081.Sentinel規則持久化-推模式持久化到Nacos
•082.Spring Cloud Gateway 網關功能特性
•083.Spring Cloud Gateway 網關搭建
•084.Spring Cloud Gateway 網關服務調用
•085.Spring Cloud Gateway 網關謂詞
•086.Spring Cloud Gateway 網關謂詞
•087.Spring Cloud Gateway 網關謂詞
•088.Spring Cloud Gateway 網關過濾器
•089.Spring Cloud Gateway 問答交流
•090.Spring Cloud Gateway自定義謂詞
•091.Spring Cloud Gateway自定義謂詞
•092.Spring Cloud Gateway自定義謂詞不匹配404頁面
•093.Spring Cloud Gateway自定義過濾器
•094.Spring Cloud Gateway全局過濾器
•095.Spring Cloud Gateway自定義全局過濾器
•096.Spring Cloud Gateway集成Ribbon實現負載均衡
•097.Spring Cloud Gateway集成Sentinel限流
•098.Spring Cloud Gateway集成Sentinel限流自定義錯誤頁
•099.Spring Cloud Gateway集成Sentinel規則持久化到文件
•100.Spring Cloud Gateway集成Sentinel規則持久化到Nacos
•101.Spring Cloud Gateway內部執行流程源碼分析
•102.Spring Cloud Gateway小結
•103.快速回顧
•104.Spring Cloud Gateway跨域CORS請求
•105.Spring Cloud Gateway跨域CORS請求
•106.What is SkyWalking？
•107.Skywalking運行環境部署
•108.SkyWalking Agent對微服務的鏈路追蹤
•109.SkyWalking Agent對微服務鏈路追蹤
•110.SkyWalking Agent加入IDEA中對微服務鏈路追蹤
•111.SkyWalking 監控告警通知
•112.SkyWalking 監控告警通知
•113.SkyWalking 微服務鏈路追蹤數據持久化MySQL
•114.SkyWalking 問答交流
•115.Skywalking持久化跟蹤數據elasticsearch
•116.Skywalking持久化跟蹤數據elasticsearch
•117.Skywalking對多個跨服務的鏈路跟蹤
•118.Skywalking對多個跨服務的鏈路跟蹤
•119.Skywalking自定義鏈路跟蹤
•120.Skywalking集成logback輸出traceId日誌
•121.Skywalking UI界面-儀表盤
•122.Skywalking UI界面-拓撲圖-追蹤-性能剖析-告警
•123.Skywalking 基於nacos集群
•124.Skywalking 基於nacos集群
•125.Skywalking 基於nacos集群
•126.Skywalking 問答交流
•127.What is Seata？
•128.Seata分布式事務生命周期
•129.Seata TC Server運行環境部署
•130.Seata基於AT事務模式單體應用多數據源分布式事務
•131.Seata基於AT事務模式單體應用多數據源分布式事務
•132.Seata基於AT事務模式單體應用多數據源分布式事務
•133.Seata基於AT事務模式多個微服務分布式事務
•134.Seata基於AT事務模式多個微服務分布式事務
•135.Seata基於AT事務模式多個微服務分布式事務
•136.Seata基於AT事務模式執行機制
•137.Seata AT事務模式
•138.Seata AT事務模式寫數據隔離
•139.Seata AT事務模式寫數據隔離
•140.Seata AT事務模式讀數據隔離
•141.Seata AT事務模式讀數據隔離
•142.Seata TC Server集群環境部署
•143.Seata TC Server集群環境部署
•144.Seata TC Server集群環境集成測試
•145.Seata TC Server集群環境集成測試
•146.Seata TCC事務模式的運行機制
•147.Seata TCC事務模式SpringBoot單體應用案例
•148.Seata TCC事務模式SpringBoot單體應用案例
•149.Seata TCC事務模式SpringCloudAlibab微服務應用案例
•150.Seata TCC事務模式SpringCloudAlibab微服務應用案例
•151.What is Spring Cloud Stream
•152.Spring Cloud Stream的核心概念
•153.Spring Cloud Stream集成RocketMQ配置
•154.Spring Cloud Stream集成RocketMQ發送消息
•155.Spring Cloud Stream集成RocketMQ接收消息
•156.Spring Cloud Stream集成RocketMQ監聽接收消息
•157.Spring Cloud Stream集成RocketMQ多種發送消息方式
•158.Spring Cloud Stream Starter代碼分析
•159.Spring Cloud Stream集成RocketMQ發送事務消息
•160.Spring Cloud Stream集成RocketMQ對象標簽消息
•161.Spring Cloud Stream問答交流
❿ Spring Cloud
本文中我們主要介紹微服務開發框架——Spring Cloud。盡管Spring Cloud帶有"Cloud"的字樣，但它並不是雲計算解決方案，而是Spring Boot的基礎上構建的，用於快速構建分布式系統的通用模式的工具集。
Spring Cloud有以下特點:
由上圖可知，Spring Cloud是以 英文單詞+SR+數字 的形式命名版本號的。那麼英文單詞和SR分別表示什麼呢？
因為Spring Cloud是一個綜合項目，它包含很多子項目。由於子項目也維護著自己的版本號，Spring Cloud採用了這種命名方式，從而避免與子項目的版本混淆。其中英文單詞如Edware是倫敦某地鐵站名，它們按照字母順序發行，可以將其理解為主版本的演進。SR表示"Service Release"，一般表示Bug修復。
版本兼容性如下
版本內容
可參考官方文檔： https://spring.io/projects/spring-cloud#overview
我的上一篇博客(微服務理論篇)中談到，對單體應用進行服務拆分得到各個微服務，而這些服務又是相互獨立的，那麼我們如何知道各個微服務的健康狀態、如何知道某個微服務的存在呢？由此、一個擁有服務發現的框架顯得尤為重要。這也就是Eureka誕生的原因。
綜上，Eureka通過心跳檢查、客戶端緩存等機制，確保了系統的高可用性、靈活性和可伸縮性。
通過使用Eureka已經實現了微服務的注冊與發現。啟動各個微服務時，Eureka Client會把自己的網路信息注冊到Eureka Server上。似乎一切更美好了一些。然而，這樣的架構依然有一些問題，如負載均衡。一般來說，各個微服務都會部署多個實例。那麼服務消費者要如何將請求分攤到多個服務提供實例上呢？
如果服務提供者相應非常慢，那麼消費者對提供者的請求就會被強制等待，知道提供者響應或超時。在高負載場景下，如果不作任何處理，此類問題可能會導致服務消費者的資源耗竭甚至整個系統崩潰。
微服務架構的應用系統通常包含多個服務層。微服務之間通過網路進行通信，從而支撐起整個應用系統，因此，微服務之間難免存在依賴關系。而這種由於"基礎服務故障"導致"級聯故障"的現象稱為雪崩效應。
如圖所示，A最為服務提供者（基礎服務），B為A的服務消費者，C和D是B的服務消費者。當A不可用引起了B的不可用，並將不可用像滾雪球一樣放大到C和D時，雪崩效應就形成了。
那麼Hystrix是如何容錯的呢？
以下對該圖做個簡單講解：
Zuul作為微服務架構中的微服務網關。微服務架構經過前幾個組件的組合，已經有了基本的雛形了，那麼我們為什麼還要使用微服務網關呢？我們可以想像，一般情況下我們一個業務並不是只調用一個介面就可以完成一個業務需求。
如果讓客戶端直接與各個微服務通信，會有以下問題：
如圖，微服務網關封裝了應用程序的內部結構，客戶端只須跟網關交互，而無須直接調用特定微服務介面。同時，還有以下優點：
為什麼要同一管理微服務配置？
對於傳統的單體應用，常常使用配置文件管理所有配置。例如一個Spring Boot 項目開發的單體應用，可以將配置內容放到application.yml文件中。如果需要切換環境，可以設置多個Profile,並在啟用應用時指定spring.profile.active={profile}。
而在微服務架構中，微服務的配置管理一般有以下需求：