全量容器化:騰訊雲日誌服務CLS的雲原生破局之道

圖片

圖片

👉騰小云導讀

數字化轉型的本質是一個企業不斷打破自我壁壘的過程,這種壁壘的打破通常來源於兩個方面,一個是技術重構,另一個是組織重構。本次分享主要側重的是技術重構方面,將圍繞如何實現應用現代化,以業務視角找到實現業務雲原生化的破局之道,從而獲得更高的業務價值。本文根據騰訊雲日誌服務研發負責人王國樑在 ArchSummit 2023上海站的演講內容整理而成。歡迎閱讀。

👉看目錄,點收藏

1 騰訊雲 CLS 的業務背景和挑戰

2 雲原生技術的“三個代表”

3 日誌服務 CLS 老舊系統架構挑戰分析

3.1 基礎設施混亂,應該如何改造和選擇?

3.2 有狀態應用如何轉化爲無狀態應用?

3.3 如何改造應用的配置管理?

3.4 如何平滑升級架構?

3.5 彈性伸縮,我們爲什麼需要它?

3.6 爲什麼需要流量防護和容錯?

3.7 可觀測能力的建設和研效?

4 日誌服務的雲原生化架構和收益

01、騰訊雲 CLS 的業務背景和挑戰

騰訊雲日誌服務(Cloud Log Service,CLS)是騰訊雲全自研的一站式、高可靠、高性能日誌數據解決方案。支持各種數據源 PB 級的數據接入,提供日誌採集、存儲、檢索、統計分析、數據加工、消費訂閱等能力,可以幫助客戶大大降低日誌運維門檻,並解決業務數據處理的各種訴求。

圖片

CLS 產品能力概覽

由於日誌和業務屬性關聯強,業務的高低峯也會直接導致日誌量的高低峯。所以與單個業務相比,日誌服務的流量洪峯波動狀況更加頻繁,也更加不可預估,可能瞬間就有幾十萬 QPS、GB/s 日誌寫入;

日誌數據應用場景也更加敏感,大量客戶會直接基於日誌配置告警、監控等實時性要求強的場景,就要求日誌從產生到可檢索出來的延遲一定秒級,更精確的來說要在3s以下,不然此時日誌的價值將大打折扣。

此外,CLS 在商業化初期,產品迭代非常快,日誌量從每天幾千萬條增長到十萬億條級別,擁有百億級數據秒級檢索分析能力。新增客戶的需求多且複雜,技術架構和基礎設施陳舊,在應對規模增長、性能要求、迭代需求等多方面壓力下,整個服務穩定性不足,研發團隊也頻於救火,甚至**影響客戶口碑、影響收入,這也是爲什麼我們必須要在技術上實現徹底的改造和升級。

02、雲原生技術的“三個代表”

雲原生技術對於我們而言究竟意味着什麼,這裏總結出“三個代表”:

圖片

  • 雲原生代表着最先進技術生產力的發展方向

    雲原生技術(容器、K8S、Serverless等)都是如今基礎設施先進生產力的代名詞,技術成熟且被廣泛應用;相反,如果基礎設施/技術理念還保持陳舊思路,那必然無法滿足當今業務需求,也會成爲企業/產品發展的阻礙。

  • 雲原生代表着技術企業產品競爭力的發展要求

    爆炸式的擴張和增長已成爲當今新產品和新應用的典型特徵,因此產品的研發、測試、發佈、交付、運維效率就直接決定了產品迭代週期,研效的提升一定程度上決定了我們的產品是否可以在關鍵時刻做到“快人一步”。

  • 雲原生代表着企業降本增效的技術保障

    企業內獨立的資源池、資源 Buffer 會導致業務之間嚴重的“貧富差距”,資源彈性能力差、低效使用直接影響企業運營成本;此外,企業內不同團隊的技術棧、架構和重複造“輪子”也會導致研發成本居高不下。

所以,在如今想要實現應用的現代化,雲原生技術改造已經成爲企業發展的必然選擇。

02、日誌服務 CLS 老舊系統架構挑戰分析

對日誌服務 CLS 而言,在架構上面臨的每一個問題都能決定產品最終的成敗,例如基礎設施混亂、應突發能力差、性能和穩定性差、服務治理困難以及資源浪費嚴重,運營成本高等。

圖片

3.1 挑戰一:基礎設施混亂,應該如何改造和選擇?

CLS 在21年絕大部分資源都還是物理機和虛擬機,這會帶來一系列問題。

圖片

首先是資源環境複雜,無論是機型差異、內核版本還是系統參數等,都會在某個不經意的時間點導致同樣版本的應用行爲不一致,對資源上線和維護的要求非常高。

物理機以及虛擬機擴容耗時又是另一個大問題,從提出資源需求到資源到位有時候需要幾個小時甚至幾天,導致業務側不得不提前囤資源,但即使囤積 20% 的資源對於業務也是一塊不小的成本;其他基礎設施的混亂,例如本地 IDC 和雲上管理運維繫統不匹配,監控告警以及觀測能力不一致等,成爲傳統應用面臨的最痛點。

