Question

我总是有动态代码的东西。代码很容易添加很酷的新功能，而无需做太多工作。出于这个原因，我构建了许多动态框架并在我的项目中使用它们。有些很小，有些很大。

作为一个例子，我构建了一个小型自定义错误报告框架，我今天几乎在所有项目中都使用它。

以下是一个如何运作的简单示例：

error_reportLibrary.php - 这就是所有魔法发生的地方。这个类和所有方法都在这里。这是需要框架时包含的文件。

error_reportConfig.php - 这是我的配置（错误类型，等等）。以下是此文件的示例，它将为您提供有关小框架如何工作的非常好的解释：

（代码中的注释应解释每个元素作为设置的作用）

# ------ Main Settings ---------

$error_handlingSettings['errorStat']=true;//set this to false, and I wont display any errors. I don't care what the other errorTypes have to say.
$error_handlingSettings['default_highlight_color']="red";//this is the default highlight color that will be used if no color is defined for a specific errorType

# ------ Open API -------
$error_handlingSettings['open_api']['status']=true;//set this to true and I'll show errors for the Open API
$error_handlingSettings['open_api']['highlight_color']="#0ff";//shall I highlight any errors that occur for this specific type? if so, set this to a color.
$error_handlingSettings['open_api']['onRemoteAddr']=true;//shall I display errors to specific IP addresses?
$error_handlingSettings['open_api']['remote_addr'][]="86.8.168.228";//so I will show to this IP
$error_handlingSettings['open_api']['remote_addr'][]="127.0.0.1";//and this IP

# ------ SQL Core -------
$error_handlingSettings['sql_core']['status']=true;//set this to true and I'll show errors for the SQL Core
$error_handlingSettings['sql_core']['highlight_color']="orange";//shall I highlight any errors that occur for this specific type? if so, set this to a color.
$error_handlingSettings['sql_core']['onRemoteAddr']=true;//shall I display errors to specific IP addresses?
$error_handlingSettings['sql_core']['remote_addr'][]="86.8.168.228";//so I will show to this IP
$error_handlingSettings['sql_core']['remote_addr'][]="127.0.0.1";//and this IP

你可能会说，每个错误类型只是我正在使用框架的项目的不同部分（例如，SQL Core是我使用的数据库框架。所以如果发生任何数据库查询问题，这个打印错误时将查看errorType。

因此，对于打印错误，这是语法：

errorModule::doError("errorType","error messege");

正如您所看到的，我可以做一些额外的小事。就像显示某些IP地址并突出显示错误文本一样，我可以自信地说：不会影响框架的可伸缩性。

请记住，上面只是我在项目中创建/使用的动态框架的一个示例。

现在，问题（几乎）：我的一些大学告诉我，在可扩展性方面，上述动态框架非常糟糕。无论它们是否非常易于维护。因此，如果我在一个每天获得1M +请求的Web应用程序中使用上述框架，那么它将完全搞砸......

现在我不反对他们的意见（实际上......），但我想知道为什么会这样？为什么像上面这样的动态框架被认为对可伸缩性有害？

Answer 1

我认为你在创建'动态框架'时忽略了这一点。

我早期的许多PHP代码都是这样的;一个带有一堆方法的类，也许是一个建立状态的构造方法，使用全局变量来跟踪数组中的配置。与完全OOP方法相比，这些都使用了大量内存;而且，与“现成”解决方案相比，内存更少，速度更快;与我现在设计框架的方式相比没什么。

看起来你没有利用接口，抽象类，类和接口继承等等。这些类型的框架确实可扩展，因为原始代码库非常小并且利用了特定的OOP功能（如PHP 5.x的魔术方法。）

将您觉得在服务器上运行速度足够快的脚本乘以100而不是非常累，并且您遇到了问题;而你的记忆力已经不足了并且事情将爬到你被迫重启/在服务器上投入更多资源的程度。

为什么呢？编写得不好的程序代码试图表现出OOP，甚至试图看起来像是一个新的包装中的旧习惯。

Answer 2

PHP总的来说很慢而且很笨拙。它是高级别的，这意味着每条线都带有“行李”。通常，单行PHP代码将转换为一系列低级指令。

您仍然可以扩展严重依赖PHP底层系统的“动态”框架，并且不会在高级抽象中浪费大量时间或内存。

在我看来，大而“方便”的框架通常会导致更多的问题，而不是他们在生产环境中遇到风扇时会遇到的问题。我最喜欢的老师总是提醒我K.I.S.S. - 保持简单愚蠢。

当然，如果你想要真正可扩展的性能，你可能想用hiphop编译你的php，或者用C ++或D等编译语言编写应用程序。

为什么这样的动态框架不可扩展？

2 个答案: