API 网关在微服务架构中处理 Web 服务

Posted 2023-03-08

【中文标题】API 网关在微服务架构中处理 Web 服务

【英文标题】：API Gateway handling Webservices in a Microservice Architecture

【发布时间】：2017-03-19 18:11:16

【问题描述】：

我有一个架构问题。我们正在将旧的单体应用转变为微服务架构。因此，我们计划识别有界上下文并从中构建微服务。

为了跟上我们的公共 API，我们将有一个 API 网关来正确路由这些东西。内部通信将通过 REST 完成（在第一次拍摄时）。不幸的是，我们现有的公共 API 大部分时间都是关于 WebServices 的。

如果我们从 Web 服务转换为 REST 通信，我们已经需要了解域对象的内容。这不是已经违反了微服务设计吗？最后，这意味着在微服务 A 中添加一个字段意味着还涉及 API 网关。我不喜欢。

我错了吗？您对此有何看法？

【参考方案1】：

如果您不打算将域实体用作内部 REST 服务的输入参数，请不要在此处看到任何违规行为。使用普通的旧 DTO 对象作为输入参数，然后将它们映射到您的域对象。

如果我是你，我也不会使用 API Gateway 解决方案。我了解您正试图让您的更改对您的 API 客户端透明，但 API 网关添加了一个冗余步骤，这可能会导致性能问题。

我建议执行以下操作：

将域逻辑提取到可重用的库中，以便新旧 API 都可以使用它们。 使用项目 #1 中的库构建 API 的新版本 确保所有新客户都在使用新 API，并在旧客户中推广它

是的，在一段时间内支持这两种 API 并不容易，但从长远来看，您将摆脱那个 API 网关。

【讨论】：

如果我的理解是正确的，API网关层是必需的，因为它将Web服务协议（可能是基于SOAP的）转换为RESTful API。

对，所以最好尝试摆脱它，让客户使用新的 restfull api

您很幸运能够选择摆脱旧服务。在不可能的地方，我提出的解决方案已被广泛接受和使用。这确实是一个干净的解决方案。

如果没有办法让当前客户端开始使用新的 API，你是对的，但值得一试。

【参考方案2】：

如果我的理解是正确的（请参阅我在 Maksym 的回放中的评论），那么您的 API 网关类似于 SOA 中的 ESB。如果是这种情况，您可以借用 ESB 中的一些常见模式来帮助解决您的问题。在 ESB 中，我们经常放入定制的适配器来转换服务之间或服务与开放标准之间的消息格式。在您的情况下，您需要在 API 网关中引入一个额外的层，以将公共 API 的数据模型转换为 MS A 和 B 理解的数据模型，反之亦然。通过这样做，公共 API 和 MS A 和 B 仍然是松散耦合的。确实，如果 MS A 和 B 中的数据模型或公共 API 发生更改，您将不得不对适配器进行更改。但它的影响将是最小的，因为适配器重量很轻，它们被设计成可以快速更换。

【讨论】：

您正确理解了我的担忧 - 因此看起来没有干净的解决方案。