我有一个架构问题。我们正在将旧的单体应用转变为微服务架构。因此，我们计划识别有界上下文并从中构建微服务。
为了跟上我们的公共 API，我们将有一个 API 网关来正确路由这些东西。内部通信将通过 REST 完成（在第一次拍摄时）。不幸的是，我们现有的公共 API 大部分时间都是关于 WebServices 的。
如果我们从 Web 服务转换为 REST 通信，我们已经需要了解域对象的内容。这不是已经违反了微服务设计吗？最后，这意味着在微服务 A 中添加一个字段意味着还涉及 API 网关。我不喜欢。
我错了吗？您对此有何看法？
【问题讨论】：
标签： web-services rest architecture microservices
如果您不打算将域实体用作内部 REST 服务的输入参数，请不要在此处看到任何违规行为。使用普通的旧 DTO 对象作为输入参数，然后将它们映射到您的域对象。
如果我是你，我也不会使用 API Gateway 解决方案。我了解您正试图让您的更改对您的 API 客户端透明，但 API 网关添加了一个冗余步骤，这可能会导致性能问题。
我建议执行以下操作：
是的，在一段时间内支持这两种 API 并不容易，但从长远来看，您将摆脱那个 API 网关。
【讨论】：
如果我的理解是正确的（请参阅我在 Maksym 的回放中的评论），那么您的 API 网关类似于 SOA 中的 ESB。如果是这种情况，您可以借用 ESB 中的一些常见模式来帮助解决您的问题。在 ESB 中，我们经常放入定制的适配器来转换服务之间或服务与开放标准之间的消息格式。在您的情况下，您需要在 API 网关中引入一个额外的层，以将公共 API 的数据模型转换为 MS A 和 B 理解的数据模型，反之亦然。通过这样做，公共 API 和 MS A 和 B 仍然是松散耦合的。确实，如果 MS A 和 B 中的数据模型或公共 API 发生更改，您将不得不对适配器进行更改。但它的影响将是最小的，因为适配器重量很轻，它们被设计成可以快速更换。
【讨论】：