​

作者 | 劉金龍(福辰) 高德團隊

引言

​

“前方事故多發地段,請注意保持車距...”
“您已疲勞駕駛，請注意休息...”
“前方經過泰山旅遊景區，中國 5 A級景區，是第一批國家級風景名勝區...."

......

​

這是高德出行的導航場景，像這樣暖心的語音提示，在春節期間的每天都會有上百億次，以保障您的出行安全。然而這背後，任何系統抖動或者故障，都會影響到使用者的出行安全，所以在節日期間整個團隊會嚴陣以待並去現場值班，以保障系統的穩定性。
​

在過去的 2021 年，高德地圖提出了新的品牌主張：在“高德地圖，哪兒都熟”的背景下，高德出行 App 增添了更多的使用者使用場景，隨之而來業務系統也變得更為複雜。為了保障系統的穩定性，每一個節日大促期間，都會有同事去現場值班。
​

為了解決這一困境，我們對系統架構進行了更深的思考，並一致認同 Serverless 會是未來的技術趨勢，所以在過去的一年中，我們對 Serverless 技術做了很多的探索，並實現了部分核心業務的 Serverless 化。利用 Serverless ：低成本，免運維，高彈性等優勢，達成了上述提及業務，節假日無需同事再去現場值班的目標，讓團隊成員可以在家過一個安心團圓年。
​

本文會分享過去的一年，高德地圖在 Serverless 領域做過哪些探索？如何與業務相結合，實現了一個低成本，低程式碼，免運維的現代化的 Serverless 研發平臺。
​

業務背景

​

自 2021 年 7 月，高德地圖宣佈品牌履新：整體向 “出門好生活開放服務平臺”升級，同時提出了“高德地圖，哪兒都熟”的新品牌主張。高德地圖從導航工具升級為出行服務平臺、生活資訊服務入口； 為了更好地服務使用者，擴充和出行相關的生活資訊服務場景：高德地圖主圖、我的頁面、行前行後場景以業務卡片的方式，透出了業務推薦資訊。下圖是高德 App 中出現的幾個典型卡片推薦場景：
​

樣式多變

高德地圖的業務特點之一是：高頻率的樣式變化。節日氣氛的襯托、假期旅遊的引導、交通訊息的提醒等等多變不同的需求下，亟需一種能夠快速迭代的研發模式。而傳統的研發模式是：每一個變化都是在 App 客戶端上研發，然後隨著 App 版本的釋出進行樣式再更新。（這種發版效率很慢，並且要考慮到穩定性；每月一個版本，如果仍使用這種研發模式，其實是很難滿足業務需求的。）

策略多變

卡片業務背後的後端程式碼，會隨著業務型別的不斷增加，因此相應的業務策略越來越多，如果不及時與系統功能模組進行抽離，就像生命力頑強的爬山虎一樣，系統程式碼不斷無序增加，越來越臃腫，複雜性也越來越高。而多變的策略，會要求在系統架構上做出改變，達到策略的快速增加與刪除，以及實時的生效。

客戶端瘦身

過多的業務邏輯糅合到客戶端，雖然可以一定程度上提高效能，但是如果客戶端過大，也會導致使用者不願更新。其實動輒幾百兆的更新，不僅會增加我們的頻寬成本，也佔用了使用者的資料流量。此外因為程式碼多，相應的涉及業務也多，如果每一個業務都有快速迭代的要求，這就需要 App 客戶端擁有能夠快頻率的更新的能力。
​

兩者構成了惡性的迴圈，不利於 App 的長期發展，所以客戶端瘦身勢在必行。

早晚峰值

上班早高峰，下班晚高峰，相信大家都有過一致的體驗：堵 ！！同樣地圖導航類應用，早晚峰值時間段非常的明顯，且峰值和低谷的波谷差距非常大，如果所有的機器資源按照峰值去準備，這成本無疑是非常高的，在低峰期，會造成極大的資源浪費。所以我們需要能夠按需使用的彈性資源技術，去降低我們的機器資源成本。

技術選型

經過架構組的多輪討論，最終我們並達成達成一致目標：全面擁抱 Serverless。 因為 Serverless 的優勢特點，恰好解決了我們的業務痛點需求。我們也相信未來一定是屬於 Serverless 的時代。

Serverless for frontend

不用多說，當下前端最熱的技術趨勢就是：雲端一體化研發模式，它實際上是以 Serverless 技術作為技術底座去構建的現代化應用研發模式；不僅降低了“全棧開發工程師” 的技術門檻，還大幅提高了研發效率，阿里內部多個大型 App 都已全量使用，比如淘寶，天貓，飛豬等等。經過嚴格的資料統計，Serverless 在研發提效上能提高 38%，這也是我們選擇 Serverless 最重要的資料依據。除此以外，基於 Serverless 實現的 CSR/SSR 首屏提速技術方案，目前也已經非常的成熟，幾乎覆蓋了阿里內部的 App 應用。

快速迭代

工程卓越一直是我們的追求目標，但是由於各大技術產品關注重點不同，所以對於“研發最後一公里”的相關事項並沒有做太多關注，這就導致了技術產品的功能與使用者體驗出現割裂感，很多業務方放棄使用。
​

Serverless 的目標就是讓你儘可能多的專注自己的業務邏輯，能夠少關注或者忽略非業務核心的運維工作；加速開發時間，降低線上資源的冗餘成本，所以 Serverless 無疑是扛得起降本提效的大旗的。

完全彈性

​

