導(dǎo)讀：高可用架構(gòu) 7 月 30 日在上海舉辦了『互聯(lián)網(wǎng)架構(gòu)的基石』專題沙龍，進(jìn)行了閉門私董會(huì)研討及對外開放的四個(gè)專題的演講，期望能促進(jìn)業(yè)界對互聯(lián)網(wǎng)基礎(chǔ)服務(wù)及工具的建設(shè)及發(fā)展，本文是姚捷分享唯品會(huì)全鏈路監(jiān)控方案。

姚捷，唯品會(huì)平臺(tái)架構(gòu)部高級架構(gòu)師，加入唯品會(huì)前有超過 10 年的金融／保險(xiǎn)互聯(lián)網(wǎng)技術(shù)架構(gòu)和團(tuán)隊(duì)管理經(jīng)驗(yàn)，擅長以產(chǎn)品思維設(shè)計(jì)和構(gòu)建系統(tǒng)?，F(xiàn)專注于互聯(lián)網(wǎng)基礎(chǔ)架構(gòu)，負(fù)責(zé)唯品會(huì)全鏈路監(jiān)控／分析平臺(tái)的開發(fā)，管理，推廣和運(yùn)維落地工作。對大數(shù)據(jù)體系，實(shí)時(shí)計(jì)算，微服務(wù)體系，消息系統(tǒng)有深入研究和實(shí)踐。

我來自唯品會(huì)平臺(tái)架構(gòu)部，非常感謝高可用架構(gòu)在上海組織了這么一場高逼格的活動(dòng)。唯品會(huì)平臺(tái)架構(gòu)部是長期致力于基礎(chǔ)應(yīng)用架構(gòu)建設(shè)與推廣的部門，我們承擔(dān)非常多的基礎(chǔ)應(yīng)用架構(gòu)研發(fā)。

唯品會(huì)有三大特點(diǎn)，特賣 + 閃購 + 正品，在唯品會(huì)，峰值訪問量非常大，這樣的流量，使得唯品會(huì)平臺(tái)架構(gòu)部承擔(dān)非常大的挑戰(zhàn)，包括我今天分享的全鏈路監(jiān)控系統(tǒng)。

上面是我們的新廣告，周杰倫代言，傲嬌品牌，只賣呆萌的價(jià)格。

今天給大家?guī)淼氖俏覀円粋€(gè)比較重要的產(chǎn)品 Mercury，它是一個(gè)大型互聯(lián)網(wǎng)應(yīng)用全鏈路監(jiān)控系統(tǒng)解決方案。

大家可能了解，500 錯(cuò)誤場景可能是大家在線上經(jīng)常遇到的問題，等待很長時(shí)間，然后系統(tǒng)給你 500，讓大家很抓狂。在部署全鏈路監(jiān)控之前，大家可能需要使用比較古老的方式，跑到生產(chǎn)機(jī)上面去查問題，這個(gè)過程可能耗費(fèi)大量的時(shí)間。

之前在唯品會(huì)，我們做了一個(gè)叫 Logview 的產(chǎn)品，它是一款基于 nginx access log 的監(jiān)控平臺(tái)。唯品會(huì)大量系統(tǒng)前置了一個(gè)代理服務(wù)器，Logview 的機(jī)制是通過解析 nginx access log，構(gòu)建一個(gè)日志監(jiān)控平臺(tái)。它跑了蠻長時(shí)間，迄今還在線上穩(wěn)定運(yùn)行，它曾經(jīng)是唯品會(huì)最重要的一個(gè)監(jiān)控平臺(tái)。

但隨著業(yè)務(wù)規(guī)模的不斷增加，基于 nginx access log 的監(jiān)控會(huì)遇到不少問題。

沒有辦法從代碼級別進(jìn)行監(jiān)控，通過它只能看到粗粒度的監(jiān)控信息；

隨著服務(wù)化的改造，大部分的流量，已經(jīng)不經(jīng)過 nginx 了； 

它支持告警，但是沒有辦法通過告警跟蹤到問題的 root cause。比如說 500 通常是某一個(gè)異常導(dǎo)致的，但是這里是看不到異常的，你還得到主機(jī)上、到 ELK 上查日志。它沒有辦法通過告警很快速的定位到我們線上的 root  cause，尋找問題的成本還是很高。

告警規(guī)則配置呆板，維護(hù)變更代價(jià)大。

沒有辦法跟蹤業(yè)務(wù)之間的調(diào)用關(guān)系。唯品會(huì)在全網(wǎng)大概有上千個(gè)業(yè)務(wù)域，主機(jī)現(xiàn)在接近幾萬臺(tái)，這個(gè)體量是非常之大的，當(dāng)一個(gè)系統(tǒng)一個(gè)域出了一個(gè)業(yè)務(wù)問題的時(shí)候，其實(shí)導(dǎo)致它產(chǎn)生問題的地方可能是很深層的。Logview 沒有辦法幫你跟蹤到這些業(yè)務(wù)之間的關(guān)聯(lián)關(guān)系，調(diào)用關(guān)系沒有建立起來，出了問題你不知道最根本的原因在哪個(gè)域。

沒有辦法快速定位應(yīng)用性能瓶頸。上面也提到，應(yīng)用出了問題沒有辦法關(guān)聯(lián)異常。

高峰值期間流量一上來就經(jīng)常掛。

因?yàn)樯厦娣N種問題，我們痛定思痛，尋找新的方法。這個(gè)新的方向是什么？當(dāng)時(shí)我們看了 Google Dapper (http://research.google.com/pubs/pub36356.html)  的文章之后，認(rèn)為基本上就是全鏈路監(jiān)控系統(tǒng)。

Dapper 是幫大家構(gòu)建一套比較完整的端到端的全鏈路日志采集的規(guī)范，是大家可以跟隨的一個(gè)原則或者準(zhǔn)則。它最關(guān)鍵的概念就是 span。

基于 Dapper 原理，有蠻多行業(yè)解決方案，比較有名的有淘寶 eagle eye，點(diǎn)評/攜程的 CAT，微博的 Watchman，還有聽云 Server 等。當(dāng)時(shí)我們也對這些方案做了一些調(diào)研，但最終我們還是選擇自建平臺(tái)。

為什么呢？因?yàn)槲ㄆ窌?huì)還算有錢，團(tuán)隊(duì)的能力也比較強(qiáng)，有蠻多資深的技術(shù)人員。除了有錢有之外，更多的是從業(yè)務(wù)上，從系統(tǒng)層面上去看我們?yōu)槭裁匆越ㄆ脚_(tái)。

第一，系統(tǒng)復(fù)雜。上千個(gè)業(yè)務(wù)域，同時(shí)又是異構(gòu)系統(tǒng)，有很多系統(tǒng)還是 PHP。服務(wù)化體系內(nèi)存在眾多的異構(gòu)系統(tǒng)的，我們要去監(jiān)控這樣的異構(gòu)系統(tǒng)，顯然不能直接用一些業(yè)界的方案。

