1. 注冊中心概念和定義
服務注冊中心本質上是為了解耦服務提供者和服務消費者。對於任何一個微服務，原則上都應存在或者支持多個提供者，這是由微服務的分布式屬性決定的。更進一步，為了支持彈性擴縮容特性，一個微服務的提供者的數量和分布往往是動態變化的，也是無法預先確定的。因此，原本在單體應用階段常用的靜態LB機制就不再適用了，需要引入額外的組件來管理微服務提供者的注冊與發現，而這個組件就是服務注冊中心
能夠提供額外服務來管理微服務提供者的注冊與發現的組件就是服務注冊中心。
2. CAP理論
CAP理論是分布式架構中重要理論, 它包含:
- 一致性(Consistency)
所有節點在同一時間具有相同的數據
- 可用性(Availability)
保證每個請求不管成功或者失敗都有響應
(某個系統的某個節點掛了，但是並不影響系統的接受或者發出請求)
- 分隔容忍(Partition tolerance)
系統中任意信息的丟失或失敗不會影響系統的繼續運作
(在整個系統中某個部分，掛掉了，或者宕機了，並不影響整個系統的運作或者說使用)
CAP不可能都滿足
原因如下:
1. 如果C是第一需求的話，那么會影響A的性能。
因為要數據同步，不然請求結果會有差異，但是數據同步會消耗時間，可用性就會降低。
2. 如果A是第一需求，那么只要有一個服務在，就能正常接受請求。
但是對於返回結果便不能保證，原因是，在分布式部署的時候，數據一致的過程不可能像切線路那么快。
3. 如果同時滿足一致性和可用性，那么分區容錯就很難保證了。
但是CAP理論提出就是針對分布式數據庫環境的，所以P這個屬性是必須具備的。
P就是在分布式環境中，由於網絡的問題可能導致某個節點和其它節點失去聯系，這時候就形成了P(partition)。
3. 服務注冊中心的主流解決方案
縱觀當下的主流服務注冊中心解決方案，大致可歸為三類：
- 應用內
直接集成到應用中，依賴於應用自身完成服務的注冊與發現(eg: Netflix Eureka -- 一站式解決方案)
- 應用外
把應用當成黑盒，通過應用外的某種機制將服務注冊到注冊中心，最小化對應用的侵入性
(eg:Airbnb的SmartStack，HashiCorp的Consul)
- DNS
將服務注冊為DNS的SRV記錄，嚴格來說，是一種特殊的應用外注冊方式
(eg: SkyDNS是其中的代表, 由於DNS固有的緩存缺陷，這里不對第三類注冊方式作深入探討)
4. 各類注冊中心產品詳細介紹
Apache Zookeeper -> CP
Apache Zookeeper在設計時就緊遵CP原則。
任何時候對 Zookeeper 的訪問請求能得到一致的數據結果，同時系統對網絡分割具備容錯性，
但是 Zookeeper 不能保證每次服務請求都是可達的。
Zookeeper適合的場景:
分布式數據存儲
但是由於Zookeeper 不能保證服務可用性。
對於服務發現來說，情況就不太一樣了，針對同一個服務，
即使注冊中心的不同節點保存的服務提供者信息不盡相同，也並不會造成災難性的后果。
因為對於服務消費者來說，能消費才是最重要的，
消費者雖然拿到可能不正確的服務實例信息后嘗試消費一下，
也要勝過因為無法獲取實例信息而不去消費，導致系統異常要好。
Spring Cloud Eureka -> AP
Netflix在設計Eureka時就緊遵AP原則(盡管現在2.0發布了，但是由於其閉源的原因, 目前 Ereka 1.x 任然是比較活躍的)
架構圖:
優點:
從設計角度來看，Eureka可以說是無懈可擊，注冊中心、提供者、調用者邊界清晰<br>通過去中心化的集群支持保證了注冊中心的整體可用性
缺點:
Eureka屬於應用內的注冊方式，對應用的侵入性太強，且只支持Java應用
Eureka Server 也可以運行多個實例來構建集群，解決單點問題。
但不同於 ZooKeeper 的選舉 leader 的過程，Eureka Server 采用的是Peer to Peer 對等通信。
這是一種去中心化的架構，無 master/slave 之分，每一個 Peer 都是對等的。
在這種架構風格中，節點通過彼此互相注冊來提高可用性，
每個節點需要添加一個或多個有效的 serviceUrl 指向其他節點。
每個節點都可被視為其他節點的副本。
在集群環境中如果某台 Eureka Server 宕機，Eureka Client 的請求會自動切換到新的 Eureka Server 節點上，
當宕機的服務器重新恢復后，Eureka 會再次將其納入到服務器集群管理之中。
當節點開始接受客戶端請求時，所有的操作都會在節點間進行復制（Replicate To Peer）操作，
將請求復制到該 Eureka Server 當前所知的其它所有節點中。
當一個新的 Eureka Server 節點啟動后，會首先嘗試從鄰近節點獲取所有注冊列表信息，並完成初始化。
Eureka Server 通過 getEurekaServiceUrls() 方法獲取所有的節點，並且會通過心跳契約的方式定期更新。
默認情況下，如果 Eureka Server 在一定時間內沒有接收到某個服務實例的心跳（默認周期為30秒），
Eureka Server 將會注銷該實例
（默認為90秒， eureka.instance.lease-expiration-duration-in-seconds 進行自定義配置）。
當 Eureka Server 節點在短時間內丟失過多的心跳時，那么這個節點就會進入自我保護模式。
Eureka的集群中，只要有一台Eureka還在，就能保證注冊服務可用（保證可用性），
只不過查到的信息可能不是最新的（不保證強一致性）。
除此之外，Eureka還有一種自我保護機制，如果在15分鍾內超過85%的節點都沒有正常的心跳，
那么Eureka就認為客戶端與注冊中心出現了網絡故障。
此時會出現以下幾種情況：
1. Eureka不再從注冊表中移除因為長時間沒有收到心跳而過期的服務；
2. Eureka仍然能夠接受新服務注冊和查詢請求，但是不會被同步到其它節點上（即保證當前節點依然可用）；
3. 當網絡穩定時，當前實例新注冊的信息會被同步到其它節點中；
因此，Eureka可以很好的應對因網絡故障導致部分節點失去聯系的情況，
而不會像zookeeper那樣使得整個注冊服務癱瘓。
Consul
Consul 是 HashiCorp 公司推出的開源工具，用於實現分布式系統的服務發現與配置。
Consul 使用 Go 語言編寫，因此具有天然可移植性(支持Linux、windows和Mac OS X)。
架構圖:
Consul本質上屬於應用外的注冊方式，但可以通過SDK簡化注冊流程。
而服務發現恰好相反，默認依賴於SDK，但可以通過Consul Template去除SDK依賴。
Consul 內置了服務注冊與發現框架、分布一致性協議實現、健康檢查、Key/Value 存儲、多數據中心方案，
不再需要依賴其他工具（比如 ZooKeeper 等），使用起來也較為簡單。
Consul 遵循CAP原理中的CP原則，保證了強一致性和分區容錯性，
且使用的是Raft算法，比zookeeper使用的Paxos算法更加簡單。
雖然保證了強一致性，但是可用性就相應下降了，
例如服務注冊的時間會稍長一些，因為 Consul 的 raft 協議要求必須過半數的節點都寫入成功才認為注冊成功 ；
在leader掛掉了之后，重新選舉出leader之前會導致Consul 服務不可用。
優點:
最小化對已有應用的侵入性
降低運維的復雜度(Consul Agent既可以運行在服務器模式，又可以運行在客戶端模式)
缺點:
由於是實現了CP, A沒有保證, 在leader掛掉了之后，重新選舉出leader之前會導致Consul 服務不可用
Nacos
Nacos是阿里開源的，Nacos 支持基於 DNS 和基於 RPC 的服務發現。
Nacos = Spring Cloud注冊中心 + Spring Cloud配置中心
優點:
同時支持AP和CP模式, 可以根據服務注冊選擇臨時和永久來決定走AP模式還是CP模式
同時支持注冊中心和配置中心
架構圖:
在Spring Cloud中使用Nacos，只需要先下載 Nacos 並啟動 Nacos server，
Nacos只需要簡單的配置就可以完成服務的注冊發現。
