本文是蘭建剛分享餓了么服務(wù)治理經(jīng)驗(yàn)。
蘭建剛，餓了么框架部門(mén)技術(shù)總監(jiān)，前愛(ài)立信首席軟件工程師，10 年以上高可用性，高并發(fā)系統(tǒng)架構(gòu)設(shè)計(jì)經(jīng)驗(yàn)?，F(xiàn)餓了么框架工具部負(fù)責(zé)人，負(fù)責(zé)餓了么中間件的設(shè)計(jì)及實(shí)施，通過(guò)中間件以及研發(fā)工具的輔助提升研發(fā)人員的工作效率，提升網(wǎng)站的穩(wěn)定性及性能。
今天我想站在一個(gè)大的角度上，看一下餓了么最近一年多的時(shí)間，經(jīng)歷的技術(shù)上一些痛苦的問(wèn)題與改進(jìn)的過(guò)程。
為什么講比較痛苦的事情？昨天和一位專家聊天受益很大，他說(shuō)人在什么時(shí)候能夠自我驅(qū)動(dòng)？就是痛苦的時(shí)候。 只有感到痛苦，才會(huì)有改變。 當(dāng)然改變有兩種結(jié)果，一種是徹底放棄沉淪，另外就是一想辦法自動(dòng)化、智能化，把自己變成一個(gè)高手。
我現(xiàn)在也很痛苦，但是還沒(méi)有放棄。先講一下 MVP 原則，MVP（Minimum Viable Product） 現(xiàn)在比較火， 一個(gè)產(chǎn)品是做大而全，還是可用就行？ 我從去年 3 月份加入餓了么，開(kāi)始組建框架和工具的團(tuán)隊(duì)。中間件里面很多東西都可以去做，但是我真的需要把所有的東西都做全嗎還是 MVP 原則就好？這是我們思考的一個(gè)問(wèn)題。
MVP 的意思就是做一個(gè)最小可用的就可以，大家以前很流行說(shuō)，“世界那么大，我想去看看”，其實(shí)框架很多東西看看就好，做全做好是需要長(zhǎng)時(shí)間積累的，我們?nèi)钡那∏∈菚r(shí)間。我們要做的就是立足現(xiàn)狀，解決痛點(diǎn)問(wèn)題?，F(xiàn)在餓了么的現(xiàn)狀說(shuō)白了比百?gòu)U待興好一點(diǎn)。 當(dāng)有太多事情可以去做的情況下，更需要抓住重點(diǎn)，不死人的盡量不要去踏。
服務(wù)治理是一個(gè)很大的話題，它涵蓋了很多內(nèi)容，比如前面曉波老師介紹的 Redis 治理、姚捷老師講的鏈路監(jiān)控系統(tǒng)（參看文末文章），都可以涵蓋在里面。
先介紹語(yǔ)言，剛才會(huì)場(chǎng)一些人說(shuō)他們是異構(gòu)的語(yǔ)言，但可能還是沒(méi)有餓了么這么復(fù)雜。餓了么語(yǔ)言主要有兩種，Python 及 Java，原來(lái)整個(gè)公司語(yǔ)言都是以 Python 為主，可以說(shuō)是上海最大的 Python 大廠。為什么不堅(jiān)持用 Python？不是說(shuō) Python 語(yǔ)言不好，而是招不到人。在業(yè)務(wù)急速發(fā)展的時(shí)候怎么辦？換 Java 語(yǔ)言就成了自然的選擇。
在我進(jìn)公司的時(shí)候，其實(shí)不僅僅是這兩種語(yǔ)言，還有 PHP，C 語(yǔ)言等?；谶@些現(xiàn)狀，框架的選擇點(diǎn)就比較少。因此做了一些妥協(xié)，SOA 的框架有兩套，主要是為 Python 和 Java 做的，Python 的叫 Vespense，Java 版本的叫 Pylon，Vespense 和 Pylon 都是星際爭(zhēng)霸里面的兩種最基本的東西，沒(méi)有這兩種東西游戲根本打不下去。
SOA 框架里面需要包含什么？ 首先必須包含 RPC ，我們的 RPC 有兩種：Thrift 和 JSON。Python 使用 Thrift，Java 使用 JSON。為什么 Java 框架重新選擇一套 RPC 協(xié)議？ 主要是覺(jué)得 Thrift 對(duì) Java 不太友好。舉個(gè)例子，用 Thrift 生成的 Java 代碼在接口比較多的時(shí)候，它的一個(gè)文件就超過(guò) 20M ，連 IDE 都拒絕分析這個(gè)文件。另外 JSON 是純文本的，因?yàn)楫?dāng)初也沒(méi)有日志系統(tǒng)，也沒(méi)有鏈路跟蹤系統(tǒng)，排查問(wèn)題的時(shí)候，一種好的辦法就是抓包，如果是一個(gè)二進(jìn)制的協(xié)議的話那就痛苦。所以最終 Java 選擇了 JSON。當(dāng)然 RPC 都是對(duì)業(yè)務(wù)透明的，SOA 框架會(huì)屏蔽 RPC 細(xì)節(jié)，業(yè)務(wù)就像使用本地調(diào)用一樣使用遠(yuǎn)程服務(wù)。
路由我們是基于集群做的，沒(méi)有進(jìn)一步細(xì)化到機(jī)器級(jí)別，因?yàn)橛X(jué)得這個(gè)就足夠了。此外也做了客戶端的 SLB，還有熔斷、降級(jí)、限流，這是保護(hù)服務(wù)的幾大法寶，充分證明了這些東西拯救了我們很多次。經(jīng)?？吹奖O(jiān)控群里面說(shuō)，我們把什么什么服務(wù)限流了吧，把它降級(jí)了吧，那是因?yàn)檫@個(gè)服務(wù)可能寫(xiě)的不太好，把它降掉了，保住我們的主要業(yè)務(wù)。還有一些埋點(diǎn)，全鏈路跟蹤等等，全部都內(nèi)嵌在框架里面。這樣的好處就是， 增加特性只要升級(jí)一個(gè)框架就可以了 。
我們的服務(wù)發(fā)現(xiàn)和配置中心叫 Huskar，這是 DOTA 里面的一個(gè)英雄人物的名字，它是基于 ZooKeeper。
負(fù)載均衡有好幾種， 首先有嵌在 SDK 里的軟負(fù)載 ，拿到一個(gè)服務(wù)全部的列表，做一個(gè)輪循就可以了。這種策略有一些不足，比如一個(gè) IDC 里面機(jī)器型號(hào)性能可能會(huì)稍微不一樣，如果單純用輪循會(huì)產(chǎn)生負(fù)載不均的問(wèn)題。但這個(gè)問(wèn)題當(dāng)前還不是最緊迫的，我們可以繞過(guò)去，只要保證同一個(gè)集群里機(jī)器型號(hào)都是相同的就好。
此外也用中間層的方式，以前我們的 haproxy 用起來(lái)比較麻煩，配置復(fù)雜，而且它不能進(jìn)行熱加載，一個(gè)配置上去了之后需要重啟一遍，因此工程師就用 Go 語(yǔ)言寫(xiě)了一個(gè) GoProxy，基于四層，它會(huì)從服務(wù)中心把你需要的列表全部抓下來(lái)，做四層的負(fù)載均衡。他可以代理一些沒(méi)有 SOA 框架支持的語(yǔ)言寫(xiě)的服務(wù)，也可以代理其他的基礎(chǔ)組件，比如說(shuō)像 Redis，數(shù)據(jù)庫(kù)，它都會(huì)代理。
我們有 CI、CD 灰度發(fā)布的系統(tǒng)，叫 eless，雖然我們做了 CD 但是百?gòu)U待興，目前只有一些基本的單元測(cè)試，因?yàn)檫@個(gè)太耗工夫了?；叶劝l(fā)布也是基于發(fā)布系統(tǒng)做的，我們會(huì)在發(fā)布系統(tǒng)里面定義集群，每個(gè)集群里面的機(jī)器又分成不同的組，發(fā)布的時(shí)候按這些組來(lái)發(fā)布的，你可以先發(fā)一個(gè)組，觀察沒(méi)有問(wèn)題后，然后再發(fā)其他的組。
我們有自己的監(jiān)控和報(bào)警系統(tǒng)。 監(jiān)控現(xiàn)在做的比較簡(jiǎn)單，是 statsd + graphite + grafana 的組合 ?，F(xiàn)在最大的問(wèn)題是監(jiān)控系統(tǒng)不支持 tags，所有的指標(biāo)匯聚到一起，一個(gè)服務(wù)的指標(biāo)是匯聚在一起的，一個(gè)機(jī)器或者集群慢了，它會(huì)把這些指標(biāo)分?jǐn)偟狡渌麢C(jī)器或者集群上去的，所以查的時(shí)候比較困難，所以我們現(xiàn)在準(zhǔn)備切成我們自己的系統(tǒng)。
報(bào)警系統(tǒng)也是自己寫(xiě)的。 報(bào)警系統(tǒng)的需要是快、全、準(zhǔn) 。我們現(xiàn)在做的是全，逼著大家去把報(bào)警系統(tǒng)用起來(lái)，只看監(jiān)控系統(tǒng)是看不過(guò)來(lái)。如果線上發(fā)生了一個(gè)故障，比如交換機(jī)發(fā)生故障，影響到某個(gè)業(yè)務(wù)，但是業(yè)務(wù)報(bào)警沒(méi)有報(bào)出來(lái)，那業(yè)務(wù)要承擔(dān)連帶責(zé)任，因?yàn)槟銢](méi)有報(bào)警出來(lái)。
報(bào)警最常見(jiàn)的基于閾值，閾值這件事情比較痛苦，我們有很多指標(biāo)，但這個(gè)閾值怎么去配，需要很有經(jīng)驗(yàn)的人才能配好，閾值配小了，你會(huì)經(jīng)常收到報(bào)警，配太大有可能出問(wèn)題收不到報(bào)警，這個(gè)非常痛苦。所以一個(gè)同事提出 基于趨勢(shì) 來(lái)配置來(lái)判斷，我們?cè)谝欢螘r(shí)間發(fā)現(xiàn)趨勢(shì)在偏離了，就做報(bào)警。
我們也在做 trace，前兩天終于把拓?fù)鋱D給畫(huà)出來(lái)，把一個(gè)業(yè)務(wù)所有的調(diào)用展示成一個(gè)調(diào)用樹(shù)，這樣就可以很好的分析業(yè)務(wù)。我們現(xiàn)在是一個(gè)近千人公司，業(yè)務(wù)系統(tǒng)極度復(fù)雜，很少有工程師能清晰說(shuō)出一個(gè)業(yè)務(wù)到底調(diào)用了哪些服務(wù)，通過(guò)這種 trace 方式來(lái)做輔助分析就很有用了。
光展示，我們覺(jué)得它的價(jià)值還沒(méi)有利用到極致，可以把所有的調(diào)用關(guān)系和報(bào)警結(jié)合在一起。大家分析問(wèn)題的時(shí)候，會(huì)發(fā)現(xiàn)如果某個(gè)點(diǎn)上發(fā)生的錯(cuò)誤一直往上報(bào)，從而導(dǎo)致整條鏈路失敗，那這個(gè)點(diǎn)就是 root cause，把它修復(fù)就可以問(wèn)題解決了。我們做 trace 的思路是一樣的， 在調(diào)用鏈上進(jìn)行著色，輔助找到問(wèn)題的 root cause ，也就是最初發(fā)生問(wèn)題的那個(gè)點(diǎn)。
“不能被爛用的框架不是好框架”，這個(gè)是我們 CTO 經(jīng)常說(shuō)的一句話。原因是什么？比如我們那個(gè)監(jiān)控的 SDK 曾經(jīng)被業(yè)務(wù)錯(cuò)誤的使用，每發(fā)一次報(bào)警就啟一個(gè)新線程，最后整個(gè)進(jìn)程因?yàn)殚_(kāi)了太多的線程掛掉了。峰哥（CTO）說(shuō)你無(wú)法預(yù)測(cè)每個(gè)開(kāi)發(fā)者會(huì)怎么使用你的框架，即使框架被濫用了，最壞的情況，也需要保證能夠活的下去。
所以后面寫(xiě)的東西都嚴(yán)格要求自我狀態(tài)的檢查，比如秒殺的時(shí)候，所有的監(jiān)控系統(tǒng)，鏈路跟蹤系統(tǒng)都是可以降級(jí)的，不能因?yàn)檫@些東西導(dǎo)致整個(gè)系統(tǒng)崩潰。
框架由于在底層，出了問(wèn)題最容易被懷疑。比如一個(gè) SDK，使用方說(shuō)為什么占用了整個(gè)集群上 8% 的 CPU？跑過(guò)去一看，整個(gè)機(jī)器的 CPU 才 12%。某種程度做框架其實(shí)有無(wú)助的時(shí)候，容易被質(zhì)疑及譴責(zé)，所以做好自我狀態(tài)檢查是很必要的。
為了避免濫用的問(wèn)題，我們會(huì)定期線上掃描。比如一些日志本來(lái)就是可以降級(jí)可以丟的，但如果開(kāi)發(fā)用了寫(xiě)文件的同步方式，那性能就會(huì)變慢，通過(guò)掃描發(fā)現(xiàn)這些問(wèn)題，改成異步日志服務(wù)性能就會(huì)更好。
這個(gè)強(qiáng)調(diào)多少遍都不過(guò)分，因?yàn)榇_實(shí)很重要。服務(wù)不行的時(shí)候一定要熔斷。限流是一個(gè)保護(hù)自己最大的利器，原來(lái)我們前端是用 PHP 做的，沒(méi)有自我保護(hù)機(jī)制，不管有多少連接都會(huì)接收，如果后端處理不過(guò)來(lái)，前端流量又很大的時(shí)候肯定就掛了。所以我們做任何框架都會(huì)有限流措施。
有個(gè)小插曲，我們上 DAL （數(shù)據(jù)庫(kù)中間件）第一版的時(shí)候，有次一個(gè)業(yè)務(wù)怎么指標(biāo)突然降了 50%，然后大家去查，原來(lái) DAL 做了限流，你不能做限流，你把它給我打開(kāi)，聽(tīng)你們的我打開(kāi)了，打開(kāi)了然后數(shù)據(jù)庫(kù)的 QPS 瞬間飆到兩萬(wàn)，業(yè)務(wù)部門(mén)就慌了，趕緊邀請(qǐng)我們?cè)俳o他限制住。這是我覺(jué)得 DAL 做的最好的一個(gè)功能。
還有連接復(fù)用，有些工程師并不能特別理解，如果不用連接池，來(lái)一個(gè)請(qǐng)求就發(fā)一個(gè)連接怎么樣？這樣就會(huì)導(dǎo)致后端資源連接過(guò)多。對(duì)一些基礎(chǔ)服務(wù)來(lái)說(shuō)，比如 Redis，數(shù)據(jù)庫(kù)，連接是個(gè)昂貴的消耗。所以我們一些中間件的服務(wù)都實(shí)現(xiàn)了連接復(fù)用的功能。
上線發(fā)布是很危險(xiǎn)的一件事情，絕大部分的事故都是由發(fā)布引起的，所以發(fā)布需要跟很多系統(tǒng)結(jié)合起來(lái)，所以我們做了整套流程。在每次發(fā)布的時(shí)候，一個(gè)發(fā)布事件開(kāi)始，到我們這個(gè)監(jiān)控系統(tǒng)以及調(diào)用鏈上，調(diào)用鏈就開(kāi)始分析了， 發(fā)布后把它的所有指標(biāo)比一比，到底哪些指標(biāo)發(fā)生了改變，這些指標(biāo)如果有異常，就發(fā)報(bào)警 ，所有發(fā)布都會(huì)打到監(jiān)控的主屏上面去，如果出了什么問(wèn)題，這些事情優(yōu)先回滾，如果可以回滾，我們肯定第一時(shí)間就把問(wèn)題解決掉了。
超時(shí)配置：超時(shí)配多少是合適的？100ms？300ms？極端情況有些業(yè)務(wù)配到 3 秒的。閾值怎么配和超時(shí)怎么配其實(shí)是同一個(gè)概念，并不是所有的程序員都知道超時(shí)設(shè)成多少合適。那怎么辦？峰哥（CTO）想了一個(gè)辦法，你的監(jiān)控系統(tǒng)，你的調(diào)用鏈分析系統(tǒng)，你的日志系統(tǒng)，基礎(chǔ)監(jiān)控系統(tǒng)每天產(chǎn)生多少數(shù)據(jù)？這些數(shù)據(jù)到底有沒(méi)有用？是否可以從這些數(shù)據(jù)里面挖掘出一些東西，比如這種超時(shí)的配置，是可以基于它歷史的超時(shí)配置、所有請(qǐng)求的響應(yīng)時(shí)間去做的。
這件事情正在進(jìn)行中，但落地有點(diǎn)麻煩，比如說(shuō)我們請(qǐng)求大概每天有三千萬(wàn)的調(diào)用量，你只有很小的一個(gè)比例它會(huì)超時(shí)，但是絕對(duì)量是很大的，你設(shè)置一個(gè)超時(shí)值，它可能有三萬(wàn)個(gè)請(qǐng)求都失敗了?，F(xiàn)在一直在優(yōu)化這個(gè)東西，希望下次大家來(lái)我們這里的時(shí)候，能給大家詳細(xì)介紹一下這個(gè)超時(shí)到底怎么做。
線程池配置：剛才說(shuō)最重要的是限流，你不可能無(wú)限制的接受請(qǐng)求，不可能一百個(gè)并發(fā)你就接收一百個(gè)并發(fā)，并發(fā)到底怎么配？又是很復(fù)雜的事情。我經(jīng)?？次覀兙€程池的配置，這個(gè)東西要經(jīng)過(guò)嚴(yán)格的性能測(cè)試，做很多調(diào)整才能調(diào)出來(lái)。在做性能測(cè)試的時(shí)候，其實(shí)有條曲線的，有個(gè)最高點(diǎn)的，我們?cè)谙朐趯?shí)時(shí)的過(guò)程中計(jì)算出這個(gè)最高點(diǎn)，但發(fā)現(xiàn)這個(gè)東西其實(shí)挺難的。
我們便用了另外一種方法， 每個(gè)線程池用一個(gè)排列隊(duì)列 ，當(dāng)我發(fā)現(xiàn)它在漲的時(shí)候我就適當(dāng)把那個(gè)線程池?cái)U(kuò)大一點(diǎn)，同時(shí)我們監(jiān)測(cè)其他指標(biāo)。如果發(fā)現(xiàn)在我擴(kuò)大并發(fā)量的時(shí)候這些指標(biāo)產(chǎn)生了報(bào)警，那我就把這個(gè)線程調(diào)整的操作直接拒絕掉，就保持原來(lái)那個(gè)大小。如果這些指標(biāo)證明是沒(méi)有問(wèn)題的，那我就把它再擴(kuò)大一點(diǎn)。
Cache，DB，Queue 的手工配置問(wèn)題。還有一個(gè)是服務(wù)治理，Redis、數(shù)據(jù)庫(kù)等配置還都是手工的，我們也不知道我們線上有 Redis，怎么辦？我們正在做基礎(chǔ)服務(wù)的服務(wù)化，業(yè)務(wù)其實(shí)不需要關(guān)心到底連到哪個(gè) Redis，你上線的時(shí)候你告訴我你需要多大的容量，填個(gè)工單過(guò)來(lái)，運(yùn)維幫你配好了，然后通過(guò)一些自動(dòng)化的方式你把這些拿到初始化 SDK 就可以了。
還有一個(gè)比較痛的問(wèn)題就是排查問(wèn)題很難。首先故障定位困難，每次我們出了事情之后，大家各自查各自的，比較低效。問(wèn)題排查其實(shí)是有方法可以做，需要把它自動(dòng)化，我們現(xiàn)在還缺這個(gè)東西，調(diào)用鏈分析是需要考慮去做。
我們現(xiàn)在的業(yè)務(wù)增長(zhǎng)量非?？植溃ツ晡覀兪且?5 倍的速度增長(zhǎng)了，但其實(shí)這個(gè) 5 – 10 倍要看你的基數(shù)，當(dāng)基數(shù)很大，擴(kuò)一倍量也是非常多，評(píng)估線上到底要布多少臺(tái)機(jī)器是一件很復(fù)雜的事情。
我們成立一支性能測(cè)試團(tuán)隊(duì)，做全鏈路的壓測(cè)?；谌溌穳簻y(cè)的結(jié)果來(lái)評(píng)估整個(gè)系統(tǒng)的容量。這個(gè)全鏈路只能在線上做，也不能在白天壓，只能在晚上低峰期的時(shí)候做。所以性能測(cè)試也是一個(gè)比較挑戰(zhàn)的工作，不僅僅是智力上，也是身體上的一種考驗(yàn)。
全鏈路壓測(cè)試一些服務(wù)有時(shí)候出現(xiàn)性能下降，比如 QPS 從 500 下降到了 400，但大家并不知道最直接的原因。上次畢洪宇老師也幫我們出了主意，比如把全鏈路指標(biāo)拉出來(lái)做一下對(duì)比，看看哪些指標(biāo)有變化，可能就是罪魁禍?zhǔn)住?/p>
容量評(píng)估方面容易出現(xiàn)溫水煮青蛙的事情，今天流量增長(zhǎng)一點(diǎn)沒(méi)問(wèn)題，明天再增長(zhǎng)一點(diǎn)也沒(méi)有問(wèn)題，連續(xù)幾天然后服務(wù)就掛了。這個(gè)時(shí)候怎么辦？只能用最苦逼的方法，找個(gè)性能測(cè)試團(tuán)隊(duì)進(jìn)行壓測(cè)。有沒(méi)有更智能化的方法？我們也正在探尋這條道路。
資源利用率低的問(wèn)題。很多團(tuán)隊(duì)一碰到性能下降，就希望擴(kuò)容，這會(huì)導(dǎo)致很多時(shí)候機(jī)器利用率只有 10%（更新一下數(shù)據(jù)，其實(shí)很多服務(wù)器的利用率不足1%）。我們正在積極準(zhǔn)備上容器化方案來(lái)解決這個(gè)問(wèn)題。
大的系統(tǒng)中，服務(wù)依賴的調(diào)用鏈相當(dāng)復(fù)雜，一個(gè)業(yè)務(wù)下去到底調(diào)用了哪些服務(wù)比較難說(shuō)清。我們已經(jīng)在做一個(gè)泳道規(guī)劃。泳道這件事情有多種說(shuō)法，有的人喜歡所有的服務(wù)都做一個(gè)大池子，只要保證它的足夠容量就可以了，但是我更傾向小集群的思路，因?yàn)楦綦x起來(lái)就會(huì)更安全。
我們現(xiàn)在還沒(méi)有做到按用戶來(lái)區(qū)分泳道，目前只是按流量來(lái)切，50% 隨機(jī)，部署的東西都一樣。我們想通過(guò)泳道把這些流量隔離，VIP 客戶可以把他放最重要的泳道里面，一些不那么重要的城市，可以放到另一個(gè)集群，如果不得已降級(jí)，只能犧牲這些次重要的用戶。
有痛點(diǎn)就要努力，要么放棄，要么努力，這是我們努力的方向，前面講了一下智能流控系統(tǒng)，超時(shí)推薦我們也做，大數(shù)據(jù)和智能化才是將來(lái)。有些監(jiān)控?cái)?shù)據(jù)只是落在磁盤(pán)上不用那就是浪費(fèi)，是不是能把它利用起來(lái)？
然后我們也在做 Cache、數(shù)據(jù)庫(kù)、Queue 等服務(wù)化。
Trace 系統(tǒng)我們也在做，拓?fù)鋱D畫(huà)出來(lái)，幫助大家了解是怎么回事，我們可以做鏈路染色，幫你了解問(wèn)題的根源在哪里，我們也可以做依賴度的分析。我們說(shuō)依賴分兩種，強(qiáng)依賴和弱依賴。弱依賴要處理它，有一個(gè)異常出來(lái)的時(shí)候要把它干掉，不能把這個(gè)異常跑到最上面去，那整個(gè)服務(wù)就都掛掉了，但是大家并不知道到底它是弱依賴還是強(qiáng)依賴，這需要分析，我們?nèi)ソy(tǒng)計(jì)一下，它是一個(gè)強(qiáng)依賴還是弱依賴。然后弱依賴就可以做一些改進(jìn)，比如做一些異步調(diào)用，節(jié)省整個(gè)服務(wù)的調(diào)用時(shí)間，優(yōu)化用戶體驗(yàn)。
容量預(yù)警我們通過(guò)做一些大數(shù)據(jù)的分析，所有的指標(biāo)跟訂單量這些關(guān)聯(lián)，做一個(gè)相似度的分析，當(dāng)這些指標(biāo)偏離的時(shí)候，我們是不是可以認(rèn)為它的容量有問(wèn)題，當(dāng)然這是努力的方向。
容器方面我們也在做，系統(tǒng)叫 APPOS，有的服務(wù) CPU 只用了10%，但是我們規(guī)定了一臺(tái)服務(wù)器只能裝一個(gè)服務(wù)怎么辦，那就上容器吧。
蘭建剛：準(zhǔn)確度的確是個(gè)問(wèn)題，我們用了一個(gè)算法叫 3-sigma，準(zhǔn)確度還不是特別確定，因?yàn)檫@個(gè)東西真的是服務(wù)治理里面最大的難題，報(bào)警分級(jí)怎么分？這是很大的學(xué)問(wèn)，我們現(xiàn)在整個(gè)報(bào)警系統(tǒng)里面報(bào)警通道每天上千個(gè)報(bào)警，很多都不看的，因?yàn)橛X(jué)得這個(gè)報(bào)警沒(méi)什么意義。這是一個(gè)實(shí)際當(dāng)中要去調(diào)整的問(wèn)題。
蘭建剛：對(duì)，你要知道我們的業(yè)務(wù)有兩個(gè)明顯的尖峰，十二點(diǎn)和下午四五點(diǎn)的時(shí)候都是訂餐的高峰，之后則所有的指標(biāo)都會(huì)有下降趨勢(shì)的時(shí)候，如果你曲線偏離的很厲害就會(huì)引發(fā)報(bào)警。
多指標(biāo)聚合是我們正在做的，發(fā)生一個(gè)指標(biāo)報(bào)警的時(shí)候可能是一個(gè)小問(wèn)題，但是這個(gè)問(wèn)題會(huì)觸發(fā)一個(gè) CEP 的流程，比如“是不是 CPU 飆高的同時(shí)響應(yīng)時(shí)間會(huì)抖動(dòng)？”，我們可以定義這樣整個(gè)一套規(guī)則，去做報(bào)警來(lái)提高準(zhǔn)確度。
蘭建剛：當(dāng)然是底層的基礎(chǔ)服務(wù)了，我們不建議用 Go 寫(xiě)業(yè)務(wù)。為什么我們選 Go 做工具，是因?yàn)槲仪懊嫣岬剑驹瓉?lái)一些工具是搭在 Python 上，有一幫 Python 工程師，讓他去寫(xiě) Java 他是絕對(duì)不干的，但是讓他去寫(xiě) Go 語(yǔ)言是沒(méi)有問(wèn)題的，Python 其實(shí)不適合寫(xiě)底層框架，因?yàn)樗莻€(gè)動(dòng)態(tài)語(yǔ)言，工程化方面也會(huì)差一點(diǎn)。
蘭建剛：就是因?yàn)橛龅焦收狭?，因?yàn)楹芏喑瑫r(shí)配得很亂，有的同學(xué)直接配 3 秒超時(shí)（這是配置模版里的一個(gè)例子，很多同學(xué)就拿去直接用了），那還不如不配，有些情況很多服務(wù)就是 10ms 就正常返回了。只要保證這件事情對(duì)絕大部分的服務(wù)來(lái)說(shuō)，是有利可圖的，那我們就去做這件事情。
文章轉(zhuǎn)載請(qǐng)保留網(wǎng)址：http://16qt59sf.cn/news/industry/1747.html
