大家應該知道eureka閉源了，接下來在springcloud2的時候可能會遇到一些不可把控的問題。不過相對於國內市場來講，影響很小，大部分還停留在D版本(目前已發佈到了G版本了)。這裏就考慮是否需要更換註冊中心了。
下圖爲cloud支持註冊中心的功能對比圖：
關於CAP可參考文章：https://blog.csdn.net/yeyazhishang/article/details/80758354
Consistency (一致性)：
“all nodes see the same data at the same time”,即更新操作成功並返回客戶端後，所有節點在同一時間的數據完全一致，這就是分佈式的一致性。一致性的問題在併發系統中不可避免，對於客戶端來說，一致性指的是併發訪問時更新過的數據如何獲取的問題。從服務端來看，則是更新如何複製分佈到整個系統，以保證數據最終一致。
Availability (可用性):
可用性指“Reads and writes always succeed”，即服務一直可用，而且是正常響應時間。好的可用性主要是指系統能夠很好的爲用戶服務，不出現用戶操作失敗或者訪問超時等用戶體驗不好的情況。
Partition Tolerance (分區容錯性):
即分佈式系統在遇到某節點或網絡分區故障的時候，仍然能夠對外提供滿足一致性或可用性的服務。
分區容錯性要求能夠使應用雖然是一個分佈式系統，而看上去卻好像是在一個可以運轉正常的整體。比如現在的分佈式系統中有某一個或者幾個機器宕掉了，其他剩下的機器還能夠正常運轉滿足系統需求，對於用戶而言並沒有什麼體驗上的影響。
CAP三個特性只能滿足其中兩個，那麼取捨的策略就共有三種：
CA without P：如果不要求P（不允許分區），則C（強一致性）和A（可用性）是可以保證的。但放棄P的同時也就意味着放棄了系統的擴展性，也就是分佈式節點受限，沒辦法部署子節點，這是違背分佈式系統設計的初衷的。
CP without A：如果不要求A（可用），相當於每個請求都需要在服務器之間保持強一致，而P（分區）會導致同步時間無限延長(也就是等待數據同步完才能正常訪問服務)，一旦發生網絡故障或者消息丟失等情況，就要犧牲用戶的體驗，等待所有數據全部一致了之後再讓用戶訪問系統。設計成CP的系統其實不少，最典型的就是分佈式數據庫，如Redis、HBase等。對於這些分佈式數據庫來說，數據的一致性是最基本的要求，因爲如果連這個標準都達不到，那麼直接採用關係型數據庫就好，沒必要再浪費資源來部署分佈式數據庫。
AP wihtout C：要高可用並允許分區，則需放棄一致性。一旦分區發生，節點之間可能會失去聯繫，爲了高可用，每個節點只能用本地數據提供服務，而這樣會導致全局數據的不一致性。典型的應用就如某米的搶購手機場景，可能前幾秒你瀏覽商品的時候頁面提示是有庫存的，當你選擇完商品準備下單的時候，系統提示你下單失敗，商品已售完。這其實就是先在 A（可用性）方面保證系統可以正常的服務，然後在數據的一致性方面做了些犧牲，雖然多少會影響一些用戶體驗，但也不至於造成用戶購物流程的嚴重阻塞。
簡而言之：
P:是必不可少的
CP:數據一致性強，但是用戶體驗不好
AP:用戶體驗好，但存在數據一致性的風險
場景舉例：
支付系統 -- 選用CP
CMS系統 -- 選用AP