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

Question

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

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

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

我的域名说明

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

在单片应用程序中，我会使用这种架构： - 具有Mobile / Angular-Ember的表示层 - 带有NGINX的REST API的业务层 - 具有标准MySQL数据库的DAL - 可扩展性仅适用于X轴

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

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

问题

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

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

这是一个让它运作的好方法吗？处理X机器访问数据时是否存在延迟问题？

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

c / flux（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协议？

感谢您提前

Answer 1

  

A /

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

  

B /

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

  

C /

不清楚问题是什么。

  

d /

某人推荐的模式是HATEOAS模式，建议用于API响应。

  

E /

仅在服务之间需要通信时才需要AMQP。永远不要直接从一个服务直接调用另一个服务的API。

修改

  

C /

在这种情况下，您需要实现回退逻辑。例如，如果服务不可用，超时或任何其他故障，则需要采取某些操作。像Netflix Hystrix这样的工具有助于实现这一目标。

  

E /

通信模式必须是对称的而不是非对称的。如下所示，

这种模式可以实现微服务之间的松散耦合，从而实现灵活性。