是否可以在内部（专用）IIS服务器上运行Golang REST Web应用程序？

Question

我想用GoLang创建一个可在IIS（7、8或10）或Tomcat 7.0下运行的Web服务。我们有多个环境，每个环境都有多个服务器，所有环境均为Windows 2008 R2、2012或2016。所有服务器均为私有（10.x）。我的目标是向同时使用IIS和Tomcat的COTS product添加一些REST服务。我宁愿避免将Nginx或其他东西粘贴到任一服务器上，以免损害COTS产品或让其技术支持人员不接电话。同样，服务器只能通过公司VPN访问，而不能面向公共Internet。

哪种服务器将提供使工作正常的最简单途径-Tomcat或IIS？

Answer 1

这与Go无关，但是我至少可以想到两种解决方案：

• HTTP请求的反向代理。

  1. 写一个普通的Go服务器通过HTTP服务请求。

     也许可以使用golang.org/x/sys/windows/svc将其转换为正确的Windows服务。

  2. 部署它。

     如果要将其托管在运行IIS的同一台计算机上，则可以使其仅在localhost上侦听。请注意，它将需要一个专用的TCP端口来侦听，并且您需要在这方面使您的服务器可以以某种方式进行配置。

  3. 设置reverse proxying in your IIS，以使其将请求传递到您想要的任何URL（一部分）到Go服务器。

• 使用FastCGI。

  Go支持通过FastCGI服务请求 协议by means of its standard library， 和IIS suports FastCGI workers。

  因此可以（重新）编写Go服务器以使用FastCGI 而不是HTTP，然后通过此协议将其连接到IIS。

在我看来，这些解决方案的优缺点是：

• 开发人员更熟悉通过纯HTTP服务 使服务器更“便携” —从某种意义上说，如果需要时，更容易更改其部署方案。 直接将其提供给Internet的权利。

  相反，使用FastCGI，您将始终需要FastCGI主机作为“中间件”。

• 有传言称HTTP代码在术语上进行了微调 性能要比FastCGI好。

  不过，这仅在合理的核心负载下才需要考虑。

• FastCGI通过HTTP的一个可能好处是它可以 通过管道而不是TCP服务。例如，您可能 使它通过IIS的FastCGI模块支持的命名管道进行服务，并且存在3rd-party packages for Go implementing support for them （甚至包括Microsoft®的一个）。

  这样做的好处是管道可以减少数据传输的开销（基本上，它只是在属于两个进程的内核缓冲区之间铲起字节，而不是将它们压入整个TCP / IP堆栈），并使用管道使您无需为Go服务器指定TCP端口。

  不过，我对这种设置及其性能折衷没有任何个人经验。