第二，海量數(shù)據(jù)。唯品會(huì)峰值每分鐘上億日志量，一天達(dá)到上百億的日志量，這是非常海量的數(shù)據(jù)。BAT 之外，對比其他公司，唯品會(huì)在這個(gè)數(shù)據(jù)量上面也是很高的。對這些海量日志，怎么樣端到端對海量數(shù)據(jù)搜集、計(jì)算、存儲(chǔ)、檢索，這是一個(gè)很大的挑戰(zhàn)。

第三，我們需要自建服務(wù)化體系的監(jiān)控。我們有自建的服務(wù)化體系，這個(gè)服務(wù)化體系要怎么監(jiān)控？我們的服務(wù)端其實(shí)需要一些定制的埋點(diǎn)和數(shù)據(jù)透傳機(jī)制的，它沒有辦法說我直接打一個(gè) log，這其實(shí)是每個(gè)公司有自己的服務(wù)化體系，它需要自己去埋點(diǎn)。

第四，高度可治理。這個(gè)非常重要，因?yàn)楫?dāng)你整個(gè)攤子鋪大了之后，上千個(gè)域都接入后，怎么去管理？比如說大促的時(shí)候經(jīng)常遇到我沒數(shù)據(jù)了，為什么沒有數(shù)據(jù)，整個(gè)體系是非常復(fù)雜的，我怎么樣能夠快速的知道這個(gè)業(yè)務(wù)為什么沒有監(jiān)控?cái)?shù)據(jù)了，這就涉及到治理。

另外大促的時(shí)候我們要做一些動(dòng)態(tài)的升降級，這些動(dòng)態(tài)的升降級也是依賴比較強(qiáng)的治理能力，需要在生產(chǎn)環(huán)境去控制日志的產(chǎn)生。

第五，快速接入，升級便捷。因?yàn)槲覀兊膱F(tuán)隊(duì)很大，開發(fā)人員很多，所以我們的產(chǎn)品要做到讓業(yè)務(wù)用起來很方便，我們需要一些無侵入埋點(diǎn)，快速接入。

同時(shí)在我們很復(fù)雜的體系當(dāng)中，需要考慮怎么快速的升級，我不知道大家有沒有經(jīng)歷過在一個(gè)很龐大的體系當(dāng)中升級客戶端，不管是監(jiān)控系統(tǒng)的客戶端，還是其他的客戶端都是很頭疼的問題，特別是在業(yè)務(wù)線眾多的大型公司。據(jù)說阿里的 dubbo/hsf 的升級其實(shí)是非常困難的，我們現(xiàn)在也遇到類似的問題，因此需要提前去考慮這些問題。

第六，靈活的告警策略和高效告警。我們需要一個(gè)多維度、多監(jiān)督、多級別、多時(shí)效、同時(shí)支持告警收斂的告警引擎

第七，還有一個(gè)很重要的一點(diǎn)，監(jiān)控體系要與公司的很多體系無縫對接，我需要滿足不同角色的需求，同時(shí)要與唯品會(huì)的發(fā)布、監(jiān)控、問題跟蹤平臺(tái)無縫對接。

所以正是因?yàn)橐陨戏N種原因，我們決定自建平臺(tái)。

先快速給大家介紹一下 Mercury。

Mercury 是唯品會(huì)自主研發(fā)的應(yīng)用性能監(jiān)控和問題跟蹤平臺(tái) 

基于客戶端探針上報(bào)應(yīng)用調(diào)用鏈相關(guān)日志   

基于流式計(jì)算和大數(shù)據(jù)存儲(chǔ)和檢索技術(shù) 

提供實(shí)時(shí)和準(zhǔn)實(shí)時(shí)告警,并快速定位根源問題

分布式應(yīng)用調(diào)用鏈路跟蹤 

提供快速有效的數(shù)據(jù)展現(xiàn)和分析平臺(tái) 

唯品會(huì)監(jiān)控體系

我們的全鏈路應(yīng)用監(jiān)控體系在唯品會(huì)處于什么樣的位置？

系統(tǒng)層監(jiān)控我們主要還是 Zabbix，我們在上面做了一些封裝，提供更好的交互。

業(yè)務(wù)層我們有一個(gè)產(chǎn)品叫 Telescope，所有的業(yè)務(wù)監(jiān)控，包括 PV/UV、定單量、支付成功/失敗率等重要業(yè)務(wù)數(shù)據(jù)，全部在這個(gè)產(chǎn)品上面可以看到。

在應(yīng)用層，現(xiàn)在 ELK 用得比較多，另外一個(gè)產(chǎn)品 SKYHAWK，它其實(shí)是 APP 應(yīng)用端的監(jiān)控平臺(tái)。

接下來是 Mercury，唯品會(huì)現(xiàn)在所有的應(yīng)用，所有服務(wù)化的應(yīng)用，所有 PHP/Web 應(yīng)用，都是通過 Mercury 來做應(yīng)用層的監(jiān)控。

為唯品會(huì)的監(jiān)控生態(tài)而設(shè)計(jì)

在說到一些技術(shù)之前，我還想強(qiáng)調(diào)一點(diǎn)，我們做產(chǎn)品并不是簡單地做一個(gè)技術(shù)，簡單地把很多東西搭在一起，我們更多的是要為整個(gè)技術(shù)生態(tài)去設(shè)計(jì)。我們的產(chǎn)品更多的是為滿足整個(gè)唯品會(huì)的運(yùn)營、技術(shù)運(yùn)營的需要，為這個(gè)生態(tài)的需要而設(shè)計(jì)，所以會(huì)涉及到人、流程和技術(shù)。

人的話，無非就是開發(fā)、監(jiān)控、運(yùn)維、運(yùn)營、管理人員，這些人都會(huì)通過我們平臺(tái)，去查看他們想看的數(shù)據(jù)。我們的監(jiān)控系統(tǒng)會(huì)發(fā)布流程，發(fā)布的時(shí)候我要監(jiān)控整個(gè)發(fā)布的質(zhì)量，監(jiān)控流程、故障問題定位、故障問題修復(fù)、以及故障回顧，這些其實(shí)是整個(gè)監(jiān)控系統(tǒng)需要控制的流程。

技術(shù)上，主要包括大數(shù)據(jù)采集、大數(shù)據(jù)計(jì)算、大數(shù)據(jù)的存儲(chǔ)和分析，這些技術(shù)整個(gè)形成了我們的監(jiān)控生態(tài)。

Mercury 核心價(jià)值

Mercury 的核心價(jià)值在于：

生產(chǎn)環(huán)境端到端的性能可視化；

展現(xiàn)一個(gè)應(yīng)用的完整的拓?fù)潢P(guān)系，通過全鏈路監(jiān)控系統(tǒng)，我們把整個(gè)鏈路的拓?fù)湔宫F(xiàn)出來；

