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

Question

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

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

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

我的域名的描述

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

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

在这种情况下,我想使用微服务架构,因为它是"域可扩展的"并且非常灵活(当然要学习更多关于它的内容).

在架构上,在每个服务中,都有相关API公开的唯一HTTP URL.

问题

a /在(1)flux中,"mobile"在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

一个/

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

b /

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

C/

不是很清楚问题是什么.

d /

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

E /

只有在服务之间需要通信时才需要AMQP.永远不应该直接从一个服务直接调用另一个服务的API.

编辑

C/

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

E /

通信模式必须是对称的而不是非对称的.就像下面一样,

该模式将实现微服务之间的松散耦合,从而实现灵活性.