php - 与 mvc/oop 相比，Spaghetti php 代码的性能和可扩展性？

Question

我有一个包含大约 50-55 个代码文件的 php 应用程序。代码量最大的文件大约有 1200 行代码(包括空格、制表符和多个换行符...)，其余代码文件相对较小。

几乎每个文件中的应用程序代码都是 html、sql 和 php(你称之为意大利面条)的混合体，除了少数文件是纯 php 包含文件....例如包含所需函数的文件在许多其他地方。

我一直在考虑将此应用程序重构为 mvc 类型架构是否是个好主意。

现在我知道 mvc 应用程序提供了许多优点，例如易于维护、重用和易于进一步开发等，但可伸缩性和性能如何 - 特别是在这种情况下？

我的假设是，由于这是一个小型应用程序(我相信是这样，您认为它足够小吗？)，我不认为维护或添加更多功能(最多)会很困难just 可能意味着在现有文件中添加一些内容，或者说最多添加 5-10 个新文件。

所以我认为我不应该为了维护而转换为 mvc。

据我了解，您可以将 mvc 的每个组件放在单独的服务器上以分散负载，以便让不同的服务器服务于 html、数据库和逻辑，并进一步进行其他优化/缓存以实现更高的性能mvc 应用程序缩放和执行。

我认为即使在小型意大利面条应用程序中我们不能为 html、数据库等使用不同的服务器，我们也可以通过在 Web 服务器、数据库服务器等前面设置负载平衡器来轻松扩展而不会降低性能(假设涉及到一台服务器不够用的情况)

更重要的是，就其本身而言，意大利面条代码应该比 mvc 执行得更好，因为它没有任何开销，例如要求包含或文件或从属于 mvc 不同组件的文件夹下的文件调用函数。

那么，考虑到所有这些因素，您真的认为将相对较小的意大利面条式应用程序重构为 mvc 以获得可扩展性和性能有用吗？

请不要告诉我重构在未来会有用(我知道这会有所帮助并且会考虑我们是否真的需要向现有代码库添加更多代码)但请给我一个明确的答案

1)为了可扩展性和性能，我真的需要将此应用程序转换为 mvc 架构吗？

2)像这样的意大利面应用程序能否扩展并执行至少每天至少 100 万个请求，其中一半发生在某个高峰时段？

Answer 1

As far as i understand you may put each component of mvc on a separate server to spread the load

我自己从没听说过 - 但我来自一个 .Net 世界，在那里你无论如何都会在同一台服务器上运行所有托管代码(这不像在 Java 世界中你经常有一个单独的“应用程序”服务器和“Web”服务器)。

您可能转向 MVC 的主要原因(正如您提到的那样)是为了管理代码的好处:关注点分离、重用等；不是性能。

从理论上讲，您可以使用基于对象/组件的技术(例如 Java 或 .Net)来实现这一点，在这些技术中组件相互通信 - 但在过程代码中？我不这么认为!

So, considering all these things do you really think it's useful to refactor a relatively small spaghetti application to mvc for scalability and performance?

否 - 假设您指的是系统的运行时质量的可伸缩性和性能，我相信这就是您的意思。

如果您将可扩展性和性能纯粹放在开发环境中(人们编码 - 他们在系统上工作的速度和容易程度，将开发人员添加到项目中的容易程度)那么答案将是是.

2)Can a spaghetti application like this scale and perform for atleast a minimum of 1 million request a day and half of which occur during some peak time?

没有什么是不可能的——我喜欢 Gordon 的这些评论——但我相信你会同意，这可能不是你能立足的最佳立足点。