【51CTO.com原創(chuàng)稿件】許令波，花名君山，WOTA全球架構(gòu)與運(yùn)維技術(shù)峰會(huì)分享嘉賓，現(xiàn)任滴滴出行技術(shù)研究員，從事容器化和資源調(diào)度方面的技術(shù)建設(shè)，曾在淘寶工作七余載。在淘寶，基本經(jīng)歷網(wǎng)站PV從1到50億的增長(zhǎng)歷程、歷程中涉及端與管道、應(yīng)用層代碼級(jí)、應(yīng)用架構(gòu)和端到端等全鏈路的優(yōu)化，架構(gòu)方面從單個(gè)應(yīng)用到分布式、無(wú)線多端、中臺(tái)以及國(guó)際化的演進(jìn)。在當(dāng)前正處于發(fā)展階段的滴滴，這些歷史積累得到應(yīng)用實(shí)踐的同時(shí)也獲得很多新的經(jīng)驗(yàn)。

高可用架構(gòu)建設(shè)的挑戰(zhàn)：流量與業(yè)務(wù)復(fù)雜性

何為高可用？原則有三：故障監(jiān)測(cè)與排除、消除達(dá)點(diǎn)故障，互備和容災(zāi)。大流量網(wǎng)站的架構(gòu)建設(shè)最重要的挑戰(zhàn)來(lái)自流量與業(yè)務(wù)復(fù)雜性兩方面。

流量。高可用架構(gòu)首要應(yīng)對(duì)的是大流量且變動(dòng)復(fù)雜場(chǎng)景下的可用性問(wèn)題。故在建設(shè)過(guò)程中，架構(gòu)需要具備高伸縮性，能實(shí)現(xiàn)快速擴(kuò)展。讀Cache也是解決大流量帶來(lái)麻煩的手段。

業(yè)務(wù)復(fù)雜性。于網(wǎng)站而言，業(yè)務(wù)復(fù)雜性比流量帶來(lái)的挑戰(zhàn)要大，因除技術(shù)性問(wèn)題，還涉及人的因素。如整個(gè)業(yè)務(wù)流程沒(méi)經(jīng)過(guò)很好的整理，后續(xù)會(huì)帶來(lái)繁多且復(fù)雜的問(wèn)題。在網(wǎng)站建設(shè)過(guò)程中，一方面架構(gòu)上要做到分布式化，業(yè)務(wù)功能域要做到服務(wù)化，這樣可以保證架構(gòu)的高可用、高伸縮性。另一方面業(yè)務(wù)架構(gòu)與組織架構(gòu)要相匹配，網(wǎng)站流量逐漸增大同時(shí)組織架構(gòu)與業(yè)務(wù)架構(gòu)要隨之變化，相互匹配。反之，如在業(yè)務(wù)發(fā)展過(guò)程中，做系統(tǒng)變更會(huì)帶來(lái)一系列問(wèn)題：如開(kāi)發(fā)和發(fā)布效率會(huì)因?qū)懘a風(fēng)格和發(fā)布頻率（假設(shè)所有業(yè)務(wù)寫到同一系統(tǒng)）受到影響、如問(wèn)題排查找不到對(duì)應(yīng)的負(fù)責(zé)人等。

實(shí)踐：故障檢測(cè)與排除、分布式服務(wù)化改造和大流量系統(tǒng)高可用迭代

2011年，淘寶PV處于從1億到10億的PV階段，系統(tǒng)性能成為最大挑戰(zhàn)，針對(duì)大流量系統(tǒng)設(shè)計(jì)高可用的靜態(tài)化方案，應(yīng)用在詳情、購(gòu)物車以及秒殺系統(tǒng)中；參與雙11大促時(shí)，交易全鏈路進(jìn)行優(yōu)化，這些歷史積累在滴滴得到應(yīng)用實(shí)踐。滴滴在過(guò)去近一年時(shí)間做了三方面實(shí)踐：

一、      針對(duì)故障檢測(cè)，做了全平臺(tái)壓測(cè)

