服务发现
为了实现多个微服务之间的调用,我们除了需要Feign这种调用组件外还得依赖服务发现组件。主要的原因是每个微服务所在的机器ip并非总是固定的,并且每个微服务都可能部署多个实例在不同的机器上,所以我们不能把依赖的微服务ip地址写在代码或配置文件里,我们需要有个组件去动态的管理,这就是为什么微服务架构里服务发现功能是必须的。
那么服务发现组件是怎么实现服务发现的呢?我们以大家比较熟悉的MySQL来做类比,通过MySQL简单说明一下服务发现机制的实现。如下图:
简单说明一下什么是服务提供者与服务消费者:
· 服务提供者:服务的被调用方(即:为其他微服务提供接口的微服务)
· 服务消费者:服务的调用方(即:调用其他微服务接口的微服务)
· 例如:订单服务需要调用用户服务的接口,那么订单服务就是服务消费者,而用户服务则是服务提供者
· 服务提供者与服务消费者实际描述的是微服务之间的调用关系,一般都是成对出现的
当微服务启动的时候会向服务发现组件注册自身信息,在上图中就类似于向MySQL发送一条insert语句,将服务的元数据如服务名称、ip地址及服务状态等信息插入到MySQL中,如上图的registry表数据所示,这个过程称之为服务注册,所以服务发现组件内部会都维护类似于这样的一张注册表。
微服务在注册完成后,会读取服务发现组件中保存的其他微服务的元数据并缓存一份到本地,就类似于向MySQL发送一条select all语句。这样在调用其他服务的时候,就不需要每次都去服务发现组件上查询,而是从本地缓存去查找调用地址,这样可以减轻服务发现组件的压力。所以上图中的调用箭头并没有指向服务发现组件,而是直接指向服务提供者。这样的好处是哪怕是服务发现组件挂掉了,还能从本地缓存中获取其他微服务的调用地址。到这一步微服务之间就可以互相发现了,即完成基本的服务发现
但微服务有可能会挂掉或下线,此时其他服务不应该去发现一个不存在的服务。所以每个服务启动且向服务发现组件注册完成之后,都会通过心跳机制告知存活状态。上图中用last_heartbeat字段表示,若某个服务在超过一定的时间都没有发送心跳包的话,就会被服务发现组件检测到,此时就会删除注册表里该服务的注册信息,并通知其他服务更新本地缓存(若有新注册的服务也会通知其他服务更新本地缓存)。
搭建