一、什么是微服務架構？
????????微服務架構是一種架構模式或者說是一種架構風格， 它提倡將單一應用程序劃分成一組小的服務 ，每個服務運行在其獨立的自己的進程中 ，服務之間互相協(xié)調(diào)、互相配合，為用戶提供最終價值。服務之間采用輕量級的通信機制互相溝通（通常是基于HTTP的RESTful API）。每個服務都圍繞著具體業(yè)務進行構建，并且能夠被獨立地部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等。另外，應盡量避免統(tǒng)一的、集中式的服務管理機制，對具體的一個服務而言，應根據(jù)業(yè)務上下文，選擇合適的語言、工具對其進行構建，可以有一個非常輕量級的集中式管理來協(xié)調(diào)這些服務，可以使用不同的語言來編寫服務，也可以使用不同的數(shù)據(jù)存儲。?
二、微服務的優(yōu)缺點
優(yōu)點 ：
①每個服務足夠內(nèi)聚，足夠小，代碼容易理解這樣能聚焦一個指定的業(yè)務功能或業(yè)務需求 ，開發(fā)簡單、開發(fā)效率提高，一個服務可能就是專一的只干一件事。
②微服務能夠被小團隊單獨開發(fā)，這個小團隊是2到5人的開發(fā)人員組成。?微服務易于被一個開發(fā)人員理解，修改和維護，這樣小團隊能夠更關注自己的工作成果。無需通過合作才能體現(xiàn)價值。?
③微服務是松耦合的，是有功能意義的服務，無論是在開發(fā)階段或部署階段都是獨立的。?微服務只是業(yè)務邏輯的代碼，不會和HTML,CSS 或其他界面組件混合。微服務允許你利用融合最新技術。
④微服務能使用不同的語言開發(fā)。?每個微服務都有自己的存儲能力，可以有自己的數(shù)據(jù)庫。也可以有統(tǒng)一數(shù)據(jù)庫。?
⑤易于和第三方集成，微服務允許容易且靈活的方式集成自動部署，通過持續(xù)集成工具，如Jenkins, Hudson, bamboo 。?
缺點：
①開發(fā)人員要處理分布式系統(tǒng)的復雜性?
②多服務運維難度，隨著服務的增加，運維的壓力也在增大?
③系統(tǒng)部署依賴?
④服務間通信成本?
⑤數(shù)據(jù)一致性?
⑥系統(tǒng)集成測試?
⑦性能監(jiān)控
三、微服務技術棧
四、當前各微服務框架對比
五、SpringCloud是什么？
????????SpringCloud，基于SpringBoot提供了一套微服務解決方案，包括服務注冊與發(fā)現(xiàn)，配置中心，全鏈路監(jiān)控，服務網(wǎng)關，負載均衡，熔斷器等組件，除了基于NetFlix的開源組件做高度抽象封裝之外，還有一些選型中立的開源組件。?SpringBoot并沒有重復制造輪子，它只是將目前各家公司開發(fā)的比較成熟、經(jīng)得起實際考驗的服務框架組合起來，通過SpringBoot風格進行再封裝屏蔽掉了復雜的配置和實現(xiàn)原理， 最終給開發(fā)者留出了一套簡單易懂、易部署和易維護的分布式系統(tǒng)開發(fā)工具包?
? ? ? ? SpringCloud=分布式微服務架構下的一站式解決方案，是各個微服務架構落地技術的集合體，俗稱微服務全家桶。
六、SpringCloud和SpringBoot關系
? ??????SpringBoot專注于快速方便的開發(fā)單個個體微服務。 SpringCloud是關注全局的微服務協(xié)調(diào)整理治理框架，它將SpringBoot開發(fā)的一個個單體微服務整合并管理起來， 為各個微服務之間提供，配置管理、服務發(fā)現(xiàn)、斷路器、路由、微代理、事件總線、全局鎖、決策競選、分布式會話等等集成服務 SpringBoot可以離開SpringCloud獨立使用開發(fā)項目， 但是SpringCloud離不開SpringBoot ，屬于依賴的關系。
? ? ? ? 總結來說：SpringBoot專注于快速、方便的開發(fā)單個微服務個體，SpringCloud關注全局的服務治理框架。?
七、SpringCloud和Dubbo的對比
底層協(xié)議：springcloud基于http協(xié)議，dubbo基于Tcp協(xié)議，決定了dubbo的性能相對會比較好
注冊中心：Spring Cloud 使用的 eureka ，dubbo推薦使用zookeeper
模型定義：dubbo 將一個接口定義為一個服務，SpringCloud 則是將一個應用定義為一個服務
SpringCloud是一個生態(tài)，而Dubbo是SpringCloud生態(tài)中關于服務調(diào)用一種解決方案（服務治理）
? ??????最大區(qū)別：SpringCloud拋棄了Dubbo的RPC通信，采用的是基于HTTP的REST方式。?
????????嚴格來說，這兩種方式各有優(yōu)劣。雖然從一定程度上來說，后者犧牲了服務調(diào)用的性能，但也避免了原生RPC帶來的問題。而且REST相比RPC更為靈活，服務提供方和調(diào)用方的依賴只依靠一紙契約，不存在代碼級別的強依賴，這在強調(diào)快速演化的微服務環(huán)境下，更加合適。?
????????最為重要的是，DUBBO停止了5年左右的更新。雖然2017.7重啟了。對于技術發(fā)展的新需求，需要由開發(fā)者自行拓展升級（比如當當網(wǎng)弄出了DubboX），這對于很多想要采用微服務架構的中小軟件組織，顯然是不太合適的，中小公司沒有這么強大的技術能力去修改Dubbo源碼+周邊的一整套解決方案，并不是每一個公司都有阿里的大牛+真實的線上生產(chǎn)環(huán)境測試過。?
八、服務注冊中心
1.什么是服務治理？
????????SpringCloud封裝了Netflix公司開發(fā)的Eureka模塊實現(xiàn)服務治理，在傳統(tǒng)的rpc遠程調(diào)用框架中，管理每個服務與服務之間的依賴關系比較復雜，管理比較復雜，所以需要服務治理，管理服務與服務之間的依賴關系，可以實現(xiàn)服務調(diào)用，負載均衡，容錯等，實現(xiàn)服務發(fā)現(xiàn)與注冊。
2.什么是服務注冊與發(fā)現(xiàn)？
? ? ? ? Eureka采用了CS的設計架構，Eureka Server作為服務注冊功能的服務器，他是服務注冊中心，而系統(tǒng)中其他微服務，使用Eureka客戶端連接到Eureka Server并維持心跳連接。這樣系統(tǒng)的維護人員就可以通過Eureka Server 來檢測系統(tǒng)中各個微服務模塊是否正常運行。
? ? ? ? 在服務注冊與發(fā)現(xiàn)中，有一個注冊中心。當服務器啟動時，會把當前自己服務器的信息，比如服務地址通訊地址以別名方式注冊到注冊中心。另一方，消費者，以該別名的方式去注冊中心獲取到實際的服務通訊地址，然后實現(xiàn)本地RPC調(diào)用RPC遠程調(diào)用，框架核心設計思想在于注冊中心，因為使用注冊中心管理每個服務于服務之間的一個依賴關系（服務治理概念）。在任何RPC遠程框架中，都會有一個注冊中心（存放服務地址相關信息（接口地址））。
3.Eureka
3.1Eureka服務發(fā)現(xiàn)怎么做？
? ??首先在Controller中加入
@Resource
private? DiscoveryClient? ? discoveryClient;
? ??然后調(diào)用discoveryClient就可以獲取到當前注冊中心中的信息，在主啟動類中加入一個@EnableDiscoveryClient注解就可以實現(xiàn)一個簡單的注冊發(fā)現(xiàn)了
3.2.Eureka的自我保護機制
????????意思就是，某時刻某一個微服務不可用了，Eureka不會立即清理，依舊會對該服務的信息進行保存。寧可保留可能錯誤的服務注冊信息，也不會盲目注銷掉任何可能健康的服務實例。真好死不如賴活著。
????????產(chǎn)生的原因是：為了防止可能是EurekaServer網(wǎng)絡不通暢，但是其實EurekaClient是正常運行的，所以，Eureka會有那么一種保護機制。是一種AP的設計思想，高可用。
? ? ? ? 默認情況下，如果EurekaServer在一定時間內(nèi)（默認90秒）沒有收到EurekaClient向EurekaServer發(fā)送的心跳包，便會直接從服務注冊列表中剔除該服務，但是如果在短時間內(nèi)丟失了過多的客戶端，那么這個節(jié)點就進入了自我保護模式。
3.3.Eureka的自我保護機制的禁用：
4.Zookeeper??
在conf目錄下，新建一個名為zoo.cfg的文件，其中內(nèi)容如下：
4.1注冊進zookeeper
1.pom文件引入jar包
2.yml文件配置好
3.controller測試一下
4.成功后的結果
????????和Eureka自我保護機制來看，Zookeeper是一個提供的服務是一個臨時節(jié)點，一定時間內(nèi)，如果接受不到心跳，就會把入駐的踢掉，如果你又回來了，又是陌生人，絲毫不念舊情，無情的一批，Zookeeper比Eureka更加的無情。
5.Consul服務注冊與發(fā)現(xiàn)
5.1Consul的安裝
1.下載地址https://www.consul.io/downloads.html
2.將解壓后的文件consul ?拷貝到/usr/local/bin下
? ? sudo cp consul /usr/local/bin
3.打開bin文件，執(zhí)行consul，查看consul命令，如下即表示成功
4.啟動consul
consul agent -dev
啟動成功之后可以訪問consul的頁面?http://localhost:8500/
6..三種服務注冊框架的異同點
CAP：
????????C : Consistency(強一致性)
????????A : Availability(可用性)
????????P : Partition tolerance(分區(qū)容錯性)
? ? ? ? CAP的核心是，一個分布式系統(tǒng)不可能同時滿足很好的一致性、可用性和分區(qū)容錯性三個需求，因此，根據(jù)CAP原理可以將其分為三類:
? ? ? ? CA：單點集群，滿足一致性，可用性的系統(tǒng)，通?？蓴U展性上不太強大。
? ? ? ? CP：滿足一致性，分區(qū)容忍性的系統(tǒng)，通常性能不是特別高。
? ? ? ? AP：滿足可用性，分區(qū)容忍性的系統(tǒng)，通常對一致性大的要求低一些。
????????綜上來看，只有Eureka是AP的，保證高可用，當注冊的用戶斷掉之后，會認為是網(wǎng)絡出現(xiàn)了問題，認為注冊的用戶是沒問題的，保證了高可用，而Consul和Zookeeper是CP，要保證一致性，當客戶端宕機之后，Server沒有收到心跳包，會將客戶端移除，有就是有，沒有就是沒有，保證一致性。Eureka和Consul是自帶前臺頁面展示的，而Zookeeper只有客戶端。
? ? ? ? 所以，我個人更喜歡Consul，而且Consul的界面更加簡單美觀易懂。
九、服務調(diào)用
1.Ribbon? ??
????1.1Ribbon是什么
????????SpringCloud Ribbon是基于Netflix Ribbon實現(xiàn)的一套客戶端負載均衡工具。主要功能是提供客戶端的軟件負載均衡算法和服務調(diào)用，提供一系列完善的配置如連接超時，重試等。簡單來說，就是配置文件中列出Load Balancer（簡稱LB）后面所有的機器，Ribbon會自動幫助基于某種規(guī)則（如簡單輪詢，隨機連接等）去連接這些機器。
????1.2LB負載均衡是什么？
????????簡單來說就是將用戶的請求平攤的分配到多個服務上，從而達到HA(高可用)。常見的負載均衡軟件有Nginx、LVS、硬件F5等
????1.3Ribbon本地負載均衡客戶端? VS? Nginx服務端負載均衡
????????Nginx是服務器負載均衡，客戶端會將請求都發(fā)給Nginx，然后由nginx實現(xiàn)轉發(fā)請求，即負載均衡是在服務端實現(xiàn)的。屬于集中式LB（即在服務的消費方和提供方之間使用的獨立的LB設施，由該設施負責把訪問請求通過某種策略轉發(fā)到服務的提供方）。
? ? ? ? Ribbon是本地負載均衡，在調(diào)用微服務接口時，會在注冊中心上獲取注冊信息服務列表之后緩存到JVM本地，從而實現(xiàn)RPC遠程調(diào)用技術。屬于進程式LB（將邏輯集成到消費方，消費方從服務注冊中心獲知有哪些地址可用，然后自己再從這些地址中選擇一個合適的服務器）。它只是一個類庫，集成于消費方進程，消費方通過他來獲取到服務提供方的地址。
????1.4Ribbon工作流程圖
? ? ? ? 一、先選擇EurekaServer，它優(yōu)先選擇在同一個區(qū)域內(nèi)負載較少的Server
? ? ? ? 二、根據(jù)用戶指定的策略，在server取到的服務提供者列表選擇一個地址
? ? ? ? 其中Ribbon有很多的策略，比如輪詢、隨機和根據(jù)響應時間加權。
?1.5RestTemplete
????????兩個模塊，一個是采購模塊，一個是支付模塊，假如采購模塊要調(diào)用支付模塊的接口，可以使用RestTemplete。在后面調(diào)用會使用Openfeign來實現(xiàn)。
? ? ? ? 如上就可以訪問cloud-payment-service的/payment/get/{id}路徑了
????????使用RestTemplete一般是getForObject方法和getForEntity，對比來看，前者返回的基本上可以理解為json，后者返回的則更加全面，可以獲得響應中的一些重要信息，比如說響應頭、響應狀態(tài)碼、響應體等。一般常用getForObject()方法
1.6問：有沒有使用過Ribbon其他負載均衡的算法，有沒有手寫過，設計思想是什么？
1.6.1首先Ribbon自帶的負載均衡算法一共有七種：
1.6.2默認的負載均衡算法是輪詢，那怎么替換成別的方法？
? ? ? ? 首先，官網(wǎng)特殊說明，不要將自定義配置類放在@ConponentScan所能掃描的當前包以及子包下，會達不到特殊定制化的目的。而@SpringBootApplication注解會將所有本包以及本包以下掃入，所以新建一個包myrule，在里面定制規(guī)則，然后在主啟動類加上注解如圖
1.6.3負載均衡輪詢算法原理：
? ??????rest接口第幾次請求數(shù)%服務器集群總數(shù)量=實際調(diào)用服務器下標。比如1%2=1；2%2=0；3%2=1.......輪流著調(diào)用下標為0和1的服務器。注意：每次服務重啟后rest接口計數(shù)從1開始。
1.6.4手寫輪詢算法：
? ? ? ? 學完JUS再回來補充、42節(jié)
2.OpenFeign
2.1.OpenFeign是什么？
? ? ? ? OpenFeign是一個聲明式web服務客戶端，讓編寫Web服務客戶端變得更加容易，只需要創(chuàng)建一個接口并在接口上添加注解即可。Feign也可以支持拔插式的編碼器和解碼器。SpringCloud對Feign進行了封裝，使其支持了Spring MVC標準注解和HttpMessageConverters。Feign可以與Eureka和Ribbon組合使用以支持負載均衡。
2.2Feign能干什么
? ? ? ? 前面在使用Ribbon時候，利用RestTemplete對http請求封裝處理形成一套模板化的調(diào)用方法。但是在實際開發(fā)過程中，由于對服務依賴的調(diào)用可能不止一處，往往一個接口會被多處調(diào)用，所以通常都會針對每個微服務自行封裝一些客戶端類來包裝這些依賴服務的調(diào)用，所以Feign在此基礎上做了進一步的封裝，我們只需要在一個微服務接口上標注一個Feign注解即可完成對服務提供方的接口綁定，簡化了Spring Cloud Ribbon時，自動封裝服務調(diào)用客戶端的開發(fā)量。
? ? ? ? 可Ribbon對比，F(xiàn)eign只需要在服務調(diào)用接口上加一個注解就可以了，優(yōu)雅而簡單的實現(xiàn)了服務調(diào)用。
2.3.OpenFeign和Feign對比
2.4.OpenFeign的使用
????????1.pom文件引入依賴
????????2.寫yml
????????3.寫主啟動類，注意要加上@EnableFeignClients注解
????????4.業(yè)務類：新建一個Service接口，在接口上加注解@FeignClient(value ="cloud-payment-service")，并指向要調(diào)用的服務實例名。然后在接口中加入在服務端Controller調(diào)用的方法。然后在客戶端調(diào)用接口即可，上圖來理解：
2.5.OpenFeign的超時控制
? ? ? ? 注意OpenFeign默認等待一秒鐘，但是服務端處理需要超過1s，導致Feign客戶端返回報錯，Read timed out，讀取超時，而我們有時候需要設置Feign客戶端的超時控制，就在yml文件中進行設置。
2.6日志打印功能
????????其實就是 OpenFeign提供了對Feign接口調(diào)用情況進行監(jiān)控和輸出。日志級別一共分為四類：
NONE：默認的，不顯示任何日志；
BASIC：僅記錄請求方法、URL、響應狀態(tài)碼及執(zhí)行時間。
HEADERS：除了BASIC中定義的信息·，還有請求和響應的頭信息。
FULL：除了HEADERS中定義的信息，還有請求和響應的正文及元數(shù)據(jù)。
十、服務降級
1.Hystrix斷路器
1.1.Hystrix是干嘛的
????????Hystrix是一個用于處理分布式系統(tǒng)的延遲和容錯的一個開源庫，在分布式系統(tǒng)里，許多依賴不可避免的會調(diào)用失敗，比如超時、異常等，Hystrix能保證在一個依賴出現(xiàn)問題的情況下，不會導致整體服務失敗，避免級聯(lián)故障，以提高分布式系統(tǒng)的穩(wěn)定性。“斷路器”本身是一種開關裝置，當某個服務單元發(fā)生故障之后，通過斷路器的故障監(jiān)控（類似熔斷保險絲），向調(diào)用方返回一個符合預期的，可處理的備選響應，而不是長時間等待或者拋出調(diào)用方無法處理的異常，這樣就保證了服務調(diào)用方的線程不會被長時間、不必要的占用，從而避免了故障在分布式系統(tǒng)中的蔓延，乃至雪崩。
1.2.服務降級（Fallback）
? ? ? ? 1.2.1什么是服務降級
????????假設對方系統(tǒng)不可用了，向調(diào)用方返回一個符合預期的，可備選的響應。服務器忙，請稍后重試，不讓客戶等待并立刻返回一個友好的提示，這就是服務降級。就像if( ){ }else if{}....有備選方案。再比如給10086打電話，客服繁忙...
? ? ? ? 出現(xiàn)服務降級的情況：
? ? ? ? ①程序運行異常；②超時；③服務熔斷觸發(fā)服務降級；④線程池/信號量打滿也會導致服務降級。
? ? ? ? 1.2.2進行服務降級的情況
????????用jmeter進行壓力測試，開啟20000個線程進行測試，測試服務端8001環(huán)境下的兩個地址，結果發(fā)現(xiàn)不僅壓測訪問的地址變慢，同一微服務下的另一個地址訪問也變慢了，假設客戶端80訪問，一定會更慢，那樣客戶端一定會很不滿意。那就來試一下，讓客戶端訪問：8001同一層次的其它接口服務被困死（20000個線程訪問），因為tomcat線程池里面的工作線程已經(jīng)被擠占完畢，80此時調(diào)用8001，客戶端訪問響應會變慢，轉圈圈。正是因為這些故障和不佳表現(xiàn)，才有我們的降級、容錯、限流等技術的產(chǎn)生，來吧老弟。
? ??????解決要求：超時導致服務器變慢（轉圈）：超時不再等待；出錯（宕機或程序運行出錯）：出錯要有兜底。
? ? ? ? 1.2.3解決方案
????????對方服務(8001)超時了，調(diào)用者(80)不能一直卡死等待，必須有服務降級；對方服務（8001）宕機了，調(diào)用者(80)不能一直卡死等待，必須服務降級；對方服務(8001)OK(可能)，調(diào)用者(80)自己出故障或有自我要求（自己的等待時間小于服務提供者)，自己處理降級。
? ? ? ? 1.2.4如何啟用服務降級
? ? ? ? 首先服務端來做一下降級試一下。
? ? ? ? ①首先在業(yè)務類中加入新的配置標簽@HystrixCommand，相當于在fallbackMethod中添加一個方法，如下value設置為3s，當超過3秒時，就會調(diào)用備用的方法，或者是方法中運行錯誤，比如說是以下的10/0報錯。
? ? ? ? ②然后在主啟動類中加入@EnableCircuitBreaker，這樣就可以在服務提供端測試自己的服務降級了
? ? ? ? 而一般Hystrix服務降級fallback是放在客戶端的，步驟如下：
? ? ? ? ①首先在yml加上hystrix和feign的配置
????????②在主啟動類中添加注解@EnableHystrix
? ? ? ? ③在業(yè)務類中利用Hystrix實現(xiàn)服務降級就行了，跟服務提供端類似。在這里消費者端的服務降級時間設置的是1.5秒，而上面服務端設置的時間是3s，加入服務端線程運行時間實際花費了2秒，在客戶端照樣會發(fā)生服務降級，而以下10/0在會直接進行降級。
? ? ? ? 上面的方法是利用openfeign直接調(diào)用服務端提供的方法。是前面學習過的。
? ? ? ? 1.2.5設置全局通用服務降級方法
????????目前存在的問題，每個業(yè)務方法都會有一個兜底的方法，會導致代碼膨脹，可以設置一個全局通用的服務降級兜底的方法，如果需要特殊配置的在另外配。需要加入一個新的注解：DefaultProperties(defaultFallback=" ")統(tǒng)一跳轉到處理結果頁面。這樣可以使得代碼量大大減少。
????????首先在類上加上新的注解，其他的方法沒有設置fallback屬性的話，就會進入全局fallback方法。
????????就像這樣，下面的方法只添加了@HystricCommand注解，如果出現(xiàn)異常就會進入payment_global_fallback兜底方法。
1.2.6通配服務降級
? ? ? ? 目前來看，耦合度太高，在controller中要聲明很多兜底的方法以備用，可以從源頭來解決這個問題，在這里使用的feign調(diào)用的服務端提供的方法，可以直接在這個調(diào)用類里進行解決，如下：寫一個fallback的類直接實現(xiàn)這個接口，一旦這個接口中的某個方法出現(xiàn)了問題，會直接調(diào)用實現(xiàn)類中的方法。如果發(fā)生運行、超時、宕機異常都會導致降級，而下面的paymentinfo_OK在其他地方?jīng)]有配置降級方法，如果8001宕機，一定會調(diào)用下面實現(xiàn)類的paymentinfo_OK方法。
1.3服務熔斷（break）? ? ? ??
? ? ? ? 類似保險絲達到最大服務訪問時，直接拒絕訪問，拉閘限電，然后調(diào)用服務降級的方法并返回友好提示。斷路器就相當于是保險絲。
? ? ? ? 熔斷機制的描述：熔斷機制是應對雪崩效應的一種微服務鏈路保護機制，當扇出鏈路某個微服務出錯不可用或者響應時間太長時，會進行服務降級，進而熔斷該節(jié)點微服務的調(diào)用，快速返回錯誤信息。當檢測到該節(jié)點微服務調(diào)用響應正常后，恢復調(diào)用鏈路。熔斷機制通過Hystrix實現(xiàn)，Hystrix會監(jiān)控微服務間的調(diào)用的狀況，當失敗的調(diào)用到一定的閾值，缺省是5秒內(nèi)20次調(diào)用失敗，就會啟動熔斷機制，熔斷機制的注解是@HystrixCommand。
????????如以下所示，仍然還是在HystrixCommand注解中進行配置，在上面加了四個Hystrix新的屬性配置，意思就是在10s的窗口期內(nèi)，發(fā)送十次請求，假如說有60%也就是6次都失敗了，就激活斷路器。而當他斷路器激活以后，所有的請求都無法處理了，而過一段時間之后，斷路器又會嘗試著讓少量的請求通過一下(也就是斷路器進入了half-open狀態(tài))，而如果請求仍然失敗，斷路器又會重新回到open狀態(tài)，如果請求成功，斷路器則會關閉。也就是鏈路恢復。
? ? ? ? 在controller中寫出響應的調(diào)用，然后進行訪問，如果十次中有六次及以上是負數(shù)，會發(fā)現(xiàn)，第11次時就算是正數(shù)仍然會進入fallback方法，因為此時進行了服務熔斷。
1.4服務限流：(flowlimit)
? ? ? ? 秒殺高并發(fā)的操作，嚴禁一窩蜂的過來擁擠，大家排隊，一秒鐘N個，有序的進行。
會在SpringCloudAlibaba中進行講解
1.5 Hystrix工作流程總結
1.6 接近實時的監(jiān)控
? ? ? ? Hystrix還提供了準實時的調(diào)用監(jiān)控（Hystrix Dashboard），Hystrix會持續(xù)的記錄所有通過Hystrix發(fā)起的請求的執(zhí)行信息，并以統(tǒng)計報表和圖形的形式展示給用戶，包括每秒執(zhí)行多少請求，多少成功，多少失敗等。Netflix通過hystrix-metrics-event-stream項目實現(xiàn)了對以上指標的監(jiān)控。Spring Cloud也提供了Hystrix Dashboard的整合，對監(jiān)控內(nèi)容轉化成可視化界面。
1.6.1搭建流程
①首選創(chuàng)建一個新的module，導入pom，主要是spring-cloud-starter-netflix-hystrix-dashboard
<dependency>
????????<groupId>org.springframework.cloud</groupId>
????????<artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId>
</dependency>
注意還有一個依賴，這個依賴如果是要進行圖形化展示是一定要有的，一般和web同時存在
<dependency>
????????<groupId>org.springframework.boot</groupId>
????????<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
②然后配置yml
暫且配置一個端口號就夠用了
③主啟動類，注意添加了一個新的注解：@EnableHystrixDashboard，一般要用一個新的功能，就要添加新的注解
④：最后訪問localhost://9001/hystrix就可以顯示了? ??
1.6.2進一步配置以進行監(jiān)控
????????Hystrix的服務監(jiān)控需要自己配置，對于傳統(tǒng)的微服務架構一定是夠用了，而spring Cloud Alibaba提供的微服務監(jiān)控可以直接訪問，在后面會學習到，主要進行sentienl的學習。
十一、路由網(wǎng)關
????????因為zuul在升級換代的時候，核心人員跳槽，技術選型出現(xiàn)分歧，導致現(xiàn)在zuul無人維護，而zuul2正在研發(fā)當中，所以spring自己驗證了一個路由網(wǎng)關技術，也就是Gateway
1.概述簡介
? ? ? ? 解決痛點：前臺頁面發(fā)送過來的請求都會先給到網(wǎng)關，網(wǎng)關可以從注冊中心中實時的感知一個服務的上線還是下線，總是能路由到正確的位置。每一個請求過來后要鑒權，限流...Gateway旨在提供一種簡單而有效的方式來對API進行路由，以及提供一些強大的過濾器的功能，例如：熔斷、限流、重試等。
SpringCloudGateway是Spring Cloud的一個全新的項目，旨在為微服務架構提供一種簡單有效的統(tǒng)一的API路由管理方式。SpringCloud Gateway作為SpringCloud生態(tài)系統(tǒng)中的網(wǎng)關，目標是替代Zuul，在SpringCloud2.0以上的版本中，沒有對應的新版本的Zuul2.0以上最新高性能版本進行集成，仍然還是使用Zuul1.x非Reactor模式的老版本，而為了提高網(wǎng)關的性能，SpringCloud Gateway是基于WebFlux框架實現(xiàn)的，而WebFlux框架底層則使用了高性能的Reactor模式通信框架Netty?；诟卟l(fā)和異步非阻塞式通信就非常的有優(yōu)勢。
? ? ? ? SpringCloudGateway目標是提供統(tǒng)一的路由方式基于Filter鏈的方式提供了網(wǎng)關的基本功能，例如：安全，監(jiān)控/指標，限流。
2.三大核心概念
路由（Route）：路由是構建網(wǎng)關的基本模塊，他由ID，目標URI，一系列的斷言和過濾器組成，如果斷言為true，則匹配該路由。
斷言（Predicate）：開發(fā)人員可以匹配HTTP請求中的所有內(nèi)容（例如請求頭和請求參數(shù)），如果請求頭與斷言相匹配則進行路由。
過濾（Filter）：指的是Spring框架中GatewayFilter的實例，使用過濾器，可以在請求被路由前或者之后對請求進行·修改。
3.Gateway工作流程
? ? ? ? 核心邏輯：路由轉發(fā)，執(zhí)行過濾器鏈? ? ? ?
????????客戶端向SpringCloudGateway發(fā)出請求，然后在Gateway Handler Mapping中找到與請求相匹配的路由，將其發(fā)送到Gateway Web Handler。
? ? ? ? Handler再通過指定的過濾器鏈來將請求發(fā)送到我們實際的服務執(zhí)行業(yè)務邏輯，然后返回。在經(jīng)過過濾器可能會發(fā)送請求之前和之后執(zhí)行邏輯（pre和post）。Filter在"pre"中可以進行參數(shù)校驗、權限校驗、流量監(jiān)控、日志輸出、協(xié)議轉換這些。在"post"類型的過濾器可以做響應內(nèi)容、響應頭修改、日志的輸出、流量監(jiān)控等有著重要的作用。
4.入門配置
首先：添加依賴·，注意吧web和actuator依賴去除掉
<dependency>
????<groupId>org.springframework.cloud</groupId>
????<artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
②配置yml文件
③最后啟動類就可以了，配置網(wǎng)關不需要任何的業(yè)務邏輯
④測試，發(fā)現(xiàn)可以訪問成功了
第一種方式：就是以上通過yml進行配置
第二種方式：硬編碼來實現(xiàn)（比較麻煩）
5.通過微服務名實現(xiàn)動態(tài)路由
????????在這里網(wǎng)關會替代Ribbon做負載均衡，網(wǎng)關的好處是只對外提供一個接口，而且不用暴露真正的接口。
????????如下圖，在yml中，將寫死的實例地址改為我們自己聲明的實例名，這個我們在各個微服務模塊的yml中都進行過配置。這樣做的原因是，目前我們微服務提供者只有8001和8002，但是以后還可能會有8003，8004.....可能會是隨便，任何的端口號。這樣做不需要關注端口號，而直接配置實例名就可以了。
????????調(diào)用lb方法返回的是服務提供端的端口號，如下可以發(fā)現(xiàn)，動態(tài)網(wǎng)關配置成功，而且實現(xiàn)了負載均衡。
6、Predicate的使用
????????1.After Route Predicate
????????2.Before Route Predicate
????????3.Between Route Predicate
????????4.Cookie?Route Predicate
????????5.Header?Route Predicate
????????6.Host?Route Predicate
????????7.Method?Route Predicate
????????8.Path?Route Predicate
????????9.Query?Route Predicate
????????運用crul進行測試，添加cookie之后，如果不添加cookie或者添加的cookie不對都會報錯，一般項目總用到三種測試方式，postman，jmeter，curl
????????其他的那些基本上也都很簡單，都是差不多類似的，其實，Predicate就是為了實現(xiàn)一組匹配規(guī)則，讓請求過來找到對應的Route進行處理。
7、過濾器
生命周期：pre和post
種類：GatewayFilter（30多個）和GlobalFilter（10幾個）
7.1.實現(xiàn)自定義過濾器
? ? ? ? 開發(fā)過程中，一般自己配置過濾器比較多，首先創(chuàng)建實現(xiàn)GlobalFilter，Ordered兩個接口，然后重寫方法，一定要記得在類上加上注解@Component。
這樣在地址欄訪問就一定要加上參數(shù)username了，不加或者加錯參數(shù)，如下，都會報錯。
十二、服務配置
1.是什么
????????微服務意味著要將單體應用中的業(yè)務拆分成一個個子服務，每個服務的粒度相對較小，因此系統(tǒng)中會有大量的服務，由于每個服務都需要進行相關的配置信息才能運行，所以需要一套集中式的、動態(tài)的配置管理設施。我們每一個微服務都帶著自己一個application.yml，如果有上百個配置文件的管理.......SpringCloud提供了ConfigServer來解決這個問題。
????????SpringCloud Config微服務架構中的微服務提供了集中化的外部配置支持，配置服務器為各個不同微服務應用的所有環(huán)境提供了一個中心化的外部配置。 SpringCloud Config分為服務端和客戶端兩部分：
????????服務端也稱為分布式配置中心，他是一個獨立的微服務應用，用來連接配置服務器并為客戶端提供獲取配置信息，加密/解密信息等訪問接口
? ? ? ? 客戶端則是通過指定的配置中心來管理應用資源，以及與業(yè)務相關的配置內(nèi)容，并在啟動的時候就從配置中心獲取和加載配置信息，配置服務器默認采用git來存儲配置信息，這樣有助于對環(huán)境配置進行版本管理，并且可以通過git客戶端工具來方便管理和訪問配置內(nèi)容。
2.能干嗎
? ? ? ? ①集中管理配置文件（將那些公共的配置抽取出來，比如說數(shù)據(jù)庫密碼、Eureka的服務端）
? ? ? ? ②不同環(huán)境下不同配置，動態(tài)化的配置更新，分環(huán)境部署比如dev/test/prod/beta/release
? ? ? ? ③運行期間動態(tài)調(diào)整配置，不再需要在每個服務部署的機器上編寫配置文件，服務會向配置中心統(tǒng)一拉取配置自己的信息。
? ? ? ? ④當配置發(fā)生變動時，服務不需要重啟即可感知到配置的變化并應用新的配置
? ? ? ? ⑤將配置信息以REST接口的形式暴露。
3.怎么用
3.1建立配置中心服務端
①建module cloud-config-center-3344；
②配置pom文件，添加新的依賴
<dependency>
????????<groupId>org.springframework.cloud</groupId>
????????<artifactId>spring-cloud-config-server</artifactId>
</dependency>
③寫yml文件
3.2建立配置中心客戶端
①建立module
②寫pom.xml，添加新的依賴如下：
<dependency>
????<groupId>org.springframework.cloud</groupId>
????<artifactId>spring-cloud-starter-config</artifactId>
</dependency>
③寫bootstrap.yml文件
? ? ? ? application.yml是用戶級的資源配置項，bootstrap.yml是系統(tǒng)級的，優(yōu)先級更高，Bootstrap屬性有高優(yōu)先級，默認情況下，他們不會被本地配置覆蓋，因為bootstrap.yml是比application.yml先加載的，bootstrap.yml優(yōu)先級高于application.yml
④業(yè)務類進行測試
3.3分布式的配置動態(tài)刷新問題
? ? ? ? 假如在外部配置中心修改配置，（可以在本地修改然后提交到github，也可以直接在github上進行修改），修改之后，刷新本地配置的springcloud-config服務端，發(fā)現(xiàn)配置是更改過得，因為他直接訪問的是github端，而刷新客戶端發(fā)現(xiàn)并為更改，需要重啟服務器才可以使更改生效。
①首先pom.xml一定要添加依賴
<dependency>
????<groupId>org.springframework.boot</groupId>
????<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
②bootstrap.xml添加新的配置
③在業(yè)務類添加新的注解
????????@RefreshScope
④當運維人員對配置中心的配置進行修改時，還需要對客戶端進行刷新才可以生效
? ? ? ? curl -X POST "http://localhost:3355/actuator/refresh"
????????雖然避免了重啟服務器，但是不得不說這樣還是很不方便，假如說有100臺客戶端，要每個客戶端都執(zhí)行一個這個命令，寫腳本遍歷一下也還好，但是假如說是要100個其中90個重啟一下就有點難了，接下來消息總線Bus
十三、消息總線
????????SpringCloudBus配合SpringCloudConfig一起使用，可以實現(xiàn)配置的動態(tài)刷新。
1、是什么
2、能干嘛
????????Spring Cloud Bus能管理和傳播分布式系統(tǒng)間的消息，就像一個分布式執(zhí)行器，可用于廣播狀態(tài)更改，事件推送等，也可以當做微服務間的通信通道。
3、為何被稱為總線
? ? ? ? 什么是消息總線（類似于公眾號）：在微服務架構的系統(tǒng)中，通常會使用消息代理來構建一個共同的消息主題，并讓系統(tǒng)中所有微服務實例都連接上來，由于該主題中產(chǎn)生的消息會被所有實例監(jiān)聽和消費，所以稱為消息總線。在總線上的各個實例，都可以方便地廣播一些需要讓其他連接在該主題上的實例都知道的消息。
? ? ? ? 基本原理：ConfigClient實例都監(jiān)聽MQ中同一個topic（默認是SpringCloudBus）。當一個服務刷新數(shù)據(jù)的時候，他會把這個信息放到Topic中，這樣其他監(jiān)聽同一個Topic的微服務就能得到通知，然后去更新自身的配置。
