服務(wù)治理在貓眼娛樂的演進(jìn)之路

現(xiàn)實(shí)業(yè)務(wù)背景下的挑戰(zhàn)

我們開篇之前，我們先來討論一個(gè)問題，我們談到服務(wù)治理的時(shí)候，說的其實(shí)是什么呢？我們認(rèn)為，服務(wù)治理的關(guān)鍵要素在于兩點(diǎn)，人和系統(tǒng)，我們?cè)谙到y(tǒng)層面希望服務(wù)能夠按照業(yè)務(wù)愿景和架構(gòu)師的理念進(jìn)行運(yùn)行和持續(xù)演進(jìn)。而在人的層面，我們希望在這些系統(tǒng)之上工作的工程師能夠取的最大的舒適感。聽起來有點(diǎn)像廢話，但確實(shí)是我們很容易在一些高大上的名詞中忽視掉的點(diǎn)。在微服務(wù)設(shè)計(jì)一書中，其實(shí)也提到了類似的論點(diǎn)。貓眼的服務(wù)治理體系在幾年的演進(jìn)過程中，其實(shí)也碰到了一些問題。

貓眼作為國(guó)內(nèi)互聯(lián)網(wǎng)在線票務(wù)的領(lǐng)頭羊，也在全娛樂領(lǐng)域在做持續(xù)深耕，目前有數(shù)千萬(wàn)的DAU，每日百億級(jí)的調(diào)用和百萬(wàn)級(jí)的QPS。

在這個(gè)領(lǐng)域，貓眼目前面臨的主要難點(diǎn)有如下幾個(gè)，

1. 從系統(tǒng)層面來說，主要面臨的是系統(tǒng)穩(wěn)定性的問題。大家都知道，每一家公司都會(huì)有一些數(shù)據(jù)資產(chǎn)是很敏感的，所以需要對(duì)于一些爬蟲和惡意流量進(jìn)行準(zhǔn)實(shí)時(shí)的處理。另外，貓眼娛樂作為一個(gè)全娛樂領(lǐng)域的平臺(tái)型公司，也會(huì)承載業(yè)務(wù)在大檔期和大活動(dòng)中流量幾倍、十倍甚至百倍千倍的壓力爆發(fā)，如何在這種情況下，保障系統(tǒng)的可用性，也是一個(gè)值得研究的問題。以及，故障是無(wú)法避免的，無(wú)論流量高低。所以如何保障系統(tǒng)的日常柔性可用，也是需要關(guān)注的問題

2. 從人這一層面來說，主要面臨的是人效問題。服務(wù)治理的各種中間件采用的總體上是一個(gè)富SDK的方式嵌入業(yè)務(wù)方。所以這必然會(huì)帶來兩個(gè)問題，多語(yǔ)言的情況下會(huì)帶來更高的維護(hù)成本，以及SDK升級(jí)所會(huì)帶來的和業(yè)務(wù)相互耦合掣肘的問題。

以上難點(diǎn)都在過往的幾年中困擾著貓眼，也一定程度上阻礙了貓眼業(yè)務(wù)的發(fā)展。

舉兩個(gè)典型的例子，

在穩(wěn)定性這方面，2017年春節(jié)檔Redis千兆網(wǎng)卡打滿帶來的嚴(yán)重影響，我們常規(guī)時(shí)候的流量曲線會(huì)有兩個(gè)規(guī)律的早晚高峰，而大家可以看到，在故障當(dāng)天，因?yàn)榫W(wǎng)卡打滿導(dǎo)致了非常長(zhǎng)時(shí)間的服務(wù)不可用。這也是貓眼經(jīng)歷過的一個(gè)非常重大的事故。

而在人效方面，目前貓眼有1000+的服務(wù)，中間件的升級(jí)動(dòng)輒半年以上的版本升級(jí)周期，這個(gè)其實(shí)對(duì)于業(yè)務(wù)方或者底層架構(gòu)團(tuán)隊(duì)來說都是非常不友好的一個(gè)體驗(yàn)。

所以基于這些問題，貓眼開始開展服務(wù)治理的演進(jìn)之路。

高可用治理中心在貓眼的落地

我們關(guān)注發(fā)現(xiàn)，貓眼主要面臨的場(chǎng)景是大流量下的概率性故障?；谶@樣一個(gè)前提，我們需要展開了故障前、中、后全生命周期的分享優(yōu)化?；谶@樣的一些背景，我們得出高可用治理在貓眼的落地理論架構(gòu)是：面向故障全生命周期進(jìn)行治理，悲觀與樂觀并濟(jì)。

