向大佬們學習的第二天 2020.4.16-4.17
微服務（二）
Feign 聲明式客戶端
Feign是NetFlix開發的聲明式、模板化的HTTP客戶端，用於更便捷、優雅地調用HTTP API。
SpringCould對Feign進行了增強，使Feign支持Spring MVC註解、整合了Ribbon和Eureka，讓Feign使用更方便
可能是剛開始接觸微服務的關係、我對用Rest Template 或 Feign框架 的感觸不深，只是說Rest Template相對比較單一和基礎、Feign在Http請求的基礎上新增了很多功能，包括Ribbon負載均衡、Eureka註冊中心
zuul 服務網關
首先我們來看一下在沒有Zuul 服務網關之前的微服務架構
使用Eureka作爲服務註冊中心、來進行服務端和客戶端服務註冊與發現，而服務之間通過Ribbon和Fegin實現負載均衡和服務消費，通過spring could config進行外部化配置中心，用Hystrix熔斷機制避免微服務架構中部分服務故障導致的蔓延。
這樣架構存在的不足：
破壞了服務的無狀態特點，如果我們要實現對服務的訪問權限控制、而開放服務的權限控制機制將貫穿並污染整個開放服務的業務邏輯，破壞服務集羣的RESTAPI無狀態特點
無法直接複用既有的Client接口，實現外部訪問時，不能不在原有接口的基礎上，添加校驗邏輯。
因此、這裏引入 服務網關 Zuul
可以通過服務網關，將業務組件中的權限控制、日誌打印等通用東西從我們的業務組件中抽出去，放到訪問請求的最前端
Zuul是Netflix開源發微服務網關，核心是一系列的過濾器
特徵：
身份認證與安全：識別每個資源的驗證，拒絕不符合的要求
審查與監控
動態路由：動態地將請求路由到不同的後端路由
壓力測試；
負載分配：可以和Nginx配合使用
靜態響應處理：在邊緣位置直接建立部分響應，避免其轉發到內部集羣
在用戶請求服務之前，會先通過Zuul服務網關，通過Zuul進行一系列認證校驗或者邏輯校驗、通過後轉發到後端服務，所以後端微服務只需要關注業務邏輯即可，當然也就可以直接複用。
用Nginx進行轉發的話：
Zuul中最重要的就是過濾器：ZuulFliter
ZuulFilter是一個抽象類，其實現類需要實現4個方法：
shouldFilter：返回一個Boolean值，判斷該過濾器是否需要執行。返回true執行，返回false不執行。
run：過濾器的具體業務邏輯。
filterType：返回字符串代表過濾器的類型
a)pre：請求在被路由之前執行
b)routing：在路由請求時調用
c)post：在routing和errror過濾器之後調用
d)error：處理請求時發生錯誤調用
filterOrder：通過返回的int值來定義過濾器的執行順序，數字越小優先級越高。
Config 分佈式配置中心
爲什麼不把各自的配置文件放到各自的項目中，而要把他們抽出來進行分佈式配置，統一進行管理？
假如說：項目已經啓動，而數據庫服務器的IP地址突然變了，這個時候是不是隻能重啓服務器了？
假如說：我有多個項目的配置文件都要變了，是不是每個項目都需要重啓然後才能搞定？
Spring Could Config 爲分佈式系統外部化配置提供了服務端和客戶端的支持，包括Config Server 和 Config Client。
Config Server 是一個可橫向擴展、集中式的配置服務器，它用於集中管理應用程序各個環境下的配置，默認使用Git存儲配置文件內容，也可以用SVN、本地存儲、GitHub等
Config Client 是 客戶端，用於操作存儲在Config Server中的配置內容，微服務在啓動的時候會去請求Config Server獲取到配置文件，然後把它們注入到容器中，啓動容器。
雖然使用了分佈式的配置，每個Config Client 業務服務在啓動的時候都去調用你的Config Server獲取配置信息，但是當你改變Server中配置信息的時候，Client是不會自動更新的，所以在需要用到actuator，調用actuator的refresh請求，可以刷新Client中的配置信息。這裏又可以通過git中的鉤子（Web Hook），在每次更新Server配置的時候動態去調用actuator中的refresh請求。
但問題又來了，如果Client非常多，一個一個請求的去刷新好像也不是個事，所有這裏可用通過消息總線（Spring could Bus）消息隊列的方法去實現。
具體RabbitMQ的內容在下一章節展開