作者 | 陳星宇（宇慕） 阿里雲基礎技術中臺技術專家
本文整理自《cncf x alibaba 雲原生技術公開課》第 17 講。
etcd 誕生於 coreos 公司，使用 golang 語言開發，是乙個分布式 keyvalue 儲存引擎。我們可以利用 etcd 來作為分布式系統元資料的儲存資料庫，儲存系統裡面重要的元資訊。etcd 同樣也被各大公司廣泛使用。
下圖為 etcd 的基本架構
如上所示，乙個集群有三個節點：乙個 leader 和兩個 follower。每個節點通過 raft 演算法同步資料，並通過 boltdb 儲存資料。當乙個節點掛掉之後，另外的節點會自動選舉出來乙個 leader，保持整個集群的高可用特性。client 可以通過連線任意乙個節點完成請求。
首先我們來看一張圖：
上圖是乙個標準的 etcd 集群架構簡圖。可以將 etcd 集群劃分成幾個核心的部分：例如藍色的 raft 層、紅色的 storage 層，storage 層內部又分為 treeindex 層和 boltdb 底層持久化儲存 key/value 層。它們的每一層都有可能造成 etcd 的效能損失。
首先來看 raft 層，raft 需要通過網路同步資料，網路 io 節點之間的 rtt 和 / 頻寬會影響 etcd 的效能。除此之外，wal 也受到磁碟 io 寫入速度影響。
再來看 storage 層，磁碟 io fdatasync 延遲會影響 etcd 效能，索引層鎖的 block 也會影響 etcd 的效能。除此之外，boltdb tx 的鎖以及 boltdb 本身的效能也將大大影響 etcd 的效能。
從其他方面來看，etcd 所在宿主機的核心引數和 grpc api 層的延遲，也將影響 etcd 的效能。
下面具體來介紹一下 etcd server 端的效能優化。
server 端在硬體上需要足夠的 cpu 和 memory 來保障 etcd 的執行。其次，作為乙個非常依賴於磁碟 io 的資料庫程式，etcd 需要 io 延遲和吞吐量非常好的 ssd 硬碟，etcd 是乙個分布式的 key/value 儲存系統，網路條件對它也很重要。最後在部署上，需要盡量將它獨立的部署，以防止宿主機的其他程式會對 etcd 的效能造成干擾。
附：etcd 官方推薦的配置要求資訊。
etcd 軟體分成很多層，下面根據不同層次進行效能優化的簡單介紹。想深度了解的同學可以自行訪問下面的 github pr 來獲取具體的修改**。
其他的效能優化也非常多，這裡我們重點介紹一下由阿里巴巴貢獻的乙個效能優化。這個效能優化極大地提公升了 etcd 內部儲存的效能，它的名字叫做：基於 segregated hashmap 的 etcd 內部儲存 freelist 分配**新演算法。
上圖是 etcd 的乙個單節點架構，內部使用 boltdb 作為持久化儲存所有的 key/value，因此 boltdb 的效能好壞對於 etcd 的效能好壞起著非常重要的作用。在阿里巴巴內部，我們大量使用 etcd 作為內部儲存元資料，在使用過程中我們發現了 boltdb 的效能問題，這裡分享給大家。
上圖中為 etcd 內部儲存分配**的乙個核心演算法，這裡先給大家介紹一下背景知識。首先，etce 內部使用預設為 4kb 的頁面大小來儲存資料。如圖中數字表示頁面 id，紅色的表示該頁面正在使用，白色的表示未使用。
當使用者想要刪除資料的時候，etcd 並不會把這個儲存空間立即還給系統，而是內部先留存起來，維護乙個頁面的池子，以提公升下次使用的效能。這個頁面池子叫做 freelist，如圖所示，freelist 頁面 id 為 43、45、 46、50、53 正在被使用，頁面 id 為 42、44、47、48、49、51、52 處於空閒狀態。
當新的資料儲存需要乙個連續頁面為 3 的配置時，舊的演算法需要從 freelist 頭開始掃瞄，最後返回頁面起始 id 為 47，以此可以看到普通的 etcd 線性掃瞄內部 freelist 的演算法，在資料量較大或者是內部碎片嚴重的情況下，效能就會急速的下降。
針對這一問題，我們設計並實現了乙個基於 segregated hashmap 新的 freelist 分配**演算法。該演算法將連續的頁面大小作為 hashmap 的 key，value 是起始 id 的配置集合。當需要新的頁面儲存時，我們只需要 o(1) 的時間複雜度來查詢這個 hashmap 值，快速得到頁面的起始 id。
再去看上面例子，當需要 size 為 3 的連續頁面的時候，通過查詢這個 hashmap 很快就能找到起始頁面 id 為 47。
同樣在釋放頁面時，我們也用了 hashmap 做優化。例如上圖當頁面 id 為 45、46 釋放的時候，它可以通過向前向後做合併，形成乙個大的連續頁面，也就是形成乙個起始頁面 id 為 44、大小為 6 的連續頁面。
綜上所述：新的演算法將分配的時間複雜度從 o(n) 優化到了 o(1)，**從 o(nlogn) 優化到了 o(1)，etcd 內部儲存不再限制其讀寫的效能，在真實的場景下，它的效能優化了幾十倍。從單集群推薦儲存 2gb 可以擴大到 100gb。該優化目前在阿里巴巴內部使用，並輸出到了開源社群。
這裡再提一點，本次說的多個軟體的優化，在新版本中的 etcd 中都會有發布，大家可以關注使用一下。
再來介紹一下etce 客戶端的效能使用上的最佳實踐。
首先來回顧一下 etcd server 給客戶端提供的幾個 api：put、get、watch、transactions、leases 等很多個操作。
針對於以上的客戶端操作，我們總結了幾個最佳實踐呼叫：
針對於 put 操作避免使用大 value，精簡精簡再精簡，例如 k8s 下的 crd 使用；
其次，etcd 本身適用及儲存一些不頻繁變動的 key/value 元資料資訊。因此客戶端在使用上需要避免建立頻繁變化的 key/value。這一點例如 k8s下對於新的 node 節點的心跳資料上傳就遵循了這一實踐；
最後，我們需要避免建立大量的 lease，盡量選擇復用。例如在 k8s下，event 資料管理：相同 ttl 失效時間的 event 同樣會選擇類似的 lease 進行復用，而不是建立新的 lease。
「阿里巴巴雲原生關注微服務、serverless、容器、service mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。」
k8s環境從零開始部署
1.vm上安裝centos7並配置ip 參考自 2.最簡版centos7還需要安裝的工具 配置yum源的時候一定要先安裝wget,不然還要把yum倉庫檔案移動回去,不然沒法正常使用yum 參考自 3.開始配置k8s環境 首先轉殖乙個虛擬機器當作node1,node2 node3 可以等node1配置...
入門 1 從零開始的HTML
html hypertext markup languge 超文字標記語言。乙個標籤被解析後會顯示標籤要表達的內容。單單乙個標籤就可以解釋成一張。總結 html標籤內存放各種元素的集合，是乙個資訊的載體 讀取，整理，計算顯示並渲染到頁面上 解析，渲染 瀏覽器與對應核心 瀏覽器核心firefox ge...
七 效能測試從零開始 LoadRunner入門
1.4 效能測試 工具的評估和選擇 我們可以看到，效能測試和一般 功能測試 不同的是，效能測試的執行是基本功能的重複和併發，因此我們在效能開始之前需要模擬多使用者，在效能測試進行時要監控指標引數，同時效能測試的結果不是那麼顯而易見，需要對資料進行分析。這些特點決定了效能測試更適合通過工具來完成。市場...