设计问题 - 如何高效地调用遗留服务？

Darrel Miller

我们有两个应用程序App1和App2。

App1 - 一个基于Java6的遗留搜索应用（正在升级到Java 8），带有遗留用户界面；请求负载为复杂的字符串分隔结构。

App2 - 基于Java 8运行在TomEE 1.7上的应用，接受Json格式的请求负载。

需求 - App2需要调用App1的服务。

当前实现方式是：App2的用户界面向App2服务器发送JSON格式的负载。App2服务器接收到此请求后，将JSON转换成App1能够理解的字符串分隔负载，然后调用App1的服务。从App1接收响应后，App2服务器再将App1的响应转换为App2用户界面可理解的Json格式。

问题 - 是否有更优的解决方案，避免通过App2服务器中转，直接从App2调用到App1？是否存在利用API Gateway、NGinx或Mod Proxy等工具的更好方法？

kenorb

由于App2需要在请求的发送和接收两个方向上都进行数据转换，我看不到有任何方法可以完全“避免”经过App2服务器这一跳转环节。我唯一能建议的是，验证并确保你选择的解决方案能够为App1服务建立一个“持久连接”。如果你当前的做法是在每次请求时打开并关闭TCP连接，那么这是一个可以优化的地方。通过保持持久连接，可以在多次连续调用中减少网络开销和建立连接所需的时间，从而提高整体性能。

Mark Tolonen

在App2服务器中实现了App1专有的“字符串分隔”协议与JSON协议之间的协议转换器。一种更好的方法是在App1服务器上添加一个新的端点，该端点接受JSON格式的请求。

每个App1客户端可以根据需要选择使用旧的“字符串分隔”协议还是新的JSON协议来与搜索服务通信。现在，App2可以直接通过JSON与App1进行交互，并且可以从App2中移除用于处理“字符串分隔”协议的代码。

这种方法被称为“内容协商”，是将老旧的专有协议迁移到基于标准化JSON的RESTful API的好方式。

如果App2 UI客户端无法直接与新的App1服务器通信（由于负载的JSON格式不兼容，需要进行映射），可以考虑一些JSON到JSON的映射工具，比如微软开源的JsonToJsonMapper项目（https://github.com/microsoft/JsonToJsonMapper）。

devnull

是的，您可以使用API Gateway作为转换层来调用App1。这种方法可以确保对App1的所有API调用保持一致性，并减少在App2中编写重复逻辑的需求。一些API Gateway产品（如AWS API Gateway、Kong Gateway、Spring API Gateway等）支持这种功能。

Chris

如果将JSON转换为App1可理解的字符串分隔负载的复杂性较低，可以考虑在App2 UI本身中实现这一逻辑。

这样，从一开始就可以避免调用App2服务器了。

再次强调，这个建议是基于假设这种转换的成本非常低的前提。如果转换逻辑确实相对简单且易于实施到前端，那么直接在App2的用户界面端完成数据格式转换并调用App1服务是一种可行的方法，这能够减少请求在网络中的传输层级，从而可能提高系统整体性能和响应速度。