你們的服務注冊中心進行過選型調研嗎？對比一下各種服務注冊中心？
Eureka服務注冊發現集群原理：
Eureka，peer-to-peer，部署一個集群，但是集群里每個機器的地位是對等的，各個服務可以向任何一個Eureka實例服務注冊和服務發現，集群里任何一個Eureka實例接收到寫請求之后，會自動同步給其他所有的Eureka實例。
Zookeeper服務注冊發現原理：
Leader + Follower兩種角色，只有Leader可以負責寫也就是服務注冊，他可以把數據同步給Follower，讀的時候leader/follower都可以讀。
一致性保障：CP or AP
CAP，C是一致性，A是可用性，P是分區容錯性。
ZooKeeper是有一個leader節點會接收數據， 然后同步寫其他節點，一旦leader掛了，要重新選舉leader，這個過程里為了保證C，就犧牲了A，不可用一段時間，但是一個leader選舉好了，那么就可以繼續寫數據了，保證一致性。
Eureka是peer模式，可能還沒同步數據過去，結果自己就死了，此時還是可以繼續從別的機器上拉取注冊表，但是看到的就不是最新的數據了，但是保證了可用性，強一致，最終一致性。
闡述一下你們的服務注冊中心部署架構，生產環境下怎么保證高可用？
Eureka高可用，至少2台做集群。
兩個分支內相互配置另一台的ip和端口號。
你們系統遇到過服務發現過慢的問題嗎？怎么優化和解決的？
eureka，必須進行優化參數：
// 客戶端的有效負載緩存應該更新的時間間隔，默認為30 * 1000毫秒
eureka.server.responseCacheUpdateIntervalMs = 30000(30s) -> 3000(3s)
// 從eureka服務器注冊表中獲取注冊信息的時間間隔（s），默認為30秒
eureka.client.registryFetchIntervalSeconds = 30000 -> 3000
// 客戶端多長時間發送心跳給eureka服務器，表明它仍然活着，默認為30 秒
eureka.client.leaseRenewalIntervalInSeconds = 30 -> 3
// 過期實例應該剔除的時間間隔，單位為毫秒，默認為60 * 1000
eureka.server.evictionIntervalTimerInMs = 60000 -> 6000(6s)
// Eureka服務器在接收到實例的最后一次發出的心跳后，需要等待多久才可以將此實例刪除，默認為90秒
eureka.instance.leaseExpirationDurationInSeconds = 90 -> 9(s)
服務發現的時效性變成秒級，幾秒鍾可以感知服務的上線和下線
說一下自己公司的服務注冊中心怎么技術選型的？生產環境中應該怎么優化？
服務注冊、故障 和發現的時效性是多長時間？
注冊中心最大能支撐多少服務實例？
如何部署的，幾台機器，每台機器的配置如何，會用比較高配置的機器來做，8核16G，16核32G的高配置機器來搞，基本上可以做到每台機器每秒鍾的請求支撐幾千絕對沒問題。
可用性如何來保證？
有沒有做過一些優化，服務注冊、故障以及發現的時效性，是否可以優化一下，用eureka的話，可以嘗試一下，配合我們講解的那些參數，優化一下時效性，服務上線、故障到發現是幾秒鍾的時效性。
zk，一旦服務掛掉，zk感知到以及通知其他服務的時效性，服務注冊到zk之后通知到其他服務的時效性，leader掛掉之后可用性是否會出現短暫的問題，為了去換取一致性。
如果需要部署上萬服務實例，現有的服務注冊中心能否抗住？如何優化？
核心思想：注冊中心主從架構，分片存儲服務注冊表，服務按需主動拉取注冊表，不用全量拉取/推送，避免反向通知瞬時高並發。
自研注意點：
客戶端：
1. 服務拉取：不用全量拉取，按需拉取（有疑問，怎么設計按需拉取？）。還需要一個用於校驗拉取增量數據之后數據是否完整的過程。
2. 心跳發送。
3. 服務下線。
服務端：
1.服務注冊： 服務注冊表注意讀寫高並發控制，保證線程安全，也要降低鎖的爭用。
2. 健康檢查：單位時間內，如果所注冊服務沒有續約，則要將其下線。
3. 集群同步：根據具體業務需求，制定合適的集群架構方案，保證吞吐量。
參考資料：
21天互聯網Java進階面試訓練營（分布式篇）-- 中華石杉