極氪汽車云原生架構落地實踐

云原生架構落地實踐的背景

隨著極氪數字業務的飛速發展，背后的 IT 技術也在不斷更新迭代。極氪極為重視客戶對服務的體驗，并將系統穩定性、業務功能的迭代效率、問題的快速定位和解決視為構建核心競爭力的基石。

為快速響應用戶的需求，例如縮短一輛車的制造周期、便捷平滑地升級汽車操作系統等，企業從產品到用戶體驗到商業模式都需要創新。然而消費互聯網和傳統產業發展的經驗不足以完全滿足產業互聯網對成本、效率、質量等方面的高要求。云原生是一個確定性的技術發展趨勢，能有效推動產業發展，驅動企業積極革新。極氪正持續投入，將云原生能力賦能到企業內的研、產、供、銷、三電等更廣泛的業務領域。

這些業務現狀和云原生架構帶來的核心能力不謀而合。 在極氪系統改造上云的過程中，圍繞著云原生技術體系，推動極氪的各條業務線進行技術升級改造，加快數智化發展進程。在技術選型上，極氪始終遵循著 2 條原則：

一是全面擁抱開源開放的主流技術標準： 使用開源開放的主流技術標準，可以確保技術方案的成熟度，更便捷地從開發者社區獲取技術資源和最佳實踐，也能夠幫助企業更好的招募技術人才。此外，這樣的策略也避免了被封閉技術體系和特定云廠商所捆綁。軟件技術的國產化以及自主可控，也是需要考慮的點。

二是盡可能利用云的價值： 將穩定性保障、底層技術實現、技術組件維護、彈性伸縮等非功能性需求盡可能交給云廠商解決，讓技術團隊將更多的精力投入到業務創新上。

這 2 個原則并不矛盾，相反，它們之間可以非常好的融合，這也是所有使用云計算的企業用戶都值得借鑒的架構選型標準。接下來，我們將圍繞微服務架構統一、應用運行高可用、應用發布治理進行展開，并以可視化數據分析系統、車聯網數據采集、智能研發范式這三類業務場景，分享我們的云原生架構落地實踐。

實踐一：統一微服務架構

在統一微服務架構之前，極氪的各個業務單元多種技術棧并存，彼此之間相互通訊復雜度高，項目成員的交接往往要耗費巨大的精力，極大程度上阻礙了數字化轉型的進展，因此微服務架構統一勢在必行。

極氪經歷了 2 年多時間完成了這一項艱巨的工作，雖然投入精力巨大，但收益是立竿見影的，而且可以持續發揮作用：不論是內部團隊還是三方 ISV，在技術框架上都有統一的標準可以遵循，各團隊共享技術棧后，研發效率成倍提升。

關系到未來多年的 IT 戰略，在微服務架構的選型上，高開放性、高成熟度、高普及度這三條標準缺一不可，考慮到極氪以 Java 為主要開發語言，Spring Cloud Alibaba 就成為了微服務框架的最佳選擇。

Spring Cloud Alibaba 致力于提供微服務開發的一站式解決方案，包含開發分布式應用微服務的必需組件，方便開發者通過 Spring Cloud 編程模型輕松使用這些組件來開發分布式應用服務。這些組件一部分以 SDK 的形式集成到代碼中，一部分以中間件的形式獨立運行，后者往往可以選擇托管版云產品，以降低開發者的工作量。比如阿里云微服務引擎 MSE 就提升了開箱即用的注冊配置中心 Nacos，以及云原生網關。

實踐二：微服務架構高可用實踐

極氪 APP 是我們和車主的溝通紐帶，采用的是微服務架構。但是隨著注冊車主數量呈現出了爆發式的增長，用戶的使用場景也不斷擴大。在這個過程中，APP 的用戶使用體驗變得愈發重要，如何在用戶規模高速增長的同時可以保證 APP 的穩定性、敏捷性， APP 的微服務開發效率如何保證，這些都給研發團隊帶來了一定的挑戰。

1、高可用挑戰

業務連續性差缺少容量規劃

