微服务架构模式系列文章之四:客户端服务发现
微服务架构模式系列文章之四:客户端服务发现
普元云计算 发表于1年前
微服务架构模式系列文章之四:客户端服务发现
  • 发表于 1年前
  • 阅读 0
  • 收藏 0
  • 点赞 0
  • 评论 0

腾讯云 技术升级10大核心产品年终让利>>>   

背景

不同服务之间通常需要相互调用。在单体应用程序当中,服务间通过语言层级的方法或者过程实现相互调用。在传统的分布式系统部署下,服务在固定并且已知的位置(主机与端口)运行,从而确保各服务可利用HTTP/REST或者某种RPC机制进行相互调用。然而,现代化微服务应用程序中通常在虚拟化或者容器化环境中运行,在这样的环境中服务的实例数量和位置是动态变化的。

因此,要想实现客户端向动态变化的一组服务端实例发送请求,我们必须采用新的机制。

问题

服务的客户端——包括API网关或者其它服务——如何才能获取服务端实例的位置?

需求

  • 每一服务实例都会在特定位置(主机与端口)通过HTTP/REST或者Thrift等方式发布一个远程API。
  • 服务端实例的具体数量及位置会发生动态变化。
  • 虚拟机与容器通常会被分配动态IP地址。
  • 服务实例的数量会发生动态变化。例如,EC自动伸缩组会根据负载情况随时调整实例数量。

方案

在向某一服务发送请求时,客户端会通过查询 Service Registry,即服务注册表,以获取该服务实例的位置。该注册表中包含全部服务的位置。

以下示意图展现了这种模式的结构。

而这正是微服务底盘框架的典型处理方式。

示例

Netflix OSS正是客户端发现机制的典型代表:

结果

客户端发现机制拥有以下优势:

客户端发现机制亦存在着以下弊端:

  • 这一模式使客户端与 Service Registry相耦合。
  • 需要为应用程序中使用的每种编程语言/框架建立客户端服务发现逻辑,例如Java/Scala以及JavaScript/Node JS。举例来说,Netflix Prana就为非JVM客户端提供了一套基于HTTP代理的服务发现方案。

相关模式

原文链接

共有 人打赏支持
粉丝 2
博文 23
码字总数 18356
×
普元云计算
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: