註冊中心

爲何須要註冊中心

在實際生產系統中，會有這樣的一種狀況：A服務調用B服務，B服務調用C服務（只考慮同步調用，不考慮異步調用，因此經過mq的方式這裏排除）：

若是A服務想要調用B服務，咱們是須要知道B服務的IP的，同理B服務也要知道C服務的IP：

看起來已經解決了多個服務同步調用的問題，若是此時B服務的IP變了怎麼辦？A服務是否是就要作更改了，可是有沒有想過，若是還有其餘服務也調用B呢，那這些服務都要作變動，沒及時變動的就不能正常調用了。

Nginx

有人說，用Nginx反向代理：

此時對B服務的調用都是經過NGINX_1，對C服務的調用都是經過NGINX_2，若是B服務的地址改了，咱們只須要改NGINX_1的配置文件而後重啓就好。看起來能夠解決，咱們示例只有3個服務調用，鏈路就這麼長了，若是是更多的服務調用，那鏈路要多長，並且每次新增一個服務都要配置一個新的Nginx，那運維可能會打你。

DNS

有人說，那用DNS吧：

雖然屏蔽了IP，和上面同樣，每次新增一個服務都要配置一個新的域名對應IP，更麻煩的是，在集羣狀況下，Nginx能夠知道哪一個服務不可用，並把請求轉發到其餘集羣服務器，可是DNS不知道，並且DNS也不能根據必定的策略進行負載均衡，還有緩存等等問題。

註冊中心

既然上面兩種方式都不合適，咱們能夠用註冊中心。
在服務B啓動的時候，會往註冊中心註冊當前服務的ip以及端口，註冊中心維護這些註冊信息，A服務在調用以前，會經過註冊中心拿到B服務的ip和端口，這樣就能夠直接調用B服務了，不再怕服務B亂改地址、在集羣裏增減服務了。

CP仍是AP

常見的註冊中心有zookeeper、consul、eureka、nacos，前兩個是CP，eureka是AP，nacos兩個都支持，那咱們是選哪種呢？CAP概念見以前文章

性能

AP模型狀況下，此時B服務1已經註冊到註冊中心1了，B服務2也註冊到註冊中心2了，A服務1是能夠經過註冊中心1獲取B服務1的地址，A服務2也能夠經過註冊中心2獲取B服務2的地址，雖然註冊中心最終會由於同步而保持數據最終一致，可是在這個過程當中，並不影響服務從註冊中心獲取被調用方的地址，雖然有可能獲取到的數據並非完整的（數據沒有強一致性）。

CP模型狀況下，能夠看到只有Leader才能夠註冊，而後把數據同步到Slave。這個就相對於註冊中心是單寫了，因此寫的性能就比AP的差。並且爲了保證數據的一致性，要同步到其餘Follower節點的時候才能夠被讀取到，另外若是Leader宕機了，整個服務在選舉的時候是不可用的，知道新的Leader被選舉出來。

綜上，AP雖然犧牲了數據的強一致性，可是性能上比CP好。好比上面的例子，雖然A服務1只有B服務1的地址，可是也能夠正常工做的，因此數據的強一致性實際上是不太須要的。可是他也有一個問題，就是B服務宕機的時候，A服務並不能及時的發現。

腦裂

在CP模型下，咱們假設A服務1和A服務3是同一個機房的，A服務2是另一個機房的，此時出現了腦裂，致使兩個機房不能互相通訊。在這種狀況下，爲了保證數據的一致性，下面機房的註冊中心此時是不能讀寫的，這樣形成的後果以下：

1. 若是此時下面機房新啓動了B服務3，是沒辦法註冊到註冊中心。
2. 若是A服務2重啓，緩存丟失，或者A服務再加一個服務，他是沒有辦法從註冊中心獲取數據的。

因此明明是同一個機房的，卻由於腦裂而不能對B服務擴容，甚至沒法訪問B服務。

綜上，咱們應該選擇AP的註冊中心。

大規模服務

不論是CP模型仍是AP模型，在大規模服務下，註冊中心都很難支持。
AP模型下，他們會互相同步註冊信息，致使大量的數據來各個節點傳遞，佔用了網絡帶寬以及CPU。
CP模型下，每一個服務的上線下線都要通知各個服務，服務一多，網絡帶寬就被佔用。