二、      針對(duì)業(yè)務(wù)快速增長(zhǎng)情況，對(duì)系統(tǒng)做分布式服務(wù)化改造

三、      大流量系統(tǒng)高可用迭代

故障檢測(cè)與排除——全平臺(tái)測(cè)壓。 壓測(cè)是全業(yè)務(wù)，全流程的壓測(cè)。在正常情況下制造線上系統(tǒng)的線上流量，也就是自己來(lái)攻擊自己系統(tǒng)，流量可自控。

產(chǎn)生流量的線上發(fā)壓平臺(tái)

如上圖，是產(chǎn)生流量的線上發(fā)壓平臺(tái)。和淘寶瀏覽某個(gè)商品行為相比，滴滴流量發(fā)起較復(fù)雜，涉及時(shí)間、地理位置等多維度。平臺(tái)有前臺(tái)Web系統(tǒng)、后臺(tái)服務(wù)系統(tǒng)和數(shù)據(jù)存儲(chǔ)三層。在測(cè)壓過(guò)程中，遇到一些問(wèn)題。如測(cè)試數(shù)據(jù)和線上數(shù)據(jù)如何區(qū)分開(kāi)？原則上是可寫在一起，但為避免帶來(lái)問(wèn)題，這里做了和正式表一樣的影子表，同庫(kù)不同表。如怎樣識(shí)別是在做壓測(cè)？用Trace來(lái)傳遞標(biāo)識(shí)，通過(guò)中間件傳遞，中間件不完善也可通過(guò)參數(shù)來(lái)做。

由于滴滴的數(shù)據(jù)和一般數(shù)據(jù)存在差異，全平臺(tái)壓測(cè)數(shù)據(jù)構(gòu)造要做特殊處理。發(fā)單時(shí)產(chǎn)生的當(dāng)前位置、目的地等數(shù)據(jù)都會(huì)回傳系統(tǒng)。這里會(huì)出現(xiàn)坐標(biāo)問(wèn)題，如用真實(shí)坐標(biāo)會(huì)干擾線上某些因素。故把坐標(biāo)偏移到太平洋，模擬端，把精度、緯度等也做偏移。虛擬乘客和司機(jī)，做ID偏移、手機(jī)號(hào)替換。

如下，這些都是在做全平臺(tái)測(cè)壓時(shí)，發(fā)現(xiàn)的問(wèn)題：

業(yè)務(wù)線

• 順風(fēng)車：接口耗時(shí)增長(zhǎng)，如列表頁(yè)面: 100ms => 700ms
• 順風(fēng)車：日志搜集的上傳服務(wù)夯死
• 專快：派單訪問(wèn)緩存出現(xiàn)超時(shí)
• 出租車：獲取司機(jī)接口觸發(fā)限流
• 出租車：派單單條日志量太大影響性能

基礎(chǔ)平臺(tái)

• NAT：2臺(tái)NAT啟動(dòng)無(wú)用的內(nèi)核模塊，流量大時(shí)大量丟包
• LBS：位置服務(wù)寫入超時(shí)，查周邊接口有超時(shí)
• 地圖：路徑規(guī)劃服務(wù)，到達(dá)容量瓶頸

壓測(cè)工具導(dǎo)致的其他問(wèn)題

• ?？煊?jì)算超時(shí)：由于工具問(wèn)題，司機(jī)和訂單陡增，km算法超時(shí)，主要是日志過(guò)多導(dǎo)致

典型的分布式架構(gòu)

分布式改造。如上圖，是典型的分布式架構(gòu)。最重要的接入層和服務(wù)層要做到服務(wù)的無(wú)狀態(tài)化，每個(gè)節(jié)點(diǎn)都需對(duì)等，因?yàn)檫@兩層主要做讀請(qǐng)求且請(qǐng)求量較大。做無(wú)狀態(tài)化是便于橫向擴(kuò)展，當(dāng)業(yè)務(wù)量大時(shí)，就可迅速部署機(jī)器來(lái)支撐流量。數(shù)據(jù)層大部分情況下都是有狀態(tài)的，需解決的是冗余和備份，MySQL要做存庫(kù)，能讀寫分離，能做故障切換。