基礎設施的發展也經歷了從物理機-虛擬機-容器的演進:

  • 服務器:一個服務器裏面運行多個業務進程,服務器爲物理機或虛擬機,正常每個業務進程是獨立的,也存在單個服務多進程的模式。

  • 富容器:富容器是企業打包業務應用、實現業務容器化過程中,採用的一種容器模式。在業務容器化過程比較受歡迎,因爲類似服務器模式,業務無需大的改造成本,也不會對開發和運維造成任何侵入性。一個容器運行多個進程,容器運行時內部自動運行 systemd 等進程作爲1號進程,然後自動將業務進程和其他輔助進程拉起。公司內部有 Tlinux 鏡像,支持業務使用富容器。

  • Sidecar 容器:容器內部只有一個業務進程。容器內的1號進程就是業務進程,一個應用可以由一個或多個容器組成,他們彼此獨立,可以單獨升級。

圖片

富容器優點在於基本不改變業務代碼和運維代碼情況下,快速從 CVM 遷移到容器;但本質上是服務器模式到容器的過渡,沒有從根本上改變應用的管理模式,只是把底層介質從服務器轉變爲容器。

但隨着容器技術的發展,這種模式逐漸消失,更多的還是回到容器本質,一個容器一個進程的模式。隨着 K8S 成爲容器編排的事實標準,這種模式更符合雲原生的技術要求,也成爲當前容器化的標準範式。

3.2 挑戰二:有狀態應用如何轉化爲無狀態應用?

雲原生改造過程中,業務無法規避的問題是如何對有狀態應用和無狀態應用容器化,CLS 在實踐過程的經驗是:儘量實現全部應用爲無狀態應用。

無狀態代表應用隨意橫向擴容、宕機甚至隨時隨地被刪除,對服務本身都不會有影響,以此提供高併發的服務能力和更高的容災能力。

圖片

有狀態和無狀態相比:

  • 有狀態本身需要保存狀態或用戶會話,這一定程度上就增加了處理的複雜性,而無狀態則不需要存儲任何信息;

  • 有狀態中一個請求只能被一個實例處理,無狀態中任何請求可以被任何實例處理;

  • 與無狀態應用相比,有狀態應用更加複雜,擴展更難;

  • 有狀態對於故障的容忍度低,有時候需要遷移和同步數據;而無狀態應用則不需要,這也是爲什麼我們期望,最好服務不存在有狀態的應用。

傳統業務大多都是有狀態的應用,那我們應該如何去改造應用架構呢?常見的可以通過兩種方式將服務從有狀態轉變爲(近)無狀態的服務:

  • 實現多個實例可以互相同步數據,任何一個實例異常都是對等的,可以容忍任意刪除和擴容;

    實現數據集中存儲,將狀態信息轉變爲存儲,實例只需從集中存儲拉取數據到本地緩存即可。

3.3 挑戰三:如何改造應用的配置管理?

雲原生改造過程會有一個新的問題是,在複雜的雲原生應用程序中管理配置信息是非常困難的,似乎到處都有配置。在使用基於微服務架構的雲原生應用程序中,配置問題會成倍增加。

有針對網絡的配置,比如路由規則、端口控制、負載均衡;有針對數據庫的配置,服務器的配置,還有衆多微服務中間件的配置。這些配置大多是零散存儲,並且缺乏管理的。

圖片

所以首先要爲所有配置統一可信來源,統一配置管理,或者叫配置中心。

此外,配置有些時候會被複制到各處。將一臺服務器中使用的配置複製到另一臺服務器,然後再複製到另一臺服務器。最終,可能會有數百個相同或幾乎相同的配置副本。

所以配置的版本管理就非常重要,保留對配置的所有更改的歷史記錄;進行更改時,可以記錄更改人和更改原因。

隨着時間的推移,配置會發生漂移,導致配置錯誤、應用程序故障甚至安全漏洞。其實每個副本的配置其實不盡相同,每個配置副本都需要進行小的更改,就需要定義變量並自動以完全相同的方式維護類似的配置文件,且不會在每次使用配置時發生變化漂移。

這就要求我們要能進行自動化的配置管理,使用 CI/CD 管道是現代雲原生應用程序的標準策略,部署管道應部署所有配置以及所有代碼。這可以實現變量的一致應用和對宏的更改,並確保所有更改都部署在需要配置的所有組件中。

爲了實現這種升級,我們需要改造老服務兼容新的配置模式,因此我們要解決另一個問題,就是如何平滑升級?

3.4挑戰四:如何平滑升級架構?

架構升級對業務無感知是我們追求的最終目標,要求我們要具備平滑的升級流程、可靠的灰度策略以及完善的可觀測能力。

圖片

我們的過程很清晰:

  • 金絲雀模式:從小地域、部分客戶開始切換,逐步灰度完成全部流量的切換;

  • 過程:老服務保持不變,新服務切換完成後仍舊保留2周,後續再下線;

  • 風險:風險極小,出現問題可隨時切回;

