大師兄說

眾所周知，對于現(xiàn)在國內(nèi)的互聯(lián)網(wǎng)環(huán)境，不管什么樣的系統(tǒng)，一旦等用戶的訪問量上去之后，我們每增加一個功能實(shí)際上都是要考慮它的吞吐量和延遲，在加工上都是要做一個縝密的思考的。所以我相信在這方面許多人都有自己一些獨(dú)到的見解，有許多人也會對這方面比較感興趣的。所以我們這次就組織了一個關(guān)于性能優(yōu)化的話題。

全網(wǎng)首發(fā)·技術(shù)干貨·大咖對話

整理：魔窗丨 15618字丨20分鐘閱讀

來源：本文整理自跨境茶話會線上分享，為魔窗（magic-window）原創(chuàng)首發(fā)，轉(zhuǎn)載需獲得授權(quán)，可聯(lián)系微信：tina_1903

【主持丨大師兄】：大家好，我是本次跨境茶話會主持人張申竣，朋友們也可以叫我大師兄，目前擔(dān)任魔窗CTO。我先介紹一下本期嘉賓。首先介紹一下我們的耿茂。

【嘉賓丨耿茂】：大家好，我叫耿茂，我現(xiàn)在在Pinterest做SRE工程師，之前是做過多年的性能工程師。

【主持丨大師兄】：我們介紹第二位嘉賓王羽嘉，來自Splunk，和大家打個招呼吧。

【嘉賓丨王羽嘉】：好的，大家好，我叫王羽嘉。之前在EMC和現(xiàn)在在Splunk都是做性能工程師，當(dāng)然我目前主要是負(fù)責(zé)性能測試的自動化、性能測試的快速迭代的項(xiàng)目。

【主持丨大師兄】：第三位嘉賓是任志超，他目前在小紅書是整個測試團(tuán)隊(duì)的負(fù)責(zé)人。

?【嘉賓丨任志超】：大家好，我是任志超，現(xiàn)在在小紅書，目前負(fù)責(zé)整個測試團(tuán)隊(duì)，前面也在做一些我們小紅書性能保障和全鏈路壓測的一些事情，所以很高興有機(jī)會跟大家做一些分享和交流。

【主持丨大師兄】：我們接下來第一個環(huán)節(jié)是想請三位嘉賓分別談一下他們在自己公司所做的一些關(guān)于性能優(yōu)化和性能測試方面的一些最佳的實(shí)踐，志超你先來談一下吧。

【嘉賓丨任志超】：可以，從我個人的一些歷史經(jīng)驗(yàn)來看，我覺得在互聯(lián)網(wǎng)企業(yè)里面，因?yàn)槲仪懊嬖谀⒐浇执蟾殴ぷ鲀赡?#xff0c;然后又來到小紅書，現(xiàn)在大概有半年多的工作經(jīng)驗(yàn)，大部分的時間可能會跟不同的業(yè)務(wù)場景和業(yè)務(wù)產(chǎn)品下面的性能壓力打交道。

我個人認(rèn)為在不同的業(yè)務(wù)模式和互聯(lián)網(wǎng)的場景下來，性能保障和優(yōu)化是一個需要考慮不同場景下的一個綜合考慮的命題。事實(shí)上同一套方法論或者同一套優(yōu)化理論在不同的業(yè)務(wù)模式下可能是完全不適應(yīng)的。在小紅書這塊，因?yàn)閷?shí)際上它是分為兩塊，一塊是電商，另外一塊是社區(qū)。在這兩塊不同的產(chǎn)品下面它的性能的優(yōu)化和穩(wěn)定、調(diào)優(yōu)都是不同的方向。從我這邊的感觸來說，對電商來說更多的是，第一它會有一個峰值，從電商的峰值來說，對于大促通常是十倍以上的平時的壓力。在這個地方我們更多的考慮是說在峰值情況下的配比，以及基于它的不同的架構(gòu)模式下我們怎么找到壓力的平衡點(diǎn)，基于壓力的平衡點(diǎn)，我們預(yù)先對這一段壓力在大促前進(jìn)行擴(kuò)容，來保證它的平穩(wěn)通過。也就是說對于像小紅書這樣的企業(yè)來說，我們更多是簡單粗暴，如果能夠解決當(dāng)前的問題就先解決當(dāng)前的問題，然后再從架構(gòu)層面我們怎么去拆微服務(wù)，怎么去做隔離，怎么去把數(shù)據(jù)遷移出來，把核心的鏈路保持穩(wěn)定，以及做好整體的監(jiān)控。

但事實(shí)上在整個優(yōu)化過程中說實(shí)話離不開各個技術(shù)崗位的配合，其中就包括我們的產(chǎn)品，甚至包括我們的運(yùn)營，包括我們的研發(fā)團(tuán)隊(duì)，包括我們自己的測試團(tuán)隊(duì)，包括我們運(yùn)維的體系和實(shí)時響應(yīng)的效率。我分享幾個場景，第一是在整個電商業(yè)務(wù)的66大促保障過程中我們是提倡一直到66前的一天我們還在做業(yè)務(wù)的開發(fā)。在這種情況下整個66大促的性能的保障，我們更多是結(jié)合業(yè)務(wù)的開發(fā)同步進(jìn)行一些業(yè)務(wù)場景的梳理和配比的調(diào)優(yōu)。在這種情況下我們同時做線上的性能壓測，以及基于線上性能壓測快速地做擴(kuò)容和迭代。如果找到一些敏感瓶頸點(diǎn)，那我們會及時對這個瓶頸進(jìn)行處理。同時在每一個所謂的我們可能發(fā)生問題的瓶頸點(diǎn)，我們會加大監(jiān)控和線上數(shù)據(jù)采集的力度。在這種時候，我們實(shí)施上第一，責(zé)任到人，每個節(jié)點(diǎn)我們會有對應(yīng)的責(zé)任人。第二，做好應(yīng)急預(yù)案，對于每一塊的業(yè)務(wù)，擔(dān)心它出現(xiàn)問題的時候，我們用什么樣的應(yīng)急預(yù)案。第三，我們做好前期的數(shù)據(jù)的隔離，事實(shí)上我們在大促前做了幾個業(yè)務(wù)系統(tǒng)的數(shù)據(jù)遷移。基于這些數(shù)據(jù)遷移我們可以保障我們的核心內(nèi)幕盡量不要有其他的業(yè)務(wù)數(shù)據(jù)會打到我們的核心數(shù)據(jù)上面來，保證我們核心數(shù)據(jù)的統(tǒng)一。

在整個的過程中我們事實(shí)上還會碰到各種各樣的一些問題的，所以在小紅書這一類的企業(yè)更多是整個性能壓測和性能條有是持續(xù)改進(jìn)和持續(xù)變化的工作。相對來說假設(shè)我們是在一個大公司，比如阿里、京東這一類的企業(yè)，他們第一是更有計(jì)劃性。第二，可能會相對來說有更多的時間來投入在整個的性能保障和壓力上面。比如說他們在雙十一的全鏈路保障上面，他們可能從7月份開始就已經(jīng)開始做今年的雙十一的整個的性能的準(zhǔn)備和壓測了。事實(shí)上，比如說小紅書，我們?nèi)绻谧鼋衲晗掳肽昙t五的大促保障的時候，我們可能要到9月份，甚至10月份才開始。而這個過程中整個大促的開發(fā)，還有整個大促的業(yè)務(wù)的演進(jìn)可能都還在進(jìn)行中。

所以從這一點(diǎn)來說，不同的互聯(lián)網(wǎng)的工作模式和業(yè)態(tài)，以及公司的當(dāng)前所處的階段會決定你對于整個性能和線上業(yè)務(wù)穩(wěn)定性保障的不同的策略。這是我從小紅書和以前蘑菇街的經(jīng)驗(yàn)來看到的我的一些感悟。

【主持丨大師兄】：好的，非常感謝。接下來羽嘉你講一下在Splunk的目前關(guān)于性能方面的做法。

【嘉賓丨王羽嘉】：ok。剛才志超這邊講了很多在互聯(lián)網(wǎng)行業(yè)這邊確實(shí)是比較傳統(tǒng)的做法。但是在Splunk這可能是一個非常特別的案子，因?yàn)镾plunk本身它的業(yè)務(wù)場景就很特別，首先它的定位就是一個企業(yè)級的軟件，可能跟互聯(lián)網(wǎng)的行業(yè)差距比較大。簡單先說一下Splunk的場景是什么，他本身主要像我們大家都知道的ElasticSearch一樣，他們都是對非結(jié)構(gòu)化的數(shù)據(jù)做索引和搜索的。所以這種行為更多是面向比如說IT的管理人員或者說是devops，他們可能會更多地使用Splunk這樣的產(chǎn)品。

它的場景其實(shí)主要可以分為兩類，一個就是做索引，一個就是做搜索。所以我可以簡單說一下針對索引和搜索這兩塊我們是怎么考慮它的性能的。首先說做索引吧，其實(shí)它的索引行為其實(shí)也是很簡單，比如說我們會指定某一類的數(shù)據(jù)源，對這個數(shù)據(jù)源我們會把它的數(shù)據(jù)首先要抓出來，然后扔到Splunk里面去做index。這個行為我們可以理解為它是由多個管道串聯(lián)起來的，第一個管道就是我首先要在數(shù)據(jù)源的性能以及Scalability可以保證的前提下，這樣我可以使用多線程并排的方式去從一個單一的數(shù)據(jù)源里面把數(shù)據(jù)都抓出來。

我舉個例子，比如說我們可能會對AWS?S3這些所有的key做抓取，那我可以用多線程的方式把它都抓出來。通常是多個管道（pipeline），其實(shí)我們這邊的做法也比較傳統(tǒng)，多個管道連接的話我們都會用到Queue，我把數(shù)據(jù)抓出來之后我會把它扔到一個Queue里面，然后由下一個管道的具體的線程去處理我的Queue里數(shù)據(jù)，從而傳輸?shù)轿业南乱粚庸艿览锩妗＿@樣的話，如果考慮是不是在我的多個管道連接的過程當(dāng)中，會不會有一些瓶頸的存在，我們會monitor每個Queue的size和length，就是看每個Queue當(dāng)前的一個累積的數(shù)據(jù)數(shù)量是多少，那么我從而可以定位到具體是哪個管道的行為比較慢，這個我們可以再繼續(xù)做優(yōu)化。

另外一個點(diǎn)，因?yàn)槲覀兩婕暗蕉嗑€程從一個pipeline里面去扔到另外一個pipeline里面，所以必然會考慮到寫checkpoints，因?yàn)橹挥袑慶heckpoints的話才能避免我在一個多線程去抓數(shù)據(jù)的時候能夠保證數(shù)據(jù)沒有重復(fù)，并且沒有丟失數(shù)據(jù)。一般來說checkpoints的讀寫其實(shí)有很多種方式可以做。當(dāng)然比如說讀寫內(nèi)存或者是文件，或者是數(shù)據(jù)庫，那這樣的話我們要去考慮我們想達(dá)到的throughput是多少，當(dāng)然可能性能最優(yōu)的就是對數(shù)據(jù)庫的讀寫，同時也要考慮我單獨(dú)去衡量我這個數(shù)據(jù)庫讀寫的性能能夠達(dá)到多少，從而可以保證我一個點(diǎn)對點(diǎn)的總體的吞吐量是多少。這個就是我們抓數(shù)據(jù)，并且對數(shù)據(jù)做索引，整個的flow是這個樣子的。

如果是另外一種場景，就是做搜索，做搜索的話其實(shí)是完全又不一樣的。Splunk我們這邊用的搜索語言叫SPL，是我們自己的做搜索的一種比較特別的Language，大家可以理解為就像我們在查詢數(shù)據(jù)庫用SQL一樣。這個語言其實(shí)本身一樣可以像SQL一樣寫得非常復(fù)雜，包括有嵌套，包括也是類似于用一個管道去連接的。所以可能超過百分之六七十以上的情況你去優(yōu)化搜索行為的話，更多你要優(yōu)化你的SPL，在這個語言上的優(yōu)化可能是占的比重比較大的。而且我們的搜索雖然是給用戶直接使用，但是它的主要的面向?qū)ο罂赡芎芏嗟那闆r下是IT或Devops，所以它對于搜索的高并發(fā)要求并不是非常高。所以我們通常來說可能十幾個用戶是一個非常高的并發(fā)量了。

對于搜索我們其實(shí)也有一些優(yōu)化的考慮，這個可能跟Splunk自己的一些技術(shù)相關(guān)系。比如我舉一個例子，Splunk做索引和搜索跟ElasticSearch最大的差別是，像ElasticSearch更多是說我在數(shù)據(jù)進(jìn)來的時候我會把對應(yīng)的那些字段抽取出來，并且做index。但是Splunk恰恰相反，它對很多的字段其實(shí)并不是直接被寫到index里的，它還是都存在于你的raw data的，也就是說我其實(shí)在進(jìn)index的時候這個行為是非常快的，但是做搜索的時候其實(shí)在搜索的runtime里面會把你的字段再重新抽取出來作為你可以看到的字段。所以這個行為就會導(dǎo)致你的搜索其實(shí)是比較慢的。在這塊我們有很多的優(yōu)化方式。主要目的就是讓用戶可以更加動態(tài)，更加靈活地使用我進(jìn)來的這些數(shù)據(jù)。這可能是一個比較大的話題，比如Splunk支持把一部分的字段的數(shù)據(jù)或者一定時間范圍內(nèi)的數(shù)據(jù)寫進(jìn)index，這個是可以在數(shù)據(jù)進(jìn)來的后期去做的。其實(shí)在這塊是一種邏輯層面上的優(yōu)化，但是這種優(yōu)化對用戶直接的使用的體驗(yàn)效果會非常好。這只是一個例子，如果更多人有興趣的話我們其實(shí)可以再去討論更多的細(xì)節(jié)。

這邊主要是我這邊的一些經(jīng)驗(yàn)，關(guān)于Splunk的索引和搜索的場景。

【主持丨大師兄】：好，謝謝羽嘉。看來針對搜索因?yàn)槭且粋€比較大的話題，我們今后在下幾期也可以考慮單獨(dú)開一個關(guān)于搜索的話題。接下來我們請耿茂幫我們講一下Pinterest的常規(guī)的一些做法。

【嘉賓丨耿茂】：那我簡單介紹一下Pinterest的一些經(jīng)驗(yàn)。我在加入Pinterest之前其實(shí)我是在Oracle、EMC、SuccessFactors這些公司，更多的是企業(yè)級軟件和服務(wù)的公司里面做性能工程師。所以這些企業(yè)軟件基本上就是三層架構(gòu)，從Web服務(wù)器到應(yīng)用服務(wù)器到數(shù)據(jù)庫，當(dāng)然也會有一些可擴(kuò)展性的設(shè)計(jì)。比如說應(yīng)用服務(wù)器無狀態(tài)，然后可以動態(tài)擴(kuò)容，數(shù)據(jù)庫可以分庫，可以Sharding。基本上的性能工作模式是比較容易找到每一個層次不同的壓力測試點(diǎn)，會針對不同的特性我們可以去做不同的測試。外部服務(wù)器可能經(jīng)常會出現(xiàn)的是網(wǎng)絡(luò)連接的壓力，或者是網(wǎng)絡(luò)響應(yīng)時間的壓力。

