我们有两个应用程序App1和App2。
App1 - Java6 上的旧版搜索应用程序（正在升级到 Java 8），具有旧版 UI；请求负载是一个复杂的字符串分隔结构
App2 - TomEE 1.7 上的 Java 8，接受 Json 请求负载
需求 - App2需要调用App1服务
当前，App2 的 UI 使用 JSON 负载调用 App2 服务器。 App2 服务器将 JSON 转换为 App1 可理解的字符串分隔有效负载并调用 App1 服务。收到 App1 的响应后，App2 服务器将响应转换为 App2 UI 可理解的 Json
问题 - 是否有更好的解决方案，避免跳转到 App2 服务器端，然后跳转到 App1？有没有更好的方法，比如利用 API Gateway / NGinx / Mod Proxy？
我没有看到任何方法可以避免这一跳，特别是因为 App2 正在两个方向执行数据转换。我唯一的建议是验证并确保您选择的解决方案正在创建与 App1 服务的持久连接。如果您在每个请求中打开和关闭 TCP 连接，那么这是一个很容易优化的地方。
App1 专有的“字符串分隔”协议和 JSON 协议之间的协议转换器在 App2 服务器中实现。更好的方法是向 App1 服务器添加一个接受 JSON 请求的额外端点。
每个 App1 客户端都可以选择是否要使用旧的“字符串分隔”或新的 JSON 协议与搜索服务进行通信。 App2 现在可以与 App1 进行 JSON 对话，并且可以从 App2 中删除“字符串分隔”客户端的代码。
这称为“内容协商”，是从旧的专有协议迁移到更标准化的基于 JSON 的 RESTful API 的好方法。
如果App2 UI客户端无法直接与新的App1服务器通信（因为有效负载的JSON格式不兼容并且需要一些映射），您可以查看一些JSON到JSON的映射工具，例如JsonToJsonMapper .
是的，您可以使用 API Gateway 作为对 App1 的请求的转换层。这种方法将确保对 App1 的 API 调用的一致性，并减少 App2 中对冗余逻辑的需求。一些 API 网关可以让您做到这一点 AWS API Gateway、Kong Gateway、Spring API Gateway...