遠程控車、在線地圖、3C 商城等 APP 核心服務對業務連續性要求非常苛刻，均需保證 7*24 小時持續在線。特別是面臨旺季銷售活動、新車型發布、突發熱點事件等情況， APP 面臨著高并發大流量壓力，經常會發生功能失效、頁面打不開、延遲過高，甚至 APP 完全無法訪問的異常，對用戶體驗造成嚴重影響。

功能版本發布迭代速度慢

隨著用戶場景需求的增加，越來越多的功能等待發布上線，對迭代頻率的要求越來越高，但由于 APP 服務端缺少全鏈路灰度發布能力，為了保障業務穩定性，每次發布客戶只能選擇在凌晨的業務低峰期進行，開發、運維、測試同學苦不堪言，急需實現隨時發版無損發布能力。

技術架構缺少整體設計

公司成立之初，為了實現 APP 快速上線，對于技術架構整體設計考慮不足，體現在業務間高度耦合、系統鏈路過長、技術實現標準不一、云產品選型不合理等諸多問題，例如通過調研發現某核心接口請求鏈路過長，導致延遲抖動率很高，影響用戶使用體驗。

研發團隊意識到，隨著業務發展的向好，這些挑戰也會也越來越大。在業務快速發展中，既要保證好已有業務的穩定性，又要快速地迭代新功能，并且需要保證開發的效率并不會隨著業務增長而大幅降低，畢竟存在團隊招聘節奏跟不上業務發展的問題。總結來說，團隊解決 APP 應用快速迭代演進的關鍵就是解決穩定性與效率的問題。

穩定性： 用戶數多起來之后，系統的穩定性就顯得比較重要，無論是用戶在某段時間遇到異常報錯增多，還是某一個功能點持續性地報錯，再大到系統有一段時間完全不可用，這些都會影響產品在用戶中的口碑，最后這種完全不可用的場景，甚至還可能成為微博等社交網絡上的輿論熱點。
效率： 隨著用戶的增多，相應的需求也越來越多，業務場景也越來越復雜，在這個時候測試可不是內部測試就能覆蓋所有的場景，需要加大在測試上的投入。雖然功能需求越來越多，但是迭代的速度卻要求越來越快，因為市場中已經有不少競爭者，大家競爭的一個關鍵就是速度，業務更需要跑得更快，開發節奏要快，測試節奏要快，發版節奏也要快。

針對以上問題，研發團隊根據業務架構從流量入口到微服務再從全局視角進行微服務的系統優化與調優，圍繞著成本、穩定性以及效率進行深入的微服務化探索。

2、業務鏈路入口升級

極氪架構中的網關架構并不一致，各種網關都起了一定的作用。我們可以從上圖中看到流量網關、API 網關、微服務網關等眾多網關存在，他們具備了安全（WAF）、API 管理、流量分發等作用，思考一下，如果一個請求鏈路經過多個網關，那么這個事情對成本與穩定性都有一定的挑戰。

在這個時候 MSE 云原生網關出現在研發團隊的視野中，云原生網關將流量網關（Kubernetes Ingress、Nginx）和微服務網關（Spring Cloud Gateway、Zuul 網關等）二合一，降低 50% 資源成本，同時縮短了請求時間，降低運維復雜度。

作為面向南北向的公網網關，使用 Waf 防護異常流量是很常規的需求，而且隨著互聯網環境變得越來越復雜，用戶對防護的訴求是持續增強的，常規做法是將流量先接入 Waf 安全網關，過濾后再將流量轉發給流量網關，最后到達微服務網關；那么升級云原生網關后，進一步需要思考的事情是，入口流量的安全能力是否還可以具備？

云原生網關通過內置 Waf 模塊直接對接阿里云的 Waf 云產品，使得用戶的請求鏈接只經過云原生網關就可以同時完成 Waf 防護能力，大大降低了網關的運維復雜度，圖示如下：

網關作為鏈路流量的入口，除了安全能力之外，還承接著入口流量/容量的管理、高可用等職責。

3、運行時高可用