在升級之前我們需要做好很多工作,包括新老服務的兼容,方便隨時回滾切換;也包括升級預案的準備,以及我們如何驗證切換到新服務。

3.5挑戰五:彈性伸縮,我們爲什麼需要它?

圖片

實現彈性服務,就離不開彈性伸縮能力的建設。我們面臨3大主要場景的問題:首先是突增流量我們如何應對?提前擴資源勢必會導致大量的資源浪費;第二個是擴容資源量上來後,什麼時候縮容呢?不縮容造成資源浪費,縮容得快又怕來回抖動;最後一個是週期性的流量如何保護鏈路更加穩定?

在業務場景,我們首先需要實現的是應對突發流量,解決了這個痛點後,我們纔會考慮降低成本,成本有了保障後,我們纔會進一步考慮如何讓我們的服務更穩定。

所以,從這幾種場景我們可以總結彈性伸縮的“應突發、降成本、保穩定”的3步走策略:

  • 應突發: 利用 HPA 實現在正常水位之外的突增流量自動彈性擴容,保證服務質量;
  • 降成本: 利用 HPA 實現節省成本並且能夠應對突發;
  • 保穩定: 能夠感知服務鏈路上下游同步擴縮,以及用戶自定義指標彈性伸縮。

圖片

在實際的策略應用過程,我們還需要關注擴容和縮容的技巧:

  • 快擴容:儘快擴容出來 Pod 來承擔增長的流量;

  • 慢縮容:CPU 使用率短時間波動較大,縮容速度如果過快,很有可能導致縮容後利用率上升又需要擴容。

踐行這樣的策略和原則,彈性伸縮就能發揮最大的價值。

3.6挑戰六:爲什麼需要流量防護和容錯?

日誌服務其實是非常多業務的集合,同時面臨對外和對內兩方面的風險治理。

圖片

因此,CLS 設計了全鏈路接入和流量治理能力,可以應對每一個已知場景的問題:包括客戶端本地緩存、退避重試、異常上報實現端到端的觀測能力,接入鏈路實現基於泛域名的 DNS 隔離、限流、限頻、隔離拉黑等,可以應對異常上報和攻擊等;內部首先全彈性能力接入,實際場景可以實現分鐘級擴容上萬核心資源,針對依賴系統的容災降級以及最終的兜底恢復。

圖片

3.7挑戰七:可觀測能力的建設和研效

最後但也是最重要的問題:系統的可觀測能力

  • 被動發現問題:問題發現依賴客戶反饋,發現問題就是工單或故障;

  • 故障持續時長過長:發現問題過晚,故障可能已經持續了很久,影響大;

  • 故障範圍未知:很難給客戶及時反饋故障影響範圍以及恢復速度和預期;

  • 頻於救火:研發團隊苦,經常半夜和節假日處理故障,產品穩定差,導致業務口碑差,丟單風險大。

圖片

應用的可觀測其實已經超越了我們使用的監控和告警本身,需要從用戶視角、應用本身、中間件系統、基礎設施等多方面進行數據收集和分析,實現從代碼到用戶的端到端可觀測能力建設,包括監控大盤、業務分析、鏈路追蹤和智能運維等,實現統一的應用可觀測能力。

研效的提升主要有兩點:

圖片

CI 流水線的建設:我們現網有非常多的工單和問題,工單處理在某半年成爲負擔最重的任務,基於問題的自動化用例建設每次發佈都回歸歷史問題,爲了在短時間內將工單快速收斂,CLS 建設了 1000+ 用例,保障版本迭代的兼容性和穩定性;也包括代碼分析、單元測試覆蓋率等門禁。

應用的發佈編排:雲服務產品有幾十個地域,發佈任務之前每週需要投入2-3個人力,基於應用的編排在效率的提升非常明顯,也減少了人工犯錯的概率。

04、日誌服務的雲原生化架構和收益

經過上述一系列雲原生改造,最終日誌服務 CLS 實現的全自研架構目標:圍繞雲原生技術(容器、K8S、聲明式 API、彈性伸縮等),建設符合現代應用和數字化業務的發展需求架構。

圖片

整個架構演進花費了近1年的時間,經歷了三個比較大的階段,實現了從0到95%以上應用的容器化,運營成本節省2千萬+/年,減少2+HC,節省了10萬+核的資源,同時擴縮容耗時降低90%,資源利用率提升40%+。

圖片

同時日誌服務CLS 產品穩定性可達99.99%+,擁有適應客戶場景 PB 級突發流量的彈性接入能力;作爲平臺級雲服務,自身的雲原生改造也進一步助力客戶數字化升級的快速迭代和價值交付。

圖片

以上是本次分享全部內容,歡迎大家在評論區分享交流。如果覺得內容有用,歡迎轉發~

-End-

原創作者|leonglwang

技術責編|leonglwang

圖片

圖片

圖片

圖片

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章