一、 服務(wù)注冊(cè)中心

????????服務(wù)之間需要?jiǎng)?chuàng)建一種服務(wù)發(fā)現(xiàn)機(jī)制，用于幫助服務(wù)之間互相感知彼此的存在。服務(wù)啟動(dòng)時(shí)會(huì)將自身的服務(wù)信息注冊(cè)到注冊(cè)中心，并訂閱自己需要消費(fèi)的服務(wù)。

????????服務(wù)注冊(cè)中心是服務(wù)發(fā)現(xiàn)的核心。它保存了各個(gè)可用服務(wù)實(shí)例的網(wǎng)絡(luò)地址(IPAddress和Port)。服務(wù)注冊(cè)中心必須要有高可用性和實(shí)時(shí)更新功能。Netflix Eureka 就是一個(gè)服務(wù)注冊(cè)中心。它提供了服務(wù)注冊(cè)和查詢服務(wù)信息的REST API。

????????服務(wù)之間需要?jiǎng)?chuàng)建一種服務(wù)發(fā)現(xiàn)機(jī)制，用于幫助服務(wù)之間互相感知彼此的存在。服務(wù)啟動(dòng)時(shí)會(huì)將自身的服務(wù)信息注冊(cè)到注冊(cè)中心，并訂閱自己需要消費(fèi)的服務(wù)。服務(wù)通過使用POST請(qǐng)求注冊(cè)自己的IPAddress和Port。每30秒發(fā)送一個(gè)PUT請(qǐng)求刷新注冊(cè)信息。通過DELETE請(qǐng)求注銷服務(wù)?？蛻舳送ㄟ^GET請(qǐng)求獲取可用的服務(wù)實(shí)例信息。 Netflix的高可用（Netflix achieves high availability ）是通過在Amazon EC2運(yùn)行多個(gè)實(shí)例來實(shí)現(xiàn)的,每一個(gè)Eureka服務(wù)都有一個(gè)彈性IP Address。當(dāng)Eureka服務(wù)啟動(dòng)時(shí)，有DNS服務(wù)器動(dòng)態(tài)的分配。Eureka客戶端通過查詢DNS來獲取Eureka的網(wǎng)絡(luò)地址（IP Address和Port）。一般情況下，都是返回和客戶端在同一個(gè)可用區(qū)Eureka服務(wù)器地址。

????????etcd —– 高可用，分布式，強(qiáng)一致性的，key-value，Kubernetes和Cloud Foundry都是使用了etcd。

????????consul —–一個(gè)用于discovering和configuring的工具。它提供了允許客戶端注冊(cè)和發(fā)現(xiàn)服務(wù)的API。Consul可以進(jìn)行服務(wù)健康檢查，以確定服務(wù)的可用性。

????????zookeeper —— 在分布式應(yīng)用中被廣泛使用，高性能的協(xié)調(diào)服務(wù)。 Apache Zookeeper 最初為Hadoop的一個(gè)子項(xiàng)目，但現(xiàn)在是一個(gè)頂級(jí)項(xiàng)目。

1 、zookeeper服務(wù)注冊(cè)和發(fā)現(xiàn)

????????簡(jiǎn)單來講，zookeeper可以充當(dāng)一個(gè)服務(wù)注冊(cè)表（Service Registry），讓多個(gè)服務(wù)提供者形成一個(gè)集群，讓服務(wù)消費(fèi)者通過服務(wù)注冊(cè)表獲取具體的服務(wù)訪問地址（ip+端口）去訪問具體的服務(wù)提供者。

????????具體來說，zookeeper就是個(gè)分布式文件系統(tǒng)，每當(dāng)一個(gè)服務(wù)提供者部署后都要將自己的服務(wù)注冊(cè)到zookeeper的某一路徑上:/{service}/{version}/{ip:port}, 比如我們的HelloWorldService部署到兩臺(tái)機(jī)器，那么zookeeper上就會(huì)創(chuàng)建兩條目錄：分別為/HelloWorldService/1.0.0/100.19.20.01:16888 /HelloWorldService/1.0.0/100.19.20.02:16888。

