1.1 服務發現架構

     在微服務的服務治理中，服務發現占據著非常重要的地位。由于微服務架構中的微服務實例眾多，且上下游實例經常會隨著服務流量的變化進行擴縮容，因此需要一套服務發現機制來保證上下游服務隨時都能調到安全可靠的接口

       一個標準的服務發現架構主要由三部分組成，分別是服務注冊中心，服務調用者，服務提供者，其相關交互如下圖所示

       其中服務注冊中心為此架構的關鍵設備，由于下游的服務提供者眾多，且處于一個動態變化的過程，因此需要服務調用者去服務注冊中心中去進行服務訂閱，從而獲取一個下游服務的地址及端口，同時，如果下游服務發生變動，服務注冊中心也會及時將服務變更信息同步給服務調用者

       服務調用者即為客戶端，服務提供者即為服務端，因此服務發現也有著兩種主要的服務發現方式：客戶端發現和服務端發現

       客戶端發現：此方式是客戶端通過查詢服務注冊中心，獲取可用服務的地址，然后進行訪問，此方案的優點為架構簡單，擴展靈活，方便實現負載均衡功能，缺點為強耦合，有一定開發成本。

        服務端發現：此方式不是客戶端去主動查詢，而是客戶端向中間負載均衡設備發送請求，然后由負載均衡設備去向服務注冊中心去獲取服務地址，此方案對客戶端無感知，但是需要維護高可用的負載均衡設備

       同時，服務注冊也有兩種方式，一種是自己注冊，一種是第三方注冊

       自己注冊，即服務實例自己主動去注冊中心進行注冊和注銷，該方法的優點是非常簡單，不需要任何其他輔助組件，缺點是各個服務和注冊中心的耦合度比較高

      第三方注冊是服務本身不關心注冊和注銷功能，而是通過其他組件來實現服務注冊功能，可以通過如事件訂閱等方式來監控服務的狀態，如果發現一個新的服務實例運行，就向注冊中心注冊該服務，如果監控到某一服務停止了，就向注冊中心注銷該服務。

1.2 常見的服務組件

目前的主流服務發現組件主要有3種，分別是Consul，Zookeeper，Etcd

1.2.1 Zookeeper

      Zookeeper是一個常用的分布式組件，在分布式系統中通常被用于配置管理、名字服務，分布式鎖等方向。

      用Zookeeper來實現服務發現主要是使用Zookeeper的臨時節點，通過這些臨時節點來實現基本的服務注冊功能和基本的健康檢查功能，當服務實例啟動就會在Zookeeper中注冊一個臨時節點，同時，如果服務實例發生故障或下線的時候，該臨時節點就會被Zookeeper自動刪除，如果有其他服務依賴這個服務可以設置監聽該服務實例對應的臨時節點，當臨時節點被刪除時，依賴該服務的其他服務會獲得通知。依賴Zookeeper自身的高可用及臨時節點提供的健康檢查和監聽機制來實現具備容錯能力的服務發現機制。

      在 實際開發過程中，通常建議使用Apache Curator來替代Zookeeper原生客戶端庫，Apache Curator通過封裝Zookeeper原生API，提供更高抽象層次API讓Zookeeper使用起來更加容易和可靠，而且提供專用于實現服務發現的API。

1.2.2 Etcd

       Etcd是一個基于Raft共識算法具備線性強一致性（linearizable）的Key-Value存儲系統，可以為每個Key設置TTL（time to live），當TTL過后相應Key會自動過期失效。基于Etcd構建服務發現解決方案將Etcd作為服務注冊中心，服務實例注冊就是在Etcd中構建一個Key-Value記錄，由服務實例自身或代理負責設置并定期更新其關聯Key的TTL，如果服務實例故障其對應Key就會在TTL之后過期失效，相當于將該故障服務實例注銷，通過定時心跳以達到監控健康狀態的效果。而且Etcd提供監聽機制，允許為Key設置監聽器當該Key發生變化時，監聽器能及時獲取通知。Etcd自身的高可用特性，基于TTL提供基本的服務健康檢查，基于監聽機制及時感知服務實例變化，使Etcd成為微服務架構中常用服務發現解決方案。

1.2.3 Consul

       Consul是一個成熟的服務發現解決方案。其核心是一個基于Raft共識算法具備線性強一致性的Key-Value存儲系統作為服務注冊中心，并提供代理（Agent）機制一方面用于協調服務注冊，一方面提供服務健康檢查。代理（Agent）會在每個運行服務的節點上啟動，獲取節點地址并將該服務實例注冊到服務注冊中心。架構上Consul包括兩類組件：Server、Agent，服務注冊信息保存在Server上，通過Raft共識算法保證多個Server間數據線性強一致，保證服務注冊中心高可用；將所有Agent作為集群節點，使用Gossip協議進行組關系管理和故障探測，當有Agent加入（啟動）或離開（故障）集群時其他Agent會得到通知，實現服務健康檢查和監視功能。

       Gossip協議常用于集群組關系管理和故障檢測，每個節點都通過一個或多個引導節點加入集群，引導節點有集群中所有節點列表，每個節點都從自己所知節點列表中隨機選擇一組節點周期性地發送多播消息，最終集群中所有節點都能知道其他節點。這個過程看起來很神奇，實際上Gossip協議能在幾秒內將消息傳遍有上百節點的集群。Akka、Riak、Cassandra都使用Gossip協議維護集群成員列表和故障探測。