怎么理解這句話呢，從樂觀角度上來說，我們通過各種測(cè)試和評(píng)估，我們的系統(tǒng)應(yīng)該可以避免所有的問題。但是從悲觀角度來看，基于墨菲定律，我們知道可能發(fā)生的就一定會(huì)發(fā)生，所以我們必須來看假定問題發(fā)生，我們能做什么。以及問題真的發(fā)生，我們又能做什么。

而高可用在貓眼落地，需要面臨實(shí)際生產(chǎn)中的諸多難點(diǎn)與挑戰(zhàn)，比如前面有提到的，如何應(yīng)對(duì)永無(wú)止境的爬蟲和惡意流量的攻擊，如何應(yīng)對(duì)大檔期洪峰或者秒殺場(chǎng)景，另外，基于墨菲定律我們知道，故障是無(wú)法避免的。所以如何應(yīng)對(duì)隨時(shí)隨地可能出現(xiàn)的各種上下游的故障，如何避免快速故障恢復(fù)可能帶來的服務(wù)雪崩。這些都是做高可用中需要去應(yīng)對(duì)的挑戰(zhàn)，也是貓眼幾年歷程中真實(shí)出現(xiàn)的問題。

另外，高可用領(lǐng)域中，流控的常規(guī)解決方案是用富SDK來做的，而富SDK是否能滿足業(yè)務(wù)快速滾動(dòng)以及流控自身敏捷迭代升級(jí)的訴求呢？而如果將流控功能都剝離到Server端，我們知道分布式環(huán)境中會(huì)帶來最大麻煩的就是網(wǎng)絡(luò)，全部剝離到Server端的話如何保障實(shí)時(shí)性和可靠性？也就是所謂的Client Side或Server Side，我們應(yīng)該如何抉擇？

再者，我們有了限流、熔斷、混沌工程等等的工具后，很容易就出現(xiàn)有工具但實(shí)際上用不好的情況，更有甚者，因?yàn)榉植际骄W(wǎng)狀拓?fù)湎碌倪@些限流熔斷工具的濫用，反而可能將你的系統(tǒng)推向不可控的深淵。我們?nèi)绾伪苊庥行g(shù)而無(wú)道的局面呢？

基于這樣的一些考慮，我們開展了專項(xiàng)的治理行動(dòng)，自研了貓眼高可用治理中心，代號(hào)大禹。旨在提供自動(dòng)化的限流、熔斷、降級(jí)、隔離、演練、監(jiān)控報(bào)警的一站式可用性保障方案。由于篇幅限制，下面我們主要介紹系統(tǒng)的整體架構(gòu)以及一些產(chǎn)品上的特點(diǎn)。更加具體的架構(gòu)實(shí)現(xiàn)會(huì)在后續(xù)大會(huì)上去做逐步的披露。

首先，這個(gè)是我們高可用治理中心的一個(gè)分層架構(gòu)。我們來做一個(gè)簡(jiǎn)單的介紹

1. 在最上層，是我們的產(chǎn)品層，高可用治理中心目前提供出了惡意流量探測(cè)、演練、限流、熔斷、降級(jí)的產(chǎn)品，同時(shí)，為了達(dá)到策略上線效率的最大化，我們還提供了可自定義規(guī)則的模塊，我們將一條策略抽象為以斷言、條件判斷和處理三個(gè)組件為核心的一個(gè)表達(dá)式，這樣就可以在無(wú)需前端任何產(chǎn)品級(jí)別開發(fā)的前提下完成策略的快速上線。同時(shí)你可以基于我們?cè)拥牟呗越M件的自由拼裝，來實(shí)現(xiàn)你想要的自定義的策略能力。

2. 左下角的演練管控中心則支撐起了演練產(chǎn)品，他底層依托阿里的Sandbox實(shí)現(xiàn)動(dòng)態(tài)注入和銷毀，同時(shí)協(xié)同貓眼的全鏈路壓測(cè)平臺(tái)來提供流量的模擬和調(diào)度。在最右邊則是一些基礎(chǔ)模塊，包括全方位巡檢和兜底容災(zāi)的模塊，以及配置分發(fā)模塊。

