更強、更穩、更高效：解讀 etcd 技術升級的三駕馬車

點擊下載《不同的 雙11 技術：阿里巴巴經濟體雲原生實踐》

本文節選自《不同的 雙11 技術：阿里巴巴經濟體雲原生實踐》一書，點擊上方圖片便可下載！

做者 | 陳星宇（宇慕）阿里雲基礎技術中臺技術專家

導讀：etcd 是阿里巴巴內部容器雲平臺用於存儲關鍵元信息的組件。阿里巴巴使用 etcd 已經有 3 年的歷史, 在今年 雙11 過程當中它又一次承擔了關鍵角色，接受了 雙11 大壓力的檢驗。爲了讓更多同窗瞭解到 etcd 的最佳實踐和阿里巴巴內部的使用經驗，本文做者將和你們分享阿里巴巴是如何把 etcd 升級得更強、更穩、更高效的，但願經過這篇文章讓更多人瞭解 etcd, 享受雲原生技術帶來的紅利。

讓 etcd 變得更強

本節主要介紹 etcd 在性能方面的升級工做。首先咱們來理解一下 etcd 的性能背景。

性能背景

這裏先庖丁解牛，將 etcd 分爲以下幾個部分，以下圖所示：

每一部分都有各自的性能影響，讓咱們逐層分解：

1. raft 層：raft 是 etcd 節點之間同步數據的基本機制，它的性能受限於網絡 IO、節點之間的 rtt 等， WAL 受到磁盤 IO 寫入延遲；

2. 存儲層：負責持久化存儲底層 kv, 它的性能受限於磁盤 IO，例如：fdatasync 延遲、內存 treeIndex 索引層鎖的 block、boltdb Tx 鎖的 block 以及 boltdb 自己的性能；

3. 其餘還有諸如宿主機內核參數、grpc api 層等性能影響因子。

服務端優化

瞭解完背景後，這裏介紹一下性能優化手段，主要由服務端和客戶端兩個方面組成，這裏先介紹服務端優化的一些手段。

硬件部署

etcd 是一款對 cpu、內存、磁盤要求較高的軟件。隨着內部存儲數據量的增長和對併發訪問量的增大，咱們須要使用不一樣規格的硬件設備。這裏咱們推薦 etcd 至少使用 4 核 cpu、8GB 內存、SSD 磁盤、高速低延遲網絡、獨立宿主機部署等（具體硬件的配置信息）。在阿里巴巴，因爲有超大規模的容器集羣，所以咱們運行 etcd 的硬件也較強。

軟件優化

etcd 是一款開源的軟件，集合了全世界優秀軟件開發者的智慧。最近一年在軟件上有不少貢獻者更新了不少性能優化，這裏分別從幾個方面來介紹這些優化，最後介紹一個由阿里巴巴貢獻的 etcd 存儲優化。

1. 內存索引層。因爲索引層大量使用鎖機制同步對性能影響較大，經過優化鎖使用，提高了讀寫性能，具體參考：github pr；
2. lease 規模化使用。lease 是 etcd 支持 key 使用 ttl 過時的機制。在以前的版本中 scalability 較差，當有大量 lease 時性能降低的較爲嚴重，經過優化 lease revoke 和過時失效的算法，解決了 lease 規模性的問題，具體參考：github pr；
3. 後端 boltdb 使用優化。etcd 使用 boltdb 做爲底層數據庫存儲 kv, 它的使用優化對總體性能影響很大。

經過調節不一樣的 batch size 和 interval， 使咱們能夠根據不一樣硬件和工做負載優化性能，具體參考：github pr。

除此以外，新的徹底併發讀特性也優化了 boltdb tx 讀寫鎖性能，大幅度地提高了讀寫性能，具體參考：github pr。

最後介紹一個由阿里巴巴自主研發並貢獻開源社區的優化：基於 segregated hashmap 的 etcd 內部存儲 freelist 分配回收算法。

下圖是一個 etcd 節點的架構，etcd 使用 boltdb 持久化存儲全部 kv，它的性能好壞對 etcd 性能起着很是重要的做用。

在阿里巴巴內部大規模使用 etcd 用於存儲元數據，在使用中咱們發現了 boltdb 的性能問題。這裏給你們分享一下：

上圖是 etcd 內部存儲分配回收的核心算法。etcd 內部默認以 4kB 爲一個頁面大小存儲數據。圖中的數字表示頁面 id, 紅色表示該頁面正在使用, 白色表示沒有。當用戶刪除數據時 etcd 不會把存儲空間還給系統，而是內部先留存起來維護一個頁面池，以提高再次使用的性能，這個頁面池專業術語叫 freelist。當 etcd 須要存儲新數據時，普通 etcd 會線性掃描內部 freelist，時間複雜度 o(n)，當數據量超大或是內部碎片嚴重的狀況下，性能會急劇降低。

所以咱們從新設計並實現了基於 segregated hashmap 的 etcd 內部存儲 freelist 分配回收新算法，該優化算法將內部存儲分配算法時間複雜度從 o(n) 降爲 o(1), 回收從 o(nlgn) 也降爲 o(1), 使 etcd 性能有了質的飛躍，極大地提升了 etcd 存儲數據的能力，使得 etcd 存儲容量提高 50 倍，從推薦的 2GB 提高到 100GB；讀寫性能提高 24 倍。CNCF 官方博客收錄了這次更新，感興趣的讀者能夠讀一下。