應(yīng)用服務(wù)器可能很多時候是java的，會有jvm的性能優(yōu)化還有垃圾收集的調(diào)優(yōu)。還有應(yīng)用本身對于請求的處理狀態(tài)，是線程模型呢，還是一個異步的網(wǎng)絡(luò)I/O模型，這都會有不同。

像數(shù)據(jù)庫的話可能更多的關(guān)注于數(shù)據(jù)的存儲路徑，比如說數(shù)據(jù)它的存儲路徑要合理地優(yōu)化，設(shè)計(jì)的表結(jié)構(gòu)足夠合理，總是能夠和快速地存取。這些經(jīng)驗(yàn)可能是針對傳統(tǒng)的企業(yè)軟件基本上可以套用這一套規(guī)律。

但是我進(jìn)入Pinterest之后就相當(dāng)于是跨了一個行業(yè)，進(jìn)入到面向用戶的服務(wù)上。Pinterest現(xiàn)在主要是手機(jī)用戶占了八成以上，另外還有兩成是來自于網(wǎng)頁。但背后都是使用我們的服務(wù)，幾乎全在AWS之上。從架構(gòu)上是有很大的不同，是說內(nèi)部會有很多的微服務(wù)，和傳統(tǒng)的企業(yè)軟件不一樣了。這些微服務(wù)我們在Pinterest里面可能有上百個。當(dāng)然核心的幾個服務(wù)，面向用戶的幾個服務(wù)大家會比較熟悉，我們SRE會接觸的多一些，但是有好些服務(wù)我們也只知道個名字，并不清楚它內(nèi)部是如何實(shí)現(xiàn)的。

所以作為一個運(yùn)維工程師對于關(guān)心性能來說的時候，我們主要是要知道每一個服務(wù)的性能指標(biāo)，比如說這個服務(wù)它能夠接受多少個并發(fā)請求，它的50%的響應(yīng)時間應(yīng)該是多少，90%的響應(yīng)時間應(yīng)該是多少。所以，這里面有一個很重要的實(shí)踐，針對所有的這些微服務(wù)，就是說每一個服務(wù)必須要定義一個SLA，叫做服務(wù)水平協(xié)議。比如說這個服務(wù)要達(dá)到比如說99.9%的可用性，它的90%的響應(yīng)時間應(yīng)該要在50毫秒以內(nèi)，它能夠響應(yīng)的請求數(shù)每秒比如說是10萬或者百萬，這些就是這個服務(wù)要達(dá)到的目標(biāo)。在一個新的服務(wù)被設(shè)計(jì)的時候首先要考慮這個目標(biāo)，它的設(shè)計(jì)架構(gòu)要能夠支持到這個目標(biāo)。所以在每個服務(wù)我們也有一個相應(yīng)的Service Owner來負(fù)責(zé)這樣一個服務(wù)的SLA。這是針對微服務(wù)上我感覺的一個重要的不同。

另外還有一個，因?yàn)橛泻芏嗟姆?wù)，這些服務(wù)之間的依賴是很復(fù)雜的關(guān)系。有時候基本上就算是參與其中的工程師或者是架構(gòu)師都不能夠完全掌握清楚。所以這里面有很重要的是一個工具，怎么樣把這個服務(wù)之間的依賴暴露出來。在Pinterest內(nèi)部是有一個工具基于開源的軟件叫Zipkin，來建立的。它的工作機(jī)制主要就是說在每個服務(wù)的客戶端和服務(wù)端一起都會埋入一些代碼，然后產(chǎn)生一個日志。這個日志會帶有一個唯一的請求ID，或者叫做Span?ID，這一個Span ID就是從用戶的一個請求開始，一直記錄他這個請求所流過的每一個服務(wù)，這每一個服務(wù)都會有這樣的相同的ID。所以在很多不同的服務(wù)都產(chǎn)生日志之后，我們的日志抓取平臺把這些搜集起來之后然后會有一些聚合處理，最后把處理的結(jié)果放到一個ElasticSearch的集群里面。最后我們可以通過一個叫做Pintrace，基于zipkin的一個網(wǎng)頁UI然后來檢查這樣一個請求所經(jīng)過的所有服務(wù)。然后通過匯聚很多的請求，我們可以得到一個服務(wù)之間的依賴圖。然后這個依賴圖里面我們可以知道這個服務(wù)與服務(wù)之間的請求流量大小。所以這對于我們知道這個系統(tǒng)的整個狀況是很有用的一個工具。每一個服務(wù)在實(shí)現(xiàn)的時候都要遵循一定的規(guī)范，都要接入這樣一個支持zipkin的日志的埋點(diǎn)。這是微服務(wù)的另外一方面。

除了Zipkin用作服務(wù)的請求響應(yīng)時間的收集之外，還有一個很重要的東西，就是收集每一個服務(wù)它的性能指標(biāo)。這里面性能指標(biāo)可能是有基本的服務(wù)里面的每一個虛擬機(jī)的CPU使用率、內(nèi)存使用率，它的網(wǎng)絡(luò)的IO，塊讀寫的IO，所有這些東西都會產(chǎn)生一些metrics，然后被集中到一個中心的監(jiān)視系統(tǒng)。這樣一個性能監(jiān)視系統(tǒng)會搜集上百萬個，甚至上千萬個不同的metrics。然后在我們的每一個服務(wù)基本上都會定義一個dashboard,?然后可以實(shí)時地呈現(xiàn)這樣一個服務(wù)的性能狀況。

所以如果有問題的時候馬上就會有page，報(bào)警到相應(yīng)的服務(wù)的負(fù)責(zé)人。當(dāng)然整個網(wǎng)站來講的話，如果整個Site有問題，或者一些重要的路徑有問題，就會先報(bào)警到SRE的平臺，然后我們經(jīng)過分析之后定位哪一個服務(wù)有問題，然后相應(yīng)的肯定會有這個服務(wù)的負(fù)責(zé)人會被page到，然后這個服務(wù)的負(fù)責(zé)人會來解決這個問題。基本上這是我們運(yùn)維的一個實(shí)踐。

在平常還有關(guān)于性能的另外一個很重要的實(shí)踐就是從公司上下對性能的指標(biāo)都很在意。這是公司CEO制定的很重要的一個目標(biāo)。他定義一個叫做性能目標(biāo)的協(xié)議，然后發(fā)給所有的工程師。所以性能工作不是只是性能工程師或者SRE工程師的工作，而是所有人的目標(biāo)。大家首先上線新的功能或者新的服務(wù)首先都要保證這樣一個性能目標(biāo)不會下降，比如用戶的響應(yīng)時間不會下降，用戶體驗(yàn)不會下降。

相應(yīng)的性能的調(diào)優(yōu)工作有很多資深的工程師都一直在投入其中，他們會去仔細(xì)地檢查，比如說我們使用的網(wǎng)絡(luò)庫，比如說我們用到一個庫叫Finagle，它又用到Netty，在用到這些服務(wù)的響應(yīng)時間在十個毫秒以內(nèi)或者是更小，這樣子他們對網(wǎng)絡(luò)的連接的打開、關(guān)閉都非常敏感。所以有工程師會專門的去研究，然后去找到可以調(diào)優(yōu)的地方，然后通過調(diào)整這樣一些庫，因?yàn)檫@些庫是所有服務(wù)都用到的，所以在這樣一個庫的性能優(yōu)化可以達(dá)到非常顯著的性能調(diào)優(yōu)效果。

