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

邵文乐

2023-03-14

问题内容：

我实际上是在阅读有关微服务体系结构的文章，
但是，似乎他们正在以最简单的方式处理这些事情，
而无需进行深入的解释。

为了向您解释我的问题，我将向您展示我的实际小体系结构：

在此处输入图片说明

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

我的网域描述

我有一些基于移动和浏览器的客户，他们能够在
应用程序上建立联系，获得他们的用户信息，并能够查询
有关所购买商品的账单信息。

在整体应用程序上，我将使用以下架构：-
带有Mobile / Angular-Ember的表示层-带有REST API和NGINX的业务层
-带有标准MySQL数据库的DAL-可伸缩性
仅应用于X轴

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

在模式中，在每个服务中，只有相关API公开的HTTP URL
。

问题

a /在（1）流量中，“移动”在
http：//myDomain.or/auth。

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

这是使其工作的好方法吗？
使用X机器访问数据时是否没有延迟问题？

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

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

d /在另一篇文章中，我在问如何存储计费信息，
因为它与用户，另一个服务和另一个数据库相关。

在标准体系结构中，我将具有：

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

In a microservice architecture, somebody recommended to use :

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

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

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

谢谢前进

问题答案：

a/

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

b/

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

c/

不清楚是什么问题。

d/

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

e/

仅当服务之间需要通信时才需要AMQP。如果
从来没有直接从一个服务直接调用另一个服务的API。

EDIT

c/

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

e/

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

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