快速告警，并且定位根源的問題。

這三點(diǎn)我總結(jié)下來，是我們這個(gè)產(chǎn)品最核心的價(jià)值。

海量數(shù)據(jù)剛才我也提到了，大約如下：

1萬+ 應(yīng)用服務(wù)器接入 

接入業(yè)務(wù)域 500+ 

大促峰值每分鐘處理日志 1億+

日均處理日志量 150億+ 

日均存儲(chǔ)日志 5T+ 

日均索引量 1T

這些數(shù)據(jù)都體現(xiàn)我們的產(chǎn)品，我們是在支撐一個(gè)非常海量的數(shù)據(jù)。

前面提到這么多的統(tǒng)計(jì)數(shù)據(jù)也好，監(jiān)控流程也好，回頭來看一下，Mercury 是怎么去支撐這樣的海量數(shù)據(jù)的？我們的架構(gòu)是怎么樣的？我們可以深入到一些架構(gòu)的細(xì)節(jié)，去看怎么去構(gòu)建一個(gè)比較完整的全鏈路監(jiān)控系統(tǒng)。

完整的全鏈路監(jiān)控系統(tǒng)

一個(gè)比較完整的全鏈路監(jiān)控系統(tǒng)，通常會(huì)包括幾個(gè)部分。

第一，數(shù)據(jù)埋點(diǎn)和采集，這個(gè)相當(dāng)重要，其實(shí)說白了，數(shù)據(jù)是整個(gè)監(jiān)控系統(tǒng)最核心的部分，必須有能力快速和正確和方便地采集日志，所以我們在數(shù)據(jù)埋點(diǎn)和采集上做了很多文章。

第二，指標(biāo)計(jì)算。指標(biāo)計(jì)算有好幾種方式，一種我可以在客戶端做一些計(jì)算，通過 agent 上報(bào)計(jì)算結(jié)果，然后到服務(wù)端再做加工。還有一種策略是完全在服務(wù)端的計(jì)算，客戶端只做簡單的數(shù)據(jù)采集，所有的指標(biāo)計(jì)算全放在服務(wù)端。這二種架構(gòu)其實(shí)都有不同的優(yōu)缺點(diǎn)。

第三，指標(biāo)存儲(chǔ)、查詢、展現(xiàn)，這個(gè)也非常重要。算完后的指標(biāo)放在哪里，這些指標(biāo)怎么樣快速的查詢出來，指標(biāo)怎么樣很靈活的展現(xiàn)給我們的運(yùn)營人員、開發(fā)人員。

第四，調(diào)用鏈的存儲(chǔ)、查詢、展現(xiàn)。因?yàn)槲覀兪侨溌繁O(jiān)控系統(tǒng)，調(diào)用鏈怎么存、怎么查、怎么看，這個(gè)也是非常重要的。

第五，告警、問題定位，因?yàn)槟銌渭冎挥胁樵冞h(yuǎn)遠(yuǎn)不夠，我們需要一個(gè)很快速很高效的告警，同時(shí)產(chǎn)生告警之后，我們需要很快速的去定位這個(gè)告警是什么原因?qū)е碌摹?br>

第六，自監(jiān)控。我們的體系需要一個(gè)自監(jiān)控的功能，假如我在大促的時(shí)候掛了，我需要很快的恢復(fù)我們的平臺(tái)，自監(jiān)控非常重要。

第七，治理。大促之前需要?jiǎng)討B(tài)地調(diào)整日志采樣率，或者對日志采集做一些功能降級，例如不采集緩存相關(guān)日志。

建設(shè)一個(gè)完整的全鏈路監(jiān)控體系是需要考慮以上這幾個(gè)過程。

全鏈路監(jiān)控技術(shù)棧

技術(shù)棧，我們的體系有用了很多的技術(shù)，Spark 、 Open  TSDB  、HBase  、Elastic Search，Kafka，F(xiàn)lume，Python 等，整個(gè)技術(shù)棧相當(dāng)之復(fù)雜。

系統(tǒng)架構(gòu)

我們 Mercury 的架構(gòu)是怎么樣的呢，大家來看一下，大致來跟大家描述一下我們整個(gè)架構(gòu)的走法。

先說客戶端，應(yīng)用系統(tǒng)其實(shí)是依賴一個(gè) client 這樣的探針組件，它其實(shí)是一個(gè)非常非常高效的數(shù)據(jù)采集組件，對用戶來說是完全透明的，你不需要去做任何的編程，基于字節(jié)碼織入技術(shù)，只需要做一些簡單的配置。那么客戶端就能夠很高效的采集相關(guān)日志數(shù)據(jù)。這些日志是基于一個(gè)標(biāo)準(zhǔn)格式的，因此，我們的接入是非常高效的，你不需要關(guān)心我采集日志的格式是什么。很多其它的監(jiān)測系統(tǒng)，比如像 CAT，可能它需要手動(dòng)埋點(diǎn)，這個(gè)時(shí)候你可能需要非常關(guān)注它的埋點(diǎn)格式是什么。我們是不需要關(guān)心埋點(diǎn)格式的。

我們的日志數(shù)據(jù)是不會(huì)直接傳到后端的，它首先落地在客戶端的磁盤上面。

接著我們有一個(gè) flume agent，基于 Flume，我們做了一個(gè)插件，這個(gè)插件會(huì)非常高效地采集我們客戶端的日志。

當(dāng)我們搜集到了日志之后，它就很高效地把日志推到 Kafka 集群里面。我們要保證它的日志是非常精簡的，因?yàn)槲ㄆ窌?huì)有多個(gè) IDC 機(jī)房，跨機(jī)房低帶寬占用是非常重要的。這個(gè)上面我們做了一些基于 avro 的數(shù)據(jù)序列化的優(yōu)化，序列化之后帶寬基本上降了一倍左右。我們沒有用壓縮，因?yàn)閴嚎s會(huì)導(dǎo)致客戶端的消耗比較大。

當(dāng)這些數(shù)據(jù)來到 Kafka 集群，后面有幾個(gè)集群，首先第一個(gè)是 Spark 集群，這是一個(gè)非常重要的數(shù)據(jù)流式計(jì)算的集群，我們通過 Spark 做指標(biāo)計(jì)算，讓所有的日志都通過 Spark 很快速的算下來的，基本上延時(shí)在兩分鐘左右。考慮到端到端數(shù)據(jù)上報(bào)的時(shí)效性，其中只有一到兩分鐘是計(jì)算的延時(shí)。

指標(biāo)算完之后，一條線到 OpenTSDB，如果做過監(jiān)控的同學(xué)對這個(gè)應(yīng)該是蠻熟的，相對來說也是比較成熟，比較簡單的基于 HBase 的一個(gè)時(shí)間序列的框架。

