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::SimplePath::Router

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

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