????????zookeeper提供了“心跳檢測(cè)”功能，它會(huì)定時(shí)向各個(gè)服務(wù)提供者發(fā)送一個(gè)請(qǐng)求（實(shí)際上建立的是一個(gè) socket 長(zhǎng)連接），如果長(zhǎng)期沒有響應(yīng)，服務(wù)中心就認(rèn)為該服務(wù)提供者已經(jīng)“掛了”，并將其剔除，比如100.19.20.02這臺(tái)機(jī)器如果宕機(jī)了，那么zookeeper上的路徑就會(huì)只剩/HelloWorldService/1.0.0/100.19.20.01:16888。服務(wù)消費(fèi)者會(huì)去監(jiān)聽相應(yīng)路徑（/HelloWorldService/1.0.0），一旦路徑上的數(shù)據(jù)有任務(wù)變化（增加或減少），zookeeper都會(huì)通知服務(wù)消費(fèi)方服務(wù)提供者地址列表已經(jīng)發(fā)生改變，從而進(jìn)行更新。

????????更為重要的是zookeeper 與生俱來的容錯(cuò)容災(zāi)能力（比如leader選舉），可以確保服務(wù)注冊(cè)表的高可用性。

二、負(fù)載均衡

????????服務(wù)高可用的保證手段，為了保證高可用，每一個(gè)微服務(wù)都需要部署多個(gè)服務(wù)實(shí)例來提供服務(wù)。此時(shí)客戶端進(jìn)行服務(wù)的負(fù)載均衡。

1、 負(fù)載均衡的常見策略

????????（1） 隨機(jī)

????????把來自網(wǎng)絡(luò)的請(qǐng)求隨機(jī)分配給內(nèi)部中的多個(gè)服務(wù)器。

????????（2） 輪詢

????????每一個(gè)來自網(wǎng)絡(luò)中的請(qǐng)求，輪流分配給內(nèi)部的服務(wù)器，從1到N然后重新開始。此種負(fù)載均衡算法適合服務(wù)器組內(nèi)部的服務(wù)器都具有相同的配置并且平均服務(wù)請(qǐng)求相對(duì)均衡的情況。

????????（3） 加權(quán)輪詢

????????根據(jù)服務(wù)器的不同處理能力，給每個(gè)服務(wù)器分配不同的權(quán)值，使其能夠接受相應(yīng)權(quán)值數(shù)的服務(wù)請(qǐng)求。例如：服務(wù)器A的權(quán)值被設(shè)計(jì)成1，B的權(quán)值是3，C的權(quán)值是6，則服務(wù)器A、B、C將分別接受到10%、30％、60％的服務(wù)請(qǐng)求。此種均衡算法能確保高性能的服務(wù)器得到更多的使用率，避免低性能的服務(wù)器負(fù)載過重。

????????（4） IP Hash

????????這種方式通過生成請(qǐng)求源IP的哈希值，并通過這個(gè)哈希值來找到正確的真實(shí)服務(wù)器。這意味著對(duì)于同一主機(jī)來說他對(duì)應(yīng)的服務(wù)器總是相同。使用這種方式，你不需要保存任何源IP。但是需要注意，這種方式可能導(dǎo)致服務(wù)器負(fù)載不平衡。

????????（5）最少連接數(shù)

????????客戶端的每一次請(qǐng)求服務(wù)在服務(wù)器停留的時(shí)間可能會(huì)有較大的差異，隨著工作時(shí)間加長(zhǎng)，如果采用簡(jiǎn)單的輪循或隨機(jī)均衡算法，每一臺(tái)服務(wù)器上的連接進(jìn)程可能會(huì)產(chǎn)生極大的不同，并沒有達(dá)到真正的負(fù)載均衡。最少連接數(shù)均衡算法對(duì)內(nèi)部中需負(fù)載的每一臺(tái)服務(wù)器都有一個(gè)數(shù)據(jù)記錄，記錄當(dāng)前該服務(wù)器正在處理的連接數(shù)量，當(dāng)有新的服務(wù)連接請(qǐng)求時(shí)，將把當(dāng)前請(qǐng)求分配給連接數(shù)最少的服務(wù)器，使均衡更加符合實(shí)際情況，負(fù)載更加均衡。此種均衡算法適合長(zhǎng)時(shí)處理的請(qǐng)求服務(wù)，如FTP。

三、 容錯(cuò)

