返回 登录
0

微服务模式系列之五:服务端服务发现

阅读3765

背景

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

图片描述

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

问题

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

需求

每一服务实例都会在特定位置(主机与端口)通过HTTP/REST或者Thrift等方式发布一个远程API。

服务端实例的具体数量及位置会发生动态变化。

虚拟机与容器通常会被分配动态IP地址。

服务实例的数量会发生动态变化。例如,EC自动伸缩组会根据负载情况随时调整实例数量。

方案

在向某一服务发送请求时,客户端会通过在已知位置运行的路由器(或者是负载均衡器)发送请求。路由器会查询Service Registry(即服务注册表),并向可用的服务实例转发该请求。服务注册表也可能背内建于路由器之中。

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

图片描述

示例

AWS Elastic Load Balancer(即AWS弹性负载均衡,简称ELB)便是一个服务器端服务发现模式的例子。客户端向该ELB发出HTTP(S)请求(或者开启TCP连接),而ELB则在一组EC2实例中对该流量进行负载均衡。ELB既能够对来自互联网的外部流量进行负载均衡,又能够被部署在VPC中,对内部流量进行负载均衡。ELB同样可作为Service Registry发挥作用。EC2实例可通过API调用或者借助自动伸缩分组机制注册至ELB。

一些集群解决方案如Kubernetes以及Marathon,会在每台主机上运行一套代理,用来提供服务器端服务发现模式的路由机制。为了访问服务,客户端可以利用被分配至该服务的端口接入这个本地代理。该代理随后会将各请求转发给在集群某处运行的服务实例。

结果

服务器端发现机制拥有以下优势:

相较于客户端发现,其客户端代码由于无需实现发现功能而更为简单。而且客户端只需要向路由机制发送请求即可。

部分云环境提供此项功能,例如AWS Elastic Load Balancer。

但服务器端发现机制亦存在着以下弊端:

除非成为云环境的一部分,否则该路由机制必须作为另一系统组件进行安装与配置。为实现可用性和一定的接入能力,还需要为其配置一定数量的副本。

相较于客户端发现,服务器端发现机制需要更多的网络跳转。

相关模式

服务注册表

客户端发现是一种备选方案。

作者博客:http://blog.csdn.net/xn_sung

普元云计算专区:http://primeton.csdn.net/m/zone/primeton/index#

普元公众号:

图片描述

评论