引言

2021年10月22日，在雲棲大會的《雲上運維最佳實踐》分論壇，貨拉拉技術副總監陳永庭發表了主題為“基於雲的貨拉拉技術穩定性保障實踐”的演講，為大家分享了貨拉拉在過去一段時間是如何做到技術穩定性保障的，希望給有同類型業務場景的同行提供一種思考方式。

圖：貨拉拉技術副總監陳永庭

以下是根據他的演講整理成的文章，主要分為四個部分：

一、貨拉拉業務形態。

二、基礎架構治理。

三、技術保障能力的建設。

四、跨雲的思考與實施。

一、貨拉拉業務形態

貨拉拉從成立到現在已經有接近十年的時間，從2013年開始我們主要做同城貨運與國際貨運。到現在我們有企業、跨城、搬家、零擔等多條業務線。這些業務線有共性，也有不一樣的地方。在技術系統的容量保障上，與業務特徵有很強的關係。平臺提供司機運力的供給，幫助配對使用者貨物的訂單需求。

所以，在供需出現不平衡的時候，會對我們的系統帶來一些壓力，譬如：運力不足；使用者反覆下單；排程系統努力幫助訂單尋找配對的運力。這期間會產生大量的計算需求，系統的容量峰值會是正常峰值的好幾倍，但我們系統常態下沒有足夠的空閒容量。

這是貨拉拉的各個業務的流量形態圖。業務形態是典型的高峰低峰的分佈。這是正常的狀態圖，但不正常的情況也有很多。比如有的業務線週一到週五流量是比較小的，週末流量是平時的好幾倍；還有在節假日前夕，出現很多司機運力不足的問題。這個時候，我們的取消單、待配對單等指標就會增長，我們的司機排程系統也會頻繁地告警。

所以在過去1-2年裡，我們會重點關注，在當前的業務形態下，技術系統和系統容量如何去設計？我們在日常保障中如何合理的評估、壓測系統的容量？

在過去1-2年裡，我們的技術團隊規模快速增長，同時我們也遇到了一些問題需要去解決。

首先，我們的研發同學不但要快速地交付業務，而且要清還歷史技術的“債務"。尤其是前期，"債務"比較多的時候，我們要分辨出優先解決的問題。像核心服務依賴非核心服務的鏈路治理、填補主鏈路上的降級措施能力等。

另外，我們非常關注研發效率與技術保障之間的平衡。前期，在很多領域，我們會優先通過技術手段來提升普適性場景的效率，並且不需要業務研發同學投入太多時間（避免影響他們的業務交付效率）。如果要做到足夠好的技術穩定性保障，研發同學需要在自己的服務程式碼里加上更多額外的保護措施。這個工作量是比較大的，對一些業務需求交付節奏比較快的團隊來說是很難的。舉個例子：我們最早期監控框架SDK在研發接入的時候，不需要研發人員修改程式碼，只需要把JAR包整合到服務裡。

最後，在技術團隊規模快速增長的過程中，我們的技術標準，落後於我們的訴求，公司內部出現較多非標準化的技術操作。在這個時期，我們會考慮一些優先順序比較高的事情先做。比如，我們會在特定的時間裡，優先解決監控問題、告警問題、故障預案平臺的問題，然後再去解決其他非標領域的事情。

二、基礎架構治理

貨拉拉的基礎架構是如何治理的呢？如何通過基礎架構的治理來提升基礎的穩定性?

前期我們主要聚焦在兩個方面：一是貨拉拉結合自身情況去做服務化治理，其次，如何讓研發同事在相對可控、有保障的前提下，支撐他們方便快捷的釋出？甚至可以在高峰期時間釋出，且不會出現無法預料的風險。

下圖是貨拉拉最早期的技術架構版本。它實際上很簡單，支援快速開發，支撐快速交付。由於我們的研發工程師效率非常高，今天很快可以把業務需求的程式碼寫完，明天就能測試上線。這種方式快速支撐了業務的高速發展，但這種“快”也帶來一些隱患。當我們的業務規模、資料規模、服務規模在百萬訂單級別下發生了很大的變化，“快”引發的一些問題變得越來越凸顯。

首先，業務鏈路服務不可靠；關鍵服務與非關鍵服務之間不清晰，並且相互依賴。這很容易因非關鍵服務導致整個主鏈路發生故障。

其次，部分核心服務臃腫龐大，不易維護。

第三，服務自愈能力比較弱，在瞬間幾倍高峰流量下很容易發生系統癱瘓。

第四，我們過去排障效率低，故障應急處理時間長。這是我們最困難，最黑暗的一段時間。