另外一條路，通過 flume 寫到 HBase 里，因?yàn)榇蠹铱吹狡鋵?shí)我們有調(diào)用鏈，那我們要對調(diào)用鏈做很快速的檢索，我們以前是直接把調(diào)用鏈日志寫到 HBase 里，但是有一個(gè)頭疼的問題是它的寫入很快，通過 rowkey 一鍵查詢也很快，但是如果說你需要做一些比較復(fù)雜的查詢，HBase 是不支持二級索引查詢的，你必須自己在它之上構(gòu)建二級索引。

原來我們直接設(shè)計(jì)了一個(gè)索引表，但在海量數(shù)據(jù)下，查詢起來非常之慢，所以我們后來用 ElasticSearch，首先日志數(shù)據(jù)送到 Kafka 后會(huì)被消費(fèi)兩次，一條路是直接送到 ElasticSearch 里建索引。另外一條路是調(diào)用鏈日志直接落地到 HBase。

查詢的時(shí)候，首先到 ES 里根據(jù)查詢條件定位到 trace id，接著拿著 trace ID 到HBase 里一鍵把所有的端到端的請求都拉出來，所以通過一個(gè) Trace ID 就能一下子把作為的調(diào)用鏈全拉出來，因此這個(gè)設(shè)計(jì)是非常輕巧的。

整個(gè)體系還有很重要的是兩個(gè)告警引擎，它分為實(shí)時(shí)秒級告警和一個(gè)指標(biāo)告警。實(shí)時(shí)秒級告警更多的是對嚴(yán)重問題的告警，比如大量的服務(wù)超時(shí)，或者服務(wù)熔斷。這個(gè)時(shí)候我們整個(gè)體系會(huì)上報(bào)一些事件，會(huì)有一些熔斷事件，我們會(huì)預(yù)埋在我們的服務(wù)框架里面，一旦遇到這種問題的時(shí)會(huì)立刻上報(bào)。我們的上一級告警框架，會(huì)立刻檢測到這個(gè) alarm，然后做實(shí)時(shí)告警。

同時(shí)我們會(huì)對這些異常做一些收斂，假設(shè)瞬間好幾百臺(tái)或者上千臺(tái)的主機(jī)都產(chǎn)生了異常，那整個(gè)異常都會(huì)一下子上報(bào)服務(wù)端，這個(gè)時(shí)候你會(huì)在服務(wù)端產(chǎn)生大量的報(bào)警，所以我們秒級告警會(huì)做一些收斂，會(huì)做一個(gè)特征值的設(shè)定，我會(huì)在三十秒或者十秒，這個(gè)時(shí)間窗口你可以定制，比如我十秒的窗口，我先對一些有特制的異常做一些簽名，緩存到內(nèi)存里面，如果在一段時(shí)間之內(nèi)，上報(bào)的異常匹配了特征值，則不會(huì)做重復(fù)告警。

當(dāng)這個(gè)時(shí)間窗口過去之后，這個(gè)特征值就會(huì)失效，下一次再進(jìn)來的時(shí)候，我們會(huì)重新構(gòu)建這個(gè)特征值。我們用這樣的一個(gè)方法實(shí)現(xiàn)告警收斂。

下面這個(gè)是指標(biāo)告警，它是一個(gè)周期性的告警任務(wù)，它會(huì)根據(jù)我的告警規(guī)則設(shè)定，定時(shí)掃描指標(biāo)數(shù)據(jù)庫做一個(gè)周期性的告警。比如連續(xù)三分鐘，響應(yīng)時(shí)間大于 30。毫秒就告警，類似這樣的告警我們通過周期性的告警規(guī)則來設(shè)定。

在后面還有 Dashboard 和告警跟蹤系統(tǒng)。上面也提到，我們是為整個(gè)唯品會(huì)的監(jiān)控生態(tài)而設(shè)計(jì)，這個(gè)告警跟蹤系統(tǒng)會(huì)把我們所有的告警聚合到一起。告警看板的作用是說我立刻能在大盤上看到所有的告警，但是這些問題是不是已經(jīng)處理完了，我們是需要一個(gè)比較好的跟蹤平臺(tái)去跟蹤的，所以我們設(shè)計(jì)了這樣的跟蹤系統(tǒng)。它是長時(shí)間運(yùn)行的，開發(fā)人員每天會(huì)上去看。比如我昨天有些告警，這些告警有沒有處理完，都會(huì)在這個(gè)系統(tǒng)當(dāng)中呈現(xiàn)。

調(diào)用鏈

整個(gè)體系還是蠻龐大的，接下來跟大家說一下我們整個(gè)體系最核心的調(diào)用鏈。

什么是調(diào)用鏈，大家可能第一次接觸全鏈路系統(tǒng)，可能對調(diào)用鏈的概念并不一定熟。你可以認(rèn)為它是一個(gè)串聯(lián)端到端請求的鏈路，在這個(gè)鏈路上面我們會(huì)看到非常豐富的信息。

調(diào)用參數(shù)

我們在調(diào)用鏈上面我們?nèi)リP(guān)聯(lián)說這個(gè)調(diào)用的參數(shù)是什么，我的出參入?yún)⒖梢栽谶@個(gè)調(diào)用鏈上面。

業(yè)務(wù)關(guān)鍵字

這里我需要稍微解釋一下什么叫業(yè)務(wù)關(guān)鍵字。很多時(shí)候想象一下這樣一個(gè)場景，有一個(gè)用戶下單支付失敗了，這個(gè)時(shí)候我們怎么樣知道，為什么這個(gè)支付失敗了，到底是支付整個(gè)鏈路上面哪里出了問題，這個(gè)是需要我們還原現(xiàn)場。

如果有一個(gè)系統(tǒng)它能夠幫你還原這次調(diào)用，到底哪一步出了問題，所以你需要去反查，你需要拿著一些業(yè)務(wù)上面預(yù)先埋的點(diǎn)，比如說定單號(hào)或者用戶ID，通過這些信息我能夠反查到當(dāng)時(shí)用戶下單操作的那次調(diào)用，再去看那次調(diào)用到底哪里出了問題。所以業(yè)務(wù)關(guān)鍵字是非常重要的。

我們要求核心的業(yè)務(wù)系統(tǒng)要通過我們的 API 去埋它的關(guān)鍵字，把它的用戶信息、訂單號(hào)，或者說我們一些很關(guān)鍵的業(yè)務(wù)字段，都預(yù)先的埋到我們的調(diào)用鏈上面，出了問題之后就可以反查。

調(diào)用耗時(shí)