無損上下線，提升微服務穩定性

當對極氪 APP 應用進行業務發版、彈性擴縮容等場景時，會遇到請求失敗率升高，POD 不斷重啟等問題。針對此問題，結合 MSE 產品能力，通過應用下線過程中自適應等待和主動通知、應用上線過程中就緒檢查、服務預熱等手段，實現微服務無損上下線發布，有效規避了發布過程中的流量損失，降低業務訪問失敗風險。同時通過引入 MSE 流量防控能力，針對核心業務場景落地相應技術手段，如接口限流降級、MQ 削峰填谷、數據庫慢 SQL 限流治理等，提高服務整體穩定性。

水平拆分，提升業務彈性伸縮能力

隨著業務的快速發展，極氪 APP 原架構下容量不足問題愈發突出，在面對新車發布、銷售活動、突發熱點情況時，無法快速進行水平擴展，并且大量核心業務庫都放在同個數據庫實例上，容易出現“一損俱損”。阿里云服務團隊推薦使用 Polardb-X 產品，將業務庫逐個剝離出來，并通過對業務大表水平拆分解決單表過大問題，提高數據庫層面水平彈性擴容能力。另外針對微服務彈性能力不足的痛點，輸出多可用區節點彈性伸縮、HPA、CronHPA 等容器彈性方案，提高核心服務在流量突發情況的應對能力。

流量防護與容錯

想象一下，在業務高峰期，當某些下游的服務提供者遇到性能瓶頸，甚至影響業務。極氪 APP 團隊正是遇到了這樣的問題，在某次架構遷移的過程中，遇到預料之外的慢調用，拖慢了系統，導致整體穩定性的抖動。如何避免這類問題？需要對部分非關鍵服務消費者配置一個熔斷規則，當一段時間內的慢調用比例或錯誤比例達到一定條件時自動觸發熔斷，后續一段時間服務調用直接返回 Mock 的結果，這樣既可以保障調用端不被不穩定服務拖垮，又可以給不穩定下游服務一些“喘息”的時間，同時可以保障整個業務鏈路的正常運轉。

突發的事情是非常多的，那么如何可以做好系統的高可用，讓系統在不確定的情況下工作在最優解上？極氪 APP 團隊先嘗試對 APP 大的層面做微服務穩定性治理，避免出現 APP 整體宕機的情況。然后對核心服務和接口做梳理，摸清上下游，對強依賴解耦和改造，并且根據監控、可觀測數據，確認核心服務配置什么合理參數。在這之后，多次對服務進行限流降級配置以及演練、優化，總結場景實踐規律，制定恰當的技術規范。

開發測試效率提升：在線服務測試

極氪開始在云上進行部署、發布、測試之后，他們遇到了如下問題：

部署完應用之后，應用是否健康？當線上出現了一個問題，怎么能夠快速發起一次請求，進行復現。
在服務上線之前，如何快速地驗證歷史功能是否都正常？
大版本上線前，修改的內容對性能有什么影響，上量之后會不會服務壓力過大？

為了做到安全隔離，研發環境、測試環境、預發環境、生產環境部署在不同的專有網絡 VPC 內，如果自建測試工具，需要解決測試工具到不同環境的網絡互通問題，企業 IT 人員明明只想要一個簡單的測試工具，卻因為上云之后，要解決復雜的云上網絡拓撲，遠遠沒有結束，為了能夠在辦公網使用該測試工具，還需要保證該測試工具能夠被辦公網訪問，此時又面臨著網絡安全的考驗。

云上的服務測試、壓測就是為了解決這個問題。 借助 FC 的彈性計算能力，一方面打通了云上網絡打通的問題，另一方面隨用隨彈，最大程度解決資源利用率的問題； 借助服務契約提供的內容，服務測試功能可以自動填充測試參數，測試時只需要進行值的修改，就可以發起測試。還可以根據提示將服務測試進行串聯，從而達到自動化回歸、壓測的目的。

4、發布態高可用

全鏈路灰度發布，實現白天隨時發版

