Microservices 通信、高可用性和微服务

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

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

我见过的一种方法是使用某种发现服务固定IP地址，可以路由到实例，比如负载平衡器；但这无疑只是将问题推回了一层——然后发现服务需要知道一切在哪里/何时失败，等等。？那么，发现服务的高可用性又如何呢？如果您有多个发现服务的实例，那么您又回到了不知道任何东西在哪里的状态

另一种方法可能是使用pub/sub消息传递，但您仍然需要知道高可用性队列管理器的位置，等等。；因此，您基本上仍然遇到相同的问题，而使用这种方法对查询的响应更为棘手

---

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

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

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

另一种方法可能是反向响应，并且想要联系其他服务的服务广播由其他服务用所需信息应答的请求，这基本上就是DNS所做的

---

一个现成的解决方案是。看一看它提供的可能额外有用的功能，例如健康检查。

我所做的是：

我让每个服务在启动时生成一个目录，可以作为根资源访问…/{Service}/。 在此ToC中，所有端点都是映射

键是众所周知的端点ID，值始终由

标题 href 类型媒体类型 所以，基本上是一个常规链接

神奇之处在于href，例如，公共主机DNS可配置为环境变量Config Map。由于使用DNS，负载平衡等不符合要求。但您也可以将此方法用于内部IP

这是提到的良好做法

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

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

通过将其发布到名为endpoints的Kafka主题，可以重用这个ToC，其中的键是著名的ServiceId fooService或fooService:1.2.3，值是它的ToC

每个服务还具有对主题GlobalKTable的读取权限，因此当它想要生成到FooService的链接时，他在GlobalKTable中查找其ToC，通过其Id查找端点，用实际值替换模板化变量，并且完成后，不会更改类型，因为假定它是正确的

---

这里的酷之处在于Kafkas GlobalKTable和QueryableKeyStore，当FooService仅以非中断方式更改其端点时，所有其他服务自动生成新链接。DNS更改或重命名路径段将正常工作。重命名参数显然不是。

这个答案将我指向Zookeeper，它将我指向Curator，Curator中有一个服务发现框架选项-谢谢！谢谢你向我介绍了通过卡夫卡可以做到这一点的想法