這個(gè)應(yīng)該很清楚。事件，因?yàn)橛械臅r(shí)候我們要調(diào)用的時(shí)候，我們可以把一些這次調(diào)用產(chǎn)生的事件關(guān)聯(lián)在一起，我們也可以通過事件去反查當(dāng)時(shí)的調(diào)用。異常日志這個(gè)信息非常重要，因?yàn)楫?dāng)你出了 500 的時(shí)候，一定會(huì)有異常產(chǎn)生，這個(gè)時(shí)候我就要通過這次調(diào)用去關(guān)聯(lián)這個(gè)異常，然后通過這個(gè)異常信息我就知道產(chǎn)生問題的是什么。

調(diào)用結(jié)果

調(diào)用結(jié)果，成功失敗。

調(diào)用鏈總結(jié)

所以整個(gè)調(diào)用鏈的信息還是蠻豐富的，那么調(diào)用鏈最核心的是什么？核心的是每個(gè)請求都會(huì)生成一個(gè)全局唯一的 TraceID 和 SpanID，它都會(huì)端到端的透傳到上下游所有的節(jié)點(diǎn)。每一個(gè)請求 TraceID 都要透傳上去，從最上游的移動(dòng)端一直到最下面的數(shù)據(jù)庫，通過這個(gè) TraceID 我們將不同系統(tǒng)的孤立的調(diào)用日志和異常日志串聯(lián)在一起，同時(shí)通過 SpanID 可以表達(dá)節(jié)點(diǎn)的父子關(guān)系。

下面我為大家來說一說我們每一個(gè)組件當(dāng)中的一些非常重要的設(shè)計(jì)原則，

1. 客戶端 - 舉重若輕

首先從客戶端講起，客戶端我把它形容為舉重若輕，你需要有一個(gè)很輕量級的客戶端，但它同時(shí)又能夠承擔(dān)很大的流量，怎么能夠做到這一點(diǎn)？我覺得很關(guān)鍵有以下幾點(diǎn)需要去注意。

高效率

高效率更多的是對開發(fā)人員來說，我要讓他們很快能夠用我們的東西。我們現(xiàn)在是支持 Java 和 PHP，高效率主要體現(xiàn)在：

Java 采用 AOP 埋點(diǎn)，不管是一個(gè) Java 調(diào)用、其他的調(diào)用還是服務(wù)化調(diào)用，我們都會(huì)攔截所有的請求，植入我們的邏輯，包括透傳。

PHP 也有自己的框架，所以在 PHP 里面也進(jìn)行預(yù)埋，對 PHP 的應(yīng)用邏輯而言也是透明的。

日志格式是標(biāo)準(zhǔn)的，要不然日志框架沒有辦法很快的去監(jiān)控我們的系統(tǒng)，用戶是沒有感知的。

高性能

在數(shù)據(jù)采集端其實(shí)負(fù)載很低，客戶端對應(yīng)用的影響控制在 5% 以內(nèi)。為什么能夠有比較高的性能？因?yàn)槲覀兊目蛻舳藭?huì)構(gòu)建一個(gè)異步日志隊(duì)列。同時(shí)，會(huì)良好的管理內(nèi)存和 CPU 的使用。

我們通過 AVRO 序列化傳輸，可以節(jié)省一半的帶寬。

通過設(shè)計(jì)日志數(shù)據(jù)格式，避免冗余數(shù)據(jù)。整個(gè)客戶端我們先把數(shù)據(jù)打到磁盤上面，磁盤 IO 比較高效。這個(gè)時(shí)候 IO 性能是比較重要的，如果我的日志格式是相當(dāng)冗余的，會(huì)導(dǎo)致 IO 上升。所以我會(huì)做一些比較精巧的設(shè)計(jì)，讓整個(gè)日志相對來說比較小。

高可治理

客戶端的可治理也非常重要，在高可治理上面我們做了這些事情：

第一集成我們的配置中心。唯品會(huì)有一個(gè)比較重要的組件，就是配置中心，它承擔(dān)了所有的業(yè)務(wù)配置、系統(tǒng)配置、以及服務(wù)化的動(dòng)態(tài)發(fā)現(xiàn)。我們現(xiàn)在服務(wù)治理也放在這個(gè)配置中心里面，包括服務(wù)的一些路由策略。當(dāng)然在配置中心做了一些分群，讓整個(gè)管理比較可控。

通過這個(gè)配置中心我可以動(dòng)態(tài)下發(fā)很多的指令，采樣率等等都是可以被動(dòng)態(tài)的降級，比如 HTTP、OSP、SQL 等也可以關(guān)閉，出問題時(shí)，一鍵關(guān)閉這個(gè)客戶端的日志采集。

采樣率可以動(dòng)態(tài)的調(diào)整，我不知道大家對這個(gè)采樣是怎么理解的。采樣是蠻有講究，采樣不是說我這個(gè)域要設(shè)一個(gè)采樣率，那個(gè)域要設(shè)一個(gè)采樣率，在全鏈路監(jiān)控系統(tǒng)上面，采樣率必須要在調(diào)用源頭設(shè)置，需要在最上游去設(shè)置采樣率，然后采樣率會(huì)透傳到下游所有的節(jié)點(diǎn)上。每個(gè)服務(wù)一看上游給過來的，告訴說要采樣我就用它。所以整個(gè)采樣率是完全跟著最上游的節(jié)點(diǎn)來看，每個(gè)模塊不能隨便的去設(shè)采樣率。這個(gè)也是非常關(guān)鍵的一點(diǎn)，想明白這個(gè)就非常簡單了。

同時(shí)除了源頭采樣之外，我們也支持域級的采樣，雖然源頭設(shè)了采樣率，但是我不想跟隨，我就想自己設(shè)一個(gè)采樣率，也是可以支持的。這樣有一個(gè)什么后果？假如說我源頭設(shè)一個(gè)采樣率，你自己也設(shè)了一個(gè)，后果就是出了問題的時(shí)候，我去查我的調(diào)用鏈信息，如果不跟隨相同策略，有可能當(dāng)中的鏈路會(huì)斷掉。

客戶端會(huì)上報(bào)客戶端的版本，這個(gè)也是相當(dāng)?shù)闹匾?，因?yàn)樵谝粋€(gè)比較大的體系當(dāng)中，版本的規(guī)劃與升級是相當(dāng)重要，這個(gè)我們其實(shí)也踩了很多坑，因?yàn)闃I(yè)務(wù)在飛速發(fā)展，組件在飛速發(fā)展，這個(gè)時(shí)候如果需要考慮升級，就需要考慮線上到底有哪些版本，有哪些域需要推動(dòng)他們?nèi)ド?，我不知道對方需要什么版本，因?yàn)橐欢螘r(shí)間之內(nèi)，他可能會(huì)出很多個(gè)版本，最多的時(shí)候我們有五、六個(gè)版本在線上跑，當(dāng)出新版本的時(shí)候，你需要推動(dòng)升級，有上千個(gè)域，你不知道有誰在用你的版本。所以我們會(huì)把所有的版本全上報(bào)到我們服務(wù)端，通過我們的治理平臺(tái)，會(huì)很快看到我每個(gè)域的版本。