????????容錯(cuò)，這個(gè)詞的理解，直面意思就是可以容下錯(cuò)誤，不讓錯(cuò)誤再次擴(kuò)張，讓這個(gè)錯(cuò)誤產(chǎn)生的影響在一個(gè)固定的邊界之內(nèi)，“千里之堤毀于蟻穴”我們用容錯(cuò)的方式就是讓這種蟻穴不要變大。那么我們常見的降級(jí)，限流，熔斷器，超時(shí)重試等等都是容錯(cuò)的方法。在調(diào)用服務(wù)集群時(shí)，如果一個(gè)微服務(wù)調(diào)用異常，如超時(shí)，連接異常，網(wǎng)絡(luò)異常等，則根據(jù)容錯(cuò)策略進(jìn)行服務(wù)容錯(cuò)。目前支持的服務(wù)容錯(cuò)策略有快速失敗，失效切換。如果連續(xù)失敗多次則直接熔斷，不再發(fā)起調(diào)用。這樣可以避免一個(gè)服務(wù)異常拖垮所有依賴于他的服務(wù)。

1、容錯(cuò)策略

????????（1 ）快速失敗

????????服務(wù)只發(fā)起一次調(diào)用，失敗立即報(bào)錯(cuò)。通常用于非冪等性的寫操作。

????????（2） 失效切換

????????服務(wù)發(fā)起調(diào)用，當(dāng)出現(xiàn)失敗后，重試其他服務(wù)器。通常用于讀操作，但重試會(huì)帶來更長(zhǎng)時(shí)間的延遲。重試的次數(shù)通常是可以設(shè)置的。

????????（3）失敗安全

????????失敗安全， 當(dāng)服務(wù)調(diào)用出現(xiàn)異常時(shí)，直接忽略。通常用于寫入日志等操作。

????????（4）失敗自動(dòng)恢復(fù)

????????當(dāng)服務(wù)調(diào)用出現(xiàn)異常時(shí)，記錄失敗請(qǐng)求，定時(shí)重發(fā)。通常用于消息通知。

????????（5） forking Cluster

????????并行調(diào)用多個(gè)服務(wù)器，只要有一個(gè)成功，即返回。通常用于實(shí)時(shí)性較高的讀操作。可以通過forks=n來設(shè)置最大并行數(shù)。

????????（6）廣播調(diào)用

????????廣播調(diào)用所有提供者，逐個(gè)調(diào)用，任何一臺(tái)失敗則失敗。通常用于通知所有提供者更新緩存或日志等本地資源信息。

四、熔斷

????????熔斷技術(shù)可以說是一種“智能化的容錯(cuò)”，當(dāng)調(diào)用滿足失敗次數(shù)，失敗比例就會(huì)觸發(fā)熔斷器打開，有程序自動(dòng)當(dāng)前的RPC調(diào)用,來防止錯(cuò)誤進(jìn)一步擴(kuò)大。實(shí)現(xiàn)一個(gè)熔斷器主要是考慮三種模式，關(guān)閉，打開，半開。

????????我們?cè)谔幚懋惓５臅r(shí)候，要根據(jù)具體的業(yè)務(wù)情況來決定處理方式，比如我們調(diào)用商品接口，對(duì)方只是臨時(shí)做了降級(jí)處理，那么作為網(wǎng)關(guān)調(diào)用就要切換到可替換的服務(wù)上來執(zhí)行或者獲取托底數(shù)據(jù)，給用戶友好提示。還有要區(qū)分異常的類型，比如依賴的服務(wù)崩潰了這個(gè)可能需要花費(fèi)比較久的時(shí)間來解決。也可能是由于服務(wù)器負(fù)載臨時(shí)過高導(dǎo)致超時(shí)。作為熔斷器應(yīng)該能夠甄別這種異常類型，從而根據(jù)具體的錯(cuò)誤類型調(diào)整熔斷策略。增加手動(dòng)設(shè)置，在失敗的服務(wù)恢復(fù)時(shí)間不確定的情況下，管理員可以強(qiáng)制切換熔斷狀態(tài)。最后，熔斷器的使用場(chǎng)景是調(diào)用可能失敗的遠(yuǎn)程服務(wù)程序或者共享資源。如果是本地緩存本地私有資源，使用熔斷器則會(huì)增加系統(tǒng)的額外開銷。還要注意，熔斷器不能作為應(yīng)用程序中業(yè)務(wù)邏輯的異常處理替代品。