請求毫秒級的排程是 Serverless 的核心競爭力，相比傳統的分鐘級彈性擴容，Serverless 技術存在巨大的成本優勢，擴容所耗費的時間越少，預留的機器資源就會更低，如果到了毫秒級別，就無需預留任何資源，這樣成本能夠大大的降低，資源利用率可以達到 100%。

低成本遷移利器 - Runtime/Container

​

做過程式設計師的同學都知道最痛苦的事情是“改別人的程式碼”，因此，雖然 Serverless 技術十分誘人，但是對於存量的應用如何遷移到 Serverless 架構上，也一直困擾著我們。
​

我們應如何以低程式碼的方式解決傳統架構潮汐流量對資源使用不合理的問題，於是我們跟 Serverless 團隊同和合作開發 Runtime。由於高德的服務均以 C++、Go、Rust 的語言設計，於是我們開發出 C++、Go、Rust 的 Runtime。Runtime 整合了集團內的中介軟體，使得 Serverless 架構可以滿足我們之前服務的整個生命週期。讓我們可以快速的切換服務到 Serverless 平臺上。
​

但是隨著我們使用量變大，業務場景比較複雜，一些對外的服務是無法使用內部 Runtime 的，這個嚴重的問題一直掣肘著我們，使原有的架構由簡單又變得複雜起來。直到阿里雲 Serverless 團隊的同學，推出了 Custom Runimte/Container 功能，徹底解決了我們後顧之憂。我們只需改幾行啟動命令，就可以輕鬆遷移存量的應用。Serverless 團隊也針對映象的快速分發做了大量的創新優化工作，如使用四級快取，P2P 技術，按需下載等方式，提供了秒級別下載 3G 大小映象的能力。
​

得益於 Serverless 技術加持，無人值守的目標也就很容易達成，所有的運維操作，都通過 Serverless 的強大排程能力去解決，比如峰值高峰期，系統會自動毫秒級別進行擴容，低峰期同樣也會 Graceful 的進行縮容，不涉及任何人為操作運維，所以這也解決了我們在節日大促期間過多人現場值班的困境。

Serverless 技術落地

​

架構設計

​

在系統設計上，我們引入了兩層 FaaS (Function as a Serverles)，端 FaaS 和業務 FaaS，其中：

• 端 FaaS，也就是 SFF （ Serverless for frontend)，基於 Node.js，實現了端雲一體化開發，將原本客戶端的邏輯移到 FaaS 服務端來。這裡在傳統的 Frontend 和 Backend 之間抽象出了 SFF ，用來實現資料和呼叫邏輯封裝，快速開發、釋出。
• 在後端，引入業務 FaaS，基於 Java/Go 實現, 用來封裝推薦策略邏輯和資料轉換程式碼，可以提高策略迭代效率，同時減少策略迭代對主工程的影響。

​

從整體上看，將函式計算和容器化微服務整合在一起，綜合利用函式計算的高效和傳統微服務的靈活，是一種實用高效的架構設計思路。

快速迭代

​

作為核心的應用，需要一套完備的 CI/CD 流程去保障應用的質量，針對函式的質量，我們基於了 Serverless Devs 工具鏈同樣實現了一套研發全流程方案:。不僅具備函式多環境，函式灰度切流，函式可觀測等能力，而且通過這套 Serverless 研發體系，我們實現了 1 分鐘開始進入開發，5 分鐘完成上線的能力，同時預設具備異地多活的能力。

限流降級，異地多活

對於大流量應用的穩定性，限流保護，降級預案，異地多活是三大必備功能。特別是大促的時候，非預期的流量都可能引起系統雪崩，在我們的 Serverless 研發平臺上，整合了阿里雲函式計算的併發度流控，QPS 流控的能力，做到了函式粒度的流控。
​

另外一個亮點是，FaaS 的容災方案與傳統應用的容災方案相比，有著巨大的優勢。在傳統應用的容災方案中，異地多活需要在備機房中準備冗餘的機器資源，這些資源也就是成本，但是在 Serverless 場景下的方案中，因為是快速彈性，秒級別就能完成資源的準備，所以無需進行資源冗餘準備，這就大大節省了成本。雖然是三單元，但是成本仍然是一個單元的費用，目前所有核心的函式應用，我們都預設實現了三單元容災。

冷啟動優化

​

如果你的業務對於冷啟動非常的敏感，比如 50 ~ 100毫秒的延遲增加，你都無法接受的話，不要擔心，我們仍可以通過擴容策略進行彌補：預留資源來消減冷啟動對業務的影響。
​

• 預留例項，根據產品流量曲線，很容易得出固定流量是多少。這部分流量用“預留模式”，適合冷啟動敏感的業務；
• 按量擴容模式，按使用者設定的併發度或者 CPU 利用率閾值進行擴容，擴容中的例項，不會立即接收流量，而是例項 Ready 後再進行服務。所以擴容中新增的流量會仍然派發到“正在服務中”的例項，並不會觸發冷啟動。

展望

​

在過去的 2021 年，高德在 Serverless 領域中，做了很多方向的探索，也實現了部分核心業務的 Serverless 化。單在 Serverless 的業務 QPS 峰值就已經超過 40W QPS， 然而這不是終點，只是剛剛開始，後續我們會全面轉向 Serverless 化。比如，地圖資料的處理，圖片的栽剪，訊息的消費等等這些離線的非線上應用，它們同樣也是 Serverless 的最佳適用場景，我們期望今後有更多的場景去使用 Serverless，享受 Serverless 給我們帶來的技術紅利 ！

更多內容關注 Serverless 微信公眾號（ID：serverlessdevs），彙集 Serverless 技術最全內容，定期舉辦 Serverless 活動、直播，使用者最佳實踐。