服务发现基本原理
服务发现是什么？基本的实现思路？
总览
服务发现的角色组成
服务发现由三种角色组成：
- 服务提供者：服务的实际提供者，提供对应的微服务
- 服务消费者：使用服务提供者提供的微服务，一般是其他上游微服务
- 服务中介：用于联系服务的提供者与消费者的一个服务，一般为KV存储，以服务名作为Key，以服务提供者IP作为Value，在有服务提供者状态变化的时候需要及时的更新与通知。
基本的流程是：首先创建一个服务提供者(微服务)，服务提供者将自身的服务地址(一般为IP:PORT)和服务名称注册到服务中介；服务消费者在调用其他微服务时，去服务中介查找服务地址，进行调用。
服务中介
服务中介是服务发现的核心，除了支持服务注册与查找等基本功能，它还需要解决几个核心的问题：
-
服务提供者Crash后，无法主动通知中介，怎么处理？如何保证服务列表的有效性。
-
客户端心跳：服务提供者每隔一定时间主动发送“心跳”的方式来向服务端表明自己的服务状态正常，或者维护一个长连接
只说明了链路的正常，不代表服务的正常
-
服务端主动探测：服务中介主动调用服务节点的某个接口进行健康检查
服务注册中心主动调用服务的某个接口无法做到通用性。在很多场景下服务注册中心到服务发布者的网络是不通的，服务端无法主动发起健康检查，那么往往需要在宿主机器上部署一个 agent 来代替服务端的接口探测
-
-
服务列表更改之后，如何及时通知服务消费者
有一下集中机制处理：
- 消费者轮询中介 + 服务列表版本号
- 消费中介推送：TCP长连接推送 or Http Polling
- 推拉结合：消费者主动拉取，中介主动推送
-
服务发现分布式，避免单点问题
采用分布式KV存储，如etcd等
常见服务发现工具
- ECTD
- ZooKeeper
- Consul