主流微服务注册中心详解

前言

微服务的注册中心目前主流的有以下五种：

• Zookeeper

• Eureka

• Consul

• Nacos

• Kubernetes

那么实际开发中到底如何选择呢？这是一个值得深入研究的事情，别着急，今天陈某就带大家深入了解一下这五种注册中心以及如何选型的问题。

一、为什么需要注册中心

随着单体应用拆分，首当面临的第一份挑战就是服务实例的数量较多，并且服务自身对外暴露的访问地址也具有动态性。可能因为服务扩容、服务的失败和更新等因素，导致服务实例的运行时状态经常变化，如下图：

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

• 营销、订单、库存这三个服务的地址都可能动态的发生改变，单存只使用配置的形式需要频繁的变更，如果是写到配置文件里面还需要重启系统 ，这对生产来说太不友好了;

• 服务是集群部署的形式调用方负载均衡如何去实现；

解决第一个问题办法就是用我们用伟人说过一句话，没有什么是加一个中间层解决不了的 ，这个中间层就是我们的注册中心。

解决第二问题就是关于负载均衡的实现，这个需要结合我们中间层老大哥来实现。

二、如何实现注册中心

对于如何实现注册中心这个问题，首先将服务之间是如何交互的模型抽象出来，我们结合实际的案例来说明这个问题，以商品服务为例：

1. 当我们搜索商品的时候商品服务就是提供者；

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

整体的执行流程如下:

1. 在服务启动时，服务提供者通过内部的注册中心客户端应用自动将自身服务注册到注册中心，包含主机地址、服务名称等等信息；

2. 在服务启动或者发生变更的时候，服务消费者的注册中心客户端程序则可以从注册中心中获取那些已经注册的服务实例信息或者移除已下线的服务；

上图还多一个设计缓存本地路由，缓存本地路由是为了提高服务路由的效率 和容错性 ，服务消费者可以配备缓存机制以加速服务路由。更重要的是，当服务注册中心不可用时，服务消费者可以利用本地缓存路由实现对现有服务的可靠调用。

在整个执行的过程中，其中有点有一点是比较难的，就是服务消费者如何及时知道服务的生产者如何及时变更的，这个问题也是经典的生产者消费者的问题，解决的方式有两种:

1. 发布-订阅模式 ：服务消费者能够实时监控服务更新状态，通常采用监听器以及回调机制，经典的案例就是Zookeeper ；

2.  主动拉取策略 ：服务的消费者定期调用注册中心提供的服务获取接口获取最新的服务列表并更新本地缓存,经典案例就是Eureka ；

对于如何选择这两种方式，其实还有一个数据一致性 问题可以聊聊，比如选择定时器肯定就抛弃了一致性，最求的是最终一致，这里就不深入展开了，另外你可能还会说服务的移除等等这些功能都没介绍，在我看来那只是一个附加功能，注册中心重点还是在于服务注册和发现，其他都是锦上添花罢了。

三、如何解决负载均衡

负载均衡的实现有两种方式:

1. 服务端的负载均衡；

2. 客户端的负载均衡; 对于实现的方案来说本质上是差不多的，只是说承接的载体不一样，一个是服务端，一个客户端，如下图:

服务端的负载均衡，给服务提供者更强的流量控制权，但是无法满足不同的消费者希望使用不同负载均衡策略的需求。

客户端的负载均衡则提供了这种灵活性，并对用户扩展提供更加友好的支持。但是客户端负载均衡策略如果配置不当，可能会导致服务提供者出现热点，或者压根就拿不到任何服务提供者。

服务端负载均衡典型的代表就是Nginx ，客户端负载均衡典型代表是Ribbon ，每种方式都有经典的代表，我们都是可以深入学习的。

常见的负载均衡器的算法的实现，常见的算法有以下六种 ：

1、轮询法