作者介紹

許令波，花名君山，現(xiàn)任滴滴出行技術(shù)研究員，從事容器化和資源調(diào)度方面的技術(shù)建設(shè)。曾在淘寶工作七余載，經(jīng)歷了淘寶網(wǎng) PV 從 1 到 50 億的增長歷程。其中涉及端與管道、應(yīng)用層代碼級、應(yīng)用架構(gòu)和端到端等全鏈路的優(yōu)化，架構(gòu)方面從單個應(yīng)用到分布式、無線多端、中臺以及國際化的演進。這些積累的經(jīng)驗同時也在滴滴得到應(yīng)用實踐。

挑戰(zhàn)

高可用架構(gòu)建設(shè)的

流量與業(yè)務(wù)復(fù)雜性

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

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

• 業(yè)務(wù)復(fù)雜性。 于網(wǎng)站而言，業(yè)務(wù)復(fù)雜性比流量帶來的挑戰(zhàn)要大，因除技術(shù)性問題，還涉及人的因素。如整個業(yè)務(wù)流程沒經(jīng)過很好的整理，后續(xù)會帶來繁多且復(fù)雜的問題。

在網(wǎng)站建設(shè)過程中， 一方面 架構(gòu)上要做到分布式化，業(yè)務(wù)功能域要做到服務(wù)化，這樣可以保證架構(gòu)的高可用、高伸縮性。 另一方面 業(yè)務(wù)架構(gòu)與組織架構(gòu)要相匹配，網(wǎng)站流量逐漸增大的同時組織架構(gòu)與業(yè)務(wù)架構(gòu)要隨之變化，相互匹配。

反之，如在業(yè)務(wù)發(fā)展過程中，做系統(tǒng)變更會帶來一系列問題。如開發(fā)和發(fā)布效率會因?qū)懘a風(fēng)格和發(fā)布頻率（假設(shè)所有業(yè)務(wù)寫到同一系統(tǒng)）受到影響；問題排查找不到對應(yīng)的負責(zé)人等。

實踐

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

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

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

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

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

故障檢測與排除——全平臺測壓

壓測是全業(yè)務(wù)，全流程的壓測。在正常情況下制造線上系統(tǒng)的線上流量，也就是自己來攻擊自己系統(tǒng)，流量可自控。

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

如上圖，是產(chǎn)生流量的線上發(fā)壓平臺。和淘寶瀏覽某個商品行為相比， 滴滴流量發(fā)起較復(fù)雜 ，涉及時間、地理位置等多維度。

平臺有前臺 Web 系統(tǒng)、后臺服務(wù)系統(tǒng)和數(shù)據(jù)存儲三層。在測壓過程中，遇到一些問題。如：

• 測試數(shù)據(jù)和線上數(shù)據(jù)如何區(qū)分開？

  原則上是可寫在一起，但為避免帶來問題，這里做了和正式表一樣的影子表，同庫不同表。

• 怎樣識別是在做壓測？

  用 Trace 來傳遞標識，通過中間件傳遞，中間件不完善也可通過參數(shù)來做。

由于滴滴的數(shù)據(jù)和一般數(shù)據(jù)存在差異，全平臺壓測數(shù)據(jù)構(gòu)造要做特殊處理。發(fā)單時產(chǎn)生的當前位置、目的地等數(shù)據(jù)都會回傳系統(tǒng)。這里會出現(xiàn)坐標問題，如用真實坐標會干擾線上某些因素。

故把坐標偏移到太平洋，模擬端，把精度、緯度等也做偏移。虛擬乘客和司機，做 ID 偏移、手機號替換。

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

業(yè)務(wù)線

• 順風(fēng)車： 接口耗時增長，如列表頁面：100ms => 700ms

• 順風(fēng)車： 日志搜集的上傳服務(wù)夯死

• 專快： 派單訪問緩存出現(xiàn)超時

• 出租車： 獲取司機接口觸發(fā)限流

• 出租車： 派單單條日志量太大影響性能

基礎(chǔ)平臺

• NAT： 2臺NAT啟動無用的內(nèi)核模塊，流量大時大量丟包

• LBS： 位置服務(wù)寫入超時，查周邊接口有超時

• 地圖： 路徑規(guī)劃服務(wù)，到達容量瓶頸

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

• �？煊嬎愠瑫r： 由于工具問題，司機和訂單陡增，km算法超時，主要是日志過多導(dǎo)致的。

分布式改造

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

上圖是典型的分布式架構(gòu)。最重要的接入層和服務(wù)層要做到服務(wù)的無狀態(tài)化，每個節(jié)點都需對等，因為這兩層主要做讀請求且請求量較大。做無狀態(tài)化是便于橫向擴展，當業(yè)務(wù)量大時，就可迅速部署機器來支撐流量。

數(shù)據(jù)層大部分情況下都是有狀態(tài)的，需解決的是冗余和備份，MySQL 要做存庫，能讀寫分離，能做故障切換。

分布式改造關(guān)鍵的技術(shù)點有三：

• 分布式 RPC 框架： 主要解決系統(tǒng)性關(guān)聯(lián)問題，就是系統(tǒng)拆分，必須要解決系統(tǒng)之間的同步連接問題；

• 分布式消息框架： 主要解決系統(tǒng)間的數(shù)據(jù)關(guān)聯(lián)性，這是異步的，與RPC同步調(diào)用互補；