敏感信息脫敏，這個(gè)也是非常重要的，因?yàn)槲覀儾杉男畔⑾喈?dāng)豐富，所有的出參入?yún)⒍紩?huì)采集，會(huì)有很多敏感的信息，帳務(wù)信息、用戶的登陸信息，這些都是需要脫敏的。

可升級性，輕量級客戶端，還是跟上面這個(gè)版本有關(guān)，我們的客戶端要能夠支持我持續(xù)升級，我不能說每個(gè)版本它的一直工作很好，我一改以后功能都需要去升級，所以可升級是相當(dāng)重要的。

上面是建設(shè)客戶端需要注意的幾點(diǎn)。

2. 服務(wù)端 - 海納百川

下面是服務(wù)端，服務(wù)端我們形容它是海納百川，因?yàn)檎麄€(gè)服務(wù)端的數(shù)據(jù)是海量的，每分鐘上億的峰值量，所以站在服務(wù)端角度我們要考慮這些事情：

流式計(jì)算

首先是流式計(jì)算，Spark 是一個(gè)主流的流式計(jì)算平臺(tái)，我們要關(guān)注幾點(diǎn)，這里我不想去講 Spark 的架構(gòu)，更多的是我們怎么樣去用好它。

第一，Kafka 端建立多 Topic，之前老的方案我們會(huì)只建立 2 個(gè) Topic，對 Spark 內(nèi)存開銷比較大。因?yàn)?Spark 需要消費(fèi)這 2 個(gè) Topic，因?yàn)椴煌闹笜?biāo)其實(shí)需要的數(shù)據(jù)量是不一樣的，需要的數(shù)據(jù)類型是不一樣的，如果你 Topic 數(shù)量比較少，意味著我的 Spark 需要消費(fèi)一個(gè)很大的池子，然后把池子里的數(shù)據(jù)做一個(gè)篩選過濾再去做指標(biāo)計(jì)算，這個(gè)對 Spark 的內(nèi)存需要是相當(dāng)大的。

舉個(gè)例子，我的池子里面有一百條魚，我要算這一百條魚，不同的魚有不同的品種。假如我只算某一種魚類品種，我只需要把這種魚的類型挑出來再去算。如果是一百條還好，如果是一億條這個(gè)量是非常之大的，所以我們需要在客戶端的時(shí)候，首先把這些不同類型的日志分類，接著分發(fā)到不同的 Topic 上面，然后 Spark 按照不同的計(jì)算去消費(fèi)不同的 Topic，這樣就不用一億條魚全部放到里面去算了。我只需要用不同的池子去算不同的指標(biāo)。

第二，Wall  Time  Or  Event  Time，這是兩種不同計(jì)算的策略。

第一種是只算當(dāng)前的時(shí)間，我根據(jù)當(dāng)前的時(shí)間來算，根據(jù)當(dāng)前的時(shí)間來算有一個(gè)重要的缺陷，由于日志上報(bào)其實(shí)是有延時(shí)的，有些日志可能受限于客戶端，可能網(wǎng)絡(luò)的問題，或者客戶端有失敗的調(diào)用，或者說客戶端和服務(wù)端連接的問題，或者客戶端的時(shí)間有問題，都會(huì)導(dǎo)致我的日志沒有很及時(shí)的跟上，沒有很及時(shí)的上報(bào)到服務(wù)端，所以通過 wall  time 方式就會(huì)過濾到部分日志，精準(zhǔn)度就不高。

第二種是 Event  Time，是根據(jù)整個(gè)日志上報(bào)時(shí)間來的，不是根據(jù)當(dāng)前時(shí)間來的。

第三，這里有個(gè)很重要的點(diǎn)，即我們現(xiàn)在基于二階段計(jì)算模式，能夠保證整個(gè) Spark 計(jì)算的精準(zhǔn)性。大家知道 Spark 其實(shí)是一個(gè)批處理，更多的是一個(gè)批量的去處理日志，我們目前的策略會(huì)每隔 20 秒去消費(fèi)這 20 秒的數(shù)據(jù)，然后把這 20 秒的數(shù)據(jù)算完之后推到 Kafka 里面，我先不給一個(gè)最終結(jié)果，后面還有另外一個(gè)集群，它會(huì)再去計(jì)算這 20 秒的數(shù)據(jù)，再把它聚合成一分鐘的數(shù)據(jù)。

這樣的好處是什么？因?yàn)槎A段計(jì)算非常重要，它能夠容忍 30 分鐘的延遲，假設(shè)網(wǎng)絡(luò)有延時(shí)，或者客戶端有問題日志上報(bào)很慢，這時(shí)二階段就能夠包容這樣的錯(cuò)誤，它會(huì)計(jì)算 30 分鐘以前的數(shù)據(jù)，經(jīng)過聚合以后，通過一階段的計(jì)算，把這個(gè)數(shù)據(jù)量降到一個(gè)很低的程度，這個(gè)時(shí)候二階段可以重新去算這 30 分鐘的數(shù)據(jù)。這個(gè)架構(gòu)是非常之輕巧，使得我們計(jì)算的精準(zhǔn)性相當(dāng)之高。

第四，我們會(huì)記錄數(shù)據(jù)回放 Checkpoint，支持容錯(cuò)，這是流式計(jì)算很重要的一點(diǎn)。假設(shè) Spark 垮了，需要從頭找當(dāng)時(shí)消費(fèi)的 Checkpoint 去做一些容錯(cuò)，我會(huì)定時(shí)的把這個(gè) checkpoint 存下來，需要做數(shù)據(jù)回放的時(shí)候，我們就會(huì)通過它重新去拉數(shù)據(jù)。

第五，數(shù)據(jù)流控。為了保證我們的流式計(jì)算，我們會(huì)在 Spark 端做一些流控。

第六，參數(shù)調(diào)優(yōu)。內(nèi)核參數(shù)其實(shí)也是相當(dāng)重要，針對流式計(jì)算非常大的痛點(diǎn)就是，假設(shè)你忽然有一個(gè)非常大的 STW（Stop the World） GC，整個(gè)流式計(jì)算就會(huì)產(chǎn)生延時(shí)，產(chǎn)生延時(shí)的一個(gè)最大后果就是所有的指標(biāo)趨勢圖，都會(huì)看到一個(gè)波谷，因?yàn)楫a(chǎn)生延時(shí)之后，整個(gè)指標(biāo)就已經(jīng)不準(zhǔn)確了。

之前在沒有對內(nèi)核參數(shù)做調(diào)整之前，經(jīng)常會(huì)出現(xiàn)峰值高峰時(shí)，忽然監(jiān)控打電話來說，為什么某個(gè)地方?jīng)]數(shù)據(jù)了，過了五分鐘又有了。這個(gè)時(shí)候就是因?yàn)橄到y(tǒng)在做 GC，或者有內(nèi)存的換頁，或者有內(nèi)存的回收。

