谈服务发现的背景、架构以及落地方案

聊聊架构 · 公众号 · 架构 · 2017-06-21 08:21

正文

请到「今天看啥」查看全文

之前做单体式应用的时候，有个和服务发现类似的概念叫服务目录，其实这两个概念并不冲突，也不存在明显的替代关系。服务目录更像是一个市场，是一个把服务当作产品上架展示，供用户了解和购买的渠道，使用者是人；而服务发现是供服务注册自身和查询其他服务相关信息的一种机制，使用者是程序。在微服务架构中，服务发现作为一种基本机制，必须得到实现，而服务目录则是一个可选项，如果有的话，用户体验会更好一些。

InfoQ：能否以一个请求为例，介绍下服务发现的流程？

宋潇男 ：服务发现的流程比较简单，去年我翻译了 Chris Richardson 的一些微服务文章，对服务发现的流程做了些基本的描述，比较完备的说，服务发现流程应该分为两种模式：

客户端发现 ：

服务提供者的实例在启动时或者位置信息发生变化时会向服务注册表注册自身，在停止时会向服务注册表注销自身，如果服务提供者的实例发生故障，在一段时间内不发送心跳之后，也会被服务注册表注销。
服务消费者的实例会向服务注册表查询服务提供者的位置信息，然后通过这些位置信息直接向服务提供者发起请求。

服务端发现：

第一步与客户端发现相同。
服务消费者不直接向服务注册表查询，也不直接向服务提供者发起请求，而是将对服务提供者的请求发往一个中央路由器或者负载均衡器，中央路由器或者负载均衡器查询服务注册表获取服务提供者的位置信息，并将请求转发给服务提供者。

这两种模式各有利弊， 客户端发现模式的优势 是，服务消费者向服务提供者发起请求时比服务端发现模式少了一次网络跳转，劣势是服务消费者需要内置特定的服务发现客户端和服务发现逻辑； 服务端发现模式的优势 是服务消费者无需内置特定的服务发现客户端和服务发现逻辑，劣势是多了一次网络跳转，并且需要基础设施环境提供中央路由机制或者负载均衡机制。 目前客户端发现模式应用的多一些 ，因为这种模式的对基础设施环境没有特殊的要求，和基础设施环境也没有过多的耦合性。