?所以基本上這是我的一些體會。

【主持丨大師兄】：謝謝耿茂，耿茂剛剛已經(jīng)講得非常詳細(xì)了。因?yàn)樵诮酉氯サ沫h(huán)節(jié)我們是準(zhǔn)備了一些特定的關(guān)于性能的主題想和嘉賓一起采用互動的方式一起交流一下。其中有一塊就是關(guān)于在分布式環(huán)境下的一個線上的性能檢測，我想耿茂已經(jīng)很好地回答了這個問題。

剛剛許多嘉賓也談到了一個全鏈路的性能檢測和性能測試的問題，因?yàn)槲覀冎佬阅苤笜?biāo)更多的應(yīng)該是反映一種業(yè)務(wù)指標(biāo)，從一個用戶的請求到拿到響應(yīng)結(jié)果，它在什么情況下它能夠支持多少個并發(fā)，在這些并發(fā)下要求的一個延時有多少，它其實(shí)是整個的一個端到端全鏈路的過程。

首先第一個問題，我想跟大家探討一下，在條件允許的情況下，如果說我們要做性能測試，那我如何去模擬生產(chǎn)環(huán)境的測試。因?yàn)榇蠹叶贾?#xff0c;性能測試最關(guān)鍵的一點(diǎn)就是盡量要去模擬真實(shí)的一個線上的環(huán)境，包括數(shù)據(jù)和并發(fā)量，那你得到的整個的測試結(jié)果對你來說才是有參考價值的。我的第一個問題是大家覺得在模擬真正的一個線上環(huán)境上面，大家覺得有什么好的做法？還有一種觀點(diǎn)就是可能根本我就沒有辦法真實(shí)地去模擬線上的情況，那我就是在線上直接去測了，有問題再直接調(diào)整。

關(guān)于這個問題我想聽一下大家的看法，三位嘉賓有先想關(guān)于這個問題發(fā)表一下自己的意見嗎？

【嘉賓丨王羽嘉】：好的。我們先說一下線上吧，因?yàn)镾plunk這個產(chǎn)品其實(shí)它的特點(diǎn)就是我今天說的它很特別，它可以把非結(jié)構(gòu)化的數(shù)據(jù)做索引和搜索。其實(shí)，用戶在使用的時候，用戶使用的任何的日志的信息其實(shí)默認(rèn)都是可以走進(jìn)到Splunk index里面去的，所以說對于線上的用戶，比如說我們可以到他們的生產(chǎn)環(huán)境里面去，然后通過我們的Search，基本上是可以看到用戶的行為的，比如他最近遇到了一個非常慢的search，那么我們可以看到他的search發(fā)生時間的時候，系統(tǒng)中具體的一些情況。比如說CPU的使用情況，以及系統(tǒng)中是不是有一些在后臺job在工作，這些東西我們都可以看得很清楚。從這個角度來看，我們比較容易地幫他去定位一個問題。

【主持丨大師兄】：所以Splunk的做法是事先也沒有辦法真實(shí)地模擬在線上的環(huán)境，我就直接做一個基本的調(diào)優(yōu)，然后讓用戶去線上跑，如果有問題的話我再真實(shí)地去查看線上的這樣一個上下文環(huán)境，去定位問題，再告訴用戶怎么去做一些優(yōu)化。

【嘉賓丨王羽嘉】：對，這是一個非常challenge的行為。但是我們更多的總歸還是要做性能的測試，性能測試的時候我們可能會想不管用戶有沒有問題，我們需要去了解到用戶他們的使用的數(shù)據(jù)是什么樣子的，這個情況其實(shí)我們的做法是當(dāng)然我們肯定是通過我們的PM去跟用戶那邊看他們的數(shù)據(jù)量大概是多少，我們基本上是會了解一些指標(biāo)，這些指標(biāo)不包括他們比如說每天有多少的數(shù)據(jù)進(jìn)來，然后每天他們進(jìn)來的數(shù)據(jù)的數(shù)據(jù)的格式是什么樣子的。因?yàn)檫M(jìn)來的數(shù)據(jù)的格式可能是千奇百怪，可能我們要清楚。而且比如說有一些用戶，像這個用戶本身就是一個CDN的廠商，他肯定會進(jìn)來很多的網(wǎng)絡(luò)的數(shù)據(jù)，網(wǎng)絡(luò)數(shù)據(jù)里面一旦被index的話會有一些比如說IP，source IP或者destination IP，這些都會進(jìn)來。都會進(jìn)來的話，它的數(shù)據(jù)值的變化量，比如它的IP的range大概有多少，其實(shí)對我們最終做search都會有很大的影響。所以像這些指標(biāo)我們都要搞清楚，就是它數(shù)據(jù)的總量，以及數(shù)據(jù)在這個總量下面每一個字段的變化是有多少，是一千種、一萬種還是十萬種。然后我們根本他們給我們提供的指標(biāo)，比如說我們會有一個內(nèi)部的工具專門來生成這些數(shù)據(jù)的。我們把這些數(shù)據(jù)生成出來，生成在我們的測試環(huán)境里面去，然后我們來跑我們的測試，然后來評估我們的測試有沒有達(dá)到我們最終的標(biāo)準(zhǔn)（criteria）。

【主持丨大師兄】：也就是說實(shí)際上整個的數(shù)據(jù)的分布情況是你們先會和客戶做一個充分的溝通，然后利用一些溝通的結(jié)果，根據(jù)客戶提的意見然后去模擬這部分?jǐn)?shù)據(jù)，然后去做一個測試？

???

【嘉賓丨王羽嘉】：對的。

【主持丨大師兄】：那志超和耿茂關(guān)于這個有什么意見嗎？因?yàn)榭赡躍plunk是一個企業(yè)的產(chǎn)品，大家針對于互聯(lián)網(wǎng)的產(chǎn)品的情況下覺得有沒有可能也可以這樣去做呢？

【嘉賓丨任志超】：實(shí)際上在我所經(jīng)歷的兩家互聯(lián)網(wǎng)的電商企業(yè)，蘑菇街和小紅書來看，基本上你要在線下環(huán)境，就是在我們的測試環(huán)境里面去做線上的性能測試和調(diào)優(yōu)是一個偽命題。我為什么這樣說呢？事實(shí)上我在兩家公司都經(jīng)歷了這種從沒有做微服務(wù)，到微服務(wù)改造的過程。整個系統(tǒng)架構(gòu)是處于一個在原來蘑菇街是一個統(tǒng)一，就是一個PHP的大的一個單服務(wù)的情況下，最后改成基于java的阿里的這一套整個的微服務(wù)體系。小紅書是目前來說正在從python轉(zhuǎn)向基于java的這種微服務(wù)。整個這樣的一個分布式系統(tǒng)它的鏈路的調(diào)用規(guī)則和水位分布其實(shí)是在動態(tài)變化和調(diào)整過程中的。如果說我們強(qiáng)調(diào)全鏈路的性能測試或者說線上性能壓力的能力，從某種意義上來說，你在線下很難搭建一個完整的分布式的這樣一個模型來實(shí)時地模擬現(xiàn)在當(dāng)前的系統(tǒng)架構(gòu)的演進(jìn)。