分布式改造關(guān)鍵的技術(shù)點(diǎn)有三：分布式RPC框架、分布式消息框架和分布式配置框架。分布式RPC框架主要解決系統(tǒng)性關(guān)聯(lián)問(wèn)題，就是系統(tǒng)拆分，必須要解決系統(tǒng)之間的同步連接問(wèn)題 。分布式消息框架是解決系統(tǒng)間的數(shù)據(jù)關(guān)聯(lián)性，這是異步的，與RPC同步調(diào)用互補(bǔ)。分布式配置框架是解決[[191199]]狀態(tài)問(wèn)題，實(shí)際應(yīng)用中接入層和服務(wù)層也是有狀態(tài)的，最好做到無(wú)狀態(tài)。配置因?yàn)槊總€(gè)機(jī)器可能存在差異，故要通過(guò)中間件，把差異性放到配置框架中解決。

早期的滴滴系統(tǒng)架構(gòu)

去年，滴滴做了服務(wù)治理相關(guān)的事。如上圖，是早期的滴滴系統(tǒng)架構(gòu)，router接受層，到inrouter上層，中間有引入代碼。下面是Redis，本身是個(gè)代理。這里存在的問(wèn)題：上下游依賴硬編碼在代碼里；沒(méi)有使用inrouter/tgw的ip：Port；摘除和擴(kuò)容需要代碼重新上線，inrouter有網(wǎng)絡(luò)鏈路穩(wěn)定性隱患，以及效率上的損失；沒(méi)有清晰的服務(wù)目錄，API文檔以及SLA和監(jiān)控。

分布式RPC框架圖

如上是分布式RPC框架圖，目標(biāo)是把一些服務(wù)之間的調(diào)用能夠通過(guò)規(guī)范化方式串聯(lián)起來(lái)。上下游通過(guò)名字服務(wù)，從上游和下游端口解耦，名字服務(wù)需要在全公司統(tǒng)一且名字唯一。Naming服務(wù)就是做服務(wù)命名，服務(wù)注冊(cè)和發(fā)現(xiàn)，到注冊(cè)中心。RPC通道，部署私有協(xié)議，具備可擴(kuò)展性。服務(wù)路由與容災(zāi)，動(dòng)態(tài)路由，故障節(jié)點(diǎn)摘除。

這里需要提醒的是，目前滴滴技術(shù)棧還不統(tǒng)一，所以導(dǎo)致中間件會(huì)復(fù)雜一些，應(yīng)該最早期把技術(shù)棧統(tǒng)一，選擇Java或者Go等，可以避免后續(xù)的問(wèn)題。服務(wù)命名要規(guī)范，服務(wù)名自描述，要構(gòu)建統(tǒng)一服務(wù)樹(shù)。協(xié)議建議選擇私有RPC協(xié)議，為了效率和規(guī)范性。公有如http協(xié)議，測(cè)試方便，帶來(lái)方便性的同時(shí)也帶來(lái)的其他問(wèn)題，就是容易被濫用。服務(wù)路由建議是全局摘除， 像機(jī)器一旦不可用就通知上游，及時(shí)摘掉，但也有一定的風(fēng)險(xiǎn)。如網(wǎng)絡(luò)閃斷，下面機(jī)器全掛，會(huì)導(dǎo)致所有服務(wù)都不可用。所以需在全員鎮(zhèn)守情況下做全局確認(rèn)，不要拖著整個(gè)服務(wù)，要從上游做決策，再換個(gè)IP，重新做一次。

