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

高可用架構建設的挑戰(zhàn)：流量與業(yè)務復雜性

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

流量。高可用架構首要應對的是大流量且變動復雜場景下的可用性問題。故在建設過程中，架構需要具備高伸縮性，能實現(xiàn)快速擴展。讀Cache也是解決大流量帶來麻煩的手段。

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

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

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

一、      針對故障檢測，做了全平臺壓測

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

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

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

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

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

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

如下，這些都是在做全平臺測壓時，發(fā)現(xiàn)的問題：

業(yè)務線

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

基礎平臺

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

壓測工具導致的其他問題

• 專快計算超時：由于工具問題，司機和訂單陡增，km算法超時，主要是日志過多導致

典型的分布式架構

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

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

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

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

分布式RPC框架圖

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

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

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

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

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

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

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

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

[[191201]]

熱點偵測流程圖

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

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

高可用架構建設的經(jīng)驗：體系化、積累和沉淀

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

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

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

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

指導原則：將故障清晰描述和暴露出來，獲取第一手資料，找到問題反饋源頭，解決問題，消除故障同時找到對應系統(tǒng)和業(yè)務的直接負責人。

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

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

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