第二，就算有這樣一個線下的測試環(huán)境。第一，它的一些相關(guān)依賴，比如我舉一個例子，比如說redis，比如說存儲，比如說MQ，這些第三方的依賴它的第一處理能力，它的SOI的水平和線上都是會有區(qū)別的。包括我們的數(shù)據(jù)的第二個大小，比如說我們到存儲這一級別，小紅書大部分還是用mongo，蘑菇街以前是mysql，那不同的存儲集群對數(shù)據(jù)的響應(yīng)和性能都是不一樣的。而在一個自己數(shù)據(jù)中心的一個環(huán)境和你比如說用AWS或者騰訊云下面的這種云服務(wù)這樣的一個封閉式的環(huán)境下面，它的性能場景也都是不一樣的。所以在我的實(shí)踐里面，我們通常來使用做性能的測試或者是做全鏈路的測試通常是基于以下三個方式。

第一，日志回放。我們通常做的是我們會在業(yè)務(wù)層面都會收集各種訪問日志和你的使用日志。在一定的時間，我們通常說是半夜12點(diǎn)或者12點(diǎn)半以后等整個線上的業(yè)務(wù)下來以后，我們會隔離一些機(jī)器然后做線上白天的日志回放。

第二，我們寫一部分的針對某一個單點(diǎn)寫一些單點(diǎn)鏈路腳本，在夜里我們針對這個單點(diǎn)的壓測腳本，同樣把線上的服務(wù)做隔離以后對它進(jìn)行壓測。

第三，我們做影子庫，做壓測打標(biāo)，我們會對所有的我們的壓測鏈路加上我們的測試標(biāo)這一層可以在線上進(jìn)行，或者在我們的底層的業(yè)務(wù)中間層做處理。做了壓測打標(biāo)以后事實(shí)上也是在夜里12點(diǎn)以后通常來說我們會統(tǒng)一的對整個線上進(jìn)行釋壓來去模擬真實(shí)的用戶場景。

為什么我們說相對來說我們還是可以模擬出來比較真實(shí)的用戶產(chǎn)品。第一，我們會先做幾個事情。一是對歷史的峰值的壓力審閱的一個梳理。也就是說我們會對歷史上比如上一次大促我們的模型是什么樣子的。我舉一個簡單的場景，比如說有一萬個用戶同時進(jìn)到我們的首頁，其中六千個用戶可能去訪問了某個會場頁，由會場頁進(jìn)到商詳頁里面可能大概并發(fā)量是在一千五，那這個時候下單的用戶可能就是在五百，下單以后到支付可能是三百到一百五之間。所以基于這樣的使用模型你可以基于我們的線上的這種當(dāng)前架構(gòu)下面的接口的調(diào)用鏈路，也就是剛才耿茂跟大家分享的，我們有一些工具可以把當(dāng)前線上的這種鏈路調(diào)用關(guān)系以圖形和鏈路的形式反映出來。基于這樣一個鏈路調(diào)用關(guān)系我們可以援引出來壓測的行為，所以基于這樣的壓測行為我們可以去開發(fā)全鏈路的壓測腳本，而這個壓測腳本是基于我們現(xiàn)在已有的單鏈路腳本之上開發(fā)和更新的。在這樣的情況下我們可以約定在某一個時間，比如說開發(fā)、運(yùn)維和測試的同學(xué)大家都在半夜12點(diǎn)以后我們同時開始對線上的鏈路進(jìn)行集中的壓測，那這個壓測不是針對單點(diǎn)的，是針對全鏈路的。

在這樣的情況下，加上我們的測試打標(biāo)，可以把這些壓力真實(shí)地打到我們的線上的系統(tǒng)，但是同時又不會產(chǎn)生比如說我們擔(dān)心的，產(chǎn)生一些垃圾數(shù)據(jù)，是不是影響我們的業(yè)務(wù)數(shù)據(jù)，是不是影響我們線上的一些真實(shí)的體驗(yàn)。基于這樣的壓測打標(biāo)以后我們可以從業(yè)務(wù)系統(tǒng)里面，可以從我們的線上服務(wù)里面把這些數(shù)據(jù)從最終的用戶當(dāng)中去掉。但是事實(shí)上我可以對線上的系統(tǒng)進(jìn)行實(shí)時的真實(shí)的模擬。

這樣的三種模式下我們可以針對某一個點(diǎn)，某一臺機(jī)器，甚至某一個服務(wù)，和全鏈路進(jìn)行有效的線上的壓測。當(dāng)然這一切都離不開整個團(tuán)隊(duì)的配合，也就是第一，我們要有足夠好的監(jiān)控手段，就是剛才耿茂說的，我們的APM，內(nèi)部鏈路的關(guān)系，我們的Sentry，我們的業(yè)務(wù)的日志的收集，整個的運(yùn)維的平臺一定要具備。

第二，我們要具備全鏈路的施壓的能力，施壓能力提供通常來說如果用了其他的好的的情況下可以采用一些開源的現(xiàn)存工具，比如說用阿里的PTS，或者用自己寫的基于Gatling這樣一個用戶式的調(diào)用施壓鏈路。還有一些比如說像阿里內(nèi)部有一些自己內(nèi)部的一些壓測工具，實(shí)在都沒有了，可以直接用比如說AB、JMeter這樣子的一些工具對單點(diǎn)進(jìn)行。但是通過一些鏈路的調(diào)用等一些引擎，可以把這些施壓點(diǎn)串起來對整個系統(tǒng)構(gòu)成壓力行為的施壓，這樣才能夠?qū)φ麄€線上的系統(tǒng)是有價值的壓力測試的場景。

這是我們這邊實(shí)踐的一些經(jīng)驗(yàn)。

【主持丨大師兄】：非常感謝。那耿茂，你關(guān)于這點(diǎn)有什么向說的嗎？

【嘉賓丨任志超】：志超剛才說的很好，他們的壓測做得很不錯。相比較而言，Pinterest說實(shí)話我們就是在線上測，就沒有自己生成數(shù)據(jù)來做壓力測試這種東西。這里面有幾個原因，一個是我們用AWS，是一個彈性的云計(jì)算的環(huán)境，我們的這些微服務(wù)基本上都是動態(tài)伸縮的。所以它在請求量大的時候基本上是可以水平擴(kuò)展，可以去支持它的請求。所以如果我們測試的時候，那相應(yīng)的服務(wù)也會自動擴(kuò)容去支撐這樣一個流量。只要AWS沒有出現(xiàn)問題，沒有自動擴(kuò)容的能力受影響的話，一般不會有大的問題。當(dāng)然，有一些存儲的服務(wù)他們基于MySQL，或者基于HBase，是需要做預(yù)先的切分的，不能夠動態(tài)擴(kuò)容的。這種可能是先基于我們實(shí)際的流量測試之后他們會有一個相應(yīng)的準(zhǔn)備。比如說會先劃分成多少個數(shù)據(jù)庫，產(chǎn)生數(shù)據(jù)庫也可能在應(yīng)對流量增長的時候預(yù)先做容量升級，從一個低CPU或者內(nèi)存的服務(wù)器動態(tài)升級到高級的上面，在不影響服務(wù)的情況下。這是AWS這個環(huán)境給我們的一個能力，所以基本上每個服務(wù)都會考慮在線升級、在線擴(kuò)容的辦法。

我們還有一個，如果有功能的變化或者是一些性能改進(jìn)的話我們通常是做AB測試。同樣一個服務(wù)可能有不同的環(huán)境，有A環(huán)境和B環(huán)境，一部分機(jī)器是A環(huán)境，一部分是B環(huán)境，你收集相應(yīng)的性能指標(biāo)之后做一個比較，然后發(fā)現(xiàn)確實(shí)是有進(jìn)步，那我們把它全部切換到你的優(yōu)化上面。如果說性能不是你預(yù)想的那樣，那再回滾回來。所以一切都是通過動態(tài)的調(diào)整服務(wù)的集群來實(shí)現(xiàn)的。

