Skip to main content

服务发现

客户端发现模式​

一个服务实例被启动时, 它的网络地址会写到注册表上, 当服务终止时, 再从注册表删除; 这个服务实例的注册表通过心跳机制动态刷新; 客户端使用某种负载均衡算法, 去选择一个可用的服务实来响应这个请求 缺点: 没有经过一个集中式的负载均衡

客户端发现是直连模式

服务端发现模式​

服务端是经过了一个集中式的负载均衡做流量转发, 对微服务体系的去中心化来说并不太好, 可以使用服务网格来, 加一层代理, 把负载均衡下沉到Pod里

服务发现机制​

  1. 通过Family(appid)和Addr(IP:Port)定位实例, 除此之外还可以附加更多的元数据

    1. 权重
    2. 染色标签
    3. 集群 appid: 三段式命名, business.service.xxx, business表示业务名称，service表示服务名称，xxx表示环境（如dev、test、prod等）。

  2. Provider注册后定期(30s)心跳一次, 注册, 下线都需要同步, 注册和下线都需要长轮询推送

  3. Consumer启动时拉取实例, 发起30s长轮询

  4. Server定期(60s)检测失效(90s)的实例, 失效则剔除. 短时间里丢失了大量的心跳连接(15分钟内心跳低于期望值85%),开启自我保护, 保留过期服务不删除