????????有一些異常比較頑固，突然發(fā)生，無法預(yù)測(cè)，而且很難恢復(fù)，并且還會(huì)導(dǎo)致級(jí)聯(lián)失?。ㄅe個(gè)例子，假設(shè)一個(gè)服務(wù)集群的負(fù)載非常高，如果這時(shí)候集群的一部分掛掉了，還占了很大一部分資源，整個(gè)集群都有可能遭殃）。如果我們這時(shí)還是不斷進(jìn)行重試的話，結(jié)果大多都是失敗的。因此，此時(shí)我們的應(yīng)用需要立即進(jìn)入失敗狀態(tài)(fast-fail)，并采取合適的方法進(jìn)行恢復(fù)。

????????我們可以用狀態(tài)機(jī)來實(shí)現(xiàn)CircuitBreaker，它有以下三種狀態(tài)：

????????關(guān)閉( Closed )：默認(rèn)情況下Circuit Breaker是關(guān)閉的，此時(shí)允許操作執(zhí)行。CircuitBreaker內(nèi)部記錄著最近失敗的次數(shù)，如果對(duì)應(yīng)的操作執(zhí)行失敗，次數(shù)就會(huì)續(xù)一次。如果在某個(gè)時(shí)間段內(nèi)，失敗次數(shù)（或者失敗比率）達(dá)到閾值，CircuitBreaker會(huì)轉(zhuǎn)換到開啟( Open )狀態(tài)。在開啟狀態(tài)中，Circuit Breaker會(huì)啟用一個(gè)超時(shí)計(jì)時(shí)器，設(shè)這個(gè)計(jì)時(shí)器的目的是給集群相應(yīng)的時(shí)間來恢復(fù)故障。當(dāng)計(jì)時(shí)器時(shí)間到的時(shí)候，CircuitBreaker會(huì)轉(zhuǎn)換到半開啟( Half-Open )狀態(tài)。

????????開啟( Open )：在此狀態(tài)下，執(zhí)行對(duì)應(yīng)的操作將會(huì)立即失敗并且立即拋出異常。

????????半開啟( Half-Open )：在此狀態(tài)下，Circuit Breaker會(huì)允許執(zhí)行一定數(shù)量的操作。如果所有操作全部成功，CircuitBreaker就會(huì)假定故障已經(jīng)恢復(fù)，它就會(huì)轉(zhuǎn)換到關(guān)閉狀態(tài)，并且重置失敗次數(shù)。如果其中 任意一次 操作失敗了，Circuit Breaker就會(huì)認(rèn)為故障仍然存在，所以它會(huì)轉(zhuǎn)換到開啟狀態(tài)并再次開啟計(jì)時(shí)器（再給系統(tǒng)一些時(shí)間使其從失敗中恢復(fù)）。

五、限流和降級(jí)

????????保證核心服務(wù)的穩(wěn)定性。為了保證核心服務(wù)的穩(wěn)定性，隨著訪問量的不斷增加，需要為系統(tǒng)能夠處理的服務(wù)數(shù)量設(shè)置一個(gè)極限閥值，超過這個(gè)閥值的請(qǐng)求則直接拒絕。同時(shí)，為了保證核心服務(wù)的可用，可以對(duì)某些非核心服務(wù)進(jìn)行降級(jí)，通過限制服務(wù)的最大訪問量進(jìn)行限流，通過管理控制臺(tái)對(duì)單個(gè)微服務(wù)進(jìn)行人工降級(jí)。

六、SLA

????????SLA：Service-Level Agreement的縮寫，意思是服務(wù)等級(jí)協(xié)議。 是關(guān)于網(wǎng)絡(luò)服務(wù)供應(yīng)商和客戶間的一份合同，其中定義了服務(wù)類型、服務(wù)質(zhì)量和客戶付款等術(shù)語(yǔ)。 典型的SLA包括以下項(xiàng)目：

????????分配給客戶的最小帶寬；

????????客戶帶寬極限；

????????能同時(shí)服務(wù)的客戶數(shù)目；

????????在可能影響用戶行為的網(wǎng)絡(luò)變化之前的通知安排；

????????撥入訪問可用性；

????????運(yùn)用統(tǒng)計(jì)學(xué)；

????????服務(wù)供應(yīng)商支持的最小網(wǎng)絡(luò)利用性能，如99.9%有效工作時(shí)間或每天最多為1分鐘的停機(jī)時(shí)間；

????????各類客戶的流量?jī)?yōu)先權(quán)；

????????客戶技術(shù)支持和服務(wù)；

