5

我们有一个基于 FastCGI 的 Web 框架，我们在内部将其用于一些关键任务应用程序。因此，迁移到现有的 PSGI 投诉框架不是很实用。我们已经成功地将我们的框架从普通的旧 CGI.pm 转移到了 Plack 处理程序。

然而，在 Apache 的配置文件中有相当多的路由逻辑，以 mod_rewrite 规则的形式。如果我们要通过 Apache 中的反向代理使用 Plack::Handler::FCGI 部署使用我们新的 PSGI 兼容框架的应用程序，我想 mod_rewrite 规则可以继续在那里工作，并进行一些调整。（计划这样做，但尚未尝试）。

然而，阅读有关 Plack::Middleware::Rewrite 作为 mod_rewrite 的替代品的文章让我很感兴趣。

我是否需要将 mod_rewrite 规则转换为 Plack::Middleware::Rewrite 规则并将所有应用程序逻辑完全移动到 Perl 才能获得 PSGI 的全部好处？

我认为答案是肯定的，但我没有部署 PSGI 应用程序的经验，所以如果有人能分享他们的经验以确保我走上正确的道路，我将不胜感激。

子问题 PSGI 的想法是否就是让 Web 服务器尽可能少（和尽可能快地）做事，并将所有其他东西委托给应用程序服务器（中间件）？**

4

1 回答 1

3

PSGI 的好处是部署灵活性。只要您在 mod_rewrite 中有规则，您就会被 Apache 困住，因此无法充分利用 PSGI。

但是，只要您对 Apache 满意，我看不到重写所有规则的强烈动机。如果 mod_rewrite 让你头疼，那就去做吧。

还可以考虑将路由逻辑放在主应用程序代码中，例如Router::Simple或Path::Router

顺便说一句，除非你真的很喜欢 FastCGI，否则可能没有理由使用 Plack::Handler::FCGI。将 Apache 保留为您的反向代理，并且您的应用程序在 Starlet 或其他 Plack Web 服务器之一中运行。

于 2013-09-17T03:04:29.037 回答