所以，我們立馬開始著手服務化治理。讓所有業務服務是處於一種可治理狀態，讓整個業務鏈路是清晰的。這個技術本身不難，業內有諸多成熟的開源微服務治理框架可以直接使用。但對我們來說，難點是我們生產環境有很多老的服務在執行著，有的是JAVA實現的，有的是PHP實現的。我們沒有辦法做到讓研發一次性把老程式碼全部剷掉，按照標準方式重新開發，這個是無法落地的。針對這個問題，我們的方案是採取泛服務化的設計方式來解決。

何為泛服務化？泛服務化就是在保留原有HTTP URL API呼叫原型的情況下，達到服務化治理的目的。研發同學無須對老服務進行大量的程式碼改造，只需要輕量的調整HTTP URL call的程式碼呼叫方式，動幾行程式碼即可。這樣就具備了基本的服務註冊與服務發現與路由的機制。這種設計方式實現了大量老服務無須花太多代價就達到了服務治理的目標。

在這樣輕量改造下，使得我們可以快速地在生產環境進行落地，讓所有的老服務具備了基本的服務化治理的能力。在生產環境的穩定性技術保障過程中我們就有了更多的治理與應急手段。

我們業務的主要技術棧是Java和PHP，在過渡期我們的系統就會存在多種型別的服務並存。這些型別的服務他們在同一個大的執行環境裡，可以方便的相互通訊，隨著老服務被慢慢改造成標準微服務架構，最終形成了全量的標準微服務鏈路。做到了不“一刀切”（全量高成本改造）也能在初期讓服務架構具備治理能力。

我們第一代技術棧是以PHP技術為主，PHP高效快速的支援了業務的發展。但是在過渡期，我們如何讓PHP服務跟Java服務在大的服務架構裡互聯通訊 ？我們中介軟體團隊用了PHP sidecar的方式，幫助PHP做服務註冊和發現以及服務配置，讓PHP和Java可以在同一個池子裡執行。

做完服務治理之後，生產環境的鏈路就變得相對明確清晰。我們的監控工具可以把服務鏈路清晰的畫出來。當出現技術故障或者冒煙時，我們也會有更多手段去做一些降級、限流、熔斷等應急操作。我們可以更快的解決問題，讓故障恢復的時間變的更短。

在我們服務化治理達到預期後，常規的生產故障會在很短的時間內被快速修復掉。從系統的流量角度看，我們初期是一個單IDC、單鏈路的架構，鏈路容錯性比較差。在很長一段時間，我們的生產效率比較低，大版本釋出經常持續到凌晨。為了提升釋出效率，提升技術穩定性，我們演進架構到單IDC、多鏈路方式（如中間的圖）。

雖然所有服務依然在一個數據中心內，但可以創建出多條不同邏輯的流量鏈路。鏈路之間相互隔離，我們內部稱呼為泳道。這種設計方式，解決了全鏈路高峰期生產灰度釋出的場景問題。

這樣的流量排程架構不但解決了我們生產釋出效率與低風險的問題，而且它也是作為我們系統容量發生嚴重故障時的一種應急手段。如果系統容量出現了致命的瓶頸故障並且無法快速恢復，系統容量不足無法扛住全網全業務的流量，我們可以緊急配置，修改流量排程策略，保住比較重要的城市和區域業務。

三、技術保障能力的建設

貨拉拉在完成服務化架構（含泛服務化）的重構與治理之後，技術穩定性保障有了更多的手段與措施。在這個時期，技術團隊也專門成立了全域性穩定性團隊。團隊的核心職責是建設與完善貨拉拉技術保障體系平臺，目前的體系概貌如圖所示。

整套體系涵蓋了前置建設、故障發現、故障響應、故障止血與故障覆盤等領域。並且為每個領域優先打造了比較急需的能力。其中最重要的有兩個方面。

第一，NOC團隊。這個團隊的職責就是做穩定性大盤監控與職守，以及指揮生產故障的應急響應。他們需要做到快速止血、快速修復。我們要求這個團隊在1分鐘之內發現問題，5分鐘之內響應這個問題。NOC是我們技術保障體系的守門人。

第二，組織保障很重要。我們通過設定單獨的組織架構與組織職責，重視故障的覆盤與覆盤整改的跟進閉環，定義穩定性過程指標和持續跟進這些指標。

大監控平臺是我們技術保障體系最重要的領域。初期階段，我們給予監控平臺最高優先順序去建設，內部團隊一直稱呼為AI-Monitor專案。

專案啟動之初，大家一致選擇一條艱難的路，希望開發出的監控平臺既能提供監控告警的常規能力（應用接入採集、資料儲存計算、查詢展示與告警），也能解決一些深層次的問題，譬如智慧發現、智慧健康掃描、自動分析與定位，所以大家在專案名稱中帶上了AI。

目前為止，監控平臺已經覆蓋了所有應用(1000+)，覆蓋所有的節點(9000+)，每天會收到5000+條告警（降噪前）。除了監控平臺的功能性覆蓋外，我們也會關注監控指標資料的實時性，查詢響應延遲，把這些指標作為監控平臺自身的關鍵技術指標對待。

