今日內容
一、配置中心
1、遺留問題
yml配置，每一次都需要重啟項目
需要不重啟項目拿到更新的結果
引出：配置中心
選擇：Spring Cloud Config組件 / Alibaba的Nacos（注冊中心、配置中心）
使用：Nacos可以同時當配置中心和注冊中心
查看 ：默認8848端口，可以查看配置中心和注冊中心內容
2、實際創建
創建配置可以填寫yml名稱和內容
3、代碼使用新的配置
步驟：
（1）導入依賴--之前的是discovery，現在使用config包
（2）配置：當前項目的Nacos作為配置中心所在的地址
通常創建配置文件內部
（6）寫注解
引入讓配置生效的依賴
寫注解：加載想要使用外部配置文件的類上使用@RefreshScope注解
4、測試
就能夠拿到配置的username:jack
5、實現功能
無需重啟項目就能對配置文件進行更改
同時可以對配置文件進行多次修改
二、sentinel流量控制
1、遺留問題
大量訪問接口的qps，會根據機器占用資源決定
需要對接口的流量進行控制（可以只讓某個接口一個單位訪問1000次）
解決方式：
- 定義private int count = 0;被多個線程共享，就可以進行累加
- 根據系統時間的計算，進行判斷
- 超過閾值，給客戶端返回錯誤信息
原因：負載過大系統宕機，從而會影響上層服務（引起雪崩效應--影響上游服務）
下游服務不可用，級聯影響上游服務
解決【有對應組件對其進行實現】：
- 上述代碼進行限流-避免服務不掛掉
- 也可以降級--服務不可用，或希望其不可用，則調整其優先級
2、以Sentinel舉例
Sentinel-server需要知道哪些服務要進行限流/降級
需要對其進行部署（jar包或源碼）
當前目錄輸入cmd
查看啟動日志，可以看到，默認綁定在8080端口
sentinel-sentinel
需要先把需要被保護的服務接口信息上報到sentinel
3、步驟
（1）指定服務下引入依賴
無需引入版本
（2）寫配置
在yml文件中
告訴項目，sentinel-server的位置
默認不用配置用戶名密碼
也可以自定義指定認證信息，如Nacos
（3）不需要寫注解
4、查看
實際上還沒有，所以會有懶加載機制
一下子寫入對sentinel-server壓力大
只有訪問了該資源，才會把接口信息寫入sentinel-server
從而對其進行流量控制
可以捕獲錯誤信息，返回頁面給用戶【sentinel的github上面】
4、監控
5、配置
降級后，不再提供服務，可以指定時間，或異常數
對集群部署，也可以對熱點規則
6、總結
服務指定sentinel，進行懶加載方式進行流量控制
三、使用MQ進行流量削峰，緩存消息，解決並發量大的問題
1、存在問題
訂單服務中的creteOrder()使用OpenFeign的方式調用微服務時
如調用count-Service服務，調用余額deduct
調用pay-service#payMethod()
調用扣減庫存stroge-service#deduceKucun()
調用物流服務……
創建訂單調用許多服務
例如余額掛掉
不用立即減少余額，可以等恢復時再減少余額
解決：消息發到MQ，對應用解耦，降低容錯性【發到消息中間件，不用寫到一個方法中】
將同步調用變為異步調用，使用MQ完成解耦邏輯
流量削峰：某個服務（userservice並發量大時），超過qps值，可以使用sentinel進行限流（提示客戶端返回錯誤信息）
現在：使用MQ，qps=5000超過服務的1000，剩下4000對用戶體驗不好
請求不需要 落在userservice，從MQ中消費消息
進入5000qps，出來1000qps，讓用戶等待
其他應用場景：數據分發
2、選型
阿里RocketMQ【火箭】、RabbitMQ【兔子，提升性能】、K‘afka咖負咖、Pulsar、ActiveMQ【積極的】等
開發語言：Java、erlang、Scala……
功能擴展性等不同維度，適用場景不同
選擇：RocketMQ
使用：觀察者模式
3、搭建架構
4、過程及步驟Apache RocketMQ
（1）搭建server--集群式部署
（2）啟動nameserver及broker
broker用於接收消息和處理消息
nameserver理解為RocketMQ的注冊中心
先啟動注冊中心nameserver，后啟動broker【綁定ip和端口，自動創建主題】
4、使用maven啟動dashboard項目
查看默認主題
可以自己創建主題，選擇生產者
5、使用過程--原生的api
（1）引入依賴
（2）使用demo測試--ProducerGroup
broker注冊到nameserver上
異步生產消息、消費消息……操作
6、具體舉例
user-service作為生產者，order作為消費者
（1）導入依賴，可以指定版本
（2）寫配置
指定nameserver，和注冊中心打交道
在user-service生產者中配置
（3）寫注解--無
上述是針對producer
（4）編寫接口發送消息
自動裝配RocketMQTemplate
spring boot對其進行了封裝
指定主題，指定發消息的內容
最終源碼是對原生api的封裝，即
訪問時發送消息
7、消費者
（1）導入依賴
（2）寫配置
（3） 寫注解
獲取感興趣的消息
（4）測試生產消費
8、總結
優點：解耦、流量削峰
問題：
引入中間件，如果MQ掛掉，兩個服務無法直接通信；
使用中間件交互，復雜度高；
需要考慮重復消息，和消息是否丟失
四、網關
1、存在問題
微服務架構可以實現異步通信
不同服務的入口，無需暴露給客戶端
解決：網關作為前置組件，做路由的轉發，轉發到后置服務-相當於Nginx的功能，更適用於java環境
功能：實現路由
2、選型--GateWay
zuul：BIO同步阻塞
gateway：nio--同步非阻塞IO，適用於並發量比較高的場景
可以實現具體路由的轉發
3、使用GateWay
（1）創建一個單獨的工程module
並將依賴的版本與之前保持一致（gateway默認版本比較新）
特性：
支持服務的注冊發現
可以根據名稱拿到URL地址
需要在網關中整合Nacos的依賴
（2）配置
修改為yml文件
配置應用在注冊中心的名字
配置網關服務發現的能力Gateway-enable
（3）使用
定位網關、服務發現
有了服務發現的能力，就可以實現路由轉發
Netty監聽到了端口
（4）自定義路由規則
使用謂詞和過濾器完成操作
指定路由匹配的條件Predicts和Filters、uri
4、其他功能
可以實現熔斷、限流、路徑重寫、用戶認證 、授權操作
五、鏈路追蹤
1、存在問題
訪問了一個鏈接，訪問了多個服務
即：記錄微服務的調用關系，以便后面對問題進行排查
方案：基於日志記錄的思想，使用組件記錄日志，或使用AOP切面自定義記錄日志
使用Spring Cloud Sleuth組件，進行日志記錄
查看日志記錄的結果，使用zebkin進行圖形化展示
2、介紹
zebkin-server進行圖形化展示
（1）整合：在需要記錄日志的服務里面導入zebkin依賴，自動導入Sleuth組件
（2）啟動java -jar zebkin
默認9411端口
（3）寫配置
配置zebkin的位置
將sleuth的采樣概率改為100%（默認10%）
3、測試
重啟項目：my-gateway、userservice、order-service
可以通過鏈路追蹤到錯誤
4、其他選型
zebkin+sleuth
SkyWalking-功能強大，自動生成可視化圖表（Apache，國人使用Java開發的）
可以搜索skywalking【支持ES、MySQL等】和sleuth的對比
六、事務管理-SEATA
1、其他問題
RPC/rest api調用時，需要保證事務性
方式：在當前類上添加@Transactional注解
源碼底層會根據注解得到動態代理類，並根據createOrder進行增強，使用AOP對事務進行管理
分布式環境：該注解失效，會生成動態代理實現類，但問題在於三個服務使用的不是同一個數據源
管理事務的前提：基於同一個connection
分布式事務的管理：參考Seata架構
2、Seata的介紹
數據庫事務-JDBC事務-Spring事務-分布式事務
明天講原理，后天講容器化內容
今日內容總結
今天主要學到的組件和功能，包括配置中心（Nacos、Config），流量控制（sentinel），服務網關（GateWay、zuul），消息中間件（RocketMQ）、服務調用鏈路（zipkin+sleuth）、分布式事務（seata）
1、對於配置中心主要有Config組件和阿里巴巴的Nacos組件
而Nacos可以充當配置中心和注冊中心，所以使用了Nacos作為配置中心，默認端口是8848
配置中心主要實現不需要重啟項目，就能夠對配置文件進行修改
2、對於多個訪問接口的資源占用，可以對接口進行流量控制，可以對服務進行一個限流或者降級，但是使用自定義變量的方式進行判斷的話，可能會影響上層服務
因此使用了sentinel使用了懶加載的方式進行了流量控制，通過其圖形化界面，可以實現流量控制規則的定義，降級的規則，熱點的規則和授權的規則、熔斷、降級等功能，此外，還可以對服務的訪問量進行qps的監控同時可以對錯誤信息進行捕獲，返回自定義頁面。
3、使用了RocketMQ消息隊列進行流量的削峰和緩存，來解決並發量大的問題，實現流量控制，不會請求過多而導致大量的請求訪問失敗的問題，可以傳入消息隊列，讓請求進行等待，同時還有其他的場景，比如數據分發。通過圖形化管理界面，可以自己創建主題，選擇生產者，同時使用方法進行了測試，對於框架中使用了封裝好的包，配置好監聽的地址和端口以及主題后就可以發送消息了，發送到消息之后就能夠監聽到發送的消息
4、對於多個服務的入口，無需全部暴露給客戶端，可以使用服務網關進行路由的轉發，傳遞一個鏈接，將其轉發到后置的服務，與之前的nginx 進行對比，不是一個單獨的組件，更適用於開發環境，可以使用的選型包括zuul和gateway，gateway是一個nio的路由，是用於並發量比較高的場景
如果使用GateWay的話，需要創建一個單獨的工程，並在配置文件里面配置好注冊中心，從而實現服務的發現及路由轉發。此外，還可以使用自定義的路由規則，通過謂詞和過濾器完成操作，實現指定路由的匹配，同時，GateWay還能實現熔斷、限流、重寫用戶認證以及授權等操作
5、對於多個服務之間的鏈路追蹤，可以使用日志記錄的思想進行日志記錄，使用了sleuth組件，該組件基於zipkin（包含sleuth）圖形化展示組件，當請求發生錯誤的時候，就可以根據zip kin追蹤到錯誤的來源，此外，除了zepkin之外，還有一些其他的組件也可以進行鏈路追蹤，比如skywalking以及阿里的鷹眼和大眾點評的cat
6、對於分布式事務管理，可以使用seata完成