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

高可用架構建設的挑戰：流量與業務復雜性

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

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

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

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

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

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

二、      針對業務快速增長情況，對系統做分布式服務化改造

三、      大流量系統高可用迭代

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

產生流量的線上發壓平臺

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

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

如下，這些都是在做全平臺測壓時，發現的問題：

業務線

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

基礎平臺

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

壓測工具導致的其他問題

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

典型的分布式架構

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

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

早期的滴滴系統架構

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

分布式RPC框架圖

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

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

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

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

系統APS和服務層有五層代碼

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

靜態內容前置到CDN

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

[[191201]]

熱點偵測流程圖

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

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

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

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

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

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

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

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

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

以上內容根據君山老師在WOTA2017 “高可用架構”專場的演講內容整理。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】