極氪汽車APP系統雲原生架構轉型實踐

　　 前言

　　新能源汽車已經成為我國汽車市場再次崛起的關鍵支柱，隨著新能源汽車市場的快速發展，不同型別的品牌造車廠商呈現出百花齊放的態勢。極氪汽車是吉利控股集團旗下高階純電汽車新品牌，2021 年 4 月極氪釋出首款高階智慧電動車型--極氪 001，大獲市場好評，截至 2022 年 12 月，001 車型累計交付量突破 7 萬臺。連續 3 個月問鼎自主品牌 30 萬以上豪華純電車型銷量冠軍。

　　極氪堅持不止於車的服務體驗，除了為客戶提供卓越產品的同時，還透過極氪 APP 與使用者建立連線。極氪 APP 推出線上社群、訂閱出行、好物商城、極氪生活等多元創新舉措，實現了極氪產品的全生命週期管理以及使用者旅程的全場景覆蓋。從使用者想要了解相關車型，到有意向進行購買、提車使用、分享感受以及售後問題迅捷解決方案等各種環節的使用場景，都被整合到了這款 APP 之上。　　

　　“我之前對極氪汽車並不是很瞭解，極氪這款軟體對我的幫助非常大，我覺得這是很好的，同時也在極氪軟體裡面看到了自己想要買的車，關注極氪已經一年了，不僅可以瞭解極氪汽車知識~還能得極分~換商品~希望極氪多多上新實用商品~”

　　這是摘自 Apple App Store 的使用者評價。極氪 APP 既是使用者智慧控車隨時隨地掌握車況的車主服務好幫手，又能提供購買用車好物、共享社群活動的極致出行用車體驗，便於使用者獲取觸手可得的用車資訊，讓出行變得更加便捷有趣。

　　 雲原生架構探索的實踐歷程

　　雲原生技術發展

　　隨著極氪數字業務的飛速發展，背後的 IT 技術也在不斷更新迭代。極氪極為重視客戶對服務的體驗，並將系統穩定性、業務功能的迭代效率、問題的快速定位和解決視為構建核心競爭力的基石。公司副總裁劉昊表示，為快速響應使用者的需求，例如縮短一輛車的製造週期、便捷平滑地升級汽車作業系統等，企業從產品到使用者體驗到商業模式都需要創新。然而消費網際網路和傳統產業發展的經驗不足以完全滿足產業網際網路對成本、效率、質量等方面的高要求。雲原生是一個確定性的技術發展趨勢，能有效推動產業發展，驅動企業積極革新。極氪將持續投入，將雲原生能力賦能到企業內的研、產、供、銷、三電等更廣泛的業務領域。

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

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

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

　　這 2 個原則並不矛盾，相反，它們之間可以非常好的融合，這也是所有使用雲端計算的企業使用者都值得借鑑的架構選型標準。比如 Kubernetes 是典型的滿足開源開放標準的技術標準，阿里雲提供的 Kubernetes 產品可以簡化使用者的搭建成本，更好地與雲端計算資源進行整合。同時使用者依然可以基於開源 Kubernetes 的標準協議與 API 使用雲產品，這就是 2 條選型原則相互融合的最好體現。

　　業務容器化

　　雲原生趨勢下，Kubernetes 毫無疑問已經成為了企業新一代雲 IT 架構的基礎設施。從 2021 年開始，極氪就開啟了微服務和容器化改造計劃，將 IT 系統的底座逐步從虛擬機器遷移到 Kubernetes。

　　在 Kubernetes 平臺的選擇上，基於技術選型的 2 條原則，極氪選擇了阿里雲容器服務 ACK 。ACK 以阿里雲可靠穩定的 IaaS 平臺為底座，向下封裝了 30+ 款雲產品，形成了自動化運維和雲平臺互動的新介面，從而提升企業業務系統的彈性和自動化運維能力。　　

　　基於容器服務 ACK 的易用性以及整合能力，極氪 IT 系統容器化改造工作比預想中的要順利得多。對於每一個業務系統而言，從虛擬機器遷移到 Kubernetes ，僅僅是底層的承載發生了變化，不會涉及到太多的改造成本。在容器化改造的過程中，當極氪技術團隊遇到疑難問題的時候，可以第一時間從阿里雲獲得優秀實踐指導，包括叢集規劃、平臺運維、應用適配、安全防護、可觀測等多個方面，這也更進一步的提升了容器化改造的速度。

