【萬字長文】Spring Cloud Alibaba 開箱即用！
互聯(lián)網(wǎng)時(shí)代，面對復(fù)雜業(yè)務(wù)，講究 分而治之。將一個(gè)大的單體系統(tǒng)拆分為若干個(gè)微服務(wù)，保證每個(gè)系統(tǒng)的職責(zé)單一，可以垂直深度擴(kuò)展。
但是一個(gè)個(gè)獨(dú)立的微服務(wù)像一座座孤島，如何將他們串聯(lián)起來，才能發(fā)揮最大價(jià)值。
這時(shí)，我們就要提微服務(wù)的生態(tài)圈。
那么微服務(wù)生態(tài)圈都有哪些模塊？他們的作用分別是什么？
服務(wù)的注冊、發(fā)現(xiàn)。生產(chǎn)者啟動(dòng)時(shí)，會將自己的信息注冊上報(bào)，這樣調(diào)用方只需連接注冊中心，根據(jù)一定的負(fù)載算法，就可以與服務(wù)提供方建立連接，從而實(shí)現(xiàn)應(yīng)用間的解耦。 服務(wù)調(diào)用。通過多種協(xié)議（如：HTTP等）實(shí)現(xiàn)目標(biāo)服務(wù)的真正調(diào)用。 負(fù)載均衡。主要是提供多種負(fù)載算法，滿足不同業(yè)務(wù)場景下的集群多實(shí)例的選擇機(jī)制 服務(wù)的穩(wěn)定性。提供了服務(wù)熔斷、限流、降級 分布式配置中心。應(yīng)用的配置項(xiàng)統(tǒng)一管理，修改后能動(dòng)態(tài)生效 消息隊(duì)列。非核心邏輯從同步流程抽離，解耦，異步化處理，縮短RT時(shí)間 網(wǎng)關(guān)。將一些通用的處理邏輯，如：限流、鑒權(quán)、黑白名單、灰度等抽取到一個(gè)單獨(dú)的、前置化系統(tǒng)統(tǒng)一處理。 監(jiān)控。監(jiān)控系統(tǒng)的健康狀況 分布式鏈路追蹤。查看接口的調(diào)用鏈路，為性能優(yōu)化、排查問題提供輸入 自動(dòng)化部署。持續(xù)集成，快速部署應(yīng)用。
圍繞這些功能模塊，Spring Cloud Alibaba 為我們提供了微服務(wù)化開發(fā)的一站式解決方案，我們只需要少量的Spring 注解 和 yaml配置，便可以快速構(gòu)建出一套微服務(wù)系統(tǒng)。真的是創(chuàng)業(yè)者的福音。
那么這套生態(tài)規(guī)范都提供了哪些技術(shù)框架呢？
一、Spring Boot（服務(wù)基座）
Spring Boot 是Spring框架的擴(kuò)展，提供更加 豐富的注解，根據(jù) 約定勝于配置 原則，與市場主流的開源框架打通， 設(shè)計(jì)了 Starter 和 AutoConfiguration 機(jī)制，簡化配置流程，通過簡單的jar包引入，快速具備組件集成能力。大大提高了程序員的開發(fā)效率。
特點(diǎn)：
提供了豐富的注解，不要在XML文件中定義各種繁瑣的bean配置 內(nèi)嵌 Web容器，如：Tomcat（默認(rèn)）、Jetty、Undertow 集成了主流開源框架，根據(jù)項(xiàng)目依賴自動(dòng)配置
二、Nacos（注冊中心、分布式配置中心）
Nacos 是阿里巴巴的開源的項(xiàng)目，全稱 Naming Configuration Service ，專注于服務(wù)發(fā)現(xiàn)和配置管理領(lǐng)域。
Nacos 致力于幫助您發(fā)現(xiàn)、配置和管理微服務(wù)。Nacos 提供了一組簡單易用的特性集，幫助您快速實(shí)現(xiàn)動(dòng)態(tài)服務(wù)發(fā)現(xiàn)、服務(wù)配置、服務(wù)元數(shù)據(jù)及流量管理。功能齊全，可以替換之前的 Spring Cloud Netflix Eureka、Spring Cloud Config、Spring Cloud Bus，野心巨大。
客戶端語言方面目前支持 Java，go 、python、 C# 和 C++等主流語言
開源地址：https://github.com/alibaba/nacos
Nacos 有一個(gè)控制臺，可以幫助用戶管理服務(wù)，監(jiān)控服務(wù)狀態(tài)、應(yīng)用的配置管理。
集群化部署：
由于 Nacos 是單節(jié)點(diǎn)，無論做為注冊中心還是分布式配置中心，一旦服務(wù)器掛了，作為底層服務(wù)引發(fā)的麻煩還是非常大的。如何保證其高可用？
Nacos 官方提供的集群部署架構(gòu)圖：
https://nacos.io/zh-cn/docs/cluster-mode-quick-start.html
在nacos的解壓目錄nacos/conf目錄下，有配置文件cluster.conf，每行配置成 ip:port。（一般配置3個(gè)或3個(gè)以上節(jié)點(diǎn)）
#?ip:port
200.8.9.16:8848
200.8.9.17:8848
200.8.9.18:8848
這樣保證客戶端只需要寫一次，由 Leader節(jié)點(diǎn)將數(shù)據(jù)同步到其他節(jié)點(diǎn)，保證各個(gè)節(jié)點(diǎn)的數(shù)據(jù)一致性
對于上層的SLB，我們可以采用 Nginx 或者 OpenResty，在 upstream 模塊里配置 Nacos 的集群IP 地址列表，實(shí)現(xiàn)負(fù)載均衡功能。
另外，借助Nginx的心跳檢測，當(dāng)某臺 Nacos 服務(wù)掛掉后，SLB 會自動(dòng)屏蔽，將流量切換到其他 Nacos 實(shí)例。
當(dāng)然 OpenResty 也可能成為單點(diǎn)故障，為了保證高可用，我們需要借助 Keepalived
客戶端請求 VIP，然后請求打到了 OpenResty，由 OpenResty 轉(zhuǎn)發(fā)給具體的某個(gè) Nacos 節(jié)點(diǎn)。
OpenResty 只有一個(gè)節(jié)點(diǎn)提供服務(wù)，另一個(gè)暫停狀態(tài)，如果 master 節(jié)點(diǎn)宕機(jī)，那 backup 接替繼續(xù)工作。從而解決了單點(diǎn)故障問題。
Keepalived 作為一種高性能的服務(wù)器高可用或熱備解決方案，用來防止服務(wù)器單點(diǎn)故障的發(fā)生。市面資料很多，下文鏈接是《Keepalived+Nginx部署方案》具體操作步驟
https://help.fanruan.com/finereport/doc-view-2905.html
三、RestTemplate + Ribbon （遠(yuǎn)程調(diào)用）
Spring Cloud Ribbon 基于 Netflix Ribbon 封裝的負(fù)載均衡框架。內(nèi)部集成了多種負(fù)載算法，如：隨機(jī)、輪詢等。
與注冊中心打通，能自動(dòng)獲取服務(wù)提供者的地址列表。結(jié)合自身的負(fù)載算法，選擇一個(gè)目標(biāo)實(shí)例發(fā)起服務(wù)調(diào)用。
Ribbon 也提供了擴(kuò)展接口，支持自定義負(fù)載均衡算法。
public?class?CustomRule?extends?AbstractLoadBalancerRule?{
????private?AtomicInteger?count?=?new?AtomicInteger(0);
????@Override
????public?Server?choose(Object?key)?{?
????????return?choose(getLoadBalancer(),?key);
????}
????private?Server?choose(ILoadBalancer?loadBalancer,?Object?key)?{
????????List?allServers?=?loadBalancer.getAllServers();?
????????int?requestNumber?=?count.incrementAndGet();?
????????if?(requestNumber?>=?Integer.MAX_VALUE)?{?
????????????count?=?new?AtomicInteger(0);?
????????}
????????if?(null?!=?allServers)?{
????????????int?size?=?allServers.size();
????????????if?(size?>?0)?{
????????????????int?index?=?requestNumber?%?size;?????????????????
????????????????Server?server?=?allServers.get(index);
????????????????if?(null?==?server?||?!server.isAlive())?{?
????????????????????return?null;
????????????????}
????????????????return?server;
????????????}
????????}
????????return?null;
????}
}
缺點(diǎn)：
調(diào)用方每次發(fā)起遠(yuǎn)程服務(wù)調(diào)用時(shí)，都需要填寫遠(yuǎn)程目標(biāo)地址，還要配置各種參數(shù)，非常麻煩，不是很方便
//?注冊到Nacos的應(yīng)用名稱
private?final?String?SERVER_URL?=?"http://nacos-provider-demo";?
@Resource
private?RestTemplate?restTemplate;
@RequestMapping("/hello")?
public?String?hello()?{
?//?遠(yuǎn)程服務(wù)調(diào)用
???return?restTemplate.getForObject(SERVER_URL?+?"/hello",?String.class);
}
四、OpenFeign（遠(yuǎn)程調(diào)用）
RestTemplate + Ribbon 每次發(fā)起遠(yuǎn)程服務(wù)調(diào)用時(shí)，都需要填寫遠(yuǎn)程目標(biāo)地址，還要配置各種參數(shù)，非常麻煩。
Feign 是一個(gè)輕量級的 Restful HTTP 客戶端，內(nèi)嵌了 Ribbon 作為客戶端的負(fù)載均衡。面向接口編程，使用時(shí)只需要定義一個(gè)接口并加上@FeignClient注解，非常方便。
OpenFeign 是 Feign 的增強(qiáng)版。對 Feign 進(jìn)一步封裝，支持 Spring MVC 的標(biāo)準(zhǔn)注解和HttpMessageConverts
依賴包：
????org.springframework.cloud
????spring-cloud-starter-openfeign
@FeignClient(value?=?"${provider.name}")?
public?interface?OrderService?{
?//?調(diào)用服務(wù)提供者的?/create_order?接口
?@RequestMapping(value?=?"/create_order",method?=?RequestMethod.GET)?
?public?String?createOrder();
其中，@FeignClient(value = "${provider.name}") 定義了服務(wù)提供方的工程名，底層自動(dòng)打通了注冊中心，會拿到 artifactId 對應(yīng)的IP列表，根據(jù)一定的負(fù)載均衡算法，可以將請求打到目標(biāo)服務(wù)器上。
OpenFeign 默認(rèn)等待接口返回?cái)?shù)據(jù)的時(shí)間是 1 秒，超過這個(gè)時(shí)間就會報(bào)錯(cuò)。如果想調(diào)整這個(gè)時(shí)間，可以修改配置項(xiàng) feign.client.config.default.readTimeout
五、Dubbo Spring Cloud（遠(yuǎn)程調(diào)用）
RestTemplate + Ribbon 和 OpenFeign 都是基于HTTP協(xié)議調(diào)用遠(yuǎn)程接口。而 Dubbo Spring Cloud 是基于 TCP 協(xié)議來調(diào)用遠(yuǎn)程接口。相比 HTTP 的大量的請求頭，TCP 更輕量級。
Dubbo Spring Cloud = Spring Cloud ?+ Dubbo
特性：
支持多種注冊中心，用于服務(wù)的注冊、發(fā)現(xiàn) 內(nèi)置多種負(fù)載均衡策略 服務(wù)粒度是 面向接口，支持 TCP 輕量級協(xié)議容易擴(kuò)展，采用 微內(nèi)核 + 插件 的設(shè)計(jì)原則，擴(kuò)展點(diǎn)更強(qiáng)
依賴包：
????com.alibaba.cloud
????spring-cloud-starter-dubbo
注意：雖然是將 Dubbo 集成到了 Spring Cloud，增加了一些 注解 和 yaml 配置項(xiàng)，開發(fā)更方便，但大部分調(diào)用玩法還是遵守 Dubbo 框架那一套。
幾個(gè)重要的配置項(xiàng)：
dubbo.scan.base-packages ?# dubbo 服務(wù)掃描基準(zhǔn)包，上報(bào)注冊服務(wù) dubbo.protocol.name: dubbo ? # 支持的協(xié)議 dubbo.protocol.port: -1 ?# dubbo 協(xié)議端口（ -1 表示自增端口，從 20880 開始） dubbo.registry.address ?# 注冊中心地址
六、Spring Cloud Gateway（網(wǎng)關(guān)）
分布式時(shí)代，一個(gè)復(fù)雜的系統(tǒng)被拆分為若干個(gè)微服務(wù)系統(tǒng)，每個(gè)系統(tǒng)都配置獨(dú)立的域名肯定不合適。為了解決這個(gè)問題，網(wǎng)關(guān)便誕生了。
網(wǎng)關(guān)充當(dāng)反向代理的角色，作為流量的第一入口，承載了很多基礎(chǔ)的、公共的模塊功能，如：流控、鑒權(quán)、監(jiān)控、路由轉(zhuǎn)發(fā)等。
Spring Cloud 生態(tài)早期的網(wǎng)關(guān)是 Netflix 公司的Zuul，后來Zuul社區(qū)停止了維護(hù)。官方后來推出了 Spring Cloud Gateway，其底層是基于 WebFlux 框架，而WebFlux框架的底層采用高性能通訊框架 Netty，性能是 Zuul 的 1.6 倍。
核心組件：
1、路由。
內(nèi)部主要是負(fù)責(zé)轉(zhuǎn)發(fā)規(guī)則。
2、斷言（Predicate）
如果返回為true，當(dāng)前路由才有效，才會路由到具體的服務(wù)。官方提供了很多內(nèi)置路由斷言，如果滿足不了你的訴求，也可以自定義路由斷言工廠。
所有的路由斷言工廠都是繼承自 AbstractRoutePredicateFactory，自定義類的命名也有固定規(guī)則，“配置名”+RoutePredicateFactory。這樣，在yaml配置時(shí)，只需要寫前面定義的配置名即可。
3、過濾器（Filter）
主要是請求、響應(yīng)之間增加一些自定義的邏輯。按作用范圍分為：全局和局部。全局是作用于所有的路由；而局部只是作用于某一個(gè)路由。
跟上面的斷言類似，除了官方提供的過濾器，也支持自定義。
局部過濾器：繼承自 AbstractGatewayFilterFactory，自定義類的命名也有固定規(guī)則，“配置名”+GatewayFilterFactory。這樣，在yaml配置時(shí)，只需要寫前面定義的配置名即可。
全局過濾器：實(shí)現(xiàn)GlobalFilter,Ordered 兩個(gè)接口，實(shí)現(xiàn)邏輯跟上面的局部過濾器類似。這里就不展開了。其中的 Ordered 接口主要是負(fù)責(zé)優(yōu)先級，數(shù)值越小，優(yōu)先級越高。
依賴包：
?org.springframework.cloud
?spring-cloud-starter-gateway
yaml 的配置示例：
spring:
??cloud:
????gateway:
??????routes:??#路由，可配置多個(gè)
????????-?id:?user_route??#?路由id?唯一即可，默認(rèn)是UUID
??????????uri:?lb://user-server-sample?#?匹配成功后提供的服務(wù)的地址
??????????order:?1?#?路由優(yōu)先級，數(shù)值越小優(yōu)先級越高，默認(rèn)0
??????????predicates:
????????????-?Path=/user/**??#?斷言，路徑匹配進(jìn)行路由
?????????#??-?User=0,?1000???#?自定義路由斷言工廠??只允許查詢id為0?-?1000之間的用戶
?????????#??-?Method=POST????#?表示需要POST方式請求
?????????#??-?Query=id,?\d+??#?參數(shù)名id，正則表達(dá)式為\d+（一個(gè)或多個(gè)數(shù)字）
??????????filters:
????????????-?AddRequestHeader=X-Request-token,?12345678??#為原始請求加上請求頭及值
???????????
當(dāng)然，服務(wù)提供方的地址可能經(jīng)常變化，為了動(dòng)態(tài)感知，我們引入 Nacos 注冊中心，用于服務(wù)的注冊、發(fā)現(xiàn)，統(tǒng)一管理服務(wù)的IP地址。網(wǎng)關(guān)路由轉(zhuǎn)發(fā)時(shí)，只需從 Nacos 動(dòng)態(tài)獲取即可。
七、Sentinel（熔斷、限流、降級）
Sentinel 是阿里開源的流控框架，提供了簡單易用的控制臺，比 Hystrix支持的范圍更廣。
集成簡單，只需要少量配置，即可快速接入，支持如：gRPC、Dubbo、Spring Cloud 等
同類競品框架：
Hystrix 框架已經(jīng)停止維護(hù)； Resilience4j 一種輕量級容錯(cuò)庫，專為 Java 8 和函數(shù)式編程而設(shè)計(jì)。通過裝飾器的方式，以使用斷路器，速率限制器，重試或隔板來增強(qiáng)任何功能接口，lambda 表達(dá)式或方法引用。
流控規(guī)則：
頁面元素介紹：
資源名：唯一即可 針對來源：對調(diào)用者限流，填寫應(yīng)用名稱（Spring.application.name的值），只針對某個(gè)服務(wù)限流 閾值類型 QPS：每秒接收的請求數(shù) 線程數(shù)：能使用的業(yè)務(wù)線程數(shù) 流控模式 直接：達(dá)到條件后，直接執(zhí)行某個(gè)流控效果 關(guān)聯(lián)：如果訪問關(guān)聯(lián)接口B達(dá)到了閾值，則讓接口A返回失敗 鏈路：記錄從入口資源的流量，達(dá)到條件也只限流入口資源 流控效果 快速失敗：直接返回失敗結(jié)果 Warm Up：預(yù)熱，開始有一個(gè)緩沖期，初始值 = 閾值/ codeFactor(默認(rèn) 3)，然后慢慢達(dá)到設(shè)置的閾值 排隊(duì)等待：讓請求以均勻的速度通過，如果請求超過閾值就等待，如果等待超時(shí)則返回失敗
降級規(guī)則：
RT 異常數(shù) 異常比例
系統(tǒng)規(guī)則：
流控規(guī)則和降級規(guī)則是針對某個(gè)資源來說的，而系統(tǒng)規(guī)則是針對整個(gè)應(yīng)用的，粒度更大，當(dāng)前所有的接口服務(wù)都會應(yīng)用這個(gè)系統(tǒng)規(guī)則。
授權(quán)規(guī)則：
根據(jù)調(diào)用方判斷調(diào)用的接口資源是否被允許，如：黑名單、白名單機(jī)制
熱點(diǎn)規(guī)則：
將粒度進(jìn)一步細(xì)化，可以針對方法的參數(shù)做規(guī)則控制，為每個(gè)參數(shù)設(shè)置單獨(dú)的閾值，也可以多個(gè)參數(shù)組合。從而實(shí)現(xiàn)單個(gè)方法的熱點(diǎn)流量，按業(yè)務(wù)需求進(jìn)一步控制。
@SentinelResource注解
@SentinelResource 注解可以根據(jù)實(shí)際情況定制化功能，跟 Hystrix 的 @HystrixCommand 注解功能類似。達(dá)到閾值后，系統(tǒng)的默認(rèn)提示是一段英文，很不友好，所以我們要自定義兜底方法。
//?資源名稱為handle1?
@RequestMapping("/handle1")
@SentinelResource(value?=?"handle1",?blockHandler?=?"blockHandlerTestHandler")
public?String?handle1(String?params)?{?
????//?業(yè)務(wù)邏輯處理
????return?"success";
}
//?接口方法?handle1?的?兜底方法
public?String?blockHandlerTestHandler(String?params,?BlockException?blockException)?{
????return?"兜底返回";
}
注意：@SentinelResource注解中，除了blockHandler字段外，還有fallback字段
blockHandler：主觀層面，如果被限流，則調(diào)用該方法，進(jìn)行兜底處理fallback：對業(yè)務(wù)的異常兜底，比如，執(zhí)行過程中拋了各種Exception，則調(diào)用該方法，進(jìn)行兜底處理
通過上面兩層兜底，可以讓Sentinel 框架更加人性化，體驗(yàn)更好。
集群流控：
單機(jī)限流很容易做，但是互聯(lián)網(wǎng)很多應(yīng)用都是集群部署，畢竟其下游還掛載著 mysql、或者其他微服務(wù)，為了防止對下游的大流量沖擊，采用集群流控。防止單機(jī)的流量不均勻， 理想下 QPS = 單機(jī)閾值 * 節(jié)點(diǎn)數(shù)
八、Seata（分布式事務(wù)）
事務(wù)的原子性和持久性可以確保在一個(gè)事務(wù)內(nèi)，更新多條數(shù)據(jù)，要么都成功，要么都失敗。在一個(gè)系統(tǒng)內(nèi)部，我們可以使用數(shù)據(jù)庫事務(wù)來保證數(shù)據(jù)一致性。那如果一筆交易，涉及到跨多個(gè)系統(tǒng)、多個(gè)數(shù)據(jù)庫的時(shí)候，用單一的數(shù)據(jù)庫事務(wù)就沒辦法解決了，此時(shí)需要引入分布式事務(wù)
Seata 是一款開源的分布式事務(wù)解決方案，致力于提供高性能和簡單易用的分布式事務(wù)服務(wù)。Seata 將為用戶提供了 AT、TCC、SAGA 和 XA 事務(wù)模式，默認(rèn) AT 模式 ，為用戶打造一站式的分布式解決方案。
優(yōu)點(diǎn)：
對業(yè)務(wù)無侵入：即減少技術(shù)架構(gòu)上的微服務(wù)化所帶來的分布式事務(wù)問題對業(yè)務(wù)的侵入 高性能：減少分布式事務(wù)解決方案所帶來的性能消耗
Seata有3個(gè)基本組成部分：
事務(wù)管理器（TM）：定義全局事務(wù)的范圍：開始全局事務(wù)，提交或回滾全局事務(wù)。
事務(wù)協(xié)調(diào)器（TC）：維護(hù)全局事務(wù)和分支事務(wù)的狀態(tài)，驅(qū)動(dòng)全局提交或回滾。
資源管理器（RM）：管理正在處理的分支事務(wù)的資源，與TC對話以注冊分支事務(wù)并報(bào)告分支事務(wù)的狀態(tài)，并驅(qū)動(dòng)分支事務(wù)的提交或回滾。
運(yùn)行流程：
TM 向 TC 申請開啟一個(gè)全局事務(wù)，全局事務(wù)創(chuàng)建成功并生成一個(gè)全局唯一的 XID XID 在微服務(wù)調(diào)用鏈路的上下文中傳播 RM 向 TC 注冊分支事務(wù)，TC 返回分支事務(wù)ID ，并將其納入 XID 對應(yīng)全局事務(wù)的管轄 RM 執(zhí)行本地業(yè)務(wù)表操作，并記錄 undo_log日志，提交本地事務(wù)當(dāng)所有的 RM 都執(zhí)行完后，TM 向 TC 發(fā)起針對 XID 的全局提交或回滾決議 TC 調(diào)度 XID 下管轄的全部分支事務(wù)完成提交或回滾請求。如果提交，刪除 undo_log日志就可以了。如果是回滾，根據(jù)undo_log表記錄逆向回滾本地事務(wù)，把數(shù)據(jù)還原，最后再刪除undo_log日志。
關(guān)于 Seata 之前寫過很多文章，這里就不展開了，感興趣可以看看
九、Spring Cloud Stream （異步消息）
Spring Cloud Stream 是統(tǒng)一消息中間件編程模型的框架，屏蔽了底層消息中間件的差異。支持的MQ 框架有 RabbitMQ、Kafka、RocketMQ 等
常用注解：
@Input：標(biāo)記為輸入信道，消費(fèi)消息 @Output：標(biāo)記為輸出信道，生產(chǎn)消息 @StreamListener：監(jiān)聽某個(gè)隊(duì)列，接收消息，處理自身的業(yè)務(wù)邏輯 @EnableBinding：綁定通道
依賴包：
?com.alibaba.cloud
?spring-cloud-starter-stream-rocketmq
綁定通道：
@SpringBootApplication
@EnableBinding({CustomSource.class})
public?class?StreamProduceApplication?{
?public?static?void?main(String[]?args)?{
??SpringApplication.run(StreamProduceApplication.class,?args);
?}
}
定義輸出信道：
public?interface?CustomSource?{
????@Output("output1")
????MessageChannel?output1();
}
yaml 配置：
spring:
??cloud:
????stream:
??????rocketmq:
????????binder:
??????????name-server:?127.0.0.1:9876?#?rocketMq服務(wù)地址
????????bindings:
??????????output1:
????????????producer:
??????????????transactional:?true????#?事務(wù)
??????????????group:?myTxProducerGroup????#?事務(wù)分組
??????bindings:
????????output1:
??????????destination:?test-transaction-topic?#?主題
??????????content-type:?application/json?#?數(shù)據(jù)類型
發(fā)送消息：
@Service
public?class?SendMessageService?{
????@Resource
????private?CustomSource?customSource;
????public?String?sendMessage()?{?//發(fā)送簡單字符串消息的方法
????????String?message?=?"字符串測試消息";
????????//?發(fā)送消息
??customSource.output1().send(MessageBuilder.withPayload(message).build());?????????
??return?"發(fā)送成功！";
????}
}
十、SkyWalking（分布式鏈路追蹤）
SkyWalking 是 一款 APM（應(yīng)用性能監(jiān)控）系統(tǒng)，專為微服務(wù)、云原生架構(gòu)、容器（Docker、k8s、Mesos）而設(shè)計(jì)。通過探針收集應(yīng)用的指標(biāo)，進(jìn)行分布式鏈路追蹤，感知服務(wù)間的調(diào)用鏈路關(guān)系。
特性：
支持告警 采用探針技術(shù)，代碼零侵入 輕量高效，不需要大數(shù)據(jù)平臺 多個(gè)語言自動(dòng)探針。包括 Java，.NET Core 和 Node.JS。 強(qiáng)大的可視化后臺
上部分 Agent ：負(fù)責(zé)從應(yīng)用中，收集鏈路信息，發(fā)送給 SkyWalking OAP 服務(wù)器。目前支持 SkyWalking、Zikpin、Jaeger 等提供的 Tracing 數(shù)據(jù)信息。而我們目前采用的是，SkyWalking Agent 收集 SkyWalking Tracing 數(shù)據(jù)，傳遞給服務(wù)器。 下部分 SkyWalking OAP ：負(fù)責(zé)接收 Agent 發(fā)送的 Tracing 數(shù)據(jù)信息，然后進(jìn)行分析(Analysis Core) ，存儲到外部存儲器( Storage )，最終提供查詢( Query )功能。 右部分 Storage ：Tracing 數(shù)據(jù)存儲。目前支持 ES、MySQL、Sharding Sphere、TiDB、H2 多種存儲器。而我們目前采用的是 ES ，主要考慮是 SkyWalking 開發(fā)團(tuán)隊(duì)自己的生產(chǎn)環(huán)境采用 ES 為主。 左部分 SkyWalking UI ：負(fù)責(zé)提供控臺，查看鏈路等等。
SkyWalking 部署起來還是很簡單的，apache官網(wǎng)直接下載并解壓即可。
https://skywalking.apache.org/
SkyWalking 快速入門手冊：
https://skywalking.apache.org/zh/2020-04-19-skywalking-quick-start/
十一、XXL-JOB（分布式任務(wù)調(diào)度）
關(guān)于定時(shí)任務(wù)，相信大家都不陌生。但是單節(jié)點(diǎn)的定時(shí)任務(wù)有很多不足：
不支持集群，如果同時(shí)部署多個(gè)節(jié)點(diǎn)，會競爭數(shù)據(jù)，造成數(shù)據(jù)重復(fù) 如果是單節(jié)點(diǎn)，宕機(jī)后，任務(wù)無法自動(dòng)感知、重啟 不支持任務(wù)失敗重試 不支持執(zhí)行時(shí)間的動(dòng)態(tài)調(diào)整 無報(bào)警機(jī)制 無任務(wù)數(shù)據(jù)統(tǒng)計(jì)功能 不支持?jǐn)?shù)據(jù)分片
無論是集群化，還是周邊的生態(tài)建設(shè)，都不完備。而 XXL-JOB，可以完美解決這些問題。
XXL-JOB 是一款分布式任務(wù)調(diào)度框架，依賴的組件少（僅依賴 Java 和 MySQL），開箱即用。并提供了可視化界面，統(tǒng)計(jì)任務(wù)數(shù)據(jù)，動(dòng)態(tài)修改任務(wù)執(zhí)行時(shí)間，內(nèi)置郵件報(bào)警，支持任務(wù)分片和任務(wù)失敗重試。
核心模塊：
1、調(diào)度中心
本身不執(zhí)行業(yè)務(wù)邏輯，只負(fù)責(zé)向執(zhí)行器發(fā)送調(diào)度命令。
2、執(zhí)行器
接收調(diào)度中心的請求，并執(zhí)行業(yè)務(wù)邏輯。
依賴包：
?com.xuxueli
?xxl-job-core
?2.2.0
yaml 配置：
server:
??port:?8082??#程序端口
xxl:
??job:
????admin:
??????addresses:?http://127.0.0.1:8002/xxl-job-admin??#?調(diào)度中心地址，多個(gè)用逗號分開
????accessToken:??#?調(diào)度中心和執(zhí)行器通信的token，如果設(shè)置，兩邊要一樣
????executor:
??????appname:?xxl-job-executor-sample??#執(zhí)行器名稱
??????address:???#?執(zhí)行器地址，默認(rèn)使用xxl.job.executor.address配置項(xiàng)，如果為空，則使用xxl.job.executor.ip?+?xxl.job.executor.port
??????ip:???#?執(zhí)行器IP
??????port:?9989??#執(zhí)行器端口，與調(diào)度中心通信的端口
??????logpath:?D:/work/Spring-Cloud-Alibaba/sample/logs?#?日志保存路徑
??????logretentiondays:?30?#?日志保留天數(shù)
XxlJobSpringExecutor 初始化：
@Bean
public?XxlJobSpringExecutor?xxlJobExecutor()?{?//?XXL-JOB執(zhí)行器初始化
????XxlJobSpringExecutor?xxlJobSpringExecutor?=?new?XxlJobSpringExecutor();
????xxlJobSpringExecutor.setAdminAddresses(adminAddresses);
????xxlJobSpringExecutor.setAppname(appname);
????xxlJobSpringExecutor.setAddress(address);
????xxlJobSpringExecutor.setIp(ip);
????xxlJobSpringExecutor.setPort(port);
????xxlJobSpringExecutor.setAccessToken(accessToken);
????xxlJobSpringExecutor.setLogPath(logPath);
????xxlJobSpringExecutor.setLogRetentionDays(logRetentionDays);
????return?xxlJobSpringExecutor;
}
我們可以采用 BEAN 模式， 使用 @XxlJob 注解描述代碼。優(yōu)點(diǎn)：適用于一些復(fù)雜的業(yè)務(wù)場景。
也可以采用 GLUE 模式，將 執(zhí)行代碼 托管到調(diào)度中心在線維護(hù)。優(yōu)點(diǎn)：簡單快捷，不需要單獨(dú)的業(yè)務(wù)工程。
如果要處理的數(shù)據(jù)量較大時(shí)，我們可以采用分片處理機(jī)制，將任務(wù)均攤到每個(gè)節(jié)點(diǎn)，從而減輕單個(gè)節(jié)點(diǎn)的壓力。
shardingVO.getIndex()?#?當(dāng)前執(zhí)行器的分片序號（從0開始）
shardingVO.getTotal()?#?總分片數(shù)，執(zhí)行器集群的數(shù)量
#?dataSource?待處理的所有原始數(shù)據(jù)
for?(Integer?val?:?dataSource)?{?//?遍歷代理
????if?(val?%?shardingVO.getTotal()?==?shardingVO.getIndex())?{?//?取余
????????//TODO?歸屬于當(dāng)前分片處理
????}?
}??
XXL-JOB 快速入門手冊：
https://www.xuxueli.com/xxl-job/
巨人肩膀：
《Spring Cloud Alibaba 微服務(wù)實(shí)戰(zhàn)》