MVC 路由 - 使用 NGINX 而不是 PHP(或 Ruby 等)进行路由


MVC Routing - Using NGINX to route instead of PHP (or Ruby, etc.)

我目前正在为教育(如果它很好,实际实用)使用制作一个自定义 MVC 框架,我喜欢研究不同的场景以获得可能的性能提升。

说到URI路由,我熟悉标准的URI格式

/controller/action/id

解析数据以控制路由不会太困难。现在,我更想知道的是让nginx将此URI字符串解析为某种类型的查询字符串以直接传递给控制器之间的性能差异,因此最终会像

/foo/bar/12 => /application/foo.php?action=bar&id=12

而不是

/foo/bar/12 => /index.php?controller=foo&action=bar&id=12

甚至

/foo/bar/12 => /index.php?uri=/foo/bar/12   (note that this would be encoded)

我知道nginx已经在其他变量中将url,查询字符串和其他东西传递给php-fpm,但这只是为了说明目的,以显示我的想法。

这是一件愚蠢的事情吗?我知道通过在 nginx 中显式定义路由意味着每次更改配置中的路由时都需要重新启动 nginx,这可能是一个缺点。

因此,重申一个问题:当涉及到 MVC 路由时,通过让实际的 Web 服务器(在本例中为 nginx)本身处理到控制器的路由,或者使用标准登陆脚本(如索引.php在目录的根目录中)并传递要解析的 URI 以完美地解析路由,是否有任何值得的性能提升?

提前谢谢。另外,我只是在学习这些东西,所以我全心全意地欢迎关于我应该做什么的建议。

我不会将应用程序逻辑(URL路由)混合到您的HTTP服务器中。许多PHP应用程序过去都依赖Apache .htaccess文件来实现这种事情。 它最终变得一团糟。

正如你提到的,它需要重新启动Nginx来改变路由,并且它还会把你的应用程序绑定到Nginx,除非你想在将来的某个日期为另一个HTTP服务器重写所有规则。更糟糕的是,如果您决定将应用程序扩展到多个服务器上,则必须为每个上游重复这些规则。

保持图层分离。