对于没有接触过微服务的人注册中心可能会比较陌生。本文主要讲解为什么需要使用注册中心、它有哪些分类、不同场景下注册中心是选项的经验。
在微服务架构中，不同服务之间相互调用的时候，需要知道对方的调用地址。如果直接提供服务的地址，需要维护一个服务列表的，随着服务增多、版本迭代等，要定期整个服务列表，这样的效率明显比较低。这时候人们会希望有个第三方工具来自动化协助维护这个服务列表，这就是服务注册发现中心组件的价值。
在进行注册中心选型时，主要从功能丰富度、可靠性、性能、社区支持度等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等老一代的注册中心。
总体而言，我们在项目落地中，需要综合考虑丰富度、可靠性、性能、社区支持度等因素，分析出每个因素对于客户满意度、后期运维、开发影响的权重值。选择一个最匹配我们需求场景的注册中心，帮忙我们解决微服务项目，服务发现的问题，提高我们系统的稳定性。
