基於etcd實現大規模服務治理應用實戰 https://mp.weixin.qq.com/s/1VmMZlMEv-In9QKYeYOjiA

基於etcd實現大規模服務治理應用實戰

導讀：服務治理目前越來越被企業建設所重視，特別現在雲原生，微服務等各種技術被更多的企業所應用，本文內容是百度小程式團隊基於大模型服務治理實戰經驗的一些總結，同時結合當前較火的分散式開源kv產品etcd，不僅會深入剖析ectd兩大核心技術Raft與boltdb的實現原理，也會披露服務治理真實實踐的經驗，希望幫助大家在服務治理的道路上獲得更多幫助。

全文8243字，預計閱讀時間21分鐘。

一、服務治理概念介紹

服務治理是IT治理的一部分，它關注服務生命週期中的相關要素，其重點環節包括服務註冊和發現、服務平滑升級、流量監控、流量管控、故障定位、安全性等。

服務是需要"治理"的，但是治理是需要成本的，如果一個服務的業務邏輯簡單，執行流程清晰，出現問題也能及時定位和回滾，那麼該服務治理的成本可能非常低，甚至只需要人工處理就行，但是在複雜業務中，服務的提供者和服務的使用者可能分別執行在不同的程序中（甚至在不同的物理節點上），並由不同的團隊開發和維護。團隊協作和服務協同，都需要進行大量的協調工作。協調工作越多，複雜度越高，這樣就有了服務治理的需求，通過建設統一的服務治理平臺，就可以有有效的提升業務的服務治理能力，包括協同的規範化、實時監控，不斷優化呼叫鏈路的效率，以及輔助降低依賴複雜度，規避風險等。在大型業務系統中，服務治理已經是技術架構中必不可缺的一部分，也是整個業務系統最重要的基礎設施之一。

二、etcd介紹

2.1 etcd發展背景與相關競品介紹

2.2 etcd核心技術介紹

基於Raft協議實現資料高可用和強一致性

Leader選舉

日誌複製

安全性

boltdb儲存技術

檔案儲存設計

資料檔案全景結構

• metapage固定在page0與page1位置
• Pagesize大小固定在4096位元組

• bolt的檔案寫入採用了本地序（小端序）的模式，比如16進位制0x0827(2087)寫入的內容為2708000000000000

查詢設計

tx, err := db.Begin(true) // 開啟事務  if err != nil {      return  }  b := tx.Bucket([]byte("MyBucket")) // 根據名稱查詢bucket  v := b.Get([]byte("answer20")) // 根據key進行查詢   fmt.Println(string(v))  tx.Commit()

