Categories
程式開發

小鵬汽車技術中台實踐 :微服務篇


“中台”這個概念火了一年多了,年初的時候又“火”了一次。相信任何事物都有它的兩面性,正如我們做架構的時候其實也一直在做取捨。

小鵬汽車的技術中台(Logan)已經快兩歲了,今天我們不討論該不該做技術中台,只說說中台給我們帶來了什麼。

不管黑貓白貓,捉到老鼠就是好貓。

一、背景

小鵬汽車的智能離不開復雜系統的支撐,其特有的互聯網基因要求業務能夠應對市場的迅速變化:快速響應、快速試錯、快速創新。同時,為了給客戶提供優質服務,系統需要更高的可靠性,降本增效也是公司快速發展過程中特別關注的。

技術中台正好契合了公司上述所有需求。在公司的引領和推動下,2018年4月召開了小鵬汽車技術中台的啟動會,同年5月底團隊成立。技術中台團隊始終堅持“兵不在多而在精”的原則,近兩年高峰時期團隊也未超過 10 人。

也許有人會懷疑,一支足球隊規模的團隊,到底能做出個什麼樣的中台來?

簡單來說,小鵬汽車的技術中台主要由以下及部分組成:

  • 基於SpringCloud、Kubernetes自研的微服務體系平台
  • 遵循業界標準的自服務中間件平台
  • 可監可控的高性能中間件SDK

接入中台的應用不需要寫一行業務代碼,可以立即具備以下能力:

  • 生產級應用:健康檢查、節點部署反親和性、自動擴縮容、JVM GC參數調優、資源隔離、滾動部署
  • 自動接入網關:限流、熔斷、訪問控制
  • SpringBoot使用最佳實踐:配置調優、profile標準化、線程池和連接池調優
  • 自動化CICD:自動化鏡像生成、自動處理git的tag、代碼質量
  • 豐富的問題定位手段:日誌中心、註冊中心、微服務全方位監控(JVM/Trace/Metrics/告警)
  • 系統級無埋點監控、業務Metrics提供擴展機制
  • 調用鏈
  • 數據可視化:豐富的研發數據展示
  • 配置中心提供不停機,動態調整應用配置能力

對外保證:

  • DevOps提高效率:開發、部署、問題定位
  • 生產可用性:彈性、容錯

小鵬汽車技術中台實踐 :微服務篇 1

如上圖,小鵬汽車的技術中台分為微服務中台和雲平台兩大部分:

  • 雲平台:為技術中台提供底層的基礎支撐,基於主流的容器技術Docker和K8s構建,提升資源的利用率、降低運維成本;自研了容器化的部署平台,提供用戶友好的UI、日誌聚合、跨集群部署、歷史修訂版;自定義CRD 封裝應用部署單元,以效率和可用性為目標,提供生產級應用最佳實踐,簡化應用在Kubernetes的生命週期管理;開發人員只需專注業務,通過CICD 標準化構建部署到雲平台;
  • 微服務中台:基於 SpringCloud 打造,提供微服務的管理、治理、監控、統一標準化配置,助力系統微服務化,提升生產可用性;並通過研發中台提升研發、測試、問題定位效率。

本文主要分享微服務中台的實踐經驗。

二、微服務中台

2.1 技術選型

歷史背景:

  • 微服務功能薄弱:原有部分服務統一使用 SpringBoot + Dubbo 架構,具備微服務的初步形態,歷史負擔小,但版本不統一;且當時的 Dubbo 生態,無法提供足夠的監控和治理功能;
  • 缺少有效的監控手段:運維監控平台使用 Zabbix 和 Open-Falcon,缺乏對應用自身的業務監控和告警;
  • 問題排查效率低:目前有部分日誌通過agent(FileBeat)進行採集,大數據根據需要做分析,而應用無法實施查看系統日誌;缺少調用鏈的支持,由於分佈式系統的複雜性,出現問題較難定位;
  • 無法運行時修改配置:需要重新打包或修改配置,重啟應用:用戶有感知、配置缺乏回滾、審批、灰度;
  • 公共基礎功能還沒有統一:比如連接池使用、第三方依賴版本、代碼文件編碼、日誌格式;
  • 缺少項目腳手架:創建新項目多從舊項目中復制黏黏基礎代碼,無法保證持續的更新;
  • 代碼質量難度量:缺乏代碼質量管理平台,大數項目缺乏單元測試。

鑑於以上原因,開源軟件及產品被列入首選,同時結合現實情況及需求在開源的基礎上進行功能的擴展開發。只有實在沒有選擇的情況下,我們才會考慮自造輪子。

  • Netflix OSS 經過了大規模的生產級驗證,功能強大,組件豐富
  • SpringCloud 基於SpringBoot,社區支持強大,有著開發效率高、更新頻率快、等優勢,且集成了Netflix 的眾多組件,降低了使用門檻,它能夠與同樣使用SpringBoot 的原有服務完美兼容,降低接入的時間和人工成本。