隨著極氪汽車銷售越發火爆，其注冊用戶和每日活躍用戶快速增長，需要支持的業務場景和新功能也越來越多，平均兩三天一個小版本、半個月一個大版本的升級頻率。為了不影響白天業務高峰，每次發版只能選擇在凌晨業務低峰期進行，想象一下如果研發/運維人員每次都集中在晚上發布，那么這些參與發布的同學第二天的工作效率將會受到影響；如果晚上選擇較少的人參與發布，那么當出問題的時候止血措施很可能會來不及實施，故障責任也不好劃分。

阿里云服務團隊幫助極氪團隊一起制定和落地全鏈路灰度發布方案，通過部署灰度版本，并按照流量比例或客戶特征進行灰度驗證，驗證完畢后進行生產發布并切流，滿足了客戶小版本白天隨時發布的訴求。針對客戶核心業務鏈路上多個微服務同時需要發版的場景，基于 MSE 云原生網關和流量灰度打標來實現多業務的全鏈路灰度，覆 CDN、網關、MQ、配置、數據庫等灰度場景，通過這種方式讓客戶在不需要更改任何業務代碼的情況下實現多業務白天發版，同時通過逐步流量放大進行驗證，如出現問題可及時回切流量，降低了白天發布可能導致的穩定性風險。同時通過改造云效流水線，幫助客戶實現核心業務自動化發布，更好地提升部署效率。

開發環境隔離

微服務的迭代存在非常多的依賴，業務的開發人員無法在本地完成開發，必須使用一整套完整的環境，才能正常的進行開發和聯調。極氪 APP 系統中的應用數目有數十個，如果每一個開發環境都維護一整套 APP 系統所具備的微服務環境，需要消耗大量的人力以及資源的成本。

理想中的開發環境邏輯隔離應該是這樣的，基于 git-branch 的設計理念，保留一套穩定的基線環境，各個分支的開發同學通過邏輯環境隔離的方式快速拉起需要開發的 feature 環境。我們只需要維護一套完整的基線環境，在增加 feature 開發環境時，只需要單獨部署這個 feature 所涉及到改動的應用即可，而不需要在每個 feature 環境都部署整套的微服務應用及其配套設施。其中，基線環境包含了所有微服務應用，也包含了服務注冊中心、域名、SLB、網關等其他設施，而 feature 環境中只包含了這個 feature 中需要修改的應用。這樣維護 n 套 feature 環境的成本，就變成了加法，而不是原來的乘法，由 n × m 變成了 n ＋ m。這樣算下來相當于零成本增加 feature 環境，這樣我們就可以放心地擴容出多套 feature 環境。極氪團隊使用微服務治理中的全鏈路灰度方案實現“流量泳道”，做到快速拉起隔離的開發環境，在提升研發效率的同時節省了一筆不菲的成本開銷。

全鏈路壓測與調優

為了摸清楚 APP 能夠真實承載的并發容量，需要對核心業務接口進行多輪全鏈路壓測和調優。對于系統容量評估、優化與防護主要概括為四點：壓測、觀測、限流、擴容。系統高可用體系建設必須從實踐中出真知，極氪團隊通過壓測對 APP 服務能力進行性能摸底，評估性能是否能接受。如果性能不能接受的話那么需要對性能進行擴容和優化；性能符合預期，那么要配置對應的限流規則，以防超出預期的流量將服務打垮。

整個壓測演練的過程中需要做到邊壓、邊看、邊限、邊擴，不斷對對數據進行反饋調整，最終建立保證業務系統高可用的體系。通過全鏈路壓測，不僅讓大家對 APP 系統的性能、容量做到心中有數，更增強了整套生產系統升級至云原生架構的信心。

提升任務調度類服務的運維管理效率

針對極氪 APP 內，社區定時推薦、在線訂單定時確認、用戶定時通知等場景，客戶利用 MSE 任務調度 SchedulerX 統一管理和調度定時任務。該方案具備以下優勢。

