本文用数据库来类比服务发现组件，篇幅短小浅显易懂。
了解了服务注册与发现的实现原理之后，我们使用不同的组件就可以快速入门了！
大家顺着文字配合图片看下去就行啦！
这里我们用 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
这样其他微服务的如果更新了缓存（重新发送查询请求）就不会去调用下线的实例了
这就是服务注册和发现的原理啦，通过类比是不是很容易就懂了，觉得有用的话请给我点个免费的赞吧！