客戶端優化

性能優化除了服務端要作的事情外，還須要客戶端的幫助。保持客戶端使用最佳實踐將保證 etcd 集羣穩定高效地運行，這裏咱們分享 3 個最佳實踐：

1. put 數據時避免大的 value, 大的 value 會嚴重影響 etcd 性能，例如：須要注意 Kubernetes 下 crd 的使用；
2. 避免建立頻繁變化的 key/value, 例如：Kubernetes 下 node 數據上傳更新；
3. 避免建立大量 lease 對象，儘可能選擇複用過時時間接近的 lease, 例如 Kubernetes 下 event 數據的管理。

讓 etcd 管理更高效

做爲基於 raft 協議的分佈式鍵值數據庫，etcd 是一個有狀態的應用。管理 etcd 集羣狀態、運維 etcd 節點、冷熱備份、故障恢復等過程均有必定複雜性，且須要具有 etcd 內核相關的專業知識，想高效地運維 etcd 有不小的挑戰。

目前在業界裏已經有一些 etcd 運維的工具，例如開源的 etcd-operator 等，可是這些工具每每比較零散，功能通用性不強，集成度比較差，學習這些工具的使用也須要必定的時間，關鍵是這些工具不是很穩定，存在穩定性風險等。

面對這些問題，咱們根據阿里巴巴內部場景，基於開源 etcd-operator 進行了一系列修改和增強，開發了 etcd 運維管理平臺 Alpha。利用它，運維人員能夠高效地運維管理 etcd，以前要先後操做多個工具完成的任務，如今只要操做它就能夠完成，一我的就能夠管理成百上千的 etcd 集羣。

下圖展現了 Alpha 的基礎功能：

如上圖所示，Alpha 分爲 etcd 生命週期管理和數據管理兩大部分。

其中生命週期管理功能依託於 operator 中聲明式的 CustomResource 定義，將 etcd 的集羣建立、銷燬的過程流程化、透明化，用戶再也不須要爲每一個 etcd 成員單獨制定繁瑣的配置，僅須要指定成員數量、成員版本、性能參數配置等幾個簡單字段。除此以外，咱們還提供了 etcd 版本升級、故障節點替換、集羣實例啓停等功能，將 etcd 經常使用的運維操做自動化，同時也在必定程度上保證了 etcd 變動的穩定性。

其次，數據做爲 etcd 的核心內容，咱們也開發了一系列功能進行重點保障。在備份上，數據管理工具支持按期冷備及實時熱備，且保持本地盤和雲上 OSS 兩類備份，同時也支持從備份上快速恢復出一個新的 etcd 集羣。此外，數據管理工具支持對 etcd 進行掃描分析，發現當前集羣的熱點數據鍵值數和存儲量，彌補了業界沒法提供數據管理的空白，同時該拓展也是 etcd 支持多租戶的基礎。最後，數據管理工具還支持對 etcd 進行垃圾數據清理、跨集羣數據騰挪傳輸等功能。

這些豐富的功能爲上層 Kubernetes 集羣的管理提供了不少靈活的幫助，例如用戶 A 原來在某雲廠商或自建 Kubernetes 集羣，咱們能夠經過遷移 etcd 內部的帳本數據的功能，將用戶的核心數據搬移至另一個集羣，方便地實現用戶的 K8s 集羣跨雲遷移。

利用 Alpha，咱們能夠作到透明化、自動化、白屏化，減小人肉黑屏操做，讓 etcd 運維管理更高效。

讓 etcd 變得更穩

本節主要介紹一些 etcd 穩定建設的技巧。你們知道 etcd 是容器雲平臺的底層依賴核心，它的服務質量、穩定程度決定了整個容器雲的穩定程度，其重要性無需贅述。這裏先介紹一下 etcd 常見的問題和風險分析，以下圖所示，主要分三個方面：

• etcd 自身：例如 OOM、代碼 bug、panic 等；
• 宿主機環境：例如宿主機故障、網絡故障、同一臺宿主機其餘進程干擾；
• 客戶端：例如客戶端 bug、運維誤操做、客戶端濫用 ddos 等。

針對這些風險點，咱們從如下幾方面入手：

1. 創建完善的監控告警機制，覆蓋客戶端輸入，etcd 自身以及宿主機環境狀態；
2. 客戶操做審計，高危操做如刪除數據作風控限流；
3. 數據治理，分析客戶端濫用，引導最佳實踐；
4. 按期數據冷備，經過熱備實現異地多活，保證數據安全；
5. 常態化故障演練，作好故障恢復預案。

總結展望：讓 etcd 變得更智能

本文分別從性能、穩定性、生態工具三個部分享了 etcd 變得更強、更快、更高效的技巧。在將來咱們還將爲讓 etcd 變得更智能而努力。如何讓 etcd 變得更智能是一個比較高級的話題，這裏簡單作一下展望。更智能的意思是指可使 etcd 的管理更加地聰明，更少的人爲干預，例如遇到一些故障，系統能夠自行修復等。

本書亮點

• 雙11 超大規模 K8s 集羣實踐中，遇到的問題及解決方法詳述
• 雲原生化最佳組合：Kubernetes+容器+神龍，實現核心系統 100% 上雲的技術細節
• 雙 11 Service Mesh 超大規模落地解決方案

「阿里巴巴雲原生微信公衆號（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的技術公衆號。」