func (c *Cursor) search(key []byte, pgid pgid) {    p, n := c.bucket.pageNode(pgid)    if p != nil && (p.flags&(branchPageFlag|leafPageFlag)) == 0 {        panic(fmt.Sprintf("invalid page type: %d: %x", p.id, p.flags))    }    // 把當前查詢節點(page,node)壓入棧    e := elemRef{page: p, node: n}    c.stack = append(c.stack, e)    // If we're on a leaf page/node then find the specific node.    if e.isLeaf() {        c.nsearch(key)        return    }    // if node cached seach by node's inodes field    if n != nil {        c.searchNode(key, n)        return}    // recursively to load branch page and call search child node again    c.searchPage(key, p)}

三、百度基於etcd打造大規模服務治理建設思路

3.1 具體的挑戰

3.2 整體架構建設思路與方案

• 考慮到etcd跨機房呼叫的高網路延時，我們採用單機房部署，同時我們也實現了主備叢集切換的方案，解決在單機房例項全部宕機的情況下，etcd叢集不可用的問題。

• 為了降低平臺對etcd的強依賴，我們做了etcd降級使用快取的方案。在監控到etcd叢集的效能無法支援當前平臺的時候，使用快取儲存例項資料，能夠讓運維人員在恢復etcd之前，系統不受影響正常執行；etcd恢復之後，切換回etcd叢集繼續工作。

• etcd叢集的kv查詢效能很高，qps能達到10000以上。為了解決在極端併發下的效能問題，註冊中心採用多級快取提升查詢效率，降低對etcd的訪問壓力。

• 服務間呼叫使用直連的方式，請求不需要經過註冊中心進行轉發，呼叫基本沒有時間損耗。

• 考慮到將來服務例項數達到百萬級別，我們需要考慮架構的高擴充套件性。

• 使用者通過視覺化的管理平臺可以檢視已註冊的服務，也可通過管理平臺實時更新服務治理策略的配置，實時調整服務治理策略。

• 將呼叫日誌接入trace平臺，使用者可通過traceId在trace平臺查到整個呼叫鏈的記錄，便於出錯時進行快速的問題定位。

• 多語言 SDK，支援多種rpc技術，包括百度自研的rpc技術brpc(https://github.com/baidu/Jprotobuf-rpc-socket【java/go sdk】）和http jsonrpc協議等

3.3 關鍵的指標與運維目標

關鍵指標：

運維目標：

• 故障發現早

• 故障處理快

四、總結

基於etcd實現大規模服務治理應用實戰

導讀：服務治理目前越來越被企業建設所重視，特別現在雲原生，微服務等各種技術被更多的企業所應用，本文內容是百度小程式團隊基於大模型服務治理實戰經驗的一些總結，同時結合當前較火的分散式開源kv產品etcd，不僅會深入剖析ectd兩大核心技術Raft與boltdb的實現原理，也會披露服務治理真實實踐的經驗，希望幫助大家在服務治理的道路上獲得更多幫助。

全文8243字，預計閱讀時間21分鐘。

一、服務治理概念介紹

服務治理是IT治理的一部分，它關注服務生命週期中的相關要素，其重點環節包括服務註冊和發現、服務平滑升級、流量監控、流量管控、故障定位、安全性等。

服務是需要"治理"的，但是治理是需要成本的，如果一個服務的業務邏輯簡單，執行流程清晰，出現問題也能及時定位和回滾，那麼該服務治理的成本可能非常低，甚至只需要人工處理就行，但是在複雜業務中，服務的提供者和服務的使用者可能分別執行在不同的程序中（甚至在不同的物理節點上），並由不同的團隊開發和維護。團隊協作和服務協同，都需要進行大量的協調工作。協調工作越多，複雜度越高，這樣就有了服務治理的需求，通過建設統一的服務治理平臺，就可以有有效的提升業務的服務治理能力，包括協同的規範化、實時監控，不斷優化呼叫鏈路的效率，以及輔助降低依賴複雜度，規避風險等。在大型業務系統中，服務治理已經是技術架構中必不可缺的一部分，也是整個業務系統最重要的基礎設施之一。

二、etcd介紹

2.1 etcd發展背景與相關競品介紹

2.2 etcd核心技術介紹

基於Raft協議實現資料高可用和強一致性

Leader選舉

日誌複製

安全性

boltdb儲存技術

檔案儲存設計

資料檔案全景結構

• metapage固定在page0與page1位置
• Pagesize大小固定在4096位元組

• bolt的檔案寫入採用了本地序（小端序）的模式，比如16進位制0x0827(2087)寫入的內容為2708000000000000

查詢設計

tx, err := db.Begin(true) // 開啟事務  if err != nil {      return  }  b := tx.Bucket([]byte("MyBucket")) // 根據名稱查詢bucket  v := b.Get([]byte("answer20")) // 根據key進行查詢   fmt.Println(string(v))  tx.Commit()

func (c *Cursor) search(key []byte, pgid pgid) {    p, n := c.bucket.pageNode(pgid)    if p != nil && (p.flags&(branchPageFlag|leafPageFlag)) == 0 {        panic(fmt.Sprintf("invalid page type: %d: %x", p.id, p.flags))    }    // 把當前查詢節點(page,node)壓入棧    e := elemRef{page: p, node: n}    c.stack = append(c.stack, e)    // If we're on a leaf page/node then find the specific node.    if e.isLeaf() {        c.nsearch(key)        return    }    // if node cached seach by node's inodes field    if n != nil {        c.searchNode(key, n)        return}    // recursively to load branch page and call search child node again    c.searchPage(key, p)}

三、百度基於etcd打造大規模服務治理建設思路

3.1 具體的挑戰

3.2 整體架構建設思路與方案

• 考慮到etcd跨機房呼叫的高網路延時，我們採用單機房部署，同時我們也實現了主備叢集切換的方案，解決在單機房例項全部宕機的情況下，etcd叢集不可用的問題。

• 為了降低平臺對etcd的強依賴，我們做了etcd降級使用快取的方案。在監控到etcd叢集的效能無法支援當前平臺的時候，使用快取儲存例項資料，能夠讓運維人員在恢復etcd之前，系統不受影響正常執行；etcd恢復之後，切換回etcd叢集繼續工作。

• etcd叢集的kv查詢效能很高，qps能達到10000以上。為了解決在極端併發下的效能問題，註冊中心採用多級快取提升查詢效率，降低對etcd的訪問壓力。

• 服務間呼叫使用直連的方式，請求不需要經過註冊中心進行轉發，呼叫基本沒有時間損耗。

• 考慮到將來服務例項數達到百萬級別，我們需要考慮架構的高擴充套件性。

• 使用者通過視覺化的管理平臺可以檢視已註冊的服務，也可通過管理平臺實時更新服務治理策略的配置，實時調整服務治理策略。

• 將呼叫日誌接入trace平臺，使用者可通過traceId在trace平臺查到整個呼叫鏈的記錄，便於出錯時進行快速的問題定位。

• 多語言 SDK，支援多種rpc技術，包括百度自研的rpc技術brpc(https://github.com/baidu/Jprotobuf-rpc-socket【java/go sdk】）和http jsonrpc協議等

3.3 關鍵的指標與運維目標

關鍵指標：

運維目標：

• 故障發現早

• 故障處理快

四、總結