PowerDotNet平台化軟體架構設計與實現系列（05）：ETCD分散式鍵值存儲平台
ETCD目前在PowerDotNet已經被用於註冊中心和配置管理（常見的配置中心在PowerDotNet中僅僅是一個小小的模組而已）中，作為基礎設施的重要組成部分，ETCD的重要性不言而喻。
本文簡單總結介紹下個人開發使用和管理ETCD的一些經驗。
ETCD誕生於CoreOS公司，它最初是用於解決集群管理系統中OS升級的分散式並發控制以及配置文件的存儲與分發等問題。
按照官方解釋（A distributed, reliable key-value store for the most critical data of a distributed system），ETCD是一個分散式的可靠的鍵值對存儲系統，用於存儲分散式系統中的關鍵數據。
對於熟悉ZooKeeper的人來說，ETCD提供的功能和ZooKeeper非常相似，比如都是通用的一致性元資訊存儲，都提供watch機制用於變更通知和分發，也都被分散式系統用來作為共享資訊存儲等。
實際上，據說ETCD就是受到ZooKeeper與doozerd啟發而催生的一個項目，除了擁有與之類似的功能外，更專註於以下四點：
1、簡單：基於 HTTP+JSON的API讓你用curl就可以輕鬆使用
2、安全：可選 SSL 客戶認證機制
3、快速：每個實例每秒支援一千次寫操作
4、可信：使用 Raft 演算法充分實現了分散式
下面兩段介紹下ETCD基礎概念和工作原理，主要抄書，特別鳴謝這篇文章作者，對個人理解提高非常有幫助。
一、ETCD構成
ETCD主要分為四個部分：
1、HTTP Server： 用於處理用戶發送的API請求以及其它ETCD節點的同步與心跳資訊請求。
2、Store：用於處理ETCD支援的各類功能的事務，包括數據索引、節點狀態變更、監控與回饋、事件處理與執行等等，是ETCD對用戶提供的大多數API功能的具體實現。
3、Raft：Raft強一致性演算法的具體實現，是ETCD的核心。
4、WAL：Write Ahead Log（預寫式日誌），是ETCD的數據存儲方式。除了在記憶體中存有所有數據的狀態以及節點的索引以外，ETCD就通過WAL進行持久化存儲。WAL中，所有的數據提交前都會事先記錄日誌。Snapshot是為了防止數據過多而進行的狀態快照；Entry表示存儲的具體日誌內容。
通常，一個用戶的請求發送過來，會經由HTTP Server轉發給Store進行具體的事務處理，如果涉及到節點的修改，則交給Raft模組進行狀態的變更、日誌的記錄，然後再同步給別的ETCD節點以確認數據提交。最後進行數據的提交，再次同步。
ETCD作為一個高可用鍵值存儲系統，天生就是為集群化而設計的。ETCD有三種集群化啟動的配置方案，分別為靜態配置啟動、ETCD自身服務發現、通過DNS進行服務發現。
從圖上我們能看到，一個 ETCD集群，通常會由 3 個或者 5 個節點組成（由於Raft演算法在做決策時需要多數節點的投票，所以ETCD一般部署集群推薦奇數個節點，推薦的數量為3、5或者7個節點構成一個集群），多個節點之間通過 Raft 一致性演算法的完成分散式一致性協同，演算法會選舉出一個主節點作為 leader，由 leader 負責數據的同步與數據的分發。當 leader 出現故障後系統會自動地選取另一個節點成為 leader，並重新完成數據的同步。客戶端在多個節點中，僅需要選擇其中的任意一個就可以完成數據的讀寫，內部的狀態及數據協同由 ETCD 自身完成。
這裡再小結下ETCD的重要概念：
Raft：Etcd 的核心，保證分散式系統強一致性的演算法。
Node：一個 Raft 狀態機實例。
Member： 一個 Etcd 實例，它管理著一個 Node，並且可以為客戶端請求提供服務。
Cluster：由多個 Member 構成可以協同工作的 Etcd 集群。
Peer：對同一個 Etcd 集群中另外一個 Member 的稱呼。
Client： 向 Etcd 集群發送 HTTP 請求的客戶端。
WAL：預寫式日誌，Etcd 用於持久化存儲的日誌格式。
Snapshot：Etcd 防止 WAL 文件過多而設置的快照，存儲 Etcd 數據狀態。
Leader：Raft 演算法中通過競選而產生的處理所有數據提交的節點。
Follower：競選失敗的節點作為 Raft 中的從屬節點，為演算法提供強一致性保證。
Candidate：當 Follower 超過一定時間接收不到 Leader 的心跳時轉變為 Candidate 開始競選。
Term：某個節點成為 Leader 到下一次競選期間，稱為一個 Term（任期）。
Index：數據項編號。Raft 中通過 Term 和 Index 來定位數據。
二、ETCD常見使用場景
1、服務發現（Service Discovery）
2、消息發布與訂閱
3、負載均衡
4、分散式通知與協調
5、分散式鎖
6、分散式隊列
7、集群監控與Leader競選
有這樣多的常見應用場景，ETCD不可謂不強大，現在在絕大多數互聯網應用中完全可以取代運維管理複雜的ZooKeeper。
三、ETCD管理
基礎概念介紹結束，終於盼到了激動人心的實踐環節^_^。
要復用ETCD功能，我們就要開發強大靈活的後台動態配置管理ETCD，當然我們也完全可以用現成的工具如etcd-manager進行ETCD管理。
1、ETCD集群
2、ETCD伺服器
針對集群中的每台ETCD伺服器，可以精準定位，進行統計、增刪改數據等操作。
比如統計：
查看鍵值對：
比如配置中心的配置
查看鍵值對明細
或者API介面應用部署資訊
再比如說一些常見工具
如集群：
用戶角色和許可權
動態工具等：
管理後台針對常見應用場景，有針對性的進行了開發改進和優化，為此還進行了ETCD客戶端（Power.Etcd）的開發：
這個客戶端項目有機會整理開源出來，主要是有部分PowerDotNet項目專用邏輯和依賴需要清理。
3、ETCD分組
對於大中型企業來說，ETCD的使用場景還是非常非常多的，必須進行統籌管理，否則遲早會有運維和管理難題。
PowerDotNet完美支援按照系統和應用進行ETCDRoute綁定，做到按組管理。
先定義ETCDRoute，一個ETCDRoute等同於一個分散式鍵值對分組：
將ETCDRoute綁定到具體應用，這樣業務系統只要調用封裝好的公共SDK（分散式分散式鍵值對客戶端SDK命名為Power.Etcd）就能自動獲取分散式鍵值對能力，甚至不用寫任何配置，直接在配置中心，點點按鈕搞定一切，實在是太省心了。
有了ETCD分散式鍵值對管理平台，能夠最大程度的復用ETCD，接入的應用更加容易管理和運維，排查和定位問題更加方便簡潔高效。
參考：
//www.infoq.cn/article/etcd-interpretation-application-scenario-implement-principle
//www.cnblogs.com/alisystemsoftware/p/12016601.html
//blog.csdn.net/shlazww/article/details/38736511
//www.jianshu.com/p/5aed73b288f7
//thesecretlivesofdata.com/raft
