中國(guó)應(yīng)用性能管理行業(yè)盛宴—2017中國(guó)應(yīng)用性能管理大會(huì)（簡(jiǎn)稱APMCon 2017）于8月10日至11日在北京新云南皇冠假日酒店隆重召開。本屆APMCon是由聽云、極客邦和InfoQ聯(lián)合主辦，作為國(guó)內(nèi)APM領(lǐng)域最具影響力的技術(shù)大會(huì)，本次大會(huì)以“驅(qū)動(dòng)應(yīng)用架構(gòu)優(yōu)化與創(chuàng)新”為主題，致力于推動(dòng)APM在國(guó)內(nèi)的成長(zhǎng)與發(fā)展。
搜狐研發(fā)中心架構(gòu)師陳偉于大規(guī)模網(wǎng)絡(luò)架構(gòu)優(yōu)化專場(chǎng)發(fā)表了題為《搜狐服務(wù)架構(gòu)優(yōu)化實(shí)踐》的演講，現(xiàn)場(chǎng)解讀了搜狐過去幾年在后臺(tái)架構(gòu)優(yōu)化，微服務(wù)體系，用戶端連接優(yōu)化，監(jiān)控體系建設(shè)等方面的經(jīng)驗(yàn)和教訓(xùn)。
以下為演講實(shí)錄：
陳偉：大家下午好，非常高興能在這樣一個(gè)大會(huì)里，在位于中心環(huán)節(jié)的專場(chǎng)里第一個(gè)上臺(tái)給大家做展示。也希望我今天講的這些東西能給大家?guī)硎斋@，所以一會(huì)兒有什么問題，歡迎大家隨便來提問。
先自我介紹一下，我是2013年畢業(yè)，畢業(yè)后一直在搜狐工作。做的事情比較多、比較雜，也可以叫做全鏈工程師，除了這兩方面的以外也做過前端、App的開發(fā)，比較主要的項(xiàng)目都是集中在分布式后臺(tái)服務(wù)的領(lǐng)域。做過一些分布式存儲(chǔ)、分布式數(shù)據(jù)庫(kù)相關(guān)的工作。最近也還在繼續(xù)開發(fā)分布式對(duì)象存儲(chǔ)的系統(tǒng)，因?yàn)槲覀冏龊芏嚅_源的工作，未來也有可能有機(jī)會(huì)跟大家繼續(xù)介紹。在工作的這幾年中間做過比較長(zhǎng)時(shí)間的圖片和多媒體處理的工作，這是我今天后面會(huì)講到的優(yōu)化里面很重要的一環(huán)。因?yàn)樵趫D片領(lǐng)域，我們發(fā)現(xiàn)很多公司或者說業(yè)界的很知名的公司做的也都并沒有那么深入。我們?cè)谶@上面做了很多的工作，發(fā)現(xiàn)可以取得非常好的效果的。最近工作兩年主要集中在Docker相關(guān)的領(lǐng)域，我們自己開源了一套Docker的管理系統(tǒng)，后面也會(huì)有一些詳細(xì)的介紹。
一．目標(biāo)—效率
下面我們進(jìn)入今天的主要環(huán)節(jié)。我在搜狐這幾年其實(shí)也是在慢慢的摸索我們做工作的思路。最終總結(jié)下來，除了完成我們的基本工作之外，作為偏基礎(chǔ)架構(gòu)和服務(wù)端領(lǐng)域的方向上，比較核心的是四個(gè)目標(biāo)。我們所有優(yōu)化的工作，或者說我們額外的開發(fā)工作，其實(shí)都是圍繞這四個(gè)目標(biāo)來做的。穩(wěn)定性、效率、成本、安全。我在后面講的每個(gè)工作也都會(huì)圍繞這四個(gè)方面來說，每個(gè)工作都各有側(cè)重點(diǎn)。
首先看一下我們?cè)谛噬献龅念~外的工作。效率主要指的是用戶訪問的效率，當(dāng)然這本身也包括開發(fā)效率等等。對(duì)于用戶訪問來講，我們最直觀的感受就是快。今天上午所有的議題,老師們講的都是怎么能夠讓服務(wù)變得更快，或者說怎么發(fā)現(xiàn)它變慢了。對(duì)于搜狐來講，是因?yàn)樗押旭R上20年了。所以經(jīng)歷了很多代的技術(shù)的演化。在早期技術(shù)上，是沒有各種云的技術(shù)情況。所以搜狐自己在全國(guó)有20多家的數(shù)據(jù)中心，自己有全國(guó)的光纖網(wǎng)絡(luò)等等。在接入層這塊可能會(huì)跟其他很多公司做的不一樣，因?yàn)楫?dāng)你公司有云技術(shù)的時(shí)候，可以來解決問題，但量達(dá)到一定程度的時(shí)候，還是要關(guān)心很多這方面的工作。接下來我們會(huì)重點(diǎn)介紹一下最近幾年如何讓用戶的訪問變得更快。最核心的就是接入層這塊的優(yōu)化。
對(duì)接入層這方面來講沒什么太多的秘密，最核心的一點(diǎn)就是離用戶越近越好。就像你追女朋友一樣，如果說一個(gè)單位的，天天見是最容易搞定的。如果是一個(gè)城市機(jī)會(huì)也是蠻大。但假設(shè)是異地，難度就要大很多。換做是異國(guó)的話很可能就要分手了。所以說我們的服務(wù)也是這樣的。你如果不能時(shí)時(shí)刻刻離用戶更近，用戶就把你拋棄了。這也是我們優(yōu)化的一個(gè)總體思路。
在我們?nèi)珖?guó)有很多的IDC機(jī)房的情況下，最重要的一點(diǎn)就是怎么樣準(zhǔn)確的來發(fā)現(xiàn)讓哪個(gè)用戶該訪問哪個(gè)節(jié)點(diǎn)。所以在自有節(jié)點(diǎn)的流量調(diào)度方面我們做了特別多的工作，里面比較難的是發(fā)現(xiàn)用戶真實(shí)的位置。因?yàn)樵趥鹘y(tǒng)上大家的做法通常就是根據(jù)整個(gè)DNS的體系來做調(diào)度，里面比較麻煩的問題就是用戶設(shè)置的DNS，或者說運(yùn)營(yíng)商的DNS并不一定能真實(shí)的反映用戶實(shí)際所處的網(wǎng)絡(luò)情況。而且很多運(yùn)營(yíng)商的DNS會(huì)有各種各樣的問題。在最近，DNS的協(xié)議會(huì)幫我們把流量調(diào)度做得更加精準(zhǔn)。因此我們做了很多的升級(jí)，我們自己的DNS系統(tǒng)，以及第三方的DNS系統(tǒng)會(huì)更多的采用這樣的方式，準(zhǔn)確發(fā)現(xiàn)用戶的IP，做更準(zhǔn)確的調(diào)度。包括采用一些更精準(zhǔn)的IP庫(kù)。因?yàn)橐恍╅_放的IP庫(kù)可能效果并沒有那么好，而這點(diǎn)根據(jù)我們的實(shí)際檢驗(yàn)發(fā)現(xiàn)，當(dāng)你把IP庫(kù)做得更精準(zhǔn)之后，這個(gè)效果的提升是非常明顯的。除了國(guó)內(nèi)之外我們還有世界范圍內(nèi)調(diào)度的方案。
搜狐在過去的十幾年里面一直都是采用自己的IDC的方案。但是最近幾年大家也能看到公有的CDN發(fā)展的非?？欤_實(shí)這種公有的CDN在某些領(lǐng)域有非常大的優(yōu)勢(shì)，尤其是標(biāo)準(zhǔn)化的圖片訪問，或者流媒體的訪問上面有很多的優(yōu)勢(shì)。所以我們也是結(jié)合了自建的CDN和第三方CDN混合的方式。這里面最主要的核心是調(diào)度問題。因?yàn)樵谟枚嗉褻DN的時(shí)候調(diào)度問題更麻煩。比如說你同時(shí)有幾個(gè)女朋友分布在幾個(gè)城市里，這時(shí)候你去哪個(gè)城市的時(shí)候，就可以和哪個(gè)女朋友在一起。如果去了A城市聯(lián)系B城市的女朋友，可能就會(huì)出現(xiàn)一些問題。這就是說當(dāng)你用多家CDN的時(shí)候，可能會(huì)導(dǎo)致的不好的情況。在這種架構(gòu)下我們做的很重要的工作就是跟第三方CDN結(jié)合的更緊密。我們能拿到他們?cè)嫉墓?jié)點(diǎn)的位置，以及我們通過自己客戶端的方案。包括第三方，像聽云這樣的方案，來發(fā)現(xiàn)每一個(gè)位置或者說每一種網(wǎng)絡(luò)環(huán)境下，哪個(gè)CDN的效果更好，還是說我們自己的CDN效果更好，來做這樣的一種調(diào)度。當(dāng)然這個(gè)調(diào)度本身是非常復(fù)雜的，因?yàn)樗还馐且鶕?jù)效果來看，也要根據(jù)一些CDN容量規(guī)劃等等。來做這樣的一些策略。總體上我們目前已經(jīng)形成了一個(gè)比較完善的、融合的CDN方案。
這套方案本身還是基于DNS的方案，依然不夠精準(zhǔn)。那我們接下來需要做得更加精確。在App的應(yīng)用里面自主性比Web應(yīng)用強(qiáng)的多。當(dāng)一個(gè)域名可以解析很多不同的CDN廠商的服務(wù)器上，你可以自主的探測(cè)速度，再結(jié)合服務(wù)器給的策略，綜合的選擇一個(gè)你認(rèn)為最優(yōu)的策略來訪問。這是一個(gè)非常有意思的一種做法。但是局限性比較大，除了在App里面都不好用，在Web環(huán)境下比較難以做到這點(diǎn)。另外這個(gè)調(diào)度還是比較復(fù)雜的，因?yàn)槎嗉褻DN的情況下，包括你的容量的規(guī)劃，你的價(jià)格因素等等，考慮在內(nèi)，就會(huì)非常麻煩。所以這還是局限在一些量比較大，然后比較核心的App圖片或者說視頻這種標(biāo)準(zhǔn)的CDN訪問的情況下，我們會(huì)采用一些這樣的策略。
上面所有的策略都離不開一點(diǎn)，就是首先要對(duì)整個(gè)全網(wǎng)的環(huán)境和真實(shí)的數(shù)據(jù)有所了解。我們花了比較大的精力做這樣一監(jiān)控系統(tǒng)，數(shù)據(jù)源并不源自于我們自己，也包括了第三方的監(jiān)測(cè)機(jī)構(gòu)提供的原始數(shù)據(jù)。這些數(shù)據(jù)不只用來做這個(gè)，后面的很多工作都是依賴于這些原始數(shù)據(jù)。我們利用這些原始數(shù)據(jù)制作出來這樣的全網(wǎng)的品質(zhì)監(jiān)控圖，是我們后面做流量調(diào)度最核心的依據(jù)。
像這樣的一些流量調(diào)度之外，還有一些要注意的，我們會(huì)做很多服務(wù)分層的一些工作。包括你的機(jī)房的品質(zhì)，帶寬的質(zhì)量不同。不可能視頻的加載全部都用最貴的方式來解決，這樣成本太高。所以我們會(huì)針對(duì)每個(gè)服務(wù)不同的特性。比如說你DNS節(jié)點(diǎn)，需要訪問的足夠高效。對(duì)于動(dòng)態(tài)請(qǐng)求，通常來說量不大，帶寬不大，請(qǐng)求更頻繁。大多數(shù)公司的方案是經(jīng)過一些路由的選擇，或者說直接就來訪問你全國(guó)的一個(gè)或者兩個(gè)節(jié)點(diǎn)。這種情況是方案來服務(wù)的。實(shí)際上之前我們也一直是這樣做的。但是因?yàn)槎荚谡?qǐng)求，本身確實(shí)比較麻煩。所以在我們后面使用Docker的方案之后，我們開始逐漸的把一些動(dòng)態(tài)請(qǐng)求盡量的推進(jìn)用戶。這個(gè)思路還是剛才說的離用戶越近越好。動(dòng)態(tài)請(qǐng)求沒有辦法完全利用CDN的能力，就只能在自建的核心節(jié)點(diǎn)上盡量的把一些用戶的動(dòng)態(tài)請(qǐng)求就地解決掉。但這個(gè)工作相對(duì)來說難度比較大，因?yàn)樯婕暗椒?wù)的部署，你的數(shù)據(jù)庫(kù)的同步，或者緩存的同步。所以目前的應(yīng)用時(shí)間還不能做到完全把動(dòng)態(tài)請(qǐng)求推到離用戶更近的地方。而是采用一些，比如說能在緩存層解決掉的，我們就分布在幾個(gè)比較主要的機(jī)房解決，無法解決掉的還是在核心機(jī)房做處理。所以我們做這些工作是完全跟業(yè)務(wù)部門來探討這個(gè)方案，定制化出來的。
除了前面說的離用戶越近越好之外，當(dāng)然也有別的手段能夠去優(yōu)化。因?yàn)椴煌娜烁笥延貌煌姆绞饺ソ涣鞯臅r(shí)候，自然效果也不一樣，你們之間是寫信還是發(fā)微信，這自然也不一樣。
所以在協(xié)議層可做的優(yōu)化空間也是比較多的。近幾年最核心的優(yōu)化比較大的就是SPDY協(xié)議和http2協(xié)議的工作。從我們的監(jiān)控?cái)?shù)據(jù)來發(fā)現(xiàn)，整個(gè)的響應(yīng)，大概的數(shù)據(jù)來講，響應(yīng)延遲能做到原來普通延遲的幾分之一，這是采樣的數(shù)據(jù)。有了這樣一個(gè)性能的提升之后。當(dāng)然這個(gè)性能提升并不是說我直接用上這個(gè)方案就OK，它依賴于很多你的頁(yè)面里面自主做一些適應(yīng)協(xié)議的工作。之前做Web的很多工作，是把域名打散。因?yàn)闉g覽器有并發(fā)的限制這樣子，所以會(huì)把很多的圖片放在很多的域名下，但這樣的頁(yè)面布局方式是在http2的協(xié)議里面的，我們非常不推薦。所以我們會(huì)改進(jìn)這個(gè)工作，之后會(huì)把域名的分布方式改進(jìn)。效果就會(huì)非常明顯。httpS的兼容性整體上不錯(cuò)，但是在Web端依然有很多老牌的瀏覽器不能很好的兼容。
接下來其實(shí)是一些比較小的工作，像httpS證書選擇就是隱藏的坑。大部分人不會(huì)注意到不同。但我發(fā)現(xiàn)不同的httpS證書也會(huì)有差距，其中有的多一層中間CA的時(shí)候，握手時(shí)間能差到20毫秒的水平上。所以當(dāng)你對(duì)性能有更高要求的時(shí)候要舍得在這些東西上面花錢。
影響再小一點(diǎn)的就是底層的優(yōu)化工作，像TCP參數(shù)的優(yōu)化，網(wǎng)上已經(jīng)有大量的推薦的參數(shù)配置，目前已經(jīng)比較成熟了。不過在線上應(yīng)用里沒有辦法拿到那么好的數(shù)據(jù)，但確實(shí)是有提升的。我們嘗試在跨數(shù)據(jù)中心的數(shù)據(jù)同步里面，我們會(huì)嘗試用UDP的方式做這樣的工作。所以大家正常的開發(fā)接觸的主要都是TCP。另外也應(yīng)該關(guān)注一下更底層的協(xié)議優(yōu)化，可能會(huì)帶來意想不到的效果。
這塊不能叫接入層的優(yōu)化，但是在我們的架構(gòu)里面，圖片最終對(duì)外的訪問不是由業(yè)務(wù)的提供端給出的，而是我們本身的圖片平臺(tái)或者多媒體平臺(tái)提供服務(wù)的，也能看做接入層。這個(gè)影響是非常巨大的，而且改起來是非常容易的。很多網(wǎng)站慢的原因就是圖片太大了。在格式壓縮上，JPG壓縮的圖能再減少30%、40%，依然對(duì)用戶的感官上沒有任何變化。
這三張圖看不出區(qū)別來，但是經(jīng)過我們壓縮之后的圖片的效果能小到30%左右。還有Webp格式，我覺得目前已經(jīng)有很多的公司在使用這個(gè)方式了。尤其在App端，webp做得比較好的。令我們頭疼的是既符合PNG的圖，又會(huì)加載慢、耗費(fèi)用戶流量的大戶。稍微比一下，一個(gè)差不多質(zhì)量的PNG要比JPG大很多，而傳統(tǒng)上的這兩種壓縮，對(duì)圖片的效果都不明顯。我們是自己在很底層的PNG庫(kù)里做很多的工作，包括GIF的壓縮也是因?yàn)樵诙鄮臅r(shí)候沒有做相關(guān)性的關(guān)系。這是相對(duì)比較底層的優(yōu)化。在最早的時(shí)候我們GIF做這樣的工作，把GIF圖轉(zhuǎn)成MP4或者WebM都比GIF要小。但當(dāng)我們做過這樣的工作之后，其實(shí)GIF圖也可以流暢的在互聯(lián)網(wǎng)上使用。
視頻的壓縮指的不是搜狐視頻，因?yàn)槲覀兏麄兊募夹g(shù)體系相對(duì)來說不是完全在一起的。但是大家會(huì)發(fā)現(xiàn)像新聞客戶端，包括各種新聞網(wǎng)站等等，里面的視頻已經(jīng)非常多了。信息流視頻通常來說比較短，在業(yè)務(wù)線不付出額外努力的情況下，我們做很多多碼率自動(dòng)的轉(zhuǎn)化，以及這種選擇，幫助業(yè)務(wù)線使用更少的帶寬和更流暢的速度獲得這樣的效果。
二．目標(biāo)—穩(wěn)定
效率這部分講完了，然后講一下我們?cè)谔嵘麄€(gè)的后臺(tái)服務(wù)穩(wěn)定性上面做的工作。平臺(tái)化是我們這一段時(shí)間來說優(yōu)化平臺(tái)服務(wù)的一個(gè)思路。搜狐跟其他很多公司不一樣，很多公司其實(shí)是由一個(gè)業(yè)務(wù)起家，所有的工作圍繞這樣一個(gè)業(yè)務(wù)來展開。比如說摩拜單車，肯定所有的業(yè)務(wù)都是跟單車業(yè)務(wù)相關(guān)的，慢慢的往外延伸。不管是發(fā)紅包還是做活動(dòng)、會(huì)員卡，都是這個(gè)相關(guān)的業(yè)務(wù)，所以是非常集中式的。而搜狐已經(jīng)有十幾年的歷史的情況下，做了大量的，各種各樣的工作?？赡苣阋姷竭^的互聯(lián)網(wǎng)的業(yè)務(wù)，搜狐都做過。不管是電商、社交、視頻、搜索，所有的都做過。而且每一次做都是處于不同的歷史時(shí)期。技術(shù)發(fā)展確實(shí)比較快，每隔幾年可能技術(shù)棧就完全過時(shí)了。一些工作實(shí)際上采用了不同的技術(shù)棧開發(fā)，導(dǎo)致我們后面很多的優(yōu)化工作無法展開。同時(shí)也是因?yàn)檫@樣的一些體系，實(shí)際上在內(nèi)部每一個(gè)業(yè)務(wù)部門都相對(duì)比較獨(dú)立，沒有全公司的集中式的應(yīng)用運(yùn)維的管理，運(yùn)維體系更多的是做基礎(chǔ)運(yùn)維。在這樣的歷史項(xiàng)目的前提下，整個(gè)的技術(shù)?；蛘哒f我們?cè)趦?yōu)化性能方面要做的工作非常多，而且不容易做好。
平臺(tái)化就把基礎(chǔ)工作抽離開，除了寫代碼，很多的工作都浪費(fèi)在持續(xù)集成、隊(duì)列、做分析、日收集、做報(bào)表、監(jiān)控，其實(shí)后臺(tái)服務(wù)這些工作基本都要做。確實(shí)每個(gè)業(yè)務(wù)會(huì)有自己獨(dú)特的特點(diǎn)，但是大同小異的。所以我們用平臺(tái)化的方式來盡量降低業(yè)務(wù)線的負(fù)擔(dān)。之前很多公司也都提過，把中間層的業(yè)務(wù)做得更厚，業(yè)務(wù)線可以更輕量級(jí)的開發(fā)。能幾個(gè)星期上線一個(gè)業(yè)務(wù)，更多的趕上浪潮。所以這也是我們必然需要做的工作。我們?cè)谧罱鼛啄昀锇褦?shù)據(jù)庫(kù)、redis集群、對(duì)象存儲(chǔ)、圖片處理、視頻處理、抓取服務(wù)、大數(shù)據(jù)服務(wù)、隊(duì)列服務(wù)、監(jiān)控報(bào)警等等，把這些業(yè)務(wù)做成云化的方式，在公司內(nèi)提供的私有云的方式，然后業(yè)務(wù)線能夠比較簡(jiǎn)單的用起來。
由于跟其他很多公司不一樣，很多公司做單一業(yè)務(wù)是比較容易做到這點(diǎn)的，因?yàn)榈谝粋€(gè)業(yè)務(wù)來把這個(gè)redis，把大數(shù)據(jù)的組件，或者說把隊(duì)列都建好了，其他圍繞它的業(yè)務(wù)就一起來用就好了。搜狐的不同點(diǎn)是在于他本身有很多的項(xiàng)目是相互獨(dú)立開的，我們花了很多的精力讓這些組件適應(yīng)這些語(yǔ)言的開發(fā)，各種各樣的模式，能夠兼容它們，所以會(huì)做得更像云一點(diǎn)。
簡(jiǎn)單講幾點(diǎn)，對(duì)象存儲(chǔ)實(shí)際上是之前比較花大精力的工作，是從我入職開始重點(diǎn)做的工作。我們從底層系統(tǒng)開始是自己搭建的，目前也已經(jīng)有數(shù)百億的文件級(jí)別，能存儲(chǔ)在這個(gè)平臺(tái)上來提供訪問十幾PB的小圖片。這和傳統(tǒng)的KV不太一樣，我們這套系統(tǒng)更多的是能夠直接和CDN廠商，包括前面說的多CDN的選擇，和圖片處理以及視頻處理完美的融合在一起。這也是所有的業(yè)務(wù)線用的最爽的平臺(tái)，當(dāng)業(yè)務(wù)線要做一個(gè)社交系統(tǒng)的時(shí)候，讓用戶上傳一張照片，然后要分發(fā)給各種平臺(tái)下的用戶，涉及到的工作其實(shí)用這個(gè)平臺(tái)完全自動(dòng)都解決了。你上傳圖片的時(shí)候設(shè)定一個(gè)URL把這張圖片傳上來，你可以用不同的格式來取，自動(dòng)的幫你轉(zhuǎn)化好，用戶用的是什么網(wǎng)絡(luò)，用哪家CDN，都由中間的平臺(tái)層處理掉的。如果用戶上傳的是個(gè)視頻，比如說有些iPhone拍的視頻在Android上播放會(huì)有問題，可以做轉(zhuǎn)碼，轉(zhuǎn)成不同的分辨率。甚至原來是一個(gè)MOV或者M(jìn)P4的視頻，可以轉(zhuǎn)成HRS的方式，通過流媒體的方式播放出去。所以已經(jīng)不完全是一個(gè)對(duì)象存儲(chǔ)平臺(tái)，它實(shí)際上是以對(duì)象存儲(chǔ)為支撐的多媒體加圖片，加分發(fā)的綜合的處理平臺(tái)。這樣的平臺(tái)對(duì)業(yè)務(wù)線的開發(fā)速度幫助是非常大的。其實(shí)現(xiàn)在也有很多的公有云提供類似的服務(wù)。
像Redis集群，Redis基本上在一半的業(yè)務(wù)里面都會(huì)用到Redis緩存。所以我們?cè)诠緝?nèi)通過Docker資源的分配方式，并且自助化的申請(qǐng)平臺(tái)，直接在頁(yè)面上自動(dòng)申請(qǐng)，自動(dòng)分配。把這種訪問方式包括密鑰，包括IP的限制下發(fā)給用戶，用戶就可以使用了。之前我們通常用的方式是工單，并不是云化的平臺(tái)，用工單會(huì)有很多的問題，包括時(shí)效性等等。當(dāng)我們用云平臺(tái)的時(shí)候，我們發(fā)現(xiàn)業(yè)務(wù)現(xiàn)在開發(fā)效率提高了很多，整個(gè)的穩(wěn)定性也會(huì)好很多。
另外大數(shù)據(jù)平臺(tái)服務(wù)，我們把很多的數(shù)據(jù)標(biāo)準(zhǔn)化之后，當(dāng)業(yè)務(wù)線需要一些數(shù)據(jù)的時(shí)候，甚至是非技術(shù)人員，不知道什么叫表的一些人，也能夠順利的在里面去查數(shù)。大數(shù)據(jù)部門通常干的最多的事情就是查數(shù)。這樣的話就能夠方便大家一起來查數(shù)。像監(jiān)控報(bào)警就是剛才說的，我們提供了一套完整的，當(dāng)業(yè)務(wù)部署上去能夠更容易的進(jìn)行這種監(jiān)控報(bào)警的準(zhǔn)備。
三．目標(biāo)—成本
后面的一塊工作，這就是我們自己研發(fā)的DomeOS的系統(tǒng)，歡迎大家提問題。這套系統(tǒng)是基于開源的部署系統(tǒng)。這個(gè)平臺(tái)下面我們能夠完整的完成業(yè)務(wù)的上線，回滾，服務(wù)的配置，跨機(jī)房的應(yīng)用，以及持續(xù)集成，監(jiān)控報(bào)警，把剛才說的很多的工作在這個(gè)平臺(tái)下都可以自動(dòng)完成。當(dāng)代碼提交之后，剩下的事情都可以標(biāo)準(zhǔn)化來完成。這項(xiàng)工作的主要作用可能不僅僅體現(xiàn)在對(duì)于我們線上環(huán)境的變化，很大程度的規(guī)范了整個(gè)公司開發(fā)的行為，以及解決的很多歷史遺留問題。在我們使用Docker的部署方式之后所有的應(yīng)用都是動(dòng)態(tài)部署，資源利用率大大提高。資源利用率的程度非常高，會(huì)更容易拓展我們的業(yè)務(wù)。
我們最近萬年不變的搜狐主頁(yè)已經(jīng)改版了，包括手機(jī)搜狐網(wǎng)的改版，或者說焦點(diǎn)的改版。
這幾次改版主要的工作都是依賴于這套系統(tǒng)，所有的應(yīng)用都已經(jīng)跑在Docker上面了。這個(gè)流程里面業(yè)務(wù)線要做的只是把開發(fā)測(cè)試完成好，發(fā)布就是在界面上，測(cè)試環(huán)節(jié)正式發(fā)布。運(yùn)維監(jiān)控我們也做了很多的自動(dòng)工作，基礎(chǔ)的數(shù)據(jù)收集就不用說了，業(yè)務(wù)的內(nèi)存泄露等等不需要用戶配置，都可以簡(jiǎn)單的提醒用戶。作為這樣的一套系統(tǒng)覆蓋了包括集群管理的工作。同時(shí)還有日志分析，很多的業(yè)務(wù)自然都會(huì)把一些問題打到日志里面來。我們直接會(huì)把所有的業(yè)務(wù)日志，不管是控臺(tái)的還是寫到文件里，收集到ELK里面去，你要搜索日志都可以。還可以進(jìn)行關(guān)鍵詞匹配報(bào)警。這些業(yè)務(wù)之前都是要單獨(dú)做的，或者因?yàn)闆]有做這些工作都會(huì)導(dǎo)致線上的故障。在DomeOS這個(gè)系統(tǒng)里可以輕松的完成，也是延續(xù)我們平臺(tái)的思路，我們把整個(gè)公司能通用起來的業(yè)務(wù)做成智能組件，來避免業(yè)務(wù)線亂搞，就是這個(gè)意思。
大概來說一下幾個(gè)核心的模塊，日志收集加分析的工作實(shí)際上大概就是這樣的流程。首先App因?yàn)檫\(yùn)行在Docker里面，它的控制臺(tái)日志我們非常容易收集，打到文件里的日志會(huì)要求它在上線之前做配置，你要寫哪個(gè)文件，我們會(huì)把這個(gè)文件放到本地的磁盤里。然后收集走所有對(duì)套的路線。Kafka是個(gè)萬金油插件，所有的處理都沒有問題。我們的界限有到這一層，從Kafka出來之后業(yè)務(wù)線想做更多的工作也有足夠的能力。而且剛才也說我們有大數(shù)據(jù)平臺(tái)，我們可以很容易的把這些數(shù)據(jù)自動(dòng)導(dǎo)到大數(shù)據(jù)平臺(tái)。
負(fù)載均衡和服務(wù)發(fā)現(xiàn)，是大家用Docker里面容易遇到的一些問題，因?yàn)镈ocker之所以說沒有簡(jiǎn)單的用起來，很多時(shí)候都是因?yàn)樨?fù)載均衡服務(wù)發(fā)現(xiàn)不是特別好做，我們做了很多的工作。七層的代理我們?nèi)坑肗ginx來完成，因?yàn)閯?dòng)態(tài)部署的，所以每個(gè)容器所在的位置隨時(shí)會(huì)變，當(dāng)它變了之后新的IP信息會(huì)通過Nginx指導(dǎo)。同時(shí)我們?cè)贜ginx上可以做很多的服務(wù)分析，比如說你的響應(yīng)時(shí)間長(zhǎng)，用Nginx做是最合適的。如果是微服務(wù)架構(gòu)的，在容器內(nèi)要做很多訪問交互的時(shí)候，我們也可以部署注冊(cè)中心，可以點(diǎn)對(duì)點(diǎn)直接來訪問。
監(jiān)控報(bào)警不多說了，主要都是利用外部插件做的組合。我們之前這個(gè)方案也變過很多次。（英）這部分工作沒有必要完全自己開發(fā)，有很多不錯(cuò)的開源項(xiàng)目可供選擇，難點(diǎn)是如何和業(yè)務(wù)結(jié)合的更好，以及擴(kuò)展性和易用性的平衡。
這些是我們實(shí)際做的工作，用Docker不是說把原來的業(yè)務(wù)遷移到Docker里面跑起來就行，我們不追求覆蓋的速度。我們更希望在這個(gè)過程中幫助業(yè)務(wù)線梳理他們的工作。在未來規(guī)范化是我們最關(guān)心的，當(dāng)把整個(gè)體系規(guī)范化之后，未來的工作會(huì)好做很多。同時(shí)我們?cè)谧鲆恍┗贕RPC更好的服務(wù)發(fā)現(xiàn)體系，如果未來這塊有更好的進(jìn)展可以再跟大家分享。
四·目標(biāo)--安全
最后簡(jiǎn)單說一下我們最近面臨的一些問題。劫持相關(guān)的一些工作，這對(duì)我們的困擾是比較大的。原理就不多說了，有DNS劫持，也有小區(qū)寬帶接入層的劫持，主要影響的就是插廣告，插的都是很low的廣告，用戶會(huì)以為是搜狐家的，其實(shí)并不是。整個(gè)的服務(wù)的可控性也不行，比如說我們改版升級(jí)等等，因?yàn)樗慕俪謱?dǎo)致我們的改版不能很順利的確保用戶能看到。我們的解決方案就兩個(gè)，一個(gè)是監(jiān)控，更好更快的利用全國(guó)的布點(diǎn)發(fā)現(xiàn)監(jiān)控問題，比如說解析結(jié)果不對(duì)了，不是我們自己的IP，或者說訪問的頁(yè)面里面內(nèi)嵌了我們不認(rèn)識(shí)的JS。解決方案就沒什么太多的，最有用的還是投訴和協(xié)調(diào)，去跟運(yùn)營(yíng)商扯皮，能解決大部分的問題。
像小區(qū)寬帶這種插廣告的時(shí)候是通過httpS來解決，不能大規(guī)模遷移過來，但也解決的比較好。像httpDNS可以很好的解決用戶的DNS劫持的問題，當(dāng)然這也有很大的局限性。我們前面的用戶主動(dòng)選擇節(jié)點(diǎn)的方案就是使用httpDNS為基礎(chǔ)來做，比較大的問題就是只能在App里面用。同時(shí)也還是有一些對(duì)業(yè)務(wù)開發(fā)的侵入性等的工作。反劫持這塊不說太多了，httpDNS大家有興趣可以參考業(yè)界比較好的框架。
轉(zhuǎn)型的最終目的 -提質(zhì)降本增效
分享到微信 ×
打開微信，點(diǎn)擊底部的“發(fā)現(xiàn)”，
使用“掃一掃”即可將網(wǎng)頁(yè)分享至朋友圈。