工作中用到了Consul來做服務發現，之後一段時間裏，我會陸續發一些文章來講述Consul實現原理。在前幾篇文章介紹完了Consul用到的兩個關鍵性東西Raft和Gossip之後，這篇文章會講述Consul的整體架構。本文基於一篇別的譯文，並做了一些改進和完善。
術語表
代理(agent)：
代理是Consul集羣上每個成員的守護進程，它是由consul agent開始運行。代理能夠以客戶端或服務器模式運行。由於所有節點都必須運行代理，所以將節點引用爲客戶端或服務器更爲簡單，但還有其他實例的代理。所有代理可以運行DNS或HTTP接口，並負責運行檢查和保持服務同步。客戶端：
客戶端可以將所有RPC請求轉發到服務器的代理。客戶端是相對無狀態的。客戶端執行的唯一後臺活動是LANgossip池。它消耗最小的資源開銷和少量的網絡帶寬。服務器端：
服務器端是具有擴展的功能的代理，它主要參與維護集羣狀態，響應RPC查詢，與其他數據中心交換WAN gossip ，以及向leader節點或遠程數據中心轉發查詢。數據中心：
雖然數據中心的定義似乎很明顯，但仍有一些細微的細節必須考慮。比如說，在EC2中，多個可用中心（EC2和AZ是AWS裏的概念，不瞭解的話可以去看看AWS文檔）是否應該被人是一個單個的數據中心呢？我們將一個數據中心定義爲一個私有、低延遲和高帶寬的網絡環境,這不包括通過公共互聯網的通信。但是爲了我們的目的，單個EC2區域內的多個可用區域將被視爲單個數據中心的一部分。一致性 ：
在我們的文檔中，“一致性”的意思是對於被選舉出的leader以及事物的順序的認同。因爲這些事件被應用到有限狀態機上，我們對一致性的定義又暗含了複製備份的狀態機的一致性。Gossip：
consul是建立在serf之上的，它提供了一個完整的gossip協議，用在很多地方。Serf提供了成員管理，故障檢測和事件廣播的功能。Gossip的節點到節點之間的通信使用了UDP協議。LAN Gossip：
指在同一局域網或數據中心的節點上的LAN Gossip池。WAN Gossip：
指包含服務器的WAN Gossip池，這些服務器在不同的數據中心，通過網絡進行通信。RPC
遠程過程調用。這種請求/響應機制允許客戶端向服務器端發一個請求。
概覽
讓我們把這個圖拆解開來分別講述。
首先，圖中有兩個數據中心，分別爲Datacenter1和Datacenter2。Consul非常好的支持多個數據中心，每個數據中心內，有客戶端和服務器端，服務器一般爲3~5個，這樣可以在穩定和性能上達到平衡，因爲更多的機器會使數據同步很慢。不過客戶端是沒有限制的，可以有成千上萬個。
數據中心內的所有節點都會加入到Gossip協議。這就意味着有一個Gossip池，其中包含這個數據中心所有的節點。客戶端不需要去配置服務器地址信息，發現工作會自動完成。檢測故障節點的工作不是放在服務器端，而是分佈式的；這使得失敗檢測相對於本地化的心跳機制而言，更具可拓展性。在選擇leader這種重要的事情發生的時候，數據中心被用作消息層來做消息廣播。
每個數據中心內的服務器都是單個Raft中節點集的一部分。這意味着他們一起工作，選擇一個單一的領導者——一個具有額外職責的選定的服務器。leader負責處理所有查詢和事物。事物也必須作爲同步協議的一部分複製到節點集中的所有節點。由於這個要求，當非leader服務器接收到RPC請求時，就會將請求其轉發給集羣leader。
服務器端節點同時也作爲WAN Gossip池的一部分，WAN池和LAN池不同的是，它針對網絡高延遲做了優化，而且只包含其他Consul服務器的節點。這個池的目的是允許數據中心以最少的消耗方式發現對方。啓動新的數據中心與加入現有的WAN Gossip一樣簡單。因爲這些服務器都在這個池中運行，它還支持跨數據中心請求。當服務器收到對不同數據中心的請求時，它會將其轉發到正確數據中心中的隨機服務器。那個服務器可能會轉發給本地的leader。
這樣會使數據中心的耦合非常低。但是由於故障檢測，連接緩存和複用，跨數據中心請求相對快速可靠。
總的來說，數據不會在不同的數據中心之間做複製備份。當收到一個請求處於別的數據中心的資源時，本地的Consul服務器會發一個RPC請求到遠端的Consul服務器，然後返回結果。如果遠端數據中心處於不可用狀態，那麼這麼資源也會不可用，但這不影響本地的數據中心。在一些特殊的情況下，有限的數據集會被跨數據中心複製備份，比如說Consul內置的ACL複製能力，或者像consul-replicate這樣的外部工具。
參考文章：
1. https://www.consul.io/docs/internals/architecture.html
2. http://www.cnblogs.com/Summer7C/p/7327109.html