異步任務統一管理：支持將不同來源和類型的異步任務統一管理，任務類型覆 crontab 定時任務、K8s Job，兼容開源框架 XXL-JOB、ElasticJob、Spring Schedule，并支持 Java SDK/Agent 實現自研 SchedulerX 任務，任務運行來源覆蓋云上異步任務和云下 IDC。

高可靠的秒級調度能力：任務調度 server 端免運維，無需擔心機器宕機等高可用風險影響重點任務調度失敗，大幅降低運維成本；實時性要求高場景支持高精準調度，最小支持 1 秒級調度能力。

低成本海量數據處理：海量任務分布式并行執行，全面加快任務執行速度，相比消息隊列避免調用高峰拖垮在線業務，大幅降低使用成本。

實踐四：可視化數據分析系統，簡化運維管理，聚焦業務開發

隨著業務加速發展，公司迫切需要一個完善的 BI 數據平臺來輔助各業務負責人做決策支撐。眾所周知數據對于一個公司具有非常重要的價值，好的數據承載工具顯得尤為重要。極數 BI 應運而生，目的是讓企業資產數據快速流動起來，幫助企業構建自上而下的決策分析體系，實現業務流程和數據分析直接協同，提升企業內各種人員的數據分析效率，形成數據消費和價值洞察的企業文化。極數 BI 定位是一款面向極氪經營管理全體系的可視化數據分析系統，已覆蓋訂單、車輛、交付、線索、用戶、市場營銷、市場分析、威睿工廠等場景。隨著業務的快速發展，BI 平臺開始接入越來越多的業務需求，在和各業務團隊落地過程中，也面臨很多使用問題，比如：如何簡化維護管理、如何實現多版本并行運行、如何保障業務 SLA 等。

基于 Serverless 技術的發展趨勢判斷，極氪選擇使用 SAE 承載這部分業務。SAE 是面向業務側提供的一站式全托管 K8s 平臺，集成了云原生微服務治理和應用可觀測能力，使用和維護體驗更加簡單，能讓開發側更加聚焦業務價值。尤其是對 BI PAAS 平臺來講，多租隔離、權限管理、應用管理、簡化業務使用等關鍵需求，實現起來更加友好。

SAE 的使用主要在 3 個方面產生了不錯的收益：

第一，聚焦業務應用，提升開發效率。極數 BI 做為公司業務團隊的“決策參謀”，面臨復雜多變的需求，還需要能快速開發上線，采用 SAE 可以省去環境搭建的過程，代碼寫好后 1 分鐘左右就能部署上線進行測試驗證，SAE 還集成好了日志監控能力，排查問題很方便。其他業務方接入使用的時候，也不用關心資源的創建和擴容，環境也都是一致的，大家都聚焦在業務開發和維護上，極大提升了研發效率。

第二，簡化維護管理。SAE 提供了整套的應用管理能力和彈性伸縮能力，結合云效流水線實現了自動化的創建、更新流程，資源也是隨開隨用，業務方接入部署的時候，通過流水線自動就把資源和環境創建出來并完成應用部署，也就是應用即資源，Node 節點的高可用、擴縮容都不需要操心。

第三，多租戶隔離。SAE 的命名空間提供了完美的資源隔離能力，可以非常方便的用來做環境和權限劃分，極大程度上簡化了我們多租隔離的實現成本。

實踐五：車聯網數據采集分析，免運維、彈性可擴展

為了提升智能化水平，新能源汽車對車聯網的投入也是非常巨大的。其中如何實時的把海量車端數據采集到云上進行數據分析，并能支持日益增長的在線車輛數量，具備自動彈性擴容的能力至為關鍵。借助 OSS + FC 的組合，以完全 Serverless 化的模式接入端側數據上報，整體具備免運維、彈性可擴展的能力。 從車端上報的數據，以加密的形式上傳到 OSS，上傳成功后會自動觸發函數計算對數據做校驗、解密和分析，然后把清洗后的數據寫入到Kafka供后續的業務流程分析使用。整體方案不僅解決了彈性擴展問題，還極大的優化了資源利用率。此外，FC 天然可以應對大流量沖擊，保障系統穩定性和容災能力。