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

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了[翻译]微服务设计模式 - 5. 服务发现 - 服务端服务发现，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含2148字，纯文字阅读大概需要4分钟。

内容图文

原文地址：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 等)。
  • 相对于客户端服务发现来说，需要更多的网络跳转

相关的设计模式

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

内容总结

以上是互联网集市为您收集整理的[翻译]微服务设计模式 - 5. 服务发现 - 服务端服务发现全部内容，希望文章能够帮你解决[翻译]微服务设计模式 - 5. 服务发现 - 服务端服务发现所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

---