對于沒有接觸過微服務的人注冊中心可能會比較陌生。本文主要講解為什么需要使用注冊中心、它有哪些分類、不同場景下注冊中心是選項的經驗。

在微服務架構中，不同服務之間相互調用的時候，需要知道對方的調用地址。如果直接提供服務的地址，需要維護一個服務列表的，隨著服務增多、版本迭代等，要定期整個服務列表，這樣的效率明顯比較低。這時候人們會希望有個第三方工具來自動化協助維護這個服務列表，這就是服務注冊發現中心組件的價值。

在進行注冊中心選型時，主要從功能豐富度、可靠性、性能、社區支持度等4個維度進行對比分析。從功能的角度考慮。微服務的注冊中心目前主流的有以下五種：Zookeeper、Eureka、Consul、Nacos、Kubernetes。

功能方面，從實際的使用場景出發，主要考慮雪崩保護、自動注銷實例、訪問協議、多數據中心、跨注冊中心同步、Springcloud、Dubbo、k8s集成等維度。

在眾多企業級項目落地場景的經驗來看，一般都需要滿足支持多數據中心、跨注冊中心同步、Springcloud、Dubbo、k8s集成等維度。在這塊Nacos能滿足所有需求，其次可以考慮采用consul，但consul不能集成Dubbo，這需求企業有較強的開發能力，能彌補這塊足。

從可靠性角度來講，注冊中心本身的高可用和注冊中心與服務之間的健康性檢查就顯得很重要，如果注冊中心不能及時將下線或故障的節點從可用服務器地址列表剔除，那么就很可能會造成微服務某些調用的失敗。

注冊中心的探活機制顯得尤為重要。服務主動探活就是微服務定期向注冊中心發送租約信息以表面自己的存活。

主動探活場景，如果服務規模不大，那么主動探活就是一種最佳選擇，它可以較大程度地避免服務部署在Kubernetes集群后，因為Pod IP重用而導致的舊有服務節點依然存活的問題。在這種場景可以考慮采用Eureka作為我們的注冊中心。

從性能角度考慮。需要在相同硬件配置下，壓測注冊中心的服務注冊和服務發現的TPS和P99延時數據。通過總結出，在服務注冊TPS上，eureka性能是consul的2倍左右；在服務發現的TPS上，consul的性能是eureka的11倍左右。

從社區活躍度,對開源項目的評判認知依然非常模糊GitHub star 就是最直觀的一個指標，因為從大眾視角看，最簡單直接的才是最吸引眼球的。項目的活躍度，我們定義為項目的提交數、 拉取請求數和貢獻者數（其它數據，如代碼行數、文件數、issue 數、 fork 數）。如果多角度描述一個項目的活躍度，以提交數、拉取請求數、貢獻者數為三維，可以確定在某個時間點某個項目的坐標，那么計算一段時間內，該坐標點的移動軌跡和速率，可以真實的反映該項目的活躍度趨勢。總體而言，nacos、consul等注冊中心活躍度優于zookeeper、eureka等老一代的注冊中心。

總體而言，我們在項目落地中，需要綜合考慮豐富度、可靠性、性能、社區支持度等因素，分析出每個因素對于客戶滿意度、后期運維、開發影響的權重值。選擇一個最匹配我們需求場景的注冊中心，幫忙我們解決微服務項目，服務發現的問題，提高我們系統的穩定性。