Service discovery 在微服务架构中的意义

Hackernoon 原文

你如果想和你所有的朋友失去联系,最简单的办法就是换个电话号码,然后不通知任何人。

在微服务架构中也一样,如果一方换了 IP 地址,其他 service 就找不到它了。

Service discovery 的作用,就是帮忙在网络中寻找 service 。

为什么需要 service discovery

如果网站的架构都是在物理主机的基础上搭建的,那么配置、IP 地址,在多数时候都是相对稳定不变的。

但如果 app 在云端,因为 service 会经历重启、崩溃、伸缩,所以很多 service 都是使用动态的 IP。那么手动再来配置每台服务器就不方便了。

service discovery 的组成

它由3部分组成:

  1. service registry,维护一个列表,存储各个 service 的位置信息
  2. service provider 提供服务。服务开始时把自己 register 到 registry 上。服务断线时 de-register 。
  3. service consumer 使用其他服务。它需要从 registry 获取其他服务的位置

service discovery 的设计

其实我们需要做的就是维护一个 service name -> [ server IPs ] 的 hash table。注意这里使用的是 server IPs 集合,因为一个 service 可能由很多太 server 提供。

当需要获取一个 service IP 时,直接从数组中随机选择一个即可。

这样的话,用一个 redis 都可以实现一个简单的 service discovery。

但这里有以下一些复杂的情况要考虑:

  1. service 掉线时,多半不能 de-register 。那么 service discovery 如何知道它掉线了? 现在的解决方案是, service discovery 会时不时对 service 做 health check ,比如每5秒一次。如果 service 无法连接,那么就 de-register
  2. consumer 是不是每次查询其他 service 都要向询问 register? 为了减小 register 的压力,consumer 可以维护一份本地的 provider 位置信息
  3. 在 2) 的基础上,如果 provider 信息变了,如何通知 consumer? 其实实现方法挺多的。1) 如果 consumer 主动更新自己,那么consumer 可以时不时和 registry 同步信息,比如每1分钟一个。这样 registry 压力还是挺大。也可以是只有当 consumer 发现,使用本地提供的信息仍然无法连接 provider 时才向 registry 同步信息。这更像是一个 cache 的设计。 2) 如果 provider 主动更新 consumer,那么可以使用 pub-sub 模式。设计一个message queue,所有 consumer 监听这个queue。provider 位置信息变化时发一个 message,consumer 收到后更新自己。不过这样,每个 consumer 需要多一个 thread 来 listen to queue
  4. 如何避免 registry 的 single point of failure? 使用分布式系统来实现 registry ,比如 zookeeper / etcd / consul

另一种实现方法,是使用 client-side discovery,从客户端的角度实现 discovery。每一个客户端都有一份 provider 的位置信息,由客户端来实现 load balance 。Airbnb 的 SmartStack 和 Netflix 的 Eureka 就类似这个思路。这个方法有利有弊吧。

微信公众号:网站架构札记

最近发布