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

Posted 2023-03-08

【中文标题】微服务、服务注册中心、API 网关和数据共享

【英文标题】：Microservice, service registry, API gateway and data sharing

【发布时间】：2015-06-22 12:47:06

【问题描述】：

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

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

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

我的域的描述

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

在单体应用程序中，我会使用这种架构： - 使用 Mobile / 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 bis) 显示另一个：没有可用的 AuthSrv。在一个小的应用程序中，我们可以承认我们失去了一些责任，但在一个大系统中，数百个服务链接，我们如何处理服务缺陷？

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

在标准架构中我会：

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

在微服务架构中，有人推荐使用：

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

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

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

感谢提前

【问题讨论】：

例如 Spotify 使用 Protobuf 和 ZeroMQ 的组合。通过 HTTP 进行的通信很快就成为了瓶颈。

【参考方案1】：

一个/

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

b/

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

c/

不太清楚是什么问题。

d/

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

e/

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

编辑

c/

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

e/

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

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

【讨论】：

关于 e/ 因此，如果我想通过计费服务访问我的完整用户信息，我必须使用 AMQP 与相应的用户（HATEOS 格式）推送请求，并子相关的响应？关于 c/，我的意思是，如果我没有在 /auth 的服务注册表中注册服务，我该如何处理该错误？感谢提前