在IM場(chǎng)景中，常見的模式大概可以分為兩種：一種是基于數(shù)據(jù)收集的，一種。系統(tǒng)層是整個(gè)體系中最基礎(chǔ)的方式，一般來說，它主要的是操作系統(tǒng)維度的一些性能指標(biāo)。舉個(gè)例子：我們要對(duì)上線的業(yè)務(wù)進(jìn)行，可以通過Nagios、Zabbix等類似的系統(tǒng)工具，來實(shí)時(shí)收集機(jī)器相關(guān)的性能數(shù)據(jù)，如CPU、內(nèi)存、IO、負(fù)載、帶寬、PPS、Swap由于足夠通用，系統(tǒng)相關(guān)的具體細(xì)節(jié)，我在這里就不展開了，你可以在留言區(qū)與我一起在即時(shí)消息場(chǎng)景中，我們需要實(shí)時(shí)消息收發(fā)接口的QPS、耗時(shí)、失敗數(shù)、消息推比如在平臺(tái)的場(chǎng)景里，就用到了基于Graphite的體系，來對(duì)的應(yīng)用狀態(tài)進(jìn)。在對(duì)應(yīng)用層業(yè)務(wù)直接相關(guān)的API接口進(jìn)行之外，我們還需要知道在消息收發(fā)的鏈路中，這些業(yè)務(wù)直接相關(guān)的API接口所依賴的其他API或資源的性能情況，以便于我們?cè)跇I(yè)務(wù)接口出現(xiàn)失敗率高或者耗時(shí)增長(zhǎng)的時(shí)候，能夠通過系統(tǒng)，快速找到導(dǎo)致這個(gè)接口出比如，我們還需要離線Buffer用到的Redis的使用量、相應(yīng)的讀寫QPS、耗時(shí)等除了應(yīng)用層整體的情況，當(dāng)業(yè)務(wù)層直接相關(guān)的API接口在整體層面上出現(xiàn)性能問題APIAPISwapMetrics集器”Agent，或者通過本地日志記錄的方式，記錄服務(wù)的Metrics數(shù)據(jù)。聚合，然后再提交給集群。庫”來進(jìn)行多精度的，比如OpenTSDB、InfluxDB等；然后通過時(shí)序數(shù)據(jù)庫的高壓縮比和聚合計(jì)算功能，來解決數(shù)據(jù)規(guī)模大和查詢效率低的問題；最終到“時(shí)序數(shù)據(jù)庫”中的數(shù)據(jù)，通過Web服務(wù)對(duì)用戶提供時(shí)間維度的界面查詢功能。對(duì)于系統(tǒng)層和應(yīng)用層，目前業(yè)界都有非常成解決方案。比如常見的Statsd+Graphite+Grafana方案和ELK（ElasticSearch+Logstash+Kibana）方案，它們的使用度都非常高。在實(shí)現(xiàn)上，也基本和上面圖中展現(xiàn)的數(shù)據(jù)收集與架構(gòu)方式差不多，所以全鏈路Trace除了系統(tǒng)和應(yīng)用服務(wù)外，在嚴(yán)重依賴網(wǎng)絡(luò)可用性的即時(shí)消息場(chǎng)景里，很多時(shí)候，我們需要關(guān)心的不僅僅是服務(wù)端的性能，還要從用戶自身的體驗(yàn)角度出發(fā)，來全局性地IM服務(wù)的可用性和性能。另外，由于各個(gè)微服務(wù)都是獨(dú)立部署并且互相的，很多時(shí)候，我們?cè)谂挪橄⑹瞻l(fā)失敗的原因時(shí)，很難查詢到具體的異常是由哪一個(gè)依賴的服務(wù)或者資源引起的，問題定位和處理效率也就非常低。怎樣才能把某次消息收發(fā)的各環(huán)節(jié)的性能數(shù)據(jù)，以及整個(gè)鏈路的情況聚合起來，以便于一個(gè)比較好的解決方案就是：基于Trace服務(wù)，對(duì)消息的收為進(jìn)行“全鏈路數(shù)據(jù)那么，接下來我們就來了解一下，這個(gè)TraceTrace一詞的出現(xiàn)，于的一篇“Dapper，aLarge- 中，介紹了的Dapper系統(tǒng)，并首次定義了什么是分布式系統(tǒng)，為了實(shí)現(xiàn)分布式鏈路追蹤，Dapper提出了Trace、Span、Annotation的概念，并給出了一個(gè)Trace調(diào)用的示例，如下圖：A~EAARPCBC，B處理請(qǐng)求后返回，C還要發(fā)起兩個(gè)RPC請(qǐng)求到D和E，最終服務(wù)A將請(qǐng)求結(jié)果返回給用我們?cè)俜謩e來看一下Trace、Span、AnnotationTrace表示對(duì)一次請(qǐng)求完整調(diào)用鏈的，每一條鏈路都使用一個(gè)全局唯一的TraceID來標(biāo)識(shí)。類似于上圖中的整個(gè)一次調(diào)用鏈路就是一次Trace。SpanSpan。一條Trace可以被認(rèn)為是由多個(gè)Span組成的一個(gè)有向無環(huán)圖（DAG圖）。比如上圖的示例中，用戶對(duì)服務(wù)A的請(qǐng)求和響應(yīng)過程就是一個(gè)Span（假設(shè)叫Span1），服務(wù)A對(duì)服務(wù)B的調(diào)用和響應(yīng)過程是另一個(gè)Span（假設(shè)叫Span2）。Span支持父子關(guān)系，比如這里的Span1就是Span2的父Span，這些Span通過同一個(gè)TraceID來串一個(gè)Span會(huì)記錄4個(gè)時(shí)間戳：“客戶端發(fā)送時(shí)間 通過這4個(gè)時(shí)間戳，我們就可以在一次請(qǐng)求完成后，計(jì)算出整個(gè)Trace的執(zhí)行耗時(shí)、服務(wù)端處理耗時(shí)和網(wǎng)絡(luò)耗時(shí)，以及Trace中每個(gè)Span過程的執(zhí)行耗時(shí)、服務(wù)端處理耗時(shí)和網(wǎng)比如，客戶端整體調(diào)用耗時(shí)=Receive- Send，服務(wù)端處理耗時(shí)=ServerSend-ServerReceive，那么，這一次請(qǐng)求的網(wǎng)絡(luò)耗時(shí)=客戶端整體調(diào)用耗時(shí)-服務(wù)端處Annotation主要用于用戶自定義，Annotation可以攜帶用戶在鏈路環(huán)節(jié)中的自定義比如在互動(dòng)場(chǎng)景中，記錄發(fā)彈幕的Trace的Span里，還可以利用Annotation，通過KV鍵值對(duì)的方式把房間ID、發(fā)送人UID等信息也一起記錄下來，便于我們后續(xù)根據(jù)這些KV鍵值對(duì)，進(jìn)行業(yè)務(wù)維度的查詢。目前業(yè)界比較成分布式Trace系統(tǒng)有： 的Zipkin、Uber的Jaeger、阿里的鷹眼、美團(tuán)的Mtrace，等等。在這里，我以使用比較廣泛的Zpkn為例，其整體的實(shí)現(xiàn)架構(gòu)你可以參考下面的這張官網(wǎng)圖：ReporterAOPSpanTransport模塊是TraceHTTP、Kafka、ScribeColletor模塊負(fù)責(zé)Trace數(shù)據(jù)的接收，并將Trace數(shù)據(jù)寫入到中Storage部分為組件，默認(rèn)是In-Memory，并支持Cassandra、ElasticSearch、MySQL等系統(tǒng)。API層提供TraceUI部分可見，通過應(yīng)用類似Zipkin的這種分布式全鏈路Trace系統(tǒng)，我們不僅能做到快速排查消息收發(fā)鏈路中出現(xiàn)的問題，而且還能根據(jù)Trace結(jié)合實(shí)時(shí)數(shù)據(jù)分析工具（如Flink），度地進(jìn)行業(yè)務(wù)維度的和。在的線上業(yè)務(wù)中，就通過基于Zipkin優(yōu)化定制的Trace系統(tǒng)，來定位消息收發(fā)的故障這一次群聊消息查詢失敗的原因是，調(diào)用一個(gè)“富文本”解析服務(wù)1秒超時(shí)失?。t框1，調(diào)用一個(gè)叫spage接口）；而且還發(fā)現(xiàn)群聊服務(wù)對(duì)“富文本消息”解析是串行調(diào)用的（紅框2），全鏈路Trace中，一個(gè)值得注意的問題是Trace數(shù)據(jù)采樣率由于一次消息收發(fā)的調(diào)用鏈路Span數(shù)一般都非常多，對(duì)于量較大的場(chǎng)景來說，全量的TraceTrace數(shù)據(jù)的收集。比如，在App啟舉個(gè)實(shí)際的例子：在的線上環(huán)境中，對(duì)上行請(qǐng)求一般是百分百采樣，對(duì)下行普通用戶一般是1%采樣，對(duì)VIP用戶上下行請(qǐng)求是全量采樣。除了采樣率問題，另一個(gè)比較麻煩就是Trace數(shù)據(jù)問題雖然大部分分布式Trace系統(tǒng)支持多語言Reporter來上報(bào)數(shù)據(jù)，但由于各系統(tǒng)的完善程度差別比較大，特別是基于AOP等探針，來“無感知”地對(duì)各種中間件的支持還是不太夠，另外，針對(duì)多個(gè)異構(gòu)系統(tǒng)的對(duì)接，除了在各自系統(tǒng)的業(yè)務(wù)代碼中直接上報(bào)Trace數(shù)據(jù)外，我們還可以通過本地日志+Agent上報(bào)的方式，來解耦異構(gòu)系統(tǒng)對(duì)TraceSDK的強(qiáng)依賴。前面講到，不管是系統(tǒng)、應(yīng)用，還是全鏈路，本質(zhì)上都是基于數(shù)據(jù)匯報(bào)的式。正常情況下，基于各種數(shù)據(jù)收集的 ，能夠協(xié)助我們快速發(fā)現(xiàn)問題，但當(dāng)服務(wù)出現(xiàn)故障時(shí)，依賴的數(shù)據(jù)收集就會(huì)容易出現(xiàn)上報(bào)延遲，甚至上報(bào)失敗的情況。比如，當(dāng)系統(tǒng)負(fù)載很高時(shí)，業(yè)務(wù)系統(tǒng)就很難再保障數(shù)據(jù)的上報(bào)了。對(duì)于即時(shí)消息場(chǎng)景來說，大部分場(chǎng)景都是基于用戶維度的消息收發(fā)的業(yè)務(wù)形態(tài)，因此，我們可以通過固定的兩個(gè)或幾個(gè)測(cè)試用戶的UD，進(jìn)行消息的互相收發(fā)，利用消息收發(fā)回環(huán)，來實(shí)時(shí)探測(cè)消息鏈路的可用性。大概的思路如下圖：我們分別在機(jī)房1和機(jī)房2部署探測(cè)程序，用來兩個(gè)機(jī)房的消息收發(fā)接口可用性。機(jī)房1的探測(cè)程序設(shè)置成“自己的ID”為UID1，“對(duì)方的ID”為UID2，機(jī)房2的探測(cè)程APIAPI另一種情況，比如機(jī)房1的探測(cè)程序發(fā)送數(shù)字NAPI2N+1，如果沒有收到，則說明機(jī)房2的探測(cè)程序可能出現(xiàn)異常，或者機(jī)房2的應(yīng)用服務(wù)接口有異常，這可以發(fā)現(xiàn)，通過回環(huán)探測(cè)的方式，探測(cè)程序不僅能檢測(cè)本機(jī)房應(yīng)用服務(wù)接口的可用性，也能通過連續(xù)發(fā)送的數(shù)字，間接地探測(cè)出對(duì)方機(jī)房應(yīng)用服務(wù)的可用性，從而避免了由于兩個(gè)機(jī)房網(wǎng)絡(luò)間的異常，而無法發(fā)現(xiàn)消息收發(fā)失敗的情況。主動(dòng)探測(cè)程序作為一個(gè)獨(dú)立的第，通過模擬用戶消息收發(fā)的行為，彌補(bǔ)可能由于應(yīng)用服務(wù)不可用，導(dǎo)致數(shù)據(jù)無法上報(bào)的缺陷。但探測(cè)的缺陷在于可模擬的因此，我們可以將主動(dòng)探測(cè)和一起協(xié)同使用，作為即時(shí)消息服務(wù)的雙保今天，我們從消息收發(fā)鏈路的體系搭建出發(fā)，講解了業(yè)界對(duì)于服務(wù)的兩種常見模式：和主動(dòng)。主要依賴服務(wù)器或者應(yīng)用服務(wù)的數(shù)據(jù)上報(bào)，通過第系統(tǒng)，來對(duì)數(shù)又可以細(xì)分為系統(tǒng)層和應(yīng)用層，這兩種通過實(shí)時(shí)收集機(jī)器層面和應(yīng)用另外，還有一種全鏈路Trace，也屬于，實(shí)際上也屬于應(yīng)用層的范疇它是基于的Dapper Trace，將消息收為進(jìn)行整體的端到端的串聯(lián)，極大地提升了問題排查的效率，而且為鏈路優(yōu)化分析和用戶數(shù)據(jù)分析，提供了強(qiáng)有力的數(shù)據(jù)支撐。為了彌補(bǔ)依賴機(jī)器和應(yīng)用服務(wù)的數(shù)據(jù)上報(bào)的問題，我們還可以通過第的主動(dòng)探測(cè)程序，來實(shí)現(xiàn)主動(dòng)。在消息收發(fā)場(chǎng)景中，通過模擬用戶收發(fā)消息行為的回環(huán)探測(cè)方式，來通道的可用性。我們?cè)诩磿r(shí)消息場(chǎng)景中，就可以通過以上這兩種方式的協(xié)同，來更好地消息收發(fā)服搭建一套完備的體系的重要性是如此之高，特別是對(duì)于大規(guī)模的分布式應(yīng)用場(chǎng)景來說，出現(xiàn)這樣或那樣的問題和故障，已經(jīng)是一個(gè)常態(tài)化的情形。如果沒有一套可以實(shí)時(shí)反映系統(tǒng)整體健康狀況的系統(tǒng)，無異于是盲人摸象，會(huì)讓我們無法正確及時(shí)地評(píng)估業(yè)務(wù)實(shí)際受影響的范圍，也無法快速定位問題。實(shí)際上，對(duì)于今天課程中講到的這些實(shí)現(xiàn)的方式，也是前后端普遍通用的方案，不僅適用于IM的場(chǎng)景，大部分的業(yè)務(wù)場(chǎng)景也都是可以參考使用的，也希望你能嘗試去了解，然后最后給你留一個(gè)思考題：全鏈路Trace系統(tǒng)中，如果被Trace 不得售賣。頁面已增加防盜追蹤，將依法其上一 18|Docker容器化：說一說IM系統(tǒng)中模塊水平擴(kuò)展的實(shí)下一 20|和