另外，我們當(dāng)然也有測試，這就是每個服務(wù)自己的事情了。在通常做一些技術(shù)選型的時候會做足夠的測試，不管是MySQL也好，HBase也好，或者是其他用到的一些ElasticSearch、Redis這樣的一些通用的開源技術(shù)，那就是會用相應(yīng)的測試工具，如果有開源的拿開源的來用，如果沒有會自己寫一寫。然后來有針對性的針對這個服務(wù)的使用場景來測試這個基礎(chǔ)的技術(shù)的擴(kuò)展性。還有在AWS上我們會有一些測試，關(guān)于比如說EC2虛擬機(jī)類型的性能測試，我們會測試它的新一代的虛擬機(jī)比如說I3, r4, c5這些不同的虛擬機(jī)的性能表現(xiàn)，以此來決定我們是不是可以升級換代一些。或者說從CPU優(yōu)化的服務(wù)器換到存儲優(yōu)化的服務(wù)器，會做一些這樣的測試，有針對性的。還有是因?yàn)檫@些跟操作系統(tǒng)的版本和Kernel也有關(guān)系，所以有很多測試也會針對不同的Kernel來看。因?yàn)槟莻€影響其實(shí)還不小，但是所有這些測試一定是每個服務(wù)單獨(dú)來看，然后逐漸的AB測試，然后逐漸的擴(kuò)展到整個系統(tǒng)里去。所以，有些升級變化會花很長的時間。

【主持丨大師兄】：謝謝，我接下去有個問題，實(shí)際上剛剛你們在講的是關(guān)于動態(tài)擴(kuò)容的問題，那有沒有可能有一種情況，因?yàn)橛行﹩栴}可能是架構(gòu)上，或者是代碼上的一些問題，導(dǎo)致我可能前期沒有測出來，但真的等到線上環(huán)境以后，它不是靠擴(kuò)容就可以解決的，那我只根據(jù)java的話可能比如說會有Memory Leak，那等到你線上環(huán)境達(dá)到一定的量的時候出現(xiàn)了Memory Leak，那這種情況一般是擴(kuò)容解決不了，因?yàn)槟銛U(kuò)一下機(jī)器它馬上就被消耗光了，一般出現(xiàn)這種情況的話我們應(yīng)該怎么樣去做一些線上的應(yīng)對或者隔離？

【嘉賓丨耿茂】：在Pinterest的做法也是會有一個叫做rate limiter的東西，你可以限容。這個rate limiter其實(shí)就是在客戶的一些庫然后java語言或者python語言這種，這個庫就是各種客戶端的語言都支持的，所以在客戶端調(diào)用的時候會受到rate limiter的限制，如果在后端的服務(wù)支撐不了動態(tài)擴(kuò)容，不能夠支持流量增長的事實(shí)那就會限容這樣子。

【主持丨大師兄】：那如果發(fā)生這種情況的話，這個服務(wù)本身是有問題了，是打算把它隔離掉，還是接下去會怎么處理？

【嘉賓丨耿茂】：這個之后再處理，先扛住，不讓它徹底當(dāng)?shù)簟?/span>就是限制上游來的流量，讓這個等于就是降級，所以只使用這部分服務(wù)的人受到一些影響。或者說，超過了一定量的用戶受到影響，但是基本上這個服務(wù)還是暫時可用的，當(dāng)然這個服務(wù)的負(fù)責(zé)人一定會想辦法怎么樣把它盡快擴(kuò)容，然后能夠支撐，能夠解除這樣一個流量限制。

【嘉賓丨任志超】：這邊我們也可以分享一下在電商這塊我們的一些做法。通常來說作為電商來說最大的心理壓力就是平時一般都沒有什么流量，正常的用迭代、發(fā)布，然后線上一般都不會有太大的問題。最大的問題其實(shí)就是來自于這種像大促期間流量基本上是十倍以上的增長，這種情況下我們一般來說正規(guī)的做法是第一，我們會定預(yù)期水位，第二會定開關(guān)、降級預(yù)案，第三會對降級預(yù)案進(jìn)行分解。對于降級預(yù)案進(jìn)行分解會通過一些敏感服務(wù)，核心電路會產(chǎn)生什么樣子的降級做一個定義，可能會降級會有一些降級開關(guān)，它也會有一些觸發(fā)條件，以及在這個觸發(fā)條件下面相關(guān)的操作。那這些操作一些是通過動態(tài)熔斷，比如我曾經(jīng)做熔斷，另一些就是通過業(yè)務(wù)熔斷來做的。比如說我們把這個業(yè)務(wù)直接從前臺下掉了。第三個是我們可以在前臺統(tǒng)一做一些所謂的批量化，比如說把一些高并發(fā)的請求。

我們曾經(jīng)在蘑菇街做過這樣一個產(chǎn)品，就是在所有的客戶端的相應(yīng)過程中加上一層，當(dāng)他在大促時間，大促時我們把兩個開關(guān)開了以后，當(dāng)客戶端提交這個請求，發(fā)現(xiàn)我們我們的返回值是某個制定的開關(guān)結(jié)果的時候，它會把所有的對后端的請求做緩存，于是我在接下來15秒鐘之內(nèi)我不會對后臺發(fā)任何請求，對前臺會造成一個Loading的標(biāo)識，對于客戶來說感覺是慢了，但是事實(shí)上我們還是在有機(jī)會完成交易。另一方面，對于一些可降級的，比如說前端的一些頁面。

比如舉個例子，我們商詳頁，我們會對它若干個區(qū)域，比如一些核心區(qū)域，價格肯定是不能錯的，我們的下單功能肯定是不能少的，除此之外我們都是可以降級，在大促期間我們有一個降級預(yù)案，當(dāng)?shù)竭@個水平的時候我們會把商詳頁上的相關(guān)商品和相關(guān)筆記我們再下掉。在這個時候當(dāng)我們降級被觸發(fā)以后在客戶端看到的頁面會只有標(biāo)準(zhǔn)的商詳和里面的價格本身，以及一個下單的按鈕，其他的額外的東西一切都沒有了。這是正常的情況下的降級和熔斷。

但是就像你說的，總會有沒有測到的情況。比如我們出現(xiàn)過在大促前前一天剛上的一個業(yè)務(wù)，這個業(yè)務(wù)剛好是過了我們?nèi)溌穳簻y的場景以后上去的。而這個業(yè)務(wù)就有一個while true的循環(huán)就鎖住我們的數(shù)據(jù)庫，而當(dāng)時確實(shí)就上去了，這個時候又沒有降級預(yù)案。那我們的方法，第一，先定位到問題所在。發(fā)現(xiàn)當(dāng)有這個問題，我們整個數(shù)據(jù)庫鎖死，整個線上沒有反應(yīng)的時候，我們第一是回滾，因?yàn)榛谖覀兊木€上的性能監(jiān)控我們可以知道是哪個服務(wù)出了問題。首先對這個服務(wù)進(jìn)行暫時的線上的回滾，緊急回滾以后先定位到問題，定位到問題以后重新把開關(guān)設(shè)好，并且開開，在這種情況下幾個手段我們通常來說是并行開展的。就是降級、擴(kuò)容，以及線上的緊急回滾和修復(fù)，整個是一個執(zhí)行體系，和系統(tǒng)架構(gòu)，和我們的技術(shù)領(lǐng)域其實(shí)也沒有太大的關(guān)系，在任何其它領(lǐng)域都可以做類似的操作。