分布式服務(wù)化改造的大團(tuán)隊(duì)協(xié)作，從單業(yè)務(wù)系統(tǒng)做分布式改造的一個(gè)出發(fā)點(diǎn)就是解決大團(tuán)隊(duì)分工和協(xié)作問(wèn)題。代碼的分支拆分，減少代碼沖突，使得系統(tǒng)獨(dú)立，打包和發(fā)布效率都會(huì)提高；部署獨(dú)立，線上故障排查和責(zé)任認(rèn)定會(huì)更加明確。同時(shí)帶來(lái)的問(wèn)題是依賴的不確定性增加，性能上的一些損耗。像一次請(qǐng)求，如果一下調(diào)來(lái)七八個(gè)請(qǐng)求，這也會(huì)帶來(lái)一些問(wèn)題，所以這個(gè)過(guò)程要有一定的合理性，就是公司現(xiàn)在處于什么階段，現(xiàn)在需不需要拆分。所以系統(tǒng)、效率等方面要做一個(gè)平衡。

大流量系統(tǒng)的高可用迭代。大流量系統(tǒng)的架構(gòu)實(shí)現(xiàn)高可用的策略有部署帶有分組功能的一致性Hash的Cache、靜態(tài)內(nèi)容前置到CDN和熱點(diǎn)偵測(cè)等。

系統(tǒng)APS和服務(wù)層有五層代碼

如上圖，一個(gè)系統(tǒng)APS和服務(wù)層有五層代碼，通過(guò)水平擴(kuò)展加機(jī)器也解決不了問(wèn)題。在業(yè)務(wù)層，沒(méi)[[191200]]辦法做水平擴(kuò)展，必須做有狀態(tài)的變化，部署帶有分組功能的一致性Hash的Cache。

靜態(tài)內(nèi)容前置到CDN

如上圖，為了具備更大的伸縮性需要把靜態(tài)內(nèi)容前置到CDN。在服務(wù)端即使做擴(kuò)展，量還是有限，讀的請(qǐng)求，讀的數(shù)據(jù)往前推，最終推到CDN上。CDN體系比較多且有地域性，可抗百萬(wàn)級(jí)別的流量，但要解決冗余帶來(lái)的時(shí)效性、一致性的問(wèn)題。這樣做帶來(lái)的好處，除提高伸縮性，還節(jié)省帶寬，節(jié)點(diǎn)分散，可用性更高。這里提醒下，CDN可用性需要做評(píng)估，如不是自建，需要讓提供CDN的供應(yīng)商給出可用性指標(biāo)，避免后續(xù)維系困難。

[[191201]]

熱點(diǎn)偵測(cè)流程圖

如上圖，是熱點(diǎn)偵測(cè)流程圖。 前臺(tái)系統(tǒng)到后臺(tái)系統(tǒng)，整個(gè)請(qǐng)求是有鏈路的，一個(gè)請(qǐng)求從發(fā)起最終到服務(wù)端，到數(shù)據(jù)庫(kù)層中間需經(jīng)歷多層，過(guò)程中存在時(shí)間差，特定情況下，會(huì)有1-2秒延時(shí)。利用這一點(diǎn)，當(dāng)前端請(qǐng)求自導(dǎo)到接受層時(shí)，做實(shí)時(shí)熱點(diǎn)偵測(cè)，當(dāng)發(fā)現(xiàn)接收層發(fā)生變化，可及時(shí)通過(guò)認(rèn)證等手段對(duì)這個(gè)請(qǐng)求做標(biāo)記，把熱點(diǎn)數(shù)據(jù)記錄下來(lái)。之后，把熱點(diǎn)數(shù)據(jù)的信息通知下一個(gè)系統(tǒng)，這樣就可起到從上游系統(tǒng)發(fā)現(xiàn)問(wèn)題，保護(hù)下游的目的。當(dāng)發(fā)現(xiàn)某個(gè)請(qǐng)求特別熱時(shí)，提前對(duì)它做攔截。熱點(diǎn)數(shù)據(jù)通過(guò)實(shí)時(shí)發(fā)現(xiàn)，日志采集過(guò)來(lái)，做統(tǒng)計(jì)，然后把這個(gè)熱點(diǎn)數(shù)據(jù)再導(dǎo)到寫數(shù)據(jù)系統(tǒng)的后端系統(tǒng)cache中，這樣可保護(hù)后端的部分熱點(diǎn)系統(tǒng)。1%的熱點(diǎn)會(huì)影響99%的用戶，這種情況在電商是特別明顯的，如某個(gè)商品特別熱賣，商品請(qǐng)求流量占全網(wǎng)流量很大部分。且上屏容易產(chǎn)生單點(diǎn)，查數(shù)據(jù)庫(kù)時(shí)將定在同一機(jī)器。這樣很容易導(dǎo)致某個(gè)商品會(huì)影響整個(gè)網(wǎng)站的所有商品。所以要在數(shù)據(jù)庫(kù)做保護(hù)，如在本地做cache、服務(wù)層做本地cache、或者在數(shù)據(jù)庫(kù)層單獨(dú)做一個(gè)熱點(diǎn)庫(kù)等。

