php - PHP 中的内部 API，包含的替代方案？

Question

我有 1 台服务器，其中包含十多个不同的独立应用程序，全部用 PHP 编写。这些应用程序通过 API 相互通信。顶部有一个应用程序可以让他们与服务器外部的客户端通信，全局看起来像这样：

必须处理命中的应用以 JSON 格式响应 App 1，应用 1 根据 JSON 中的信息生成对命中的适当响应，例如网页、图像或纯 JSON。

如果一个应用程序需要与另一个应用程序通信，他将发送一个带有 cURL 的 HTTP 请求。基本上，他成为自己服务器上的客户。我知道这种方法比使用直接函数（如 Include 或 Require）消耗更多资源。但是当我使用这些功能时，我失去了很多独立原则。

我喜欢坚持我的独立原则的原因是我喜欢与外部初级程序员一起工作。我不希望他们被迫使用 OOP、类等。我想对他们说：“这是输入，我希望输出是这样，创建一个 PHP 应用程序来实现它”。

我的问题是：

• 与 Include 或 Require 等直接函数相比，HTTP 方法是否使用更多资源？
• 除了 Include 或 Require 之外，还有没有更好的方法来使用 PHP 构建内部 API？！

Answer 1

您的问题的答案：

1. 这取决于很多事情，包括但不限于：

   • 服务器的位置
   • 服务器之间的节点数量和节点质量
   • 服务器的延迟
   • 您用来传达信息的格式

   为了让您了解这一切是如何实现的，请考虑一个简单的情况，即您的所有应用程序都是同一个盒子上的虚拟主机。您正在使用从 app2curl击中。myserver.com/app1/你可能不知道的是：

   • 正在强制 DNS 查找myserver.com
   • 在循环返回之前，将一直到达路由器的公共接口

   考虑一下这个场景，而不是之前的场景：您使用curl的是myserver2.com从myserver.com. 两者都在一个 VPN 上，但两者都有一个公共接口（分别）myserver.com并绑定到该接口。myserver2.com结果？当您可以通过 VPN 建立隧道时，您将通过 WAN。

在所有情况下，如果呼叫转到 WAN，每次呼叫都会产生约 10 毫秒到约 50 毫秒的延迟。

“直接函数”就像include解决了一个完全不同的问题，但是是的，它们减少了整个 HTTP 请求开销。应该始终首选直接实例化，而第二好的选择应该是使用类似redis.

问题二有一个简单的答案：是的，不是建造一个。如果通过“内部 API”，您构建的只是负载均衡器，请考虑仅使用负载均衡器。如果您正在构建内容中介，请考虑将其抽象出来，让您的开发人员真正做他们擅长的事情。