3. 接下來，我們可以看到支撐產(chǎn)品形態(tài)的核心能力是一個(gè)策略引擎，除了演練模塊之外，其余無(wú)論是哪個(gè)產(chǎn)品，底層都是由這個(gè)策略引擎進(jìn)行支撐的。策略引擎提供了各種策略模塊的支撐，并提供了復(fù)合的策略層能夠進(jìn)行自由的組合拼裝來實(shí)現(xiàn)你所需要的策略。

4. 而在策略引擎的底層依托于高可用治理中心的語(yǔ)法引擎，我們將策略的場(chǎng)景最近高層次的抽象，提取出四個(gè)模塊——App、Pipeline、Stage、Component四部分。并通過高度內(nèi)聚的語(yǔ)法解析器來進(jìn)行解析。具體我們后面會(huì)有介紹。

所以這就是我們高可用治理中心的一個(gè)分層架構(gòu)。

接下來，我們簡(jiǎn)要介紹一下，前面一直提到的語(yǔ)法引擎。可以看到，在我們的建模中，我們抽象出四個(gè)維度，比如我們希望對(duì)于下單請(qǐng)求進(jìn)行限流策略控制。那么APP就是訂單服務(wù)、Pipeline就是下單功能、Stage就是限流策略，這都是一對(duì)多的關(guān)系。最后策略會(huì)由很多最原子的策略組件Component所構(gòu)成。

我們接著看，可以看到實(shí)際中，我們可以定義很多策略組件，比如特征維度、過濾器、動(dòng)作、條件判斷、恢復(fù)策略等等。而這些策略你可以定義實(shí)際組件和視圖組件，來讓你的語(yǔ)義盡可能地友好。所以你可以看到，有很多組件，他們?cè)谝晥D層和控制層其實(shí)是分離的，他們可以是一對(duì)一、多對(duì)一、一對(duì)多的關(guān)系。這樣就可以讓你的視圖層盡可能友好的情況下，實(shí)現(xiàn)控制層最大程度的精簡(jiǎn)。

整個(gè)語(yǔ)法引擎的核心表達(dá)式即如標(biāo)題右側(cè)所示。如何解析由Component自己定義說了算。這樣就實(shí)現(xiàn)了組件與組件之間的松耦合和自己內(nèi)部的高內(nèi)聚，用輕量級(jí)的原子解析，來避免將語(yǔ)法解析器做成一個(gè)難以維護(hù)的巨無(wú)霸產(chǎn)品。

右下方是一些簡(jiǎn)單的示例?？梢钥吹?，無(wú)論你是簡(jiǎn)單的頻率限制、或者稍微復(fù)雜一點(diǎn)的反爬策略，再或者是狀態(tài)機(jī)熔斷這類規(guī)則，都可以通過我們的表達(dá)式輕松搞定。

最小固化約束下的松散解析，加上VC的分離，這就是貓眼高可用治理語(yǔ)法引擎的核心理念。

接下來，我們看下大禹的系統(tǒng)架構(gòu)。系統(tǒng)架構(gòu)上，我們目前分成了幾大平臺(tái)，包括流量控制平臺(tái)、演練平臺(tái)、健康度量平臺(tái)、決策中心和租戶隔離，其中右側(cè)置灰的系統(tǒng)目前正在設(shè)計(jì)開發(fā)中。左側(cè)的系統(tǒng)都已經(jīng)大規(guī)模落地并經(jīng)歷了幾年線上流量的考驗(yàn)。

下方有個(gè)演練平臺(tái)，即用來進(jìn)行壓測(cè)模擬、故障模擬、預(yù)案驗(yàn)證。這邊不做過多介紹。

上面流量控制平臺(tái)主要負(fù)責(zé)進(jìn)行對(duì)流量的限流、熔斷、降級(jí)和實(shí)時(shí)監(jiān)控，是流量的安全保護(hù)罩。業(yè)務(wù)流量會(huì)調(diào)用遠(yuǎn)端的流控服務(wù)進(jìn)行實(shí)施的決策。

說到這，大家如果了解Servicemesh的可能會(huì)有點(diǎn)熟悉，這種遠(yuǎn)端實(shí)時(shí)控制的方式，是不是有點(diǎn)類似于Istio的Mier服務(wù)？是的，在我們16年啟動(dòng)的時(shí)候，也是經(jīng)歷了控制平面如何切割，Server還是Client為重的苦苦思索和探索，后來確定了貓眼的流控路線是Server Side為主的方式進(jìn)行。這個(gè)路線也為后續(xù)貓眼的發(fā)展帶來了非常大的便利。僅這個(gè)架構(gòu)選型幾年內(nèi)節(jié)省了數(shù)百人天以上的投入。你們可能會(huì)有疑問，Mixer在Servicemesh中被認(rèn)為是一個(gè)相對(duì)沒那么成功的實(shí)現(xiàn)，那貓眼是如何規(guī)避的呢？我們接著往下看。

