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

Question

这是一个困扰我一段时间的问题，如何编写一系列在不同位置的不同机器上运行的微服务，而不需要对每个服务的单独位置进行硬编码？

例如，我有服务 A 对 json 消息进行某种形式的验证。服务 A 在框 1、3、5 上运行，随着需求的增长，可以启动更多实例。

现在假设我有服务 B，它看起来调用服务 A，我将如何与服务 A 所在的服务 B 通信？

我考虑过的可能解决方案:

使用服务 A 的“主”节点位置对服务 B 进行硬编码，然后将任务委派给服务 A 的所有实例。

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

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

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

Answer 1

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

Eureka

Apache ZooKeeper

Consul

Etcd

服务注册表必须存在于已知位置。此位置应始终是微服务中的可配置属性。从不硬编码!为了提高灵 active ，通常通过 DNS 访问注册表端点。因此，您的服务寻找 https://registry-1而不是特定的 IP 地址，这可能会改变。

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

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