Service Discovery 服务发现¶
快速理解服务发现¶
服务提供者是什么, 简单点说就是一个HTTP服务器, 提供了API服务, 有一个IP端口作为服务地址. 服务消费者是什么, 它就是一个简单的进程, 想要访问服务提供者提供的服务来干一些事情. 一个HTTP服务器既可以是服务提供者对外提供服务, 也可以是消费者需要别的服务提供者提供的服务, 这就是服务依赖, 没有你我就不是我自己. 复杂的服务甚至有多个服务依赖.
服务发现有三个角色:
Service Provider (服务提供者)
Service Consumer (服务消费者)
Service Broker (服务中介)
逻辑上, 服务发现 就是 消费者 到 中介 处询问 提供者 的地址 这一过程.
消费者客户端程序中的代码最终还是要通过一个 IP 或 DNS 地址来访问具体的服务的. 而在获得这个地址是通过问询 中介 实现的.
所以在你的消费者程序中需要包含这样一些通用逻辑, 这也逻辑独立于具体的服务消费请求逻辑之外:
查询消费者向中介询问服务, 获得提供者地址.
定期检查提供者是否存活, 健康.
缓存提供者地址.
使用地址发起请求.
请求失败, 检查失败原因, 如有必要, 重新询问中介, 确保地址没有问题.
服务发现的实现:
目前服务发现的实现主要有两种:
通过数据库. 比如 Spark / Kafka 里的 zookeeper, K8s 里的 ETCD, 或者微服务架构中的 Redis. 好处是专用, 高可用. 坏处是客户端需要额外的支持来实现服务地址查询.
通过 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 是一个专门的组件用于解决服务发现的.