????????懲罰規(guī)定，為服務(wù)供應(yīng)商不能滿足 SLA需求所指定。

七、API網(wǎng)關(guān)

????????這里說的網(wǎng)關(guān)是指API網(wǎng)關(guān)，直面意思是將所有API調(diào)用統(tǒng)一接入到API網(wǎng)關(guān)層，由網(wǎng)關(guān)層統(tǒng)一接入和輸出。一個(gè)網(wǎng)光的基本功能有：統(tǒng)一接入、安全防護(hù)、協(xié)議適配、流量管控、長(zhǎng)短鏈接支持、容錯(cuò)能力。有了網(wǎng)關(guān)之后，各個(gè)API服務(wù)提供團(tuán)隊(duì)可以專注于自己業(yè)務(wù)邏輯處理，而API網(wǎng)關(guān)更專注于安全、流量、路由等問題。

八、多級(jí)緩存

????????最簡(jiǎn)單的緩存就是查一次數(shù)據(jù)庫(kù)然后將數(shù)據(jù)寫入緩存比如redis中并設(shè)置過期時(shí)間。因?yàn)橛羞^期失效因此我們要關(guān)注下緩存的穿透率，這個(gè)穿透率的計(jì)算公式，比如查詢方法queryOrder(調(diào)用次數(shù)1000/1s)里面嵌套查詢DB方法queryProductFromDb(調(diào)用次數(shù)300/s)，那么redis的穿透率就是300/1000,在這種使用緩存的方式下，是要重視穿透率的，穿透率大了說明緩存的效果不好。還有一種使用緩存的方式就是將緩存持久化，也就是不設(shè)置過期時(shí)間，這個(gè)就會(huì)面臨一個(gè)數(shù)據(jù)更新的問題。一般有兩種辦法，一個(gè)是利用時(shí)間戳，查詢默認(rèn)以redis為主，每次設(shè)置數(shù)據(jù)的時(shí)候放入一個(gè)時(shí)間戳，每次讀取數(shù)據(jù)的時(shí)候用系統(tǒng)當(dāng)前時(shí)間和上次設(shè)置的這個(gè)時(shí)間戳做對(duì)比，比如超過5分鐘，那么就再查一次數(shù)據(jù)庫(kù)。這樣可以保證redis里面永遠(yuǎn)有數(shù)據(jù)，一般是對(duì)DB的一種容錯(cuò)方法。還有一個(gè)就是真正的讓redis做為DB使用。就是通過訂閱數(shù)據(jù)庫(kù)的binlog通過數(shù)據(jù)異構(gòu)系統(tǒng)將數(shù)據(jù)推送給緩存，同時(shí)將將緩存設(shè)置為多級(jí)?？梢酝ㄟ^使用jvmcache作為應(yīng)用內(nèi)的一級(jí)緩存，一般是體積小，訪問頻率大的更適合這種jvmcache方式，將一套redis作為二級(jí)remote緩存，另外最外層三級(jí)redis作為持久化緩存。

九、超時(shí)和重試

????????超時(shí)與重試機(jī)制也是容錯(cuò)的一種方法，凡是發(fā)生RPC調(diào)用的地方，比如讀取redis，db，mq等，因?yàn)榫W(wǎng)絡(luò)故障或者是所依賴的服務(wù)故障，長(zhǎng)時(shí)間不能返回結(jié)果，就會(huì)導(dǎo)致線程增加，加大cpu負(fù)載，甚至導(dǎo)致雪崩。所以對(duì)每一個(gè)RPC調(diào)用都要設(shè)置超時(shí)時(shí)間。對(duì)于強(qiáng)依賴RPC調(diào)用資源的情況，還要有重試機(jī)制，但是重試的次數(shù)建議1-2次，另外如果有重試，那么超時(shí)時(shí)間就要相應(yīng)的調(diào)小，比如重試1次，那么一共是發(fā)生2次調(diào)用。如果超時(shí)時(shí)間配置的是2s，那么客戶端就要等待4s才能返回。因此重試+超時(shí)的方式，超時(shí)時(shí)間要調(diào)小。這里也再談一下一次PRC調(diào)用的時(shí)間都消耗在哪些環(huán)節(jié)，一次正常的調(diào)用統(tǒng)計(jì)的耗時(shí)主要包括： ①調(diào)用端RPC框架執(zhí)行時(shí)間 + ②網(wǎng)絡(luò)發(fā)送時(shí)間 + ③服務(wù)端RPC框架執(zhí)行時(shí)間 + ④服務(wù)端業(yè)務(wù)代碼時(shí)間。調(diào)用方和服務(wù)方都有各自的性能監(jiān)控，比如調(diào)用方tp99是500ms，服務(wù)方tp99是100ms，找了網(wǎng)絡(luò)組的同事確認(rèn)網(wǎng)絡(luò)沒有問題。那么時(shí)間都花在什么地方了呢，兩種原因，客戶端調(diào)用方，還有一個(gè)原因是網(wǎng)絡(luò)發(fā)生TCP重傳。所以要注意這兩點(diǎn)。

