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

【问题标题】：Best Practices for Microservices discovery without Hard Coding?没有硬编码的微服务发现的最佳实践？
【发布时间】：2016-08-21 01:04:01
【问题描述】：

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

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

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

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

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

【问题讨论】：

【解决方案1】：

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

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

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

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

【讨论】：

【解决方案2】：

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

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

【讨论】：