一、什麼是微服務的服務註冊中心？
　　註冊中心是微服務最核心的基礎服務之一，是隱藏在服務框架背後最基礎的服務，記錄各個服務的例項資訊，決定業務服務是否正常呼叫，主要涉及到三大角色，服務提供者、服務消費者、註冊中心。三者的架構關係如下圖：

　　服務註冊中心執行流程原理：

　　1、各微服務啟動時，會將自己的例項資訊註冊到註冊中心，註冊中心會管理和儲存這些資料。

　　2、服務消費者會從註冊中心獲取到服務提供者的例項資訊，通過ip+port的方式遠端呼叫服務提供者提供的功能介面。

　　3、註冊中心與微服務之間通過心跳來檢測服務是否執行正常，服務模組會定時的想註冊中心傳送心跳包，以向其註冊中心證明自己執行正常，同時註冊中心會對提供者服務進行健康檢查，以決定是否下線服務。

　　4、微服務發生變動時，重新註冊資訊到註冊中心。服務消費者無需改動就可以直接從註冊中心獲取最新服務。

二、註冊中心的功能

　　1、服務登錄檔：記錄各個微服務例項資訊，例如微服務的名稱、IP、埠等。服務登錄檔提供查詢和管理API，查詢API用於查詢可用的微服務例項，管理API用於服務的註冊與登出。

　　2、服務註冊與發現：服務註冊是指微服務在啟動時，將自己的資訊註冊到註冊中心的過程，而服務發現是指查詢可用的微服務列表及網路地址的機制。

　　3、服務檢查：註冊中心使用一定的機制定時檢測已註冊的服務，如發現某例項長時間無法訪問，就會從服務登錄檔移除該例項。

三、主流的服務註冊中心元件

　　常見的服務註冊中心元件有Eureka、Consul、ZooKeeper和Nacos。這幾種開源元件， 都是基於分散式理論 CAP 的 CP 、AP 來實現的。CAP理論是分散式架構實現中重要的理論，CAP理論是Brewer提出的，它描述了一個分散式系統的三個特性：一致性（C

　　分割槽容錯性：指的分散式系統中的某個節點或者網路分割槽出現了故障的時候，整個系統仍然能對外提供滿足一致性和可用性的服務。也就是說部分故障不影響整體使用。

　　可用性：一直可以正常的做讀寫操作。簡單而言就是客戶端一直可以正常訪問並得到系統的正常響應。使用者角度來看就是不會出現系統操作失敗或者訪問超時等問題。

　　一致性：在分散式系統完成某寫操作後任何讀操作，都應該獲取到該寫操作寫入的那個最新的值。相當於要求分散式系統中的各節點時時刻刻保持資料的一致性。　

　　CAP三者不可兼得，該如何取捨?

　　　　(1) CA: 優先保證一致性和可用性，放棄分割槽容錯。 這也意味著放棄系統的擴充套件性，系統不再是分散式的，有違設計的初衷。

　　　　(2) CP: 優先保證一致性和分割槽容錯性，放棄可用性。在資料一致性要求比較高的場合(譬如:zookeeper,Hbase) 是比較常見的做法，一旦發生網路故障或者訊息丟失，就會犧牲使用者體驗，等恢復之後使用者才逐漸能訪問。

　　　　(3) AP: 優先保證可用性和分割槽容錯性，放棄一致性。NoSQL中的Cassandra 就是這種架構。跟CP一樣，放棄一致性不是說一致性就不保證了，而是逐漸的變得一致。