我的一个客户对如何部署 Web 应用程序有非常严格的要求。他们要求它可以作为 WAR 部署在像 Tomcat 这样的 Java 服务器中。然而，我们的应用程序是用 golang 编写的，并编译成可执行服务器。
我能想到的唯一解决方案是在后台启动一个长期存在的 golang 进程，该进程侦听诸如 8080 之类的非标准端口，然后放入某种代理java 它将透明地代理所有 HTTP 请求和对此过程的响应。
我应该如何实现这个？我一点也不熟悉 Java Servlet 和在后台运行像这样的长时间运行的进程。
我主要关心的是如果这样的东西是标准的，
也许有更好的方法来做到这一点？像某种进程间通信机制？
【问题讨论】：
如果 HTTP 是您的 Go 应用程序公开的唯一 API，那么您只能选择向 Go 发送 HTTP 请求。是的，您可以使用ProcessBuilder 将 Go 可执行文件作为 JVM 的子进程启动。但这并不是真正嵌入到您的 WAR 中。您可以使用 JNI（Go 绑定称为 GoJVM）从 Java 调用 Go 中的本机例程，但是您还必须对您的 Go 代码库进行大量调整。
您正在寻找的可能确实是反向代理。它在 servlet / 应用程序服务器中并不经常完成，因为这通常已经在负载平衡器中完成。所以通常是 NGINX 或带有mod_rewrite 的 httpd。对于应用服务器，您可以使用代理 servlet。
例子：
内存占用通常还不错，因为您实际上只是连接流。 JVM 将能够跟踪处理器和内存利用率——如果实施得当并且 Go 可执行文件在同一台服务器上运行。显然，Java 特定的统计信息不再有意义，因为您只是将 Java 服务器用作传递。
听起来你会遇到麻烦。如果我的严格要求是可以部署到应用程序服务器的 WAR 存档，我不会接受添加到我的堆栈中的另一个可执行文件。是否反向代理。
【讨论】：
如果他们想要战争，就给他们战争！
编写一个将可执行文件嵌入为资源的薄层 Web 服务，执行它以启动 go 服务器并接受 web 调用并传递到 go 服务。
我听到你说什么都做不到？好吧，他们的武断要求也没有，这可能是由早已离开公司的人提出的，和/或因为他们缺乏在操作上处理其他形式的部署的信心/经验/知识。除了建立适当的操作程序所需的工作（懒惰）之外，没有特别好的理由拒绝部署您的服务。
只遵循他们规则的文字，而不是精神，如果被问及您的实施，请诚实。他们不会介意的。
这听起来像是在咆哮，但恕我直言，根据经验，这种方法是现实的，并且要求的驱动因素是基于情感的，因此有必要给出一些情绪化的答案。
【讨论】：