流控的核心如圖所示，包含兩大服務(wù)——斷言服務(wù)和分析服務(wù)。斷言服務(wù)主要用以快速判斷流量是否符合預(yù)期，而分析服務(wù)用以進(jìn)行流量的準(zhǔn)實(shí)時(shí)分析，并將結(jié)果傳遞給斷言服務(wù)。

這個(gè)流控核心里面有幾個(gè)大的特色

1. 時(shí)效性，我們采用了一些預(yù)測(cè)算法來進(jìn)一步保障決策的實(shí)時(shí)性，同時(shí)，斷言分析底層依賴同一套策略模型，所以你想要絕對(duì)的實(shí)時(shí)，我們也能夠快速地讓斷言服務(wù)同時(shí)具備實(shí)時(shí)分析能力。目前能夠做到無(wú)延時(shí)判斷。

2. 輕接入。采用API快速接入服務(wù)、輕SDK的方式，讓運(yùn)維升級(jí)成本下降70%以上。

3. 高性能。

1. 就近的本地緩存，并進(jìn)行嚴(yán)格的Key控制來防止指數(shù)級(jí)增長(zhǎng)撐爆業(yè)務(wù)進(jìn)程的case出現(xiàn)。

2. 分析和斷言流程的快慢分離，比較重的分析流程異步化，進(jìn)一步提升實(shí)時(shí)流量性能。

3. 基于請(qǐng)求特征樹緩存來加速特征提取，速度比Spring快50%以上。同時(shí)也通過這種方式對(duì)請(qǐng)求大小進(jìn)行了壓縮。

4. 通過以上這些方式對(duì)性能的優(yōu)化。目前我們的RT僅在9us。這個(gè)其實(shí)也就側(cè)面解決了Mixer目前的最大困擾。

4. 低成本。除了上述因?yàn)椴捎肧erver-Side為主進(jìn)行一些重策略的處理所帶來的運(yùn)維成本大幅下降之外，策略底層是由一個(gè)個(gè)策略原子組件所構(gòu)成，這些組件本身具備高度的可復(fù)用性，目前策略復(fù)用率在90%以上。

前面其實(shí)說到了貓眼面臨的一些場(chǎng)景，我們這邊可以來進(jìn)一步感受下。比如最開始貓眼面臨的鋸齒狀的惡意流量，如果攻擊者或者爬蟲做得好的話，我們一些場(chǎng)景下連這個(gè)鋸齒都看不到。以及隨時(shí)業(yè)務(wù)的快速發(fā)展，大檔期來臨時(shí)候的脈沖流量的沖擊。再之后隨著熱門演唱會(huì)業(yè)務(wù)、以及銀行活動(dòng)等等業(yè)務(wù)的蓬勃發(fā)展，我們逐漸碰到了越來越高流量的秒殺場(chǎng)景。從最開始的一些核心系統(tǒng)QPS突增1k，到后來的突增近100w QPS。這給貓眼其實(shí)帶來了非常高的技術(shù)挑戰(zhàn)。而大禹中心是如何在限流上去做出反應(yīng)的呢？

階段一：惡意流量

在2016年及以前，我們其實(shí)面臨了非常多的惡意流量、爬蟲流量，在嘗試對(duì)貓眼進(jìn)行一些攻擊和商業(yè)敏感數(shù)據(jù)的抓取，針對(duì)這個(gè)問題，我們研制了策略引擎，并基于此搭建了流控平臺(tái)，在此基礎(chǔ)上，在策略上，我們提供了一些精細(xì)化的行為探測(cè)，黑白名單，以及基于請(qǐng)求內(nèi)容特征的決策策略。

實(shí)現(xiàn)的關(guān)鍵點(diǎn)主要有四個(gè)，第一，從0到1研制策略引擎，第二，策略需要支持任意維度的組合。第三，基于Redis采用滑動(dòng)窗口計(jì)數(shù)。第四，進(jìn)行行為和內(nèi)容特征庫(kù)的持續(xù)持久化積累。