　　目前，極氪 APP 以及 SCRM 等系統，已經 100% 基於 Kubernetes。相比傳統的基於虛擬機器部署方式，容器化幫助極氪在資源利用率上提升了 20%，在運維效率上提升了 50%。在 2022 年 9 月透過了中國信通院雲原生技術架構成熟度評估， 同時極氪的技術團隊也在容器化改造的過程中，掌握了管理超大規模 Kubernetes 叢集的能力，並促成了更多雲原生新技術的運用。

　　統一微服務架構

　　與容器化改造幾乎同步進行的是對微服務架構的統一。在此之前，極氪的各個業務單元多種技術棧並存，彼此之間相互通訊複雜度高，專案成員的交接往往要耗費巨大的精力，極大程度上阻礙了數字化轉型的進展，因此微服務架構統一勢在必行。

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

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

　　Spring Cloud Alibaba 致力於提供微服務開發的一站式解決方案，包含開發分散式應用微服務的必需元件，方便開發者透過 Spring Cloud 程式設計模型輕鬆使用這些元件來開發分散式應用服務。這些元件一部分以 SDK 的形式整合到程式碼中，一部分以中介軟體的形式獨立執行，後者往往可以選擇託管版雲產品，以降低開發者的工作量。比如阿里雲微服務引擎 MSE 就提升了開箱即用的註冊配置中心 Nacos，以及雲原生閘道器。

　　穩定性與效率問題愈發凸顯

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

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

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

　　功能版本釋出迭代速度慢

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

　　技術架構缺少整體設計

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

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

　　穩定性：使用者數多起來之後，系統的穩定性就顯得比較重要，無論是使用者在某段時間遇到異常報錯增多，還是某一個功能點持續性地報錯，再大到系統有一段時間完全不可用，這些都會影響產品在使用者中的口碑，最後這種完全不可用的場景，甚至還可能成為微博等社交網路上的輿論熱點。

　　效率：隨著使用者的增多，相應的需求也越來越多，業務場景也越來越複雜，在這個時候測試可不是內部測試就能覆蓋所有的場景，需要加大在測試上的投入。雖然功能需求越來越多，但是迭代的速度卻要求越來越快，因為市場中已經有不少競爭者，大家競爭的一個關鍵就是速度，業務更需要跑得更快，開發節奏要快，測試節奏要快，發版節奏也要快。

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

　　業務鏈路入口升級

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

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

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

　　雲原生閘道器透過內建 Waf 模組直接對接阿里雲的 Waf 雲產品，使得使用者的請求連結只經過雲原生閘道器就可以同時完成 Waf 防護能力，大大降低了閘道器的運維複雜度，圖示如下：　　

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

　　微服務高可用探索

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

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

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

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

　　流量防護與容錯

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

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

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

　　極氪開始在雲上進行部署、釋出、測試之後，他們遇到了如下問題：

　　1. 部署完應用之後，應用是否健康？當線上出現了一個問題，怎麼能夠快速發起一次請求，進行復現。

　　2. 在服務上線之前，如何快速地驗證歷史功能是否都正常？

　　3. 大版本上線前，修改的內容對效能有什麼影響，上量之後會不會服務壓力過大？

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

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

　　全鏈路治理

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

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

　　阿里雲服務團隊幫助極氪團隊一起制定和落地全鏈路灰度釋出方案，透過部署灰度版本，並按照流量比例或客戶特徵進行灰度驗證，驗證完畢後進行生產釋出並切流，滿足了客戶小版本白天隨時釋出的訴求。針對客戶核心業務鏈路上多個微服務同時需要發版的場景，基於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 進行雲原生架構升級探索，提高了 C 端業務系統的穩定性和敏捷性，為衝擊更高的銷量目標提供了堅實的技術支撐。這僅僅是探索的開始，隨著雲原生架構的深入，業務的可用性將持續增強，從而為汽車終端使用者帶來更好的出行體驗和樂趣。