没有硬编码的微服务发现的最佳实践？

Question

这是一个令我讨厌的问题，如何编写一系列在不同位置的各种机器上运行的微服务，而无需对每个服务的每个位置进行硬编码？

就像说例如我有服务A，它执行json消息的某种形式的验证。服务A在方框1,3,5上运行，随着需求增长，可以调出更多的实例。

现在说我有服务B，它看起来要打电话给服务A，我将如何与我的服务A所在的服务B进行通信？

可能的解决方案，我认为：

• 硬编码与服务A，然后委托任务分给服务A的所有实例“主”节点的位置服务B

• 消息队列的使用情况？ - 服务B写入一系列消息队列，服务A实例从设置的消息队列中读取并将结果发送回服务B.

• SSDP-利用某种形式的简单服务发现协议来广播哪些服务在哪里运行设置网络并跟踪这些服务。

我对这种建筑风格很陌生，所以我希望我没有遗漏一些非常简单的东西？

Answer 1

一般来说，有2种方法来实现服务发现：

1. 与反向代理/ API网关。这种方法提供更快的更新传播。当您的服务被部署/重新部署/取消部署时，所有更改都可以立即通过反向代理进行处理，因此其配置总是反映您的微服务的状态。但是，这会对性能产生影响 - 所有请求（包括内部请求）都应该通过反向代理组件。有关此方法的更多详细信息https://memz.co/api-gateway-microservices-docker-node-js/
2. 与DNS。由于每个组件（实质上是每个用于调用可发现组件的http客户端）需要重新验证其DNS缓存，这可能需要一些时间（可以使用相应的DNS条目的TTL进行配置），因此此方法提供的更新速度较慢。此外，它假定每个http客户端实现都将遵守该TTL值。作为第一个近似值，我们可以假设TTL可以设置为低至60秒，因此，配置更改将不会生效。关于此方法的更多详细信息https://memz.co/service-discovery-microservices-skydns-docker/

Answer 2

使用service registry并在运行时查找其他服务的位置。以下是一些用于此的典型技术（还有其他一些技术）。

• Eureka
• Apache ZooKeeper
• Consul
• Etcd

服务注册必须存在于一个已知位置。该位置应始终是微服务中的可配置属性。从来没有硬编码！为了提高灵活性，通过DNS访问注册表端点是非常典型的。所以，你的服务寻找https://registry-1而不是一个特定的IP地址，这可能会改变。

根据您希望在系统中使用的通信机制，消息队列将帮助您的服务进行通信，但它不会帮助发现。在这种方法中，您仍然使用DNS和可配置属性来告知每个微服务消息队列的位置。然后，单个服务将发布消息并将消息订阅到队列中。微服务永远不会意识到其他服务（没有发现），并且所有的通信都将通过队列中的消息。

Sam Newman's book on microservices更详细地介绍了这些方法，并涵盖了您可能感兴趣的其他关注领域。