在這個(gè)階段，我們的業(yè)務(wù)特性要求我們的攻防處理時(shí)候，準(zhǔn)確性的重要性大于實(shí)時(shí)。經(jīng)過第一階段的處理，我們也有不錯(cuò)的一個(gè)效果，比較明顯的是我們的一些系統(tǒng)負(fù)載下來了，我們核心數(shù)據(jù)的反爬率到達(dá)了70%以上，且保持誤傷率在百萬(wàn)分之三以下。

階段二：大檔期洪峰

到了下一個(gè)階段的攻防，主要就是流量過載的防御，2017年大年初一的服務(wù)雪崩給業(yè)務(wù)帶來了較大影響。大檔期洪峰來臨后，我們這個(gè)階段要求實(shí)時(shí)性要進(jìn)一步提升，而本來的這種異步分析的方式是無(wú)法滿足我們需求的，我們研發(fā)了持續(xù)洪峰限流策略，基于去噪預(yù)測(cè)算法基于過去的歷史數(shù)據(jù)來預(yù)測(cè)當(dāng)前時(shí)刻的數(shù)據(jù)，準(zhǔn)確率可以達(dá)到99.2%。這不到1%的一個(gè)qps犧牲來?yè)Q取0延時(shí)的效果，是可以接受的。同時(shí)我們采用多級(jí)緩存、批量緩沖以及自然窗口計(jì)數(shù)的方式，進(jìn)一步降低對(duì)Redis的依賴，徹底實(shí)現(xiàn)了Redis無(wú)熱點(diǎn)情況下的集群持續(xù)洪峰限流策略。

除此之外，我們也提供了其他的能力。比如客戶端限流，我們都知道限流越靠前效果越好，所以我們也將限流前置到了客戶端層面。以及降級(jí)預(yù)案，我們可以選擇非核心交易鏈路的功能，進(jìn)行緊急情況下的部分流量降級(jí)和全部降級(jí)。

通過第二階段的攻防，我們對(duì)于實(shí)時(shí)性有了更高的要求，準(zhǔn)確性可以有接受小的犧牲。第二階段完成后，接入的系統(tǒng)能夠承載數(shù)百倍過載流量壓力而不被壓垮。

階段三：秒殺

從2018年下半年開始，我們也不斷衍生出銀行活動(dòng)和演出秒殺的場(chǎng)景。這類秒級(jí)別激增的流量，用預(yù)測(cè)算法已經(jīng)無(wú)法很好支持，因?yàn)檫@種瞬時(shí)激增的脈沖流量是無(wú)法被預(yù)測(cè)的，更甚可能由于去噪預(yù)測(cè)算法會(huì)將其標(biāo)識(shí)為噪點(diǎn)數(shù)據(jù)而導(dǎo)致誤差的進(jìn)一步放大。

所以基于這樣一個(gè)背景，我們經(jīng)過權(quán)衡之后，這個(gè)階段我們?cè)诹骺貙用娴膬?yōu)化主要在于入口層面單機(jī)限流+內(nèi)部基礎(chǔ)服務(wù)持續(xù)洪峰限流。主要兩點(diǎn)考慮：

1. 因?yàn)榇藭r(shí)入口服務(wù)由于大流量的突發(fā)沖擊，持續(xù)洪峰限流策略基于過去的預(yù)測(cè)算法會(huì)失效，已經(jīng)難以滿足要求，而貓眼入口服務(wù)的負(fù)載均衡策略的RR策略，而且能夠更加實(shí)時(shí)地反應(yīng)，所以單機(jī)限流策略能夠取代前者發(fā)揮很好的作用。

2. 同時(shí)內(nèi)部服務(wù)的流量策略是多樣的，且流量已經(jīng)一定程度被打散，所以采用持續(xù)洪峰的集群式限流仍然可以起到作用，且相較于單機(jī)限流會(huì)更為保險(xiǎn)不容易誤判。

而從更全局上，我們和業(yè)務(wù)方協(xié)作，進(jìn)行了“一控四化”的權(quán)衡，什么叫一控四化呢？即：

1. 對(duì)系統(tǒng)進(jìn)行兜底控制。如上面我們所做的單機(jī)+集群持續(xù)洪峰限流策略雙管齊下。

2. 對(duì)業(yè)務(wù)進(jìn)行場(chǎng)景化。比如答題、玩游戲。

3. 對(duì)業(yè)務(wù)進(jìn)行異步化。比如排隊(duì)