• 分布式配置框架： 主要解決狀態(tài)問題，實際應(yīng)用中接入層和服務(wù)層也是有狀態(tài)的，最好做到無狀態(tài)。因為每個機器可能存在差異，故要通過中間件，把差異性放到配置框架中解決。

去年，滴滴做了服務(wù)治理相關(guān)的事。 如下圖，是早期的滴滴系統(tǒng)架構(gòu)，router 接受層，到 inrouter 上層，中間有引入代碼。下面是 Redis，本身是個代理。

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

這里存在的問題：

• 上下游依賴硬編碼在代碼里；

• 沒有使用 inrouter/tgw 的 ip：Port；

• 摘除和擴容需要代碼重新上線，inrouter 有網(wǎng)絡(luò)鏈路穩(wěn)定性隱患，以及效率上的損失；

• 沒有清晰的服務(wù)目錄，API 文檔以及 SLA 和監(jiān)控。

分布式 RPC 框架圖

目標是把一些服務(wù)之間的調(diào)用能夠通過規(guī)范化方式串聯(lián)起來。上下游通過名字服務(wù)，從上游和下游端口解耦，名字服務(wù)需要在全公司統(tǒng)一且名字唯一。

• Naming 服務(wù)就是做服務(wù)命名，服務(wù)注冊和發(fā)現(xiàn)，到注冊中心

• RPC通道，部署私有協(xié)議，具備可擴展性

• 服務(wù)路由與容災(zāi)，動態(tài)路由，故障節(jié)點摘除

這里需要提醒的是， 目前滴滴技術(shù)棧還不統(tǒng)一，所以導(dǎo)致中間件會復(fù)雜一些，應(yīng)該最早期把技術(shù)棧統(tǒng)一，選擇 Java 或者 Go 等，可以避免后續(xù)的問題。

服務(wù)命名要規(guī)范，服務(wù)名自描述，要構(gòu)建統(tǒng)一服務(wù)樹。為了效率和規(guī)范性， 協(xié)議建議選擇私有 RPC 協(xié)議。 公有如 http 協(xié)議，測試方便，帶來方便性的同時也帶來的其他問題，就是容易被濫用。

服務(wù)路由建議是全局摘除， 像機器一旦不可用就通知上游，及時摘掉，但也有一定的風(fēng)險。如網(wǎng)絡(luò)閃斷，下面機器全掛，會導(dǎo)致所有服務(wù)都不可用。所以需在全員鎮(zhèn)守情況下做全局確認，不要拖著整個服務(wù)，要從上游做決策，再換個IP，重新做一次。

分布式服務(wù)化改造的大團隊協(xié)作，從單業(yè)務(wù)系統(tǒng)做分布式改造的一個出發(fā)點就是解決大團隊分工和協(xié)作問題。代碼的分支拆分，減少代碼沖突，使得系統(tǒng)獨立，打包和發(fā)布效率都會提高；部署獨立，線上故障排查和責(zé)任認定會更加明確。

同時，帶來的問題是依賴的不確定性增加，性能上的一些損耗。像一次請求，如果一下調(diào)來七八個請求，這也會帶來一些問題，所以這個過程要有一定的合理性，就是公司現(xiàn)在處于什么階段，現(xiàn)在需不需要拆分。所以系統(tǒng)、效率等方面要做一個平衡。

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

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

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

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

為了具備更大的伸縮性需要把 靜態(tài)內(nèi)容前置到 CDN 。

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

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

熱點偵測

熱點偵測流程圖

前臺系統(tǒng)到后臺系統(tǒng)，整個請求是有鏈路的，一個請求從發(fā)起最終到服務(wù)端，到數(shù)據(jù)庫層中間需經(jīng)歷多層，過程中存在時間差。特定情況下，會有 1-2 秒延時。利用這一點，當前端請求自導(dǎo)到接受層時，做實時熱點偵測，當發(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ù)再導(dǎo)到寫數(shù)據(jù)系統(tǒng)的后端系統(tǒng) cache 中，這樣可保護后端的部分熱點系統(tǒng)。

1% 的熱點會影響 99% 的用戶，這種情況在電商是特別明顯的，如某個商品特別熱賣，商品請求流量占全網(wǎng)流量很大部分。且上屏容易產(chǎn)生單點，查數(shù)據(jù)庫時將定在同一機器。這樣很容易導(dǎo)致某個商品會影響整個網(wǎng)站的所有商品。所以要在數(shù)據(jù)庫做保護，如在本地做 cache、服務(wù)層做本地 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)驗

高可用架構(gòu)建設(shè)的

體系化、積累和沉淀

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

建議 在責(zé)任體系的建設(shè)方面， 公司一定每年都要制定高可用指標（KPI）、故障等級也要明晰，影響多少客戶都要做描述、責(zé)任和榮耀體系也同等重要，這是個長期且苦逼的事。

工具方面， 要完善且體系化，做規(guī)范，做 KPI，最終要做到工具化，通過工具化把流程、規(guī)范能固定。工具要體系化，像全機壓測，單機壓測等等都可做工具。

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

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

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

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

 

來自：http://mp.weixin.qq.com/s/t9DRMwA8BsmVvn3mVcatJQ

 

標簽： Mysql 代碼 電商 數(shù)據(jù)庫 網(wǎng)絡(luò) 網(wǎng)站建設(shè)

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。