微服务、服务注册表、API网关和数据共享

Question

我实际上正在阅读关于微服务架构的大量文章，但是似乎它们只是以最简单的方式处理事情，而没有深入解释。

为了向您解释我的问题，我将展示我的实际小型架构：

所以，这就是我想要使用的。在进行任何技术操作之前，我需要更多的理论信息。

我的领域描述

我有一些移动和基于浏览器的客户端，能够连接到应用程序、获取其用户信息并能够查看他们购买的账单信息。

在一个单体应用程序中，我会使用以下架构： - 带有 Mobile / Angular-Ember 的表示层 - 带有 NGINX 前端的 REST API 业务层 - 使用标准 MySQL 数据库的数据访问层 - 只对 X 轴应用可扩展性

在这种情况下，我想使用微服务架构，因为它具有“领域可扩展性”和非常灵活（当然也为了更多地了解它）。

在架构图中，每个服务都公开了其相应 API 的唯一 HTTP URL。

问题

a/ 在(1)流程中，“mobile”会在http://myDomain.or/auth上发送一个http请求。

在我的想法中，API 网关能够询问标准的服务注册表（Eureka、ZooKeeper 或其他）是否可以找到可访问 AuthSrv 的网络地址。然后 API 网关可以请求 AuthSrv 并响应服务器。

这是一个行之有效的方式吗？在访问数据时涉及到 X 台机器时，是否存在延迟问题？

b/ 流程 (2) 查询服务注册表。服务注册表如何理解 /auth 上的每个请求，即使在子 URL（如 /auth/other）上也是如此，都与此 IP:端口上的服务相关联？

c/ 流程 (3) 显示服务注册表已经有一个可用的 AuthSrv。流程 (3 bis) 则显示没有可用的 AuthSrv。在小型应用程序中，我们可以接受系统有些许不可用时间，但在大型系统中，其中数百个服务相互连接时，如何处理服务缺乏情况？

d/ 在另一篇文章中，我问了如何存储与用户相关的账单信息，来自另一个服务和另一个数据库。

在标准架构中，我会有：

{
   billingInformations:{...},
   billingUser:ObjectId("userId")
}

在微服务架构中，有人建议使用以下内容：

{
    billingInformations:{...},
    billingUser:"/user/12365" // URL corresponding the the user Resource in the other service
}

这是处理“服务数据共享”且不耦合服务的最佳方式吗？

e/ 在这种特定情况下，我应该何时优先使用AMQP协议而不是HTTP协议？

提前感谢。

- mfrachet

---

例如，Spotify使用Protobuf和ZeroMQ的组合。通过HTTP进行通信很快就成为了瓶颈。 - Anatoly

Answer 1

a/

不，像Zookeeper这样的服务注册表是内存中的，保证高吞吐量和低延迟。

b/

在像Zookeeper这样的服务注册表中，您可以创建类似于文件系统路径的服务注册。例如：/App1/Service1 和 /App1/Service2。

c/

不太清楚问题出在哪里。

d/

某人推荐的模式是HATEOAS模式，这是API响应的推荐模式。

e/

只有在服务之间需要通信时才需要使用AMQP。从一个服务直接调用另一个服务的API是不合适的。

编辑

c/

在这种情况下，您需要实现回退逻辑。例如，如果某个服务不可用、超时或出现其他故障，需要采取一些措施。像Netflix的Hystrix这样的工具可以帮助实现这一点。

通信模式必须是对称的而不是非对称的。就像下面这样： 。 这种模式将使微服务之间的耦合度降低，从而实现灵活性。

- shazin

---

关于 e/，所以如果我想通过计费服务访问我的完整用户信息，我必须使用相应的用户（HATEOS格式）向AMQP发送请求并提交相关响应？关于 c/，我的意思是，如果我在服务注册表中没有为 /auth 注册服务，我该如何处理错误？提前感谢。 - mfrachet