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

Question

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

为了跟上我们的公共API，我们将有一个API网关，可以正确地路由这些东西。内部通信将通过REST完成（第一次拍摄）。不幸的是，我们现有的公共API大多数时候都是关于Web服务的。

如果我们从Webservices转换到REST通信，我们就需要了解Domain Objects的内容。是不是已经违反了微服务设计。最后，这意味着在微服务A中添加一个字段意味着还要触摸API网关。我不喜欢。

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

Answer 1

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

如果我是你，我也不会使用API​​网关解决方案。我们了解到您正在努力使您的API客户端更改透明，但API网关会添加冗余步骤，这可能会导致性能问题。

我建议做以下事情：

1. 将域逻辑提取到可重用的库中，因此旧API和新API都可以使用它们。
2. 使用第1项
中的库构建新版API
3. 确保所有新客户都使用新API，并在旧API中推广

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

Answer 2

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