小额服务服务注册登记和发现

Question

小域表示

我实际上有两个微服务：

• 用户对CRUD的管理
• billings -管理帐单上的CRUD，并对与计费有关的用户提供“参考”

解释

在HTTP请求中调用计费时，我需要在加载用户的情况下发送完整的计费对象。在这种情况下，在这个特殊的情况下，我真的需要这个。

在第一次，我环顾四周，似乎是一个好主意，使用消息队列，为了异步，所以计费服务可以发送到一个队列：

“id 123456的用户是谁?我需要加载它”

这样，我的两个服务就可以相互交换，而不必真正了解对方，也不知道对方的“位置”。

问题

• 我的第一个问题是，在这种情况下使用服务注册中心的目的是什么？消息队列可以不知道任何关于用户服务位置的信息就给我们提供信息，不是吗？
• 我们什么时候需要使用服务注册:在聚合器模式中，使用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/

Answer 1

很多好问题！

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

您的例子很简单:两个微服务需要交换一些信息。您选择了异步队列--好的，在这种情况下，它们并不需要真正了解对方。队列并不期望消费者之间有任何发现。

但在其他情况下，我们需要服务发现！例如，支持服务:数据库、缓存以及实际上的队列。如果没有服务发现，您可能会硬编码到队列的URL，但是如果它下降，您将一无所有。您需要具有高可用性--例如，复制队列的节点集群。当您添加新节点或已崩溃的现有节点时-您不应该更改任何内容，服务发现工具应该理解这一点并更新注册表。

Consul是一个完美的现代服务发现工具，您只需使用自定义的DNS名称来访问您的支持服务，而领事将执行持续的健康检查并保持集群的健康。

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

可能最混乱的原因是你在动物园管理员中看到了“硬编码”URL。你认为你需要手动处理。像领事或etcd这样的现代工具可以让你避免头痛，只需要依赖它们。它实际上也可以实现与动物园管理员，但它将需要更多的时间和资源有类似的设置。

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