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

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

为了向你解释我的问题，我将向你展示我的实际小建筑：

所以，这就是我想用的。在从技术上做任何事情之前，我需要更多的理论信息。

我的域名描述

我有一些基于移动和浏览器的客户，能够在应用程序上连接自己，获取他们的用户信息，并能够查阅有关他们购买的账单信息。

在整体式应用程序上，我将使用此体系结构： - 具有移动/Angular-Ember的表示层 - 具有REST API的业务层，其前面是NGINX - 具有标准MySQL数据库的DAL - 可扩展性将仅适用于X轴

在这种情况下，我想使用微服务架构，因为它是“域可扩展的”并且非常灵活（当然，要更多地了解它）。

在架构上，在每个服务中，存在相关 API 公开的唯一 HTTP URL。

问题

a/在（1）flux中，“移动”在 http://myDomain.or/auth 上发送http请求。

在我看来，APIGateway能够要求标准服务注册表（Eureka，ZooKeeper或其他东西）能够找到AuthSrv是否可以访问并可以检索他的网络地址。然后ApiGateway可以请求AuthSrv并响应服务器。

这是让它工作的好方法吗？在处理X机器访问数据时，难道没有延迟问题吗？

b/通量 （2） 咨询服务注册表。服务注册表如何理解 /auth 上的每个请求，甚至在 /auth/other（如果已公开）等子 URL 上的请求都与此地址 ip：port 上的此服务相关？

c/通量 （3） 显示服务注册表具有可用的 AuthSrv。（3之二）显示另一个：没有AuthSrv可用。在一个小应用中，我们可以承认，我们有时会失去不负责任，但是在一个大系统中，有数百个服务是链接的，我们该如何处理服务不足呢？

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

在标准架构中，我会有：

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

在微服务架构中，有人建议使用：

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

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

e/在这种特定情况下，我什么时候应该更喜欢使用AMQP协议而不是HTTP协议？

感谢您的提前