Service Discovery 服务发现

快速理解服务发现

服务提供者是什么, 简单点说就是一个HTTP服务器, 提供了API服务, 有一个IP端口作为服务地址. 服务消费者是什么, 它就是一个简单的进程, 想要访问服务提供者提供的服务来干一些事情. 一个HTTP服务器既可以是服务提供者对外提供服务, 也可以是消费者需要别的服务提供者提供的服务, 这就是服务依赖, 没有你我就不是我自己. 复杂的服务甚至有多个服务依赖.

服务发现有三个角色:

  • Service Provider (服务提供者)

  • Service Consumer (服务消费者)

  • Service Broker (服务中介)

逻辑上, 服务发现 就是 消费者 到 中介 处询问 提供者 的地址 这一过程.

消费者客户端程序中的代码最终还是要通过一个 IP 或 DNS 地址来访问具体的服务的. 而在获得这个地址是通过问询 中介 实现的.

所以在你的消费者程序中需要包含这样一些通用逻辑, 这也逻辑独立于具体的服务消费请求逻辑之外:

  1. 查询消费者向中介询问服务, 获得提供者地址.

  2. 定期检查提供者是否存活, 健康.

  3. 缓存提供者地址.

  4. 使用地址发起请求.

  5. 请求失败, 检查失败原因, 如有必要, 重新询问中介, 确保地址没有问题.

服务发现的实现:

目前服务发现的实现主要有两种:

  1. 通过数据库. 比如 Spark / Kafka 里的 zookeeper, K8s 里的 ETCD, 或者微服务架构中的 Redis. 好处是专用, 高可用. 坏处是客户端需要额外的支持来实现服务地址查询.

  2. 通过 DNS 查询. 好处是客户端通常天生带有 DNS 查询, 坏处是 DNS 服务本身比较难以维护.

一些经典系统中的服务发现

K8S:

K8S 用 ETCD 作为分布式 元数据 数据库.

每个 K8S 集群都会在 kube-system 命名空间中用 Pod 的形式运行一个 DNS 服务, 通常称为 集群DNS, 英文叫做 DNS Pod and Service. 而这个 DNS 服务所使用的技术来自于开源项目 CoreDNS.

AWS Cloud Map:

AWS 有很多很棒的微服务组件, 比如 Lambda, ECS, EKS. AWS Cloud Map 是一个专门的组件用于解决服务发现的.