十、線程池隔離

????????在抗量這個(gè)環(huán)節(jié)，Servlet3異步的時(shí)候，有提到過線程隔離。線程隔離的之間優(yōu)勢(shì)就是防止級(jí)聯(lián)故障，甚至是雪崩。當(dāng)網(wǎng)關(guān)調(diào)用N多個(gè)接口服務(wù)的時(shí)候，我們要對(duì)每個(gè)接口進(jìn)行線程隔離。比如，我們有調(diào)用訂單、商品、用戶。那么訂單的業(yè)務(wù)不能夠影響到商品和用戶的請(qǐng)求處理。如果不做線程隔離，當(dāng)訪問訂單服務(wù)出現(xiàn)網(wǎng)絡(luò)故障導(dǎo)致延時(shí)，線程積壓最終導(dǎo)致整個(gè)服務(wù)CPU負(fù)載滿。就是我們說的服務(wù)全部不可用了，有多少機(jī)器都會(huì)被此刻的請(qǐng)求塞滿。那么有了線程隔離就會(huì)使得我們的網(wǎng)關(guān)能保證局部問題不會(huì)影響全局。

十一、降級(jí)和限流

????????關(guān)于降級(jí)限流的方法業(yè)界都已經(jīng)有很成熟的方法了，比如FAILBACK機(jī)制，限流的方法令牌桶，漏桶，信號(hào)量等。這里談一下我們的一些經(jīng)驗(yàn)，降級(jí)一般都是由統(tǒng)一配置中心的降級(jí)開關(guān)來實(shí)現(xiàn)的，那么當(dāng)有很多個(gè)接口來自同一個(gè)提供方，這個(gè)提供方的系統(tǒng)或這機(jī)器所在機(jī)房網(wǎng)絡(luò)出現(xiàn)了問題，我們就要有一個(gè)統(tǒng)一的降級(jí)開關(guān)，不然就要一個(gè)接口一個(gè)接口的來降級(jí)。也就是要對(duì)業(yè)務(wù)類型有一個(gè)大閘刀。還有就是 降級(jí)切記暴力降級(jí)，什么是暴力降級(jí)的，比如把論壇功能降調(diào)，結(jié)果用戶顯示一個(gè)大白板，我們要實(shí)現(xiàn)緩存住一些數(shù)據(jù)，也就是有托底數(shù)據(jù)。限流一般分為分布式限流和單機(jī)限流，如果實(shí)現(xiàn)分布式限流的話就要一個(gè)公共的后端存儲(chǔ)服務(wù)比如redis，在大nginx節(jié)點(diǎn)上利用lua讀取redis配置信息。我們現(xiàn)在的限流都是單機(jī)限流，并沒有實(shí)施分布式限流。

十二、網(wǎng)關(guān)監(jiān)控和統(tǒng)計(jì)

????????API網(wǎng)關(guān)是一個(gè)串行的調(diào)用，那么每一步發(fā)生的異常要記錄下來，統(tǒng)一存儲(chǔ)到一個(gè)地方比如elasticserach中，便于后續(xù)對(duì)調(diào)用異常的分析。鑒于公司docker申請(qǐng)都是統(tǒng)一分配，而且分配之前docker上已經(jīng)存在3個(gè)agent了，不再允許增加。我們自己實(shí)現(xiàn)了一個(gè)agent程序，來負(fù)責(zé)采集服務(wù)器上面的日志輸出，然后發(fā)送到kafka集群，再消費(fèi)到elasticserach中，通過web查詢?，F(xiàn)在做的追蹤功能還比較簡(jiǎn)單，這塊還需要繼續(xù)豐富。