- 服务如何注册
- consumer如何知道provider
- 服务注册中心如何高可用
- 服务上下线，消费端如何动态感知
文章目录
- 1.服务注册
- 2.服务消费
- 3.注册中心高可用
- 4.动态感知服务上下线
1.服务注册
当我们把服务信息注册上去后，就应该是：
服务列表保存通常有三种方式：本地内存、数据库、第三方缓存系统
注册上去后，consumer需要服务地址的时候，就可以用相应key去注册中心获取对应的服务列表。
同一个服务注册中心，我们可以注册多个服务，比如用户服务、商品服务、订单服务…
2.服务消费
consumer如何知道provider
consumer端通过key获取指定的服务地址列表。
3.注册中心高可用
高可用无非就是做集群，我们可以对注册中心部署多个节点。在消费端consumer只需要知道一个服务注册中心集群地址cluster-url即可。
4.动态感知服务上下线
consumer拿到服务列表后，会把服务列表保存起来，保存到本地缓存里。
consumer通过一定的负载均衡算法，选择出一个地址，最后发起远程的调用。
如果我们的服务节点挂掉一个了，怎么办
我们的服务注册中心需要知道哪个服务节点挂了，然后从对应服务列表里删除。
有种办法叫做心跳检测heartBeat，即就是服务注册中心，每隔一定时间去监测一下provider，如果监测到某个服务挂了，那就把对应服务地址从服务列表中删除。
但是服务注册中心的服务列表和consumer端的服务列表不一样了。
动态的感知: 拉取或者推送push和pull
- push：服务注册中心主动推送服务列表给consumer。
- pull：consumer主动从注册中心拉取服务列表。
Question:
- 不管是push还是pull，都会存在consumer和服务注册中心的通信管道。如果他们之间断开了，那就无法获取服务列表了。
- push有个不好点，那就是服务注册中心需要维护大量的会话，而且还需要对每个会话维持一个心跳，一遍知晓这些会话状态，得确保这些consumer能收到数据，
- pull因为是定时去拉取，所以会存在一定的数据延迟，比如consumer刚刚拉取服务列表，但就在拉取结束的后，某个服务provider挂了，consumer就要等下次拉取才知道对应服务provider挂了。
RA:
还有一种方式long-pull，也叫长轮询，是上面两种方案的优化方案，consumer发起拉取请求时，先把这个请求hold住，当服务注册中心有发生变化后，consumer端能立马感知。
优点：实现也不复杂，同时相对轮询，节约带宽
缺点：还是存在占用服务端资源的问题，虽然及时性比轮询要高，但是会在没有数据的时候在服务端挂起，所以会一直占用服务端资源，处理能力变少
