微服务服务注册和发现

Question

小型域名介绍

我目前有两个微服务：

• User - 管理用户的CRUD操作
• Billings - 管理账单的CRUD操作，其中包括与账单相关的用户"引用"

解释

当HTTP请求中调用账单时，我需要发送完整的账单对象及其已加载的用户。在这种情况下，我确实需要这样做。

首先，我四处寻找并发现使用消息队列是一个不错的主意，因为它可以实现异步性，因此账单服务可以发送到队列上：

"ID为123456的用户是谁？我需要加载它"

因此，我的两个服务可以交换信息，而无需真正了解彼此或知道彼此的"位置"。

问题

• 我的第一个问题是，使用服务注册表的目的是什么？消息队列能够在不知道用户服务位置的情况下为我们提供信息，不是吗？

• 何时需要使用服务注册： 在聚合器模式下，使用RESTFul API，我们可以通过hateoas链接导航。也许在代理模式下？当微服务由另一个服务接口时？

• 现在假设我们使用代理模式，有一个“前置服务”。在这种情况下，我可以使用服务注册。但这意味着前置发送服务知道服务注册中的userService和billing service的名称吗？例如：

Service User在ZooKeeper上注册为“UserServiceOfHell：{{link1：http://80.80.80.80/v1/}}”

Service Billing在ZooKeeper上注册为“BillingService：{{link2：http://90.90.90.90/v4.3/}}”

前端服务需要向用户服务和计费服务发送一些请求，这意味着它需要知道用户服务是“UserServiceOfHell”。这在项目开始时就定义好了吗？

最后一个问题，我们可以在一个微服务架构中使用多个微服务模式，还是这是一种不好的做法？

注：我问的所有问题都基于http://blog.arungupta.me/microservice-design-patterns/。

- mfrachet

Answer 1

很多好问题！

首先，我想回答你的最后一个问题 - 当您知道自己在做什么时，多种模式都可以。混合异步队列、HTTP调用甚至二进制RPC是可以的 - 这取决于一致性、可用性和性能要求。有时候您可以看到简单的PubSub非常适合，有时候您需要分布式锁 - 微服务是不同的。

您的例子很简单：两个微服务需要交换一些信息。您选择了异步队列 - 在这种情况下，它们实际上不需要彼此了解。队列不期望消费者之间进行任何发现。

但是，在其他情况下，我们需要服务发现！例如，支持服务：数据库、缓存和实际上也包括队列。如果没有服务发现，您可能会将URL硬编码到队列中，但如果它崩溃了，您就什么也没有了。您需要具有高可用性 - 例如，一个节点集群复制您的队列。当您添加新节点或现有节点崩溃时 - 您不应更改任何内容，服务发现工具应理解并更新注册表。 Consul是完美的现代服务发现工具，您只需使用自定义DNS名称访问支持服务，Consul将执行不断的健康检查并保持集群健康。

同样的规则也适用于微服务 - 当您有一个运行服务A的集群，并且您需要从没有任何队列的服务B访问它（例如，进行HTTP调用）时，您必须使用服务发现来确保您使用的终端节点将带您到健康节点。因此，它非常适合您提到的文章中的聚合器或代理模式。

可能最令人困惑的是您在Zookeeper中看到“硬编码”的URL。您认为您需要手动管理它。像Consul或etcd这样的现代工具可以让您避免这种头痛，并只依赖于它们。实际上，这也可以通过Zookeeper实现，但需要更多的时间和资源才能获得类似的设置。

PS：请记住微服务中最重要的规则 - http://martinfowler.com/bliki/MonolithFirst.html

- sap1ens