【主持丨大師兄】：謝謝。我這邊接下去的問題剛剛都有說了，就是整個系統(tǒng)的話不僅僅是Performance團(tuán)隊(duì)或者是測試團(tuán)隊(duì)的事，而是和開發(fā)，和運(yùn)維，和架構(gòu)都相關(guān)。

我的一個問題是說可能在你不考慮性能的情況下，那我上的功能肯定決定是很快的，開發(fā)的話我就按功能開發(fā)完就沒事了。但是如果涉及到我這邊性能方面是有些要求，有些架構(gòu)，就像各位剛剛介紹的一樣。首先要有一些微服務(wù)的監(jiān)測，我每上一個功能是要有可監(jiān)測的，我可能還會去準(zhǔn)備一些降級的預(yù)案做一些隔離，那我要考慮到這些架構(gòu)的方方面面的時候，那我怎么同時能夠保證我的開發(fā)上的敏捷度，或者怎么樣去和真正的業(yè)務(wù)上的開發(fā)比較好的做一個協(xié)同呢？

【嘉賓丨任志超】：從我們這邊的實(shí)踐來看說實(shí)話這是一個不斷教育的過程，可能因?yàn)槲掖墓径急容^特殊，都處在一個快速擴(kuò)張的時間，進(jìn)云的速度是相當(dāng)快。比如我們一個業(yè)務(wù)可能在半年的時間里面可能翻一翻，兩三翻 ，里面的性能對于一些老同學(xué)來說它對限容架構(gòu)和當(dāng)前的服務(wù)有些什么問題他是很清楚的，在這樣一種狀態(tài)下還是比較容易去做協(xié)同和擴(kuò)展的。

但是，當(dāng)然不斷的有新同學(xué)來，團(tuán)隊(duì)在不斷的擴(kuò)充，新業(yè)務(wù)在不斷的增加的過程中其實(shí)很難有一個合適的途徑對他進(jìn)行一個教育。更多的是，第一，樹立一個Ramp up Plan的時候，我們可能需要對他性能方面的專項(xiàng)的一個Enablement，就是讓他能夠知道我所負(fù)責(zé)的這塊業(yè)務(wù)當(dāng)前的一個性能模型是什么意義，架構(gòu)是什么意義，以前有什么坑，那這些坑我們當(dāng)時又怎么解決的。

另外一點(diǎn)，對于整個公司來說通常我們都會有一個相對于底層的虛擬團(tuán)隊(duì)也好，還是一個基礎(chǔ)團(tuán)隊(duì)也好，會負(fù)責(zé)對一些就像剛剛耿茂說的，對一些中間層，對一些公共庫我們要做一些規(guī)范和標(biāo)準(zhǔn)化。比如說我們會要求所有的目前來說所有的微服務(wù)中間層都采用Thrift協(xié)議，都采用長鏈讓我們的服務(wù)尋址和路由都用我們自己封裝好的REDRPC這一套。通過這樣一些分層和公共組件的隔離，我們可以把一些和性能相關(guān)的一些東西從這個里面抽象出來，抽離出來，這樣對于業(yè)務(wù)開發(fā)的時候可以更關(guān)注在業(yè)務(wù)本身。

第三點(diǎn)，目前來說大部分互聯(lián)網(wǎng)公司都在做前后端分離，那做了前后端分離以后對于業(yè)務(wù)的同學(xué)通常來說會換成兩種不同的東西，第一種我聚焦在后端的接口開發(fā)，同時前端的同學(xué)會對UI展現(xiàn)和交互進(jìn)行一些設(shè)計(jì)，然后在這個設(shè)計(jì)過程中通過和產(chǎn)品的緊密配合大概知道從業(yè)務(wù)的層面怎么去優(yōu)化交互的性能，有很多東西其實(shí)可以在前端的層面去做的，比如我們的一些CDN，我們一些回源，我們的一些接口的優(yōu)化，實(shí)際上是和整個業(yè)務(wù)開發(fā)的同學(xué)是可以做隔離的。

有了這些關(guān)鍵的做法以后，另外一點(diǎn)就是一個定期了，因?yàn)閷τ陔娚虂碚f定期的月促，每年至少有兩次或者三次或者更多的大促，借助這樣的機(jī)會我們會對它進(jìn)行幾輪的這種全鏈路的壓測和定期的單鏈路的壓測，其實(shí)就相當(dāng)于在持續(xù)的更新和迭代的過程。通過這樣的過程教育新來的同學(xué)讓他慢慢地成長起來。其實(shí)沒有什么所謂的Silver bullet這種銀彈，更多的還是執(zhí)行力的過程。

【主持丨大師兄】：非常感謝。我相信可能大部分公司也都是這么做的，接下來我們時間差不多了，我這邊就留一些時間給一些聽眾，看看他們有什么問題，或者大家有問題的話可以在群里面提出來，讓嘉賓幫忙解答一下。

【嘉賓丨耿茂】：我看到余侃有一個問題是關(guān)于Docker對吧？我正好可以想講一下，這也是在Pinterest我一進(jìn)去就開始做的事情。之前Pinterest的部署主要是基于Puppet，有很多的問題。因?yàn)镻uppet在動態(tài)更新環(huán)境的時候可能會遇到一些意想不到的問題，好像依賴的包會有問題，或者其他的東西，引起部署失敗。后面引入Docker之后一切通過Docker Image去部署的話，那就一切好了很多。用Puppet這是歷史原因，以前是這么搞的。現(xiàn)在替換成為Docker之后這個部署就相應(yīng)地穩(wěn)定很多，但是不是所有的服務(wù)都被Dockerized的，只是還在一個遷移的過程當(dāng)中。至于Kubernetes和Mesos這塊現(xiàn)在Pinterest還沒有大規(guī)模使用，Mesos我們用在數(shù)據(jù)處理平臺上。像現(xiàn)在AWS autoscaling?再加上Docker Image這種方式，其實(shí)可以做到動態(tài)的發(fā)布回滾，挺方便的。

【主持丨大師兄】：我看到有一個人在問怎么做性能相關(guān)的OKR或者KPI設(shè)計(jì)。我相信三位嘉賓當(dāng)中可能Pinterest和Splunk的做法應(yīng)該是會比較相似，可能小紅書又是不同的做法，我想請各位嘉賓分別講一下吧。

【嘉賓丨任志超】：對于我來說我最大的OKR就是保證大促的穩(wěn)定，這個里面我們做設(shè)定的時候其實(shí)很簡單，因?yàn)榇蟠偻ǔ碚f就那一波過來我們能夠穩(wěn)定地保證它平穩(wěn)地通過，所謂的平穩(wěn)通過就是說我們?nèi)?#xff0c;那核心的業(yè)務(wù)比如說我們的下單支付，我們的商詳，我們的會場是可以打開的。其實(shí)就和你在淘寶一樣，比如說你在雙十一去下單的時候，你下下去以后會不會全站都下不了單，碰到這種情況肯定你的KPI要掛了。我現(xiàn)在目前來說我對這塊更多的是保障在大促高峰的時候能夠下單和支付和商詳頁這三個主鏈路不要出問題。

【主持丨大師兄】：所以志超你這邊更多的還是比較偏業(yè)務(wù)的保證功能正常的指標(biāo)吧。

【嘉賓丨任志超】：對，線上的。

??