所以我們對這塊做一些性能調(diào)優(yōu)，讓整個(gè)內(nèi)存的回收是比較平緩的。大家可以去關(guān)注一下 Linux numa 架構(gòu)，它對這個(gè)內(nèi)存的管理。所以我們在這上面做了一些調(diào)優(yōu)，使得 Linux 內(nèi)核對于內(nèi)存的管理做得相對比較平緩，不至于非常激進(jìn)，比如內(nèi)存一旦不足就立刻做 swap 或者內(nèi)存頁回收，導(dǎo)致整個(gè)系統(tǒng) CPU 消耗很高，最終導(dǎo)致計(jì)算超時(shí)。

海量存儲(chǔ)

基于 OpenTSDB 保存全量指標(biāo)，我們其實(shí)存的是全量日志，針對于指標(biāo)你是可以查詢歷史上所有的數(shù)據(jù)點(diǎn)。

對于 TSDB，優(yōu)化整個(gè)查詢性能很重要的兩點(diǎn)，第一點(diǎn)是控制 Cardinality 的大小，要保證在設(shè)計(jì)我們指標(biāo)的時(shí)候，讓整個(gè) cardinality 盡量的小，否則從上億條里面去做一個(gè)指標(biāo)查詢是很慢的。

怎么樣讓它變??？很重要的一點(diǎn)就是通過 Shift to Metric 去設(shè)計(jì)這個(gè) Metric Name。所以當(dāng)我把這個(gè)這個(gè) Metric Name 作為一個(gè)指標(biāo)名的時(shí)候，我就能把我當(dāng)前的指標(biāo)變小，可能我的指標(biāo)會(huì)膨脹，可能我一個(gè)指標(biāo)變成十個(gè)指標(biāo)了，但是我單純?nèi)ブ笜?biāo)的時(shí)候，就會(huì)變的很快。

高速查詢

最后是高速查詢，我們通過 ElasticSearch 建立索引。ElasticSearch 怎么分布，怎么部署，怎么建立索引？我們現(xiàn)在是按日，而且按域建立索引，每天每一個(gè)業(yè)務(wù)域，它會(huì)去建立一個(gè)索引，而且針對于不同的重要的業(yè)務(wù)域，我的索引機(jī)器也不一樣，有些很重要的業(yè)務(wù)域可能給它多一點(diǎn)資源。

Trace Log 進(jìn)入 HBase，TraceId 作為 RowKey，一行保存一條調(diào)用鏈。

先查 ElasticSearch，再一鍵定位調(diào)用鏈。

告警平臺(tái)建設(shè)

告警平臺(tái)的建設(shè)，也是 Mercury 里面比較核心的一個(gè)功能。

首先是秒級告警。我們會(huì)端到端的延時(shí)30秒內(nèi)，對異常日志和異常事件告警，同時(shí)對告警做一些收斂。

指標(biāo)告警延時(shí)在兩分鐘內(nèi)。我們的告警機(jī)做了動(dòng)態(tài)分配，我們后面會(huì)有若干臺(tái)，現(xiàn)在大概有五臺(tái)告警機(jī)，每臺(tái)告警機(jī)會(huì)分配一些資源，這些資源都是可以動(dòng)態(tài)分配的，也是基于ZK做的一個(gè)告警機(jī)的動(dòng)態(tài)的注冊，動(dòng)態(tài)資源的分配。所有的告警都會(huì)推到我們的告警大盤上面。

告警策略也是相當(dāng)重要的，我們做了一些設(shè)計(jì)，我會(huì)分離我的告警策略和告警分派，你先去指定策略，然后再把策略分派給不同的業(yè)務(wù)。多維度、多監(jiān)督、多級別告警規(guī)則配置，針對業(yè)務(wù)域、針對主機(jī)、針對API，各種不同的告警都會(huì)體現(xiàn)在我們的告警策略上面，所以我們的告警策略場景覆蓋率是相當(dāng)高的。

再說一下多層告警的重要性。在我們的運(yùn)營過程當(dāng)中，要對不同的告警做不同的分類。我們現(xiàn)在其實(shí)會(huì)會(huì)警告和告警，產(chǎn)生警告的時(shí)候，通常來說可能我們的監(jiān)控人員不會(huì)一下子看這個(gè)警告的問題。當(dāng)這個(gè)警告問題上升到告警的時(shí)候，這些人才會(huì)撲上去。這個(gè)策略是蠻重要的，如果說你一下子產(chǎn)生告警，每個(gè)監(jiān)控人員都一直要關(guān)注這些告警那是相當(dāng)痛苦的。所以我們對告警會(huì)分不同的池子，哪些池子是你不需要很快的去看，哪些池子是需要你立刻去看的。

監(jiān)控質(zhì)量保障——篤定泰山

功能都有了，那我們還缺什么？我們要保障監(jiān)控質(zhì)量。

監(jiān)控?cái)?shù)據(jù)的質(zhì)量是非常重要的，不能在大促的時(shí)候，監(jiān)控先出問題。做過監(jiān)控的人也知道，監(jiān)控系統(tǒng)最麻煩的就是大促的時(shí)候，其他的業(yè)務(wù)域沒出問題，你自己先出了問題。監(jiān)控?cái)?shù)據(jù)量很大，而且對于很多業(yè)務(wù)團(tuán)隊(duì)來說，監(jiān)控系統(tǒng)的重要性不一定排在第一，所以它給到你的資源相對來說也是比較少的。所以經(jīng)常會(huì)遇到說我的監(jiān)控質(zhì)量下降了。

我們可以通過下面的方式去保障我們的監(jiān)控質(zhì)量：

第一，在系統(tǒng)層，我們的監(jiān)控系統(tǒng)的組件都會(huì)接入 Zabbix，對通常系統(tǒng)層面上的指標(biāo)做一些監(jiān)控，特別對機(jī)器的指標(biāo)也要做一些監(jiān)控。我們也會(huì)監(jiān)控跨機(jī)房的網(wǎng)絡(luò)流量，因?yàn)檫@個(gè)流量也是非常寶貴的。

第二，對客戶端，我們會(huì)監(jiān)控客戶端的日志落盤狀態(tài)?？蛻舳擞袉栴}日志沒有正常落盤，落盤之后是不是有丟失。agent 發(fā)送的日志的狀態(tài)，是不是有異常，是不是有堆積，channel  size 就能夠幫你監(jiān)控。

第三，組件的監(jiān)控。我們會(huì)對 Kafka  topic 做一個(gè)監(jiān)控，持續(xù)觀察 topic 的入口流量。很重要的一點(diǎn)，對 lag 要進(jìn)行監(jiān)控，它能讓你很快的知道下游的消費(fèi)是不是存在一些延遲。因?yàn)槲覀兒芏嗟膯栴}都是通過監(jiān)控 lag 能夠快速的發(fā)現(xiàn)的，所以對 lag 的監(jiān)控和告警是非常關(guān)鍵的。還有 Flume 的指標(biāo)、Channel  Size，以及對 HBase 也會(huì)做很多的監(jiān)控。

