我实际上正在阅读有关微服务架构的文章，但是，似乎他们正在以最简单的方式处理事情，而没有深入解释。
为了向您解释我的问题，我将向您展示我的实际小架构：
所以，这就是我想要使用的。在技术上做任何事情之前，我需要更多的理论信息。
我的域名说明
我有一些基于移动和浏览器的客户，他们能够在应用程序上连接自己，获取他们的用户信息，并能够咨询他们所购买商品的账单信息。
在单体应用程序中，我将使用以下架构： - 带有移动/Angular-Ember 的表示层 - 带有 REST API 的业务层，前面带有 NGINX - 带有标准 MySQL 数据库的 DAL - 可伸缩性仅适用于 X 轴
在这种情况下，我想使用微服务架构，因为它是“域可扩展的”并且非常灵活（当然要了解更多关于它的知识）。
在架构上，在每个服务中，相关 API 都公开了唯一的 HTTP URL。
问题
a/在（1）flux 中，“mobile”在http://myDomain.or/auth上发送一个 http 请求。
在我看来，APIGateway 能够询问标准服务注册中心（Eureka、ZooKeeper 或其他东西）是否能够找到 AuthSrv 是否可访问并可以检索他的网络地址。然后 ApiGateway 可以请求 AuthSrv 并响应服务器
这是让它工作的好方法吗？处理 X 机器访问数据时是否存在延迟问题？
b/通量（2）咨询服务注册表。服务注册表如何理解 /auth 上的每个请求，甚至是 /auth/other 等子 url 上的每个请求（如果它被暴露）都与此地址 ip:port 上的此服务相关？
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 协议？
感谢提前
