我们都知道微服务的时代，就是将传统的单体架构拆分成独立的服务进行部署
但是微服务与微服务之间的调用 存在什么问题 需要用到什么技术
或者说用什么来技术来管理微服务
我有2个微服务 一个user 一个order
现在需要的是user--->> 可以调用到order 我们通常会想到这种模型
但是nacos 给我们解决了什么问题？？或者说nacos 做了什么？？
我们通过user---->>order 的技术无非就是通过http 来调用
这类的技术很多 spring的restTemplate ，apache的Okhttp
等等 此时完全不必要上sprigncloud的架构
第一个问题 首先此时代码中我们的
String url = "http://localhost:8081/";
ResponseEntity<String> responseEntity = restTemplate.getForEntity(url, String.class);
// 此时的url 是写死的 ，如果在下游服务横向扩展的时候此时是没办法调用的,也就是说我客户端的要有个负载均衡
也就是说我们客户端需要有一个客户端负载均衡能力，从List中选中
一个并且发起请求去调用
其次 比如说下游有2个Order服务，客户端还需要感知2个服务是可用的
比如说我Order1 挂了，我就不能再调用他了 ，也就是说某个节点出现问题了 我要吧他从列表中踢出
这些都的要依赖我们注册中心去解决
假设我们自己实现一个注册中心 又会有什么思路呢，微服务中，
我们可以用mysql 表来存储服务的信息
注册中心的功能 可以记录 每一个节点的ip:端口 存货状态
我可以在我服务启动的时候往mysql中Insert 一条数据 代表我此时是up,之后在我发起调用的时候我就做一次mysql 的select 查询
然后缓存起来~， 然后再发http请求的时候 我直接读缓存就可以了
呢么 状态什么时候是up 什么时候是down 这个怎么做
这就关系到心跳机制 涉及一个名词叫做服务续约
客户端向服务端定时发心跳 服务端接受到心跳 要修改服务的续约时间
关于注册中心的功能
1> 服务注册 insert
2> 服务查询 select --->> 客户端缓存 ~
3> 服务注销 delete
4> 心跳接口 update [比如说每15s客户端发送一个心跳 我服务端收到心跳 之后 update 最新时间]
// 服务端自己
服务端服务踢出 currentTime-最后续约的时间>15s update 存活状态 改成down 【网络抖动问题 有可能等他网络好的时候给他恢复】
服务端服务踢出 currentTime-最后续约的时间>30s delete 直接删除
心跳
服务的续约
客户端向服务端定时发心跳 服务端接受到心跳 要修改服务的续约时间