大流量系統(tǒng)的高可用迭代這里需要注意的點(diǎn)有熱點(diǎn)隔離、先做數(shù)據(jù)的動(dòng)靜分離、將99%的數(shù)據(jù)緩存在客戶端瀏覽器、將動(dòng)態(tài)請(qǐng)求的讀數(shù)據(jù)cache在web端、對(duì)讀數(shù)據(jù)不做強(qiáng)一致性校驗(yàn)、對(duì)寫數(shù)據(jù)進(jìn)行基于時(shí)間的合理分片、實(shí)時(shí)熱點(diǎn)發(fā)現(xiàn)、對(duì)寫請(qǐng)求做限流保護(hù)、對(duì)寫數(shù)據(jù)進(jìn)行強(qiáng)一致性校驗(yàn)等。

高可用架構(gòu)建設(shè)的經(jīng)驗(yàn)：體系化、積累和沉淀

通過(guò)多年的高可用架構(gòu)建設(shè)，這里有一些經(jīng)驗(yàn)值得分享。最大的體會(huì)就是需要做穩(wěn)定性體系化建設(shè)，包括建立規(guī)范和責(zé)任體系。其次就是工具要完善和體系化，以及需要配套的組織保障。

建議在責(zé)任體系的建設(shè)方面，公司一定每年都要制定高可用指標(biāo)（KPI）、故障等級(jí)也要明晰，影響多少客戶都要做描述、責(zé)任和榮耀體系也同等重要，這是個(gè)長(zhǎng)期且苦逼的事。 工具方面，要完善且體系化，做規(guī)范，做KPI，最終要做到工具化，通過(guò)工具化把流程、規(guī)范能固定。工具要體系化，像全機(jī)壓測(cè)，單機(jī)壓測(cè)等等都可做工具。

一個(gè)高可用架構(gòu)的建設(shè)，不是一朝一夕，需要各方面積累和沉淀，一定要注意以下三方面的處理流程：

關(guān)于變更：在變更之前必須制定回滾方案，涉及到對(duì)變更內(nèi)容設(shè)置開(kāi)關(guān)，出現(xiàn)問(wèn)題可快速通過(guò)開(kāi)關(guān)關(guān)閉新功能；接口變更、數(shù)據(jù)結(jié)構(gòu)變更、回滾要考慮第三方依賴，在變更之中出現(xiàn)問(wèn)題，第一時(shí)間回滾。

指導(dǎo)原則：將故障清晰描述和暴露出來(lái)，獲取第一手資料，找到問(wèn)題反饋源頭，解決問(wèn)題，消除故障同時(shí)找到對(duì)應(yīng)系統(tǒng)和業(yè)務(wù)的直接負(fù)責(zé)人。

處理流程：問(wèn)題發(fā)現(xiàn)后第一時(shí)間上報(bào)到“消防群、組建應(yīng)急處理小組、跨團(tuán)隊(duì)合作，通知到對(duì)方系統(tǒng)的負(fù)責(zé)人，P1故障要通知到客服與公關(guān)接口人，盡量做到集中辦公，問(wèn)題處理完畢，立即總結(jié)和制定改進(jìn)方案、系統(tǒng)TL負(fù)責(zé)，改進(jìn)方案的執(zhí)行情況。

以上內(nèi)容根據(jù)君山老師在WOTA2017 “高可用架構(gòu)”專場(chǎng)的演講內(nèi)容整理。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】