UDN-企业互联网技术人气社区

板块导航

浏览  : 1257
回复  : 0

[资源分享] 微服务模式系列之四:客户端服务实现

[复制链接]
哥屋恩的头像 楼主
发表于 2016-10-8 22:05:13 | 显示全部楼层 |阅读模式
  背景

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

a.webp.jpg


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

  问题

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

  需求

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

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

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

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

  方案

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

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

b.webp.jpg


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

  举例

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

  Eureka1 充当其中的Service Registry2

  Ribbon Client3是一套HTTP客户端,负责向Eureka发出查询任务并将HTTP请求路由至可用的服务实例。

  结果

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

  相较于服务器端发现4 ,其活动部件与网络中转数量更少。

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

  这一模式使客户端与 Service Registry5相耦合。

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

  相关模式

  Service Registry 6-服务发现机制中的重要部分

  微服务底盘 7-客户端服务发现机制作为微服务底盘框架

  服务器端发现 8-是解决此类问题的备选方案。

  文中关键词链接地址:

  1.Eureka:https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance

  2.Service Registry:http://microservices.io/patterns/service-registry.html

  3.Ribbon Client:https://github.com/Netflix/ribbon

  4.服务器端发现:http://microservices.io/patterns/server-side-discovery.html

  5.Service Registry:http://microservices.io/patterns/service-registry.html

  6.Service Registry:http://microservices.io/patterns/service-registry.html

  7.微服务底盘:http://microservices.io/patterns/microservice-chassis.html

  8.服务器端发现:http://microservices.io/patterns/server-side-discovery.html

原文作者:宋潇男 来源:开发者头条

相关帖子

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于我们
联系我们
  • 电话:010-86393388
  • 邮件:udn@yonyou.com
  • 地址:北京市海淀区北清路68号
移动客户端下载
关注我们
  • 微信公众号:yonyouudn
  • 扫描右侧二维码关注我们
  • 专注企业互联网的技术社区
版权所有:用友网络科技股份有限公司82041 京ICP备05007539号-11 京公网网备安1101080209224 Powered by Discuz!
快速回复 返回列表 返回顶部