服务注册与发现的实现原理【大白话通俗讲解】

本文用数据库来类比服务发现组件，篇幅短小浅显易懂。

了解了服务注册与发现的实现原理之后，我们使用不同的组件就可以快速入门了！

大家顺着文字配合图片看下去就行啦！

 这里我们用 mysql数据库类比 服务发现组件

其中服务消费者（内容中心）想调用服务提供者 （用户中心）

 那么实现服务注册就变成了：

• 1. 微服务启动时向数据库插入一条数据：包含服务名、ip、端口和状态

• 2. 微服务停止时删除数据库代表的那条记录

而服务发现也很简单：

• 只用发送一条sql查询就行了

• # 服务消费者想要发现服务名为 'user-center'且状态为在线的服务实例
  select * from registry where service_name='user-center' and status='UP'

通过查询sql返回的结果就可以得到全部在线的实例进行请求啦 

但这样有个问题：

• 1. 微服务很多的时候会频繁调用服务发现组件，会给服务发现组件带来很大压力

• 2. 服务发现组件如果宕机了，微服务之间就无法互相调用了

基于问题的改进：

• 在微服务上做缓存：定时任务定时的向服务发现组件发送查询并缓存到本地，调用时永远从本地获取

改进的优势：

• 1. 不用频繁发送查询请求

• 2. 服务发现组件宕机也不影响微服务正常调用

不过这样还是有问题！！

前面都是正常情况，如果有异常场景比如某个微服务宕机了

这时将数据库表新增一个字段 last_heartbeat：心跳时间

表变成了：

 

现在每个微服务都向服务发现组件发送请求，类比这里便是更新数据库last_heartbeat为最新时间，这个请求就是心跳。

如果服务发现组件发现某个微服务很久没有发送请求了，则认为该实例下线了，会将 status的值改为 down

这样其他微服务的如果更新了缓存（重新发送查询请求）就不会去调用下线的实例了

这就是服务注册和发现的原理啦，通过类比是不是很容易就懂了，觉得有用的话请给我点个免费的赞吧！