微服务注册中心如何选型？这几个维度告诉你！ _微服务

一、前言微服务的注册中心目前主流的有以下四种：

Zookeeper
Eureka
Consul
Kube.NETes

那么实际开发中到底如何选择呢？这是一个值得深入研究的事情，别着急，今天陈某就带大家深入了解一下这四类注册中心以及如何选型的问题。
二、为什么需要注册中心？随着单体应用拆分，首当面临的第一份挑战就是服务实例的数量较多，并且服务自身对外暴露的访问地址也具有动态性。可能因为服务扩容、服务的失败和更新等因素，导致服务实例的运行时状态经常变化，如下图:

文章插图
商品详情需要调用营销、订单、库存三个服务，存在问题有：

营销、订单、库存这三个服务的地址都可能动态的发生改变，单存只使用配置的形式需要频繁的变更，如果是写到配置文件里面还需要重启系统，这对生产来说太不友好了;
服务是集群部署的形式调用方负载均衡如何去实现；

解决第一个问题办法就是用我们用伟人说过一句话，没有什么是加一个中间层解决不了的，这个中间层就是我们的注册中心。
解决第二问题就是关于负载均衡的实现，这个需要结合我们中间层老大哥来实现。
三、如何实现一个注册中心？对于如何实现注册中心这个问题，首先将服务之间是如何交互的模型抽象出来，我们结合实际的案例来说明这个问题，以商品服务为例：

当我们搜索商品的时候商品服务就是提供者；
当我们查询商品详情的时候即服务的提供者又是服务的消费者，消费是订单、库存等服务；由此我们需要引入的三个角色就是:中间层(注册中心)、生产者、消费者，如下图:

文章插图
整体的执行流程如下:

在服务启动时，服务提供者通过内部的注册中心客户端应用自动将自身服务注册到注册中心，包含主机地址、服务名称等等信息；
在服务启动或者发生变更的时候，服务消费者的注册中心客户端程序则可以从注册中心中获取那些已经注册的服务实例信息或者移除已下线的服务；

上图还多一个设计缓存本地路由，缓存本地路由是为了提高服务路由的效率和容错性，服务消费者可以配备缓存机制以加速服务路由。更重要的是，当服务注册中心不可用时，服务消费者可以利用本地缓存路由实现对现有服务的可靠调用。
在整个执行的过程中，其中有点有一点是比较难的，就是服务消费者如何及时知道服务的生产者如何及时变更的，这个问题也是经典的生产者消费者的问题，解决的方式有两种: