知識分享--雲原生

Shine-x發表於2020-03-25

Consul架構介紹

High-Level 架構

知識分享--雲原生

  • 一個顯著特點是可以跨資料中心進行狀態和其他資料同步，同步的協議是gossip
  • Consul叢集之間的資料一致性協議通過基於Raft演算法的Consensus協議完成， Consul一致性是CP模式

不同註冊中心對比

Feature Consul Zookeeper Etcd Eureka
服務健康檢查 服務狀態，記憶體，硬碟等 (弱)長連線，keepalive 連線心跳 可配支援
多資料中心 支援 — — —
kv儲存服務 支援 支援 支援 —
一致性 raft paxos raft —
CAP定理 CA (應為CP) CP CP AP
使用介面(多語言能力) 支援http和dns 客戶端 http/grpc http（sidecar）
watch支援 全量/支援long polling 支援 支援 long polling 支援 long polling/大部分增量
自身監控 metrics — metrics metrics
安全 acl /https acl https支援（弱） —
Spring Cloud整合 已支援 已支援 已支援 已支援
  • 服務的健康檢查

Euraka 使用時需要顯式配置健康檢查支援；Zookeeper,Etcd 則在失去了和服務程式的連線情況下任務不健康，而 Consul 相對更為詳細點，比如記憶體是否已使用了90%，檔案系統的空間是不是快不足了。

在選擇API Gateway的時候，要面向未來，綜合考慮效能，易用性和生態體系，總結一下目前的在CNCF Cloud Native Interactive Landscape中出現的API Gateway, 主要分以下幾類：

  1. 基於Nginx和OpenResty的
    1. APISIX
    2. Kong
    3. 3Scale
  2. Java
    1. Sentinel
    2. Mule
  3. Go
    1. Krakend
    2. traefik
    3. Tyk
    4. Ambassador
    5. Gloo
  4. Other
    1. Express gateway
    2. Reactive Interaction Gateway

Leader選舉是保證分散式資料一致性的關鍵所在。當Zookeeper叢集中的一臺伺服器出現以下兩種情況之一時，需要進入Leader選舉。

  • (1) 伺服器初始化啟動。
  • (2) 伺服器執行期間無法和Leader保持連線。

下面就兩種情況進行分析講解。

1. 伺服器啟動時期的Leader選舉

若進行Leader選舉，則至少需要兩臺機器，這裡選取3臺機器組成的伺服器叢集為例。在叢集初始化階段，當有一臺伺服器Server1啟動時，其單獨無法進行和完成Leader選舉，當第二臺伺服器Server2啟動時，此時兩臺機器可以相互通訊，每臺機器都試圖找到Leader，於是進入Leader選舉過程。

選舉過程如下

  • (1) 每個Server發出一個投票。由於是初始情況，Server1和Server2都會將自己作為Leader伺服器來進行投票，每次投票會包含所推舉的伺服器的myid和ZXID，使用(myid, ZXID)來表示，此時Server1的投票為(1, 0)，Server2的投票為(2, 0)，然後各自將這個投票發給叢集中其他機器。
  • (2) 接受來自各個伺服器的投票。叢集的每個伺服器收到投票後，首先判斷該投票的有效性，如檢查是否是本輪投票、是否來自LOOKING狀態的伺服器。
  • (3) 處理投票。針對每一個投票，伺服器都需要將別人的投票和自己的投票進行PK，PK規則如下
    • · 優先檢查ZXID。ZXID比較大的伺服器優先作為Leader。
    • · 如果ZXID相同，那麼就比較myid。myid較大的伺服器作為Leader伺服器。

對於Server1而言，它的投票是(1, 0)，接收Server2的投票為(2, 0)，首先會比較兩者的ZXID，均為0，再比較myid，此時Server2的myid最大，於是更新自己的投票為(2, 0)，然後重新投票，對於Server2而言，其無須更新自己的投票，只是再次向叢集中所有機器發出上一次投票資訊即可。

  • (4) 統計投票。每次投票後，伺服器都會統計投票資訊，判斷是否已經有過半機器接受到相同的投票資訊，對於Server1、Server2而言，都統計出叢集中已經有兩臺機器接受了(2, 0)的投票資訊，此時便認為已經選出了Leader。
  • (5) 改變伺服器狀態。一旦確定了Leader，每個伺服器就會更新自己的狀態，如果是Follower，那麼就變更為FOLLOWING，如果是Leader，就變更為LEADING。

2. 伺服器執行時期的Leader選舉

　　在Zookeeper執行期間，Leader與非Leader伺服器各司其職，即便當有非Leader伺服器當機或新加入，此時也不會影響Leader，但是一旦Leader伺服器掛了，那麼整個叢集將暫停對外服務，進入新一輪Leader選舉，其過程和啟動時期的Leader選舉過程基本一致

假設正在執行的有Server1、Server2、Server3三臺伺服器，當前Leader是Server2，若某一時刻Leader掛了，此時便開始Leader選舉。選舉過程如下

  • (1) 變更狀態。Leader掛後，餘下的非Observer伺服器都會講自己的伺服器狀態變更為LOOKING，然後開始進入Leader選舉過程。
  • (2) 每個Server會發出一個投票。在執行期間，每個伺服器上的ZXID可能不同，此時假定Server1的ZXID為123，Server3的ZXID為122；在第一輪投票中，Server1和Server3都會投自己，產生投票(1, 123)，(3, 122)，然後各自將投票傳送給叢集中所有機器。
  • (3) 接收來自各個伺服器的投票。與啟動時過程相同。
  • (4) 處理投票。與啟動時過程相同，此時，Server1將會成為Leader。
  • (5) 統計投票。與啟動時過程相同。
  • (6) 改變伺服器的狀態。與啟動時過程相同。
本作品採用《CC 協議》，轉載必須註明作者和本文連結

相關文章