小域名演示
我实际上有两个微服务：
解释
在HTTP请求中调用计费时，我需要在加载用户的情况下发送完全计费对象。在这种情况下，在这个特定情况下，我真的需要这个。
第一次，我环顾四周，似乎使用消息队列是一个好主意，因为异步性，所以计费服务可以发送队列：
“谁是id为123456的用户？我需要加载它”
所以我的两项服务可以互相交换，而不是彼此了解，或者不知道彼此的“位置”。
问题
我的第一个问题是，在这种情况下使用服务注册表的目的是什么？消息排队能够在不知道任何有关用户服务位置的情况下向我们提供信息吗？
我们何时需要使用服务注册： 在Aggregator Pattern的情况下，使用RESTFul API，我们可以浏览hateoas链接。在代理模式的情况下可能吗？当微服务被另一个服务接口时？
现在承认，我们使用代理模式，具有“正面服务”。在这种情况下，我可以使用服务注册。但这意味着前端发送服务知道服务注册中的userService名称和计费服务？示例：
服务用户注册为“UserServiceOfHell：http://80.80.80.80/v1/” 在ZooKeeper上
服务结算注册为“BillingService：http://90.90.90.90/v4.3/”
前端服务需要向用户和计费服务发送一些请求，这意味着它需要知道用户服务是“UserServiceOfHell”。这是在项目开始时定义的吗？
注意：我要求的所有内容都基于http://blog.arungupta.me/microservice-design-patterns/
答案 0 :(得分：5)
很多好问题！
首先，我想回答你的最后一个问题 - 当你知道自己在做什么时，多种模式都可以。混合异步队列，HTTP调用甚至二进制RPC都很好 - 它取决于一致性，可用性和性能要求。有时您可以看到适合简单的PubSub，有时您需要分布式锁 - 微服务是不同的。
您的示例很简单：两个微服务需要交换一些信息。你选择了异步队列 - 很好，在这种情况下，他们并不需要真正了解彼此。队列不希望消费者之间发现任何发现。
但在其他情况下我们需要服务发现！例如，支持服务：数据库，缓存和实际上也是队列。如果没有服务发现，您可能会将URL硬编码到队列中，但如果它发生故障，您什么都没有。例如，您需要具有高可用性 - 复制队列的节点集群。当您添加新节点或现有节点崩溃时 - 您不应该更改任何内容，服务发现工具应该了解并更新注册表。
Consul是一个完美的现代服务发现工具，您可以使用自定义DNS名称来访问您的支持服务，Consul将执行持续的运行状况检查并保持您的群集健康。
同样的规则可以应用于微服务 - 当您有一个运行服务A的集群并且您需要从服务B访问它而没有任何队列（例如，对于HTTP调用）时，您必须使用服务发现来确保您使用的端点将带您进入健康节点。因此，它非常适合您提到的文章中的聚合器或代理模式。
可能最混乱的原因是你看到＆＃34;硬编码＆＃34; Zookeeper中的URL。而且您认为需要手动管理。像Consul或etcd这样的现代工具可以让你避免这种头痛并且只依赖它们。它实际上也可以通过Zookeeper实现，但它需要更多的时间和资源来进行类似的设置。
PS：请记住微服务中最重要的规则 - http://martinfowler.com/bliki/MonolithFirst.html