[翻译]微服务设计模式 – 5. 服务发现 – 服务端服务发现

原文地址:https://microservices.io/patterns/server-side-discovery.html

服务之间需要互相调用,在单体架构中,服务之间的互相调用直接通过编程语言层面的方法调用就搞定了。在传统的分布式应用的部署中,服务地址和端口是固定并且提前预知的,所以只需要简单的 HTTP/REST 调用或者其他的 RPC 机制直接调用即可。但是在当下的云原生微服务体系中,微服务大多在某个虚拟机或者某个容器下运行,服务实例数量以及提供服务的地址以及端口都是不固定的,可以理解为,这些服务实例都是临时的。所以,需要实现使服务客户端能够对一组动态变化的临时服务实例发请求的机制。

提出问题

某个服务的客户端,API网关或者一些其他需要发现服务实例的服务,如何知道服务实例的位置?

考虑因素

  • 服务的每个实例都在特定的位置(主机和端口)暴露一个远程 API,例如 HTTP/REST 或 Thrift 等
  • 服务实例的数量及其位置都会动态变化
  • 虚拟机和容器通常分配动态 IP 地址
  • 服务实例的数量可能动态变化。例如,AWS 的 EC2 自动扩容组可以根据 LOAD(负载)动态调整实例数量。

解决方案

当想请求一个服务时,客户端通过运行在已知位置的路由器(即负载均衡器)发出请求。这个负载均衡器查询注册中心要调用的服务有哪些实例,或者注册表其实就集成在负载均衡器中,然后把请求转发到对应的实例。如下图所示:

举例

AWS 弹性负载均衡器(ELB)是服务器端发现路由器的一个例子。客户端将 HTTP 请求(或者其他应用协议的 TCP 链接请求)发到 ELB,ELB 负责在一组 EC2 实例中负载均衡。ELB 可以负载均衡来自外网的请求,也可以部署在VPC中负载均衡内部的请求。ELB 也作为服务注册中心,EC2 实例可以通过 API 调用显式地向 ELB 注册,或者作为自动扩容组的一部分自动注册。

一些集群解决方案,例如 Kubernetes 和 Marathon, 在每个主机上运行一个作为服务端服务发现的代理。当需要访问一个服务的时候,客户端访问本地代理,这个代理会将请求转发到集群中相应的服务实例上。

分析

  • 服务器端服务发现有许多优点:
    • 相比较客户端发现,客户端代码几乎没有侵入,因为它不需要处理发现。相反,客户机只是向路由器发出请求。
    • 一些云环境提供了这种功能,例如 AWS ELB
  • 它还存在以下缺点:
    • 除非云环境中有负载均衡器,否则需要部署这样一个额外组件,并且还需要多实例部署来满足可用性和负载能力。
    • 除非负载均衡器是基于 tcp 的路由器,否则必须支持必要的应用通信协议(例如 HTTP、grpc、thspace 等)。
    • 相对于客户端服务发现来说,需要更多的网络跳转

相关的设计模式

  • 负载均衡器使用注册中心
  • 负载均衡器可能会使用断路器调用服务
  • 客户端服务发现是另一种替代解决方案

给TA买糖
共{{data.count}}人
人已赞赏
经验教程

精通模块化JavaScript

2021-3-16 10:02:00

经验教程

掌握了开源框架还不够,你更需要掌握源代码

2021-3-16 10:32:00

⚠️
免责声明:根据《计算机软件保护条例》第十七条规定“为了学习和研究软件内含的设计思想和原理,通过安装、显示、传输或者存储软件等方式使用软件的,可以不经软件著作权人许可,不向其支付报酬。”您需知晓本站所有内容资源均来源于网络,仅供用户交流学习与研究使用,版权归属原版权方所有,版权争议与本站无关,用户本人下载后不能用作商业或非法用途,需在24个小时之内从您的电脑中彻底删除上述内容,否则后果均由用户承担责任;如果您访问和下载此文件,表示您同意只将此文件用于参考、学习而非其他用途,否则一切后果请您自行承担,如果您喜欢该程序,请支持正版软件,购买注册,得到更好的正版服务。 本站为个人博客非盈利性站点,所有软件信息均来自网络,所有资源仅供学习参考研究目的,并不贩卖软件,不存在任何商业目的及用途,网站会员捐赠是您喜欢本站而产生的赞助支持行为,仅为维持服务器的开支与维护,全凭自愿无任何强求。本站部份代码及教程来源于互联网,仅供网友学习交流,若您喜欢本文可附上原文链接随意转载。
无意侵害您的权益,请发送邮件至 momeis6@qq.com 或点击右侧 私信:momeis 反馈,我们将尽快处理。
0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
今日签到
有新私信 私信列表
搜索