【主持丨大師兄】：我想另外兩位嘉賓你們是不是會有更加關(guān)于請求的吞吐量和延時的指標(biāo)呢？會有這些KPI嗎？

【嘉賓丨耿茂】：是，我們在Pinterest?SRE其實(shí)就是負(fù)責(zé)這個整個網(wǎng)頁和面向手機(jī)客戶端的API的吞吐量和Success Rate。三個九的Success Rate是必須的。然后響應(yīng)時間要在幾百毫秒以內(nèi)，如果有低了之后馬上就會有報(bào)警告訴我們。

???

【主持丨大師兄】：這個指標(biāo)是誰定的呢？是基于一個什么樣的場景會定一個具體的量化指標(biāo)？

【嘉賓丨耿茂】：這還是根據(jù)業(yè)務(wù)來的。像我們的外部主頁其實(shí)有很多不同的路徑，像有的路徑是Create一個Pin，有的路徑是做一個搜索，有的路徑是直接看我們的Home Feed，有的路徑是看Related Pin。所以每一個路徑其實(shí)會有相應(yīng)的團(tuán)隊(duì)在背后，他們要背相應(yīng)的指標(biāo)的，比如Success Rate和響應(yīng)時間。這是面向用戶使用場景的一個事情。

【嘉賓丨王羽嘉】：我稍微補(bǔ)充一點(diǎn)，對于Splunk來說可能第一指標(biāo)是數(shù)據(jù)每天被index的數(shù)據(jù)量是多少，因?yàn)檫@個對于客戶來說，比如說它在客戶的生產(chǎn)環(huán)境里，或者他自己的IT環(huán)境里面可能每天的產(chǎn)生的數(shù)據(jù)量就是非常龐大的，他確實(shí)是可以會比較合理地說，我為了這些數(shù)據(jù)至少要在幾個小時之內(nèi)都要被index進(jìn)來，他對這個一天或者一個小時index的capability是非常在意的。一般來說我們會保證一天兩個TB的數(shù)據(jù)或者更多，這個是一個必備的指標(biāo)。

【主持丨大師兄】：關(guān)于端到端的Tracking?ID耿茂已經(jīng)回答了,?Zipkin是目前比較流行的分布式的監(jiān)測方案。

接下來最后一個問題，有一位同學(xué)問了一下開發(fā)過程中單用戶的性能和并發(fā)測試的實(shí)踐，這個問題應(yīng)該是更多在于普通的Developer在開發(fā)過程中如何對于Performance有敏銳的Insight，并付諸于實(shí)踐，寫出對于Performance友好的代碼。這個我不知道各位有對各自的一些Developer有這方面的一些要求嗎？

【嘉賓丨耿茂】：這個我說一下，像現(xiàn)在單用戶的測試在微服務(wù)的環(huán)境下是比較難做的，主要還是通過trace，就是如果有一個請求進(jìn)來，然后你可以trace到所有經(jīng)過的服務(wù)，每個服務(wù)的響應(yīng)時間都在這樣一個span里面可以體現(xiàn)出來，那你就很容易定位到問題在哪里，可以去優(yōu)化。

【主持丨大師兄】：所以你的建議還是在初期教育的時候盡量去讓他們用一些比較通用的，特別是占用外部資源的時候，可能就是占用一些公用的一些內(nèi)庫，就是保證基本的性能不會差到哪里去，可能真正的測試還是要到一個線上的環(huán)境評估一下這方面的性能？

【嘉賓丨耿茂】：對，我想其實(shí)最重要的就是你先埋入一些可測量的點(diǎn)，如果能夠收集到這些實(shí)際的數(shù)據(jù)相應(yīng)地來做性能調(diào)優(yōu)，那就很有針對性，而且就可以省掉很多時間。當(dāng)然你要埋入這些監(jiān)視的東西需要花工夫，但是你做了以后會有很大的好處。

【嘉賓丨任志超】：我也同意耿茂的，不過我們這邊通常來說會在整個上線流程都會分為幾個不同的階段，在開發(fā)的T環(huán)境下，通常來說他們會做本身開發(fā)追求的本身的功能測試。但是到了我們SIT集成環(huán)境以后其實(shí)相關(guān)的一些依賴，目前來說是有的。我們的測試過程中會保證在有線上數(shù)據(jù)同步過來的情況下會有些業(yè)務(wù)點(diǎn)在正常的處理模型下單用戶是OK的，也就是說我們會在SIT的環(huán)境下對單用戶的性能做一些監(jiān)測，這個監(jiān)測包括響應(yīng)時間等等。

等到C環(huán)境，就是我們用線上的數(shù)據(jù)然后更新我們服務(wù)代碼式的單獨(dú)的開發(fā)代碼的情況下，我們就可以對線上的依賴進(jìn)行一些基本的校驗(yàn)。耿茂說的，我們還有AB，AB上去的時候流量不是說一下子全打過來的，可能是通過灰度不斷地拉過來的，那在拉過來的過程中一旦發(fā)現(xiàn)問題，可以再回滾，整個的過程中我們的節(jié)奏里面會相對來說有效的保障，如果真的有代碼問題，在針對上線以前我們還是有幾道關(guān)口可以卡的，再加上耿茂剛剛說的鏈路的應(yīng)用監(jiān)控，也可以從這個角度來有效的保障。

【主持丨大師兄】：你們覺得內(nèi)部監(jiān)控，因?yàn)楸旧硭灿行阅芊矫娴腛verhead，你們覺得這方面是比如現(xiàn)在一些開發(fā)的框架已經(jīng)優(yōu)化得不錯，還是說再做埋點(diǎn)和Tracking的時候需要充分分析Overhead對于Production的影響。

【嘉賓丨耿茂】：我的看法是開源的已經(jīng)做得很不錯了，但是自己還是要注意，因?yàn)槁顸c(diǎn)是有Overhead的，如果你在一個循環(huán)里面，比如說是一個很critical的code path里面去做這些東西可能會影響到這個服務(wù)反而沒有起到監(jiān)控的效果了，這個是通過灰度上線、AB上線的方式來及早發(fā)現(xiàn)，及早回滾，避免出現(xiàn)真正的問題。

【主持丨大師兄】：好，謝謝耿茂。我們今天這期節(jié)目如果大家沒什么問題的話就到這里，我們下期再見。謝謝三位嘉賓。

跨境茶話會

“跨境茶話會”是由移動增長技術(shù)服務(wù)商“魔窗”聯(lián)合國內(nèi)外眾多技術(shù)專家發(fā)起的在線技術(shù)交流活動，目前已邀請嘉賓來自Google、ebay、Snap、Uber、VISA、Pinterest、BranchMeteics、Splunk、小紅書、華為等國際知名IT企業(yè)在職高級工程師，面向所有互聯(lián)網(wǎng)從業(yè)技術(shù)人員分享交流先進(jìn)理念和實(shí)戰(zhàn)案例，同時為中美技術(shù)朋友提供跨境交友和深度學(xué)習(xí)的平臺。

“跨境茶話會”結(jié)合前沿?zé)狳c(diǎn)技術(shù)話題，精心策劃每月一個線上技術(shù)主題交流，每期邀請來自國內(nèi)外互聯(lián)網(wǎng)界的三位實(shí)戰(zhàn)嘉賓分享一線技術(shù)最佳實(shí)踐，并針對核心技術(shù)問題對話答疑，為技術(shù)從業(yè)者拓寬思路、提升技術(shù)實(shí)力、驅(qū)動業(yè)務(wù)增長。

總結(jié)

以上是生活随笔為你收集整理的跨境茶话会8月期丨性能优化的艺术的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。