4. 對(duì)資源靜態(tài)化。一些內(nèi)容和功能可以分發(fā)到CDN、服務(wù)端LB上去做靜態(tài)化提速。

5. 對(duì)資源進(jìn)行隔離。無(wú)論是Set化、還是其他方式，對(duì)服務(wù)器、緩存、數(shù)據(jù)庫(kù)等等的熱點(diǎn)資源進(jìn)行物理/邏輯層面隔離。

階段四：百萬(wàn)級(jí)別QPS秒殺

但是呢，還沒結(jié)束。隨著業(yè)務(wù)的蓬勃發(fā)展，2019年演出迎來了百萬(wàn)級(jí)別的QPS秒殺場(chǎng)景，我們發(fā)現(xiàn)后續(xù)步驟用持續(xù)洪峰限流也已經(jīng)無(wú)法滿足要求，即使經(jīng)過前面幾個(gè)步驟的打散，后續(xù)步驟的一些系統(tǒng)qps仍然會(huì)有激增到很高的情況，我們的用戶、訂單服務(wù)都遭受到類似的問題沖擊影響了系統(tǒng)的穩(wěn)定性甚至導(dǎo)致關(guān)聯(lián)業(yè)務(wù)受損。

所以這時(shí)候我們對(duì)于這類的場(chǎng)景，進(jìn)行了如下幾點(diǎn)的處理。

1. 由于復(fù)雜服務(wù)拓?fù)洳渴鸾Y(jié)構(gòu)和LB策略的不同，所以內(nèi)部流量本身是不均勻的。無(wú)法直接對(duì)一些下沉在底部的基礎(chǔ)服務(wù)直接使用單機(jī)限流。所以我們將業(yè)務(wù)流量通過RR策略重新導(dǎo)到流控服務(wù)端進(jìn)行流量打平，再在流控Server端完成單機(jī)限流。

2. 但是，這個(gè)對(duì)于QPS不高的場(chǎng)景，比如業(yè)務(wù)方設(shè)置QPS為150，但是當(dāng)前流控服務(wù)端機(jī)器數(shù)只有100臺(tái)，則最大會(huì)帶來50%的誤差，進(jìn)而產(chǎn)生誤判，這種情況是不可被接受的。所以我們針對(duì)QPS不高（5k）的場(chǎng)景，自動(dòng)將其降級(jí)為擊穿到Redis進(jìn)行自然窗口計(jì)數(shù)實(shí)時(shí)分析判斷。來解決這個(gè)誤差問題。

3. 前面提到分析和斷言兩個(gè)服務(wù)底層依賴的其實(shí)是同一套策略引擎，以便于同步、異步分析的隨時(shí)切換。所以我們?cè)谶@個(gè)策略中進(jìn)行了策略引擎的同步化定制，同時(shí)將業(yè)務(wù)SDK緩存失效，以此在犧牲1-2ms性能的基礎(chǔ)上達(dá)到絕對(duì)的實(shí)時(shí)。

4. 同時(shí)，在后續(xù)流控馬上會(huì)對(duì)其進(jìn)行Set化。針對(duì)演出業(yè)務(wù)進(jìn)行獨(dú)立Set部署。避免大流量下的業(yè)務(wù)之間相互影響問題。

剛剛提到的是限流，現(xiàn)在說一下熔斷。我們的高可用治理中心的熔斷能力相比于業(yè)內(nèi)的一些實(shí)現(xiàn)，也有自己的一些特別的地方。

1. 我們能夠支持精細(xì)化的過濾和錯(cuò)誤判斷標(biāo)準(zhǔn)的自定義

2. 同時(shí)為了避免快速恢復(fù)導(dǎo)致服務(wù)雪崩，因而我們采用了階梯式的熔斷策略。有點(diǎn)類似于開手動(dòng)擋的車，可以跨檔降速，但不能跨檔提速。通過這種方式，我們提供了這種快速熔斷-階梯恢復(fù)的策略。

3. 我們目前基于貓眼業(yè)務(wù)主要提供的是基于錯(cuò)誤率的判斷，但我們都知道，當(dāng)流量較低的時(shí)候，按照錯(cuò)誤率來判斷很容易造成誤傷，而流量很低的時(shí)候，我們進(jìn)行熔斷的現(xiàn)實(shí)意義也不是很大，所以我們也設(shè)置了當(dāng)前熔斷策略啟動(dòng)的流量閾值。

