系统设计之服务发现
系统设计之服务发现
https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/?utm_source=introduction-to-microservices
在微服务的世界中，模块与模块分别部署在不同的地方，它们之间的约束或者协议由方法签名转变为更高级的协议，比如 RESTful 、PRC，在这种情况下，调用一个模块就需要通过网络，我们必须要知道目标端的网络地址与端口，还需要知道所暴露的协议，然后才能够编写代码比如使用 HttpClient 去进行调用，这个“知道”的过程，往往被称为服务发现。
服务发现三个角色
- 服务提供者，提供API服务（例如rest api）
- 服务消费者
- 服务中介： 消费者和提供者的桥梁，提供者注册，消费者从服务中介查询服务地址。
服务实例的网络地址在服务启动的时候被登记到服务注册表中 ，当实例终止服务时从服务注册表中移除。服务实例的注册一般是通过心跳机制阶段性的进行刷新。
客户端服务发现
客户端决定可用服务实例的地址并且对请求做集群的负载均衡： 客户端访问service registry 获取可用服务列表，并且使用负载均衡针选择要调用的服务实例。
Netflix Eureka- 通过rest API 管理服务实例注册和服务查询 ； Netflix Ribbon 可以和Eureka 一起使用来实现多个实例间的请求负载均衡。
服务端发现
客户端通过一个负载均衡器向服务发送请求，负载均衡器查询服务注册表并把请求路由到一台可用的服务实例上。
优势： 服务发现的细节对客户端来说是抽象的，客户端仅需向负载均衡器发送请求即可。
服务注册
一个包含服务实例网络地址的的数据库 - 需要高可用和实时性， 服务注册表对集群中的服务实例使用复制（replication）协议来维护一致性。
Eureka 为服务注册和查询提供了rest API： 服务实例使用POST 请求注册服务，并且需要定时（30秒）通过PUT 请求去刷新，服务提供者也可以DELET来删除注册信息。
其他服务注册工具：
- etcd ， 一个高可用、分布式、一致性、key-value 方式的存储
- consul，一个发现和配置服务的工具，为客户端注册和发现服务提供了API，Consul还可以通过执行健康检查决定服务的可用性。
- zookeeper，、高性能的针对分布式应用的协调服务
self-registration
服务实例自己负责通过服务注册表对自己进行注册和注销，另外如果有必要的话，服务实例可以通过发送心跳请求防止注册过期
Eureka使用这种模式，优势是先对比较简单，劣势是服务实例和服务注册表强耦合
third-party registration
服务实例本身并不负责通过服务注册表注册自己，而是通过另一个被称作 service registrar系统组件来处理注册。
service registrar 通过轮询或者订阅事件来检测一些运行实例的变化，当它检测到一个新的可用服务实例时就把该实例注册到服务注册表中去，service registrar还负责注销已经被终止的服务实例
Spring cloud Eureka
netflix 系列
- eureka
- ribbon
- Hystrix
eureka作为服务发现，服务注册是，server会尝试relicate到其他server ，但不能保证强一致性。另外服务下线是通过timeou来实现，并非实时。