什么是服务发现
即我需要调用一个服务的时候，需要知道它的IP地址。
为什么要服务端发现？
如果只有每个服务只有一个，且不会故障转移，那么直接代码或者配置文件中写IP地址即可。但是如果服务多了，或者需要自动扩缩、故障转移、无缝升级，那么则需要服务发现。
常规的服务发现有两种模式：
- 这里的调用者成为消费者服务或者上游服务。
- 提供者成为生产者服务或者下游服务。
客户端发现 client-side discovery
- 服务A启动，将地址写到注册中心。停止则从注册中心删除。
- 服务A和注册中心保持心跳，动态刷新。
- 调用者（客户端，或者叫上游服务）使用一个负载均衡算法，选择一个服务去连接。
客户端发现实现的大概逻辑：
- 简易版：
直接启动的时候写到Redis或者数据库作为注册表，调用的时候直接取注册表的数据就好了。
topic----IP 的hash结构。
万一某个服务崩了，这个注册表里面会有脏数据，所以当调用方取出来发现调用失败的时候，就删掉一下。
但是这样的问题就是每个客户端都需要实现负载均衡算法。
- 高配版：
写一个注册中心，其实也很简单，就是有服务注册的时候写入一下Redis，有服务下线就删除。然后提供一个接口告知该服务有哪些可以调用的IP列表。
这里值得注意的就是请求IP的对外方法。（敲黑板）
这个注册中心是单点的，虽然它的逻辑很简单，不容易挂，但是它毕竟连接了所有服务，如果维持长连接心跳，这个量是很大的，如果每次访问服务都要请求一下IP，这个pv是非常庞大的。
微服务大多都是点查，比如用userID查用户数据就是用户服务一个方法，虽然可以暴露一个批量查询的方法，但是服务的请求量还是非常大的，可以说是将原来的函数调用转成了服务调用，可以想象，一个函数调用需要转化为一个注册中心请求IP+一个服务请求，是不是太慢了点。
有一个比较简单地解决办法：就是上游服务连接注册中心，获取所有服务的指定IP，但是不要立即断开，等30秒，直接根据这个IP列表调用下游服务。此时如果注册中心有更新，则返回最新的，直到30秒超时断开。
这样30秒一个连接，而且不会一直频繁发包请求，压力会大大减少。当然，终极方案还是将这个中心做成高可用的，比如主备、多套负载等。
客户端发现的优缺点：
优点：
- 简单
- 直连，减少了网络跳转。（了解了服务端发现模式就懂了）
缺点：（注册中心可以解决，但是也带来了单点问题）
- 需要维护服务间的心跳联系。（注册表告知的是IP，后面的关系需要上下游自己维护）
是优点也是缺点：
- 每个上游服务可以灵活安排自己的负载均衡算法。
- 需要实现多套负载均衡的算法，服务不一定是一种语言写的，而且如果负载均衡算法涉及到更新，则需要所有服务重新打包。
服务端发现
既然想统一负载均衡算法，那么我加一个反向代理就好了，比如nginx。消费者服务不再关心IP，只需要提供topic+接口名，代理方用一定的负载均衡算法得到最优IP，直接路由过去。
服务端发现的优缺点
优点：
- 统一的负载均衡算法，方便重构、升级、迭代。
- 消费端不用关心IP，不用维持心跳，简单了很多。
缺点：
- 加了一层转发，相对会慢一点点。
- 路由转发者会成为性能瓶颈。如果想把路由转发再做成负载均衡，那就是无限套娃了（变成了怎么找负载路由转发者IP的问题）。
实现细节
从上面可以看出：
- 如果是小型业务，选简配版客户端发现模式就好。
- 中型业务，可以考虑服务端发现，大概率你的瓶颈不在转发这里。
- 大型业务，自然是自己写注册中心了。下面我们来看看注册中心的实现细节。
注册中心的实现
- 首先是需要维护一个注册表，通常是用的redis，hash存储。
- 方案A：
- 提供一个获取所有IP的接口，和获取单个topic的IP的接口。
- 消费者端自己实现负载均衡算法，可以自己定制。
- 方案B：
- 直接实现负载均衡算法，让消费者在接口中传参选择用哪一种，提供一个每个topic的IP的接口。
- 然后消费者端需要进行30秒的长连接，一旦有人下线，则广播给正在连接的消费端。
- 为生产端提供一个上线一个下线的接口。
消费者端和生产者端
- 需要统一实现一个心跳维持的逻辑（健康检查），一旦生成者下线，则再次向注册中心拉取IP列表，甚至可以附带通知注册中心它挂了。
- 生产者在上线时，先预热好了再通知注册中心，此时不用急。
- 生产者在下线时，先通知注册中心下线，不要给我流量了，然后消化掉正在连接的消费者流量，停止健康检查，再下线。
- 如果生产者崩了，则靠健康检查，消费者会主动断。