系統(tǒng)界面展示

講了這么多技術(shù)的東西，讓大家輕松一下，看幾個(gè)我們的畫面。

這是我們的入口，我們會(huì)提供若干這樣的功能，從業(yè)務(wù)監(jiān)控、大盤、策略配置、調(diào)用鏈查詢、主機(jī)系統(tǒng)查詢，組件版本查詢等等。進(jìn)入這個(gè)區(qū)域之后我們會(huì)展現(xiàn)更多的信息，曲線、服務(wù)信息、日常失敗、系統(tǒng)信息等等，都會(huì)在這個(gè)平臺(tái)上面。

這個(gè)是我截的一個(gè)調(diào)用鏈，相對來說還比較簡單，它只跨三四個(gè)域。響應(yīng)的時(shí)間，察看細(xì)節(jié)，你可以看到調(diào)用鏈的細(xì)節(jié)信息。

這是一個(gè)告警策略的指定，大家可以看到我們會(huì)先去設(shè)計(jì)告警策略，然后在這些告警分配出去，告警很簡單，比如說連續(xù)五分鐘環(huán)比請求失敗率大于昨天的三倍。告警策略我可以組合，做一個(gè)規(guī)則組，當(dāng)規(guī)則組同時(shí)滿足的時(shí)候我才告警。

這個(gè)是對業(yè)務(wù)域治理的功能，我們會(huì)每天去看哪些業(yè)務(wù)域什么時(shí)候接入的，負(fù)責(zé)人是誰，我的告警策略有沒有分配，我的告警機(jī)有沒有分配。如果出了問題，我會(huì)立刻排查標(biāo)簽，是異常、正常，還是警告。所以我們的運(yùn)營人員一看都知道說，你這個(gè)運(yùn)營可能是異常的接入，他可以直接去找那個(gè)負(fù)責(zé)人做后續(xù)的跟進(jìn)。

展望未來，智能化告警，開放平臺(tái)，打造我們唯品會(huì)后端的 SaaS 品牌。所謂 SaaS 就是說從客戶端你可以把你的數(shù)據(jù)推上來，推之后我們在這個(gè)平臺(tái)上面幫你做指標(biāo)的展現(xiàn)。這個(gè)指標(biāo)展現(xiàn)，可能涉及到你可以自定義很多的報(bào)表，同時(shí)我們可以幫你對所有指標(biāo)都做告警，你不用關(guān)心后面的時(shí)間是什么樣的，你只要把數(shù)據(jù)送上來就可以了。包括容器化的監(jiān)管，離線分析平臺(tái)，最后是對整個(gè)系統(tǒng)監(jiān)控?cái)?shù)據(jù)做結(jié)合。這些就是我們未來要做的一些事情。

Q&A

提問：你們應(yīng)該對有對 client 進(jìn)行改造的吧？

姚捷：對，我們有自己的插件。

提問：需要到生產(chǎn)的機(jī)器上去安裝這個(gè)東西？

姚捷：那肯定的，但是這個(gè)對業(yè)務(wù)系統(tǒng)不關(guān)心，它不是業(yè)務(wù)的部分，完全是部署在生產(chǎn)機(jī)上的 lib 而已，完全是運(yùn)維去推動(dòng)就可以。

提問：序列化直接在 client 做的？有沒有遇到機(jī)器的 CPU 過高？

姚捷：沒有遇到。我們對整個(gè)客戶端做過蠻多的壓力測試，單機(jī)的峰值量是蠻高的，我們一個(gè)域可能入口流量是五六千，但是五六千的 QPS 后面還會(huì)訪問很多的下游域，日志你可以認(rèn)為單機(jī)有五六萬的 QPS。在現(xiàn)場我們做過一些壓測，CPU 過關(guān)，但是出現(xiàn)過 gc 頻繁的情況，因?yàn)閷τ?gc 的參數(shù)，優(yōu)化也是蠻重要的，因?yàn)楫吘顾鼤?huì)跟你爭搶增援，所以對 gc 的優(yōu)化也是非常重要的，避免它去爭搶資源。

提問：剛才說在客戶端高性能的時(shí)候測試了一個(gè)并發(fā)隊(duì)列，一個(gè)是無鎖的，一個(gè)是有鎖的，那我想知道如果用一個(gè)無鎖隊(duì)列的話，因?yàn)樗跊]有的時(shí)候，獲取的是 null，那您如何做到觸發(fā)式？

姚捷：無鎖隊(duì)列它的優(yōu)點(diǎn)在于，它是類似于有兩個(gè)門，我的日志進(jìn)入我的前門和后門的時(shí)候，有一個(gè)比較好的技術(shù)，能夠保證一個(gè)環(huán)形。但是這個(gè)隊(duì)列要足夠的長足夠大，當(dāng)我日志量打滿我整個(gè)環(huán)形的時(shí)候，還是會(huì)包不住。所以基于這個(gè)特性，因?yàn)槲覀冋麄€(gè)客戶端要做到容錯(cuò)，當(dāng)落盤出問題的時(shí)候，client 要保證不影響業(yè)務(wù)。所以基于這個(gè)前提，我們沒有用無鎖，因?yàn)槟阌脽o鎖之后，首先這個(gè)隊(duì)列要求比較大，這個(gè)環(huán)形如果比較大的話，性能比較好。如果無鎖比較小，所有的線程打滿這個(gè)環(huán)之后，落盤出了問題，這個(gè)業(yè)務(wù)上是不能接受的，寧可丟棄日志，也不能 fail，這個(gè)是我們在業(yè)務(wù)端的策略。

相關(guān)閱讀

同程旅游緩存系統(tǒng)設(shè)計(jì):如何打造Redis時(shí)代的完美體系

10個(gè)互聯(lián)網(wǎng)團(tuán)隊(duì)?wèi)?yīng)對高壓的容量評估與高可用體系:私董會(huì)1期

滴滴passport設(shè)計(jì)之道:賬號(hào)體系高可用的7條經(jīng)驗(yàn)

大促系統(tǒng)全流量壓測及穩(wěn)定性保證——京東交易架構(gòu)分享

設(shè)計(jì)消息中間件時(shí)我關(guān)心什么?(解密電商數(shù)據(jù)一致性與完整性實(shí)現(xiàn))

本文及本次沙龍相關(guān) PPT 鏈接如下

http://pan.baidu.com/s/1nvnOEBf

想更多了解高可用架構(gòu)沙龍內(nèi)容，請關(guān)注高可用架構(gòu)微博以閱讀后續(xù)文章。。轉(zhuǎn)載請注明來自@高可用架構(gòu)