這裡重點提一下監控平臺AI OPS模組裡面的風險預測功能。平臺無時無刻不在對每一個業務應用進行“健康體檢”。捕獲應用執行機器的OS指標(CPU、IO、Mem、Network等)，服務自身程序空間的指標資訊（CPU、Thread、Mem、TCP等），應用服務的上下游服務，應用吞吐能力（QPS、Latency），應用依賴的基礎設施和中介軟體服務(DB、Cache、MQ等)，Java應用的JVM資訊。把這些指標資訊匯合在一起，檢查是否有處於不合理範圍區間的指標。一些指標也會進行“日環比/周同比”檢查，背後專家團隊也會持續的修訂和定義這些指標的合理區間，如果發現有任何一個指標出現問題，平臺就會發出預警，提醒我們研發同學做進一步的診斷。

這種風險預測能力在貨拉拉內部被廣泛使用,我們統計有超過70%的技術冒煙事件都是可以通過這些常規的預測進行提前感知的，幫助我們把一些可能會引發嚴重技術故障的起因扼殺在最早期。

監控平臺另一個比較重要的功能是根因自動分析。這個功能在內部的探索已經初具成效。我們依靠監控平臺的自動分析，做到快速定位原因。平臺的自動分析能力會聚合所有的異常指標，結合內部自動構建的服務鏈路關係，給出初步的分析建議，這大大加速了我們工程師人工排查的效率。我們可以快速定位故障的“根源”，第一時間用最合理的措施進行止損與恢復，最大程度降低了故障導致對業務的影響。

全鏈路容量壓測，是貨拉拉技術保障體系中的最核心的戰場。在穩定性保障過程中，必須要知道系統容量可以支撐多大的業務量？核心主鏈路服務的容量短板在哪些地方？貨拉拉在實現全鏈路容量壓測平臺時，也遇到過一些場景的設計與選擇。

一，技術改造的選型。貨拉拉選擇生產真實庫表。

二，資料和流量模型的設計。由於主鏈路業務服務的流量比例不同，我們針對這些服務進行流量請求的額外補償，這樣讓整個鏈路上的所有服務都得到1.5倍、2倍的流量壓力，讓整個系統的容量壓測更全面和精準。

三、容量治理與演練。我們每隔兩週做一次全鏈路容量壓測，跟進解決容量壓測發現的技術設計、效能問題。避免系統技術架構長時間迭代出現腐化。另外，技術保障團隊會定期結合壓測進行生產故障模擬演練，讓保障團隊的研發同學始終保持對生產系統的穩定性敏感度。

技術保障體系中的資料平臺建設，是貨拉拉非常重視的一塊領域。我們通過自建的DMS平臺管理和治理資料類基礎服務。平臺的建設過程中會比較關注三個方面的能力。

第一，當業務體量快速發展，資料規模成倍增長，DMS在資料隔離、服務限流和實時擴縮容做了很多自動化建設。

第二，DAL是我們快速引入並推動落地的資料庫訪問中介軟體。使資料庫具備靈活彈性的分庫分表、讀寫分離架構能力，來快速支撐業務規模的增長。

第三，資源ID化設計。我們在交付資料服務時，是不會將服務的真實物理資訊（連結串）暴露給研發的。而且我們的框架和工具是完全整合支援資源ID。研發同學做到開箱即用，不需要去了解資源ID背後各個環境的叢集、部署和配置等資訊。技術保障同學也可以通過資源ID快速定位是哪個業務應用在使用服務（譬如：DB、Cache、MQ）時出現了問題。

四、跨雲的思考與實施

最後，我們聊聊貨拉拉在多雲場景下，我們是如何平衡效率，成本，穩定性設計。主要有三個方面：磨平多雲的差異化、雲抖動的防範、IT成本的治理措施。

第一，磨平多雲的差異化。因為貨拉拉的業務在多雲場景下，雲商服務的API會存在一些差異性。所以我們內部做了一個LCloud工具平臺來對接所有的雲商，工具會磨平雲商的差異。我們內部的研發、運維同學通過LCloud可以獲得一致的操作體驗。

第二，雲是一定會抖動的。如果我們跑在雲上的服務不具備足夠的彈性，那麼雲上的“抖動”一定會影響你的業務。一旦出現網路的短暫抖動，就會導致整個服務響應延遲升高導致服務不可用。這個服務的吞吐能力會全部掉底，導致業務鏈路受損。

第三，雲服務的IT成本。貨拉拉目前的成本管控措施除了使用K8s基礎設施做資源的彈性排程外，還大量使用了雲商的一些特性，譬如：競價例項、預留例項的購買。容器化團隊也在研究如何在低峰時間彈出閒置資源，提供給離線任務場景的使用。