部分正在使用的組件:

  • API 網關 Zuul
  • 服務註冊發現 Eureka:基於 AP 模型
  • 客戶端負載均衡 Ribbon
  • 服務熔斷 Hystrix
  • 聲明式的服務調用 Feign
  • 邊車 Sidecar:集成了服務註冊和發現,以及 Zuul 用於實現跨語言的微服務調用
  • 分佈式跟踪 Sleuth & Zipkin:支持 OpenTracing 協議
  • 網關限流 spring-cloud-zuul-ratelimit:結合 Zuul一起使用,支持路徑、請求源、用戶等維讀的請求限流
  • 應用指標數據 Micrometer:支持 prometheus
  • 擴展包 Actuator:提供管理接口
  • 服務管理及監控 SpringBoot Admin
  • 自動 API 文檔 Auto Restdoc:減少代碼侵入
  • 配置中心 Apollo:攜程出品的配置中心實現,支持配置的熱更新(借助 SpringCloud 的 Context Refresh 概念
  • 數據庫連接池 Hikari:支持輸出 metrics
  • 自研項目生成器、文檔中心等

此外,中台通過自定義的 SDK 提供對上述功能開箱即用,包含組件的配置調優、Metrics輸出、統一日誌、框架 Bug 的緊急修復以及功能擴展。

2.2 系統架構

小鵬汽車技術中台實踐 :微服務篇 2

三、可用性提升

參考官方的文檔,跑個 DEMO 是很容易的,但是真正在生產級環境中使用又會踩不少坑。

可用性對於車企來說尤為重要,甚至說高於一切也毫不誇張,公司對這一方面也格外重視。

經過兩年的不斷踩坑填坑,同時藉助雲平台的能力(比如自我修復、滾動升級等功能)提升了系統的可用性;同時降低應用發佈時對業務的影響:從原本的低峰時間版本升級,提升到隨時部署升級,甚至部分服務已經可以實現自動擴縮容。

下面列出我們踩過的一部分坑,也是我們不斷修煉提升可用性過程中關注的問題點。

3.1 Eureka

小鵬汽車技術中台實踐 :微服務篇 3

a. 服務實例上下線的被發現延遲

使用默認配置的情況下,實例正常上、下線的被發現延遲最大為90s ,比如,服務B(提供方)的一個實例上/下線,服務A(調用方)在最長90s之後才會發現。這與 Netflix 的設計有關:

  1. Eureka 服務端的三級緩存模型

    a. registry :存儲服務實例信息 (服務上下線實時更新)

    b. readWriteCacheMap :讀寫緩存 (實時從 registry 中更新,過期時間 180s )

    c. readOnlyCacheMap :只讀緩存,默認從這裡獲取服務信息 (每隔 30s 從 readWriteCacheMap 更新)

  2. Eureka 消費端每隔 30s 請求 Eureka 服務端獲取增量更新,然後更新本地服務列表

  3. Ribbon 客戶端每隔 30s 從 Eureka 客戶端的本地服務列表中

可通過修改配置縮短上下線的被發現延遲:

  1. 縮短 readOnlyCacheMap 的更新周期
  2. 縮短服務消費端獲取增量更新的周期
  3. 縮短 Ribbon 客戶端從 Eureka 客戶端的本地服務列表的更新周期;或者將拉的模式,改成推的模式 (需要代碼提供新的實現)

b. 非正常下線的被發現延遲

上面提到默認配置下被發現的延遲最大是 90s。運行過程中不可避免的會出現非正常下線的情況,比如進程被強殺(kill -9),實例來不及通知註冊中心進行註銷操作就退出了。這種情況下,此實例的信息會存在服務調用方的 Ribbon 、實例列表中最長達 240s。如果是 2 個實例的話,會有 50% 的請求受到影響。這同樣源於 Netflix 的設計:

  1. 實例上線完成註冊後,會每個 30s 向註冊中心(Eureka 服務端)發送心跳請求
  2. 實例續約超時時間:實例超過 90s 未發送發送心跳才會被註冊中心清理
  3. 註冊中心的清理操作是個定時任務,間隔 60s

可通過修改配置縮短上下線的被發現延遲:

  1. 縮短心跳間隔
  2. 縮短實例約的超時時間
  3. 縮短清理任務的工作週期

c. 自我保護模式到底開不開?

Eureka是基於 CAP 理論的 AP 模型,用於保證分區容錯性,但這也導致註冊信息在網絡分區期間可能出現不一致,自我保護功能是為了盡可能減少這種不一致。

自我保護(self preservation)是Eureka的一項功能,Eureka註冊表在未收到實例的心跳情況超過一定閾值(默認:85%)時停止驅逐過期的實例。

解決了 b 中的延遲問題,必然會導致自我保護模式不准確。

解釋自我保護模式的工作原理,需要另開一篇文章來說。

d. 一個深坑

解決了 b 中的延遲問題,還會帶來一個坑更深的坑:極低的概率下,實例啟動後本地處於 UP 狀態,而遠端(註冊中心)的狀態持續處於 STARTING 狀態,且無法更新。這會導致實例實際正常運行,而且對服務消費者不可見。

這種情況在 Kubernetes 環境下尤為恐怖:實例本地狀態為 UP ,健康狀態也為 UP 。在 Kubernetes 的滾動升級模式下,舊的實例為刪除,新的實例正常運行,卻對消費端不可見。

問題的分析、重現方式已經記錄在Netflix Eureka的 issue(又是一長​​篇,目前只有英文)中,Pull Request 也已經合併到了 1.7.x 分支。不過嘛,呵呵,一直沒有發布新版本。

注:在技術中台運行一年多,生產環境累計出現的次數不到 10 次,不是 2 個實例運行的情況下沒有對請求出現影響。

3.2 Ribbon的容錯

Ribbon 大家常聽到的就是負載均衡,但是除了負載均衡之外,它還提供容錯的能力:重試 。

  • 遇到異常時進行重試:默認是 ConnectException 和 SocketTimeoutException ;
  • 重試次數:單個實例的重試次數( ribbon.MaxAutoRetries 默認:0),重試幾個實例( ribbon.MaxAutoRetriesNextServer 默認:1)。怎麼理解?比如 A 有4個實例:a1、a2、a3、a4。路由請求到 a1 的時報 ConnectException 異常,重試的時候不會再對 a1 進行重試(單個實例重試次數 0)。假如重試的對象 a2 也報同樣的異常,則會放棄繼續重試(重試 1 個實例);
  • 是否對所有操作重試: ribbon.OkToRetryOnAllOperations (默認: false ,即只對滿足條件的 GET 請求進行重試),其實對應的也就是常說的 HTTP 動詞: GET 、 POST 、 DELTE 等等。

這裡有個隱藏的坑,就是加入開啟了對所有操作重試的情況下,且出現SocketTimeoutException時,可能會導致一致性的問題:

因為 SocketTimeoutException 不只是連接超時,還有讀取超時 。假如一個 POST 請求會更新數據庫,出現客戶端的讀取超時 ,但是服務端可能在客戶端斷開後完成的更新的操作。如果客戶端進行重試,則會再次進行更新。

3.3 SpringBoot Tomcat

SpringBoot Tomcat 的優雅退出,不知為何官方沒有實現,實在匪夷所思。

為什麼需要優雅退出?當 Spring 上下文關閉時,假如有未處理完的請求,不等請求處理完畢就直接退出。從健壯性或者一致性方面考慮,並不是一個好的解決方案。

理想的方案:收到 Spring 上下文關閉事件,阻止 Connector 接受新的請求,然後對線程池執行 #shutdown() 的操作並等待隊列中的請求處理完成。當然這裡不能無限期的等待下去(滾動升級無法繼續),設置一個超時時間比如 30s 或者 60s。如果還沒執行完,那就是執行 #shutdownNow() ,讓未完成的操作自求多福吧。

3.4 HttpClient連接池的Keep-Alive

小鵬汽車技術中台實踐 :微服務篇 4

這也是我們生產中遇到的一個問題,會在凌晨的低峰時段偶發。異常如下:

org.apache.http.NoHttpResponseException: The target server failed to respond

Caused by: org.apache.http.NoHttpResponseException: 10.128.61.43:8080 failed to respond

HttpClient 連接池創建的連接初始默認的有效期(timeToLive)是 900s,後續收到響應後會嘗試從響應的頭信息中獲取 KeepAlive: timeout=xxx 服務端連接的保持時間,然後再更新連接的有效期。後續請求從連接池獲取連接後,會再次檢查有效性,避免使用過期的連接發送請求。

參考Tomcat 8.5 配置,其中也提供 Keep-Alive 相關的配置:

keepAliveTimeout: 默認為60s. 見org.apache.coyote.http11.Constants#L28.

maxKeepAliveRequests: 默認為100. 設置為1, 禁用keep alive; 設置為-1, 無限制.

SpringBoot中通過 server.connectionTimeout 來設置Tomcat的 keepAliveTimeout ,如果未設置,則使用Tomcat的默認配置。

大寫的但是 :Tomcat 並沒有在響應頭部帶上 Keep-Alive:timeout=60 。

可通過增加過濾器–在響應頭部增加 Keep-Alive 的 timeout 配置的方式來解決。

3.5 滾動升級時的可用性保障

小鵬汽車技術中台實踐 :微服務篇 5

微服務中台運行於雲平台之上,應用的升級模式為滾動升級:對服務進行升級時會先創建新版本的實例,待相應的檢查(借助Actuator 提供的/health 接口)通過後,再將舊版本的實例下線。

即使完成 3.1 中 a 和 b 兩項的優化,舊的實例還會存在於消費端的本地緩存中一段時間,當然,借助 Ribbon 的容錯可以避開這個問題,但是重試會降低吞吐。

借助 Kubernetes 的 Pod 的 preStop lifecycle hook,在 Pod 退出時會先調用 preStop 配置的腳本。在腳本中調用本地服務的 /service-registry/instance-status 接口,將實例的狀態修改為 DOWN ,並等待一段時間(比如 30s)。之後才會將退出信號放行到容器中,完成後續的退出動作。以此來降低 Eureka AP模型帶來的不一致隱患。

四、功能擴展

4.1 跨語言的微服務調用

小鵬汽車的業務比較複雜,除了主要的 Java 技術棧之外,還有基於 CPU/GPU 的 Python應用,以及 Node.js 應用和前端應用。

而中台的出發點是功能的複用,如何讓非 Java 語言的應用使用到中台的能力?

小鵬汽車技術中台實踐 :微服務篇 6

我們的做法是藉助 Sidecar 模式實現基礎功能下沉,與應用解耦,將 SDK 中的功能,下沉到獨立進程中。

對於我們運行在 Kubernetes 上的應用來說,實現這一點就更容易了:在 Pod 中增加一個 Sidecar 的容器。

同時 Sidecar 還給我們帶來了意想不到的效果:

  • 通過抽像出與功能相關的共同基礎設施到一個獨立進程,降低了微服務代碼的複雜度;
  • 因為你不再需要編寫相同的第三方組件配置文件和代碼,所以能夠降低微服務架構中的代碼重複度;
  • 降低應用程序代碼和底層平台的耦合度,使應用聚焦於業務功能,也方便基礎設施的迭代演進。

當然目前的實現也不是很完美,sidecar 的實現,我們用的是 spring-cloud-netflix-sidecar 。是的,Java 的實現很重,對資源還存在一定的浪費。但是戰略有了,戰術的選擇是多樣的,比如 C++ 實現的 Envoy 。

因此當前的方案 不只是一次嘗試,也是一個佈局 。

4.2 統一日誌

服務的容器化,允許我們在統一了日誌格式後,將日誌直接輸出到標準輸出/錯誤。通過 Docker 的 json-file driver 統一落盤到 Node(Kubernetes的工作節點)上。再經由以 DaemonSet 方式運行採集器掛在日誌目錄對日誌進行採集。

詳細的工作方式及調優,請期待雲平台實踐篇(雲平台的能力不僅限於此)。

五、CICD

小鵬汽車技術中台實踐 :微服務篇 7

技術中台同樣提供了基於 Jenkins 流水線(Pipeline)的CICD 平台,經歷過兩個階段:項目級的流水線和平台級的流水線。

這兩個流水線有什麼不同?這個跟平台的發展階段相關。平台發展之初,由於團隊規模小,在 CICD 平台上投入的成本相對較少。由於一開始接入的系統不多,流水線的腳本都放在各個項目的代碼倉庫中(項目級的流水線),每次腳本更新都要去各個項目中更新。隨著接入的系統越來越多,更新的成本變得越來越高。

因此我們在後續的演進中進一步將流水線提升到平台級,即平台上的系統使用統一的流水線腳本,腳本保存在 GitLab 倉庫中,並提供版本控制。

借助 Job DSL 插件,我們將抽象的項目元數據轉化為 Jenkins 作業。在項目註冊到平台時,會自動為其創建作業。

每個作業的結構基本一致,包含:

  • Folder Pipeline Library:與 Global Pipeline Library 一樣,都是 Shared Library 的實現。區別是前者包含的是項目相關的信息,比如所處的 Gitlab(存在多個 Gitlab)的訪問信息。後者是所有作業共享的,包含了構建腳本;
  • Project Metadata:抽象項目的元數據,比如名稱、倉庫地址、語言等;
  • Pipeline Script:流水線的入口,啟動之後使用 Global Pipeline Library 中的構建腳本進行構建。

外部對接雲平台、Sonar、Nexus 以及自動化測試平台。

六、總結

微服務中台不僅僅是技術上的開發工作,還包括中台的落地,以及打造各種配套的功能設施,比如流程的簡化、DevOps還有表面上無法體現的各種優化和修復工作。

後續除了雲平台,我們還會分享一些其他方向的經驗。 “生命不止,奮鬥不息”,小鵬汽車的技術中台也會持續演進。

作者介紹:

張曉輝:資深碼農,12 年軟件開發經驗。曾在匯豐軟件、唯品會、數人云等公司任職。目前就職小鵬汽車,在基礎架構團隊從事技術中台的研發。