One More Thing

提完了限流、熔斷。之后不得不說道目前業(yè)內(nèi)提到的一個(gè)越來越流行的做法，即基于類似BBR的TCP擁塞控制算法的方式來進(jìn)行自動(dòng)化的處理，來避免各種參數(shù)配置帶來的不可控的成本和影響。這是一個(gè)非常好的思路。

但是這種類BBR的算法的啟動(dòng)閾值判斷是需要多維考慮的，而不能就僅僅基于業(yè)內(nèi)目前提供的這種基于cpu load的方式來做。這樣對(duì)于低load的場(chǎng)景無(wú)法適用，我們認(rèn)為應(yīng)該有一些更智能更全面的評(píng)估方式來評(píng)估系統(tǒng)的健康度，當(dāng)系統(tǒng)因?yàn)榱髁吭蝰R上要出問題的時(shí)候，再啟動(dòng)對(duì)應(yīng)的BBR策略。即，我們不能將系統(tǒng)健康直接粗暴地等同于cpu使用率或者load高這樣的單一判斷。比如基于QPS、基于load、基于錯(cuò)誤率、基于容量評(píng)估、基于鏈路判斷等等。

這其實(shí)給我們提供了很大的想象空間的同時(shí)也能解放人力，是未來貓眼希望去深耕的一個(gè)方向。

我們除此之外，還提供了演練的能力，進(jìn)行了混沌工程的落地實(shí)踐。我們的演練產(chǎn)品進(jìn)行了全鏈路壓測(cè)和故障演練的打通，可以通過調(diào)度壓測(cè)的流量來進(jìn)行演練，對(duì)應(yīng)的預(yù)案能夠在演練過程中不影響線上真實(shí)流量。

同時(shí)，我們知道，為了盡量降低風(fēng)險(xiǎn)，一般的演練都會(huì)放到晚上高峰期之后再進(jìn)行。所以針對(duì)這種情況，我們也實(shí)現(xiàn)了在灰度鏈路上進(jìn)行演練，以此來大幅削減演練的成本。兩年以來，我們累計(jì)進(jìn)行十余次大型演練，發(fā)現(xiàn)了超百個(gè)問題，包含數(shù)十個(gè)致命級(jí)別的問題。這說明，我們的演練事實(shí)上發(fā)揮了非常關(guān)鍵的作用。

介紹一下大禹的精細(xì)化運(yùn)營(yíng)。我們能夠進(jìn)行秒級(jí)別的流量探測(cè)（精確到1s），同時(shí)提供了多維度的圖表來便于日常使用者和運(yùn)維方的使用，也提供了自動(dòng)巡檢的能力，來對(duì)接入的業(yè)務(wù)方進(jìn)行幾個(gè)維度的巡檢來簡(jiǎn)單判斷他的健康狀態(tài)。

同時(shí)，我們也提供了“流量預(yù)觀察”的能力。因?yàn)槲覀冎?，一條策略上線是否可靠，是否會(huì)閾值設(shè)置有問題帶來一些不可控的影響，上線之前基本業(yè)務(wù)方心里是沒有底的。這個(gè)時(shí)候我們提供了這種預(yù)觀察的能力，能夠模擬策略生效，讓你實(shí)時(shí)觀察實(shí)際的影響。從而給你提供了“反悔”的機(jī)會(huì)。這種能力在我們的限流熔斷足夠智能化無(wú)參化之前，是一個(gè)極其重要的能力。

當(dāng)然，穩(wěn)定性保障僅靠高可用治理中心是不夠的，業(yè)務(wù)層面，也進(jìn)行了大量的持續(xù)優(yōu)化。我們來看下在貓眼2018年穩(wěn)定性保障持續(xù)深耕之后的整體非功能性的故障趨勢(shì)：

可以看到，P2及以上故障下降了46%，無(wú)P1級(jí)別故障。和前面幾年形成了鮮明的反差。這也側(cè)面體現(xiàn)了貓眼在穩(wěn)定性保障這個(gè)領(lǐng)域的努力，以及高可用治理中心的價(jià)值。

結(jié)語(yǔ)

這是貓眼服務(wù)治理幾年發(fā)展以來，在穩(wěn)定性保障方面基于業(yè)務(wù)痛點(diǎn)去做出的一些工作。

推薦閱讀

• 字節(jié)跳動(dòng)踩坑記#2：Go 服務(wù)鎖死