通信、高可用性和微服务

Question

我对微服务的理解是，您可以根据需要“仅”启动同一服务的多个实例。

那么，我的问题是，如果您有 x 个微服务实例，分布在 y 个服务器上，那么在微服务上调用 API 的任何东西如何知道在哪里找到它？

我见过的一种方法是使用某种发现服务（可以路由到实例的固定 IP 地址，例如负载均衡器）；但可以肯定的是，这只是将问题推回了一层——然后发现服务需要知道一切在哪里/什么时候失败等等？那么发现服务的高可用性呢（如果你有多个实例，你又回到不知道什么地方了）

另一种方法可能是使用 pub/sub 消息传递，但您仍然需要知道队列管理器在哪里（具有高可用性等）；所以你基本上仍然遇到同样的问题 - 使用这种方法对查询的响应更加棘手。

另一个相关问题是，如果您有一个从 STOMP 提要中提取的微服务，您将如何实现 HA？您不能只拥有该服务的 x 个实例，否则您将订阅和读取数据 x 次，这意味着当数据传递到下游系统时，您最终会复制数据。所以你会想要某种主动/被动的方法，对吧？这意味着您需要一些东西来管理故障转移，这又会产生单点故障？

Answer 1

您可以拥有一个服务注册中心，其中服务在启动时注册自己。注册中心可能会监听其他服务对注册事件的广播，因此注册中心的位置不需要固定在服务中的某个位置。

然后所有其他服务可以使用此注册表通过查询注册表来查找可用实例。注册表还可以充当 DNS 解析器，因此您的服务可以使用 DNS 按名称解析其他服务，并自动在多个主机之间进行负载平衡。

另一种方法可能是颠倒责任，想要联系其他服务的服务广播请求，其他服务用所需信息回答这些请求（这基本上是 DNS 所做的）。

一个现成的解决方案是Consul by Hashi Corp。查看它提供的功能，这些功能可能还很有用，例如健康检查。

Answer 2

我做了以下事情：

我让每个服务在启动时生成一个目录，该目录可作为根资源 (.../{service}/) 访问。 在这个 ToC 中，所有端点都是 Map。

Key 是一个（众所周知的）EndpointId，一个 Value 总是包含

• title
• href
• type（媒体类型）

所以，基本上是一个常规链接。

Magic 在于href，其中公共主机 (DNS) 可配置为环境变量（例如 Config Map）。由于使用 DNS，LoadBalancing 等不在等式。但是您也可以将这种方法用于内部 IP。

这是here提到的良好做法。

除了初始 URI（书签）和适合目标受众（即任何可能使用该 API 的客户都可以理解）的标准化媒体类型集之外，应在没有任何先验知识的情况下输入 REST API。从那时起，所有应用程序状态转换必须由客户端选择服务器提供的选项来驱动，这些选项存在于接收到的表示中或用户对这些表示的操作暗示。转换可以由客户对媒体类型和资源通信机制的了解来确定（或限制），这两者都可以即时改进（例如，按需编码）。 [这里的失败意味着带外信息正在推动交互而不是超文本。]

因此每个服务都有一个根资源，其中包含指向所有端点的链接（有时是模板化的）。

同样的 ToC 通过将其发布到名为“endpoints”的 Kafka-Topic 得到重用，其中 key 是（众所周知的）ServiceId（“fooService”或“fooService:1.2.3”），@ 987654328@ 是它的 ToC。

每个 Service 还具有对 Topic (GlobalKTable) 的读取权限，因此当它想要生成到 FooService 的链接时，他在 GlobalKTable 中查找其 ToC，通过其 Id 查找端点，将模板化变量替换为真实值并完成后，它不会改变 type，因为它被假定为正确的。

这里很酷的是（由于 Kafkas GlobalKTable 和 QueryableKeyStores），当 FooService 更改其端点（仅以非破坏方式）时，所有其他服务都会自动生成新链接。 DNS 更改或重命名路径段将正常工作。参数重命名显然不行。