performance - 作为您自己的 API 的客户端是否存在性能问题？

Question

以Twitter为例，他们说twitter.com是他们自己API的客户端。这可能是 Twitter 相当“慢”的原因之一吗？

引用:http://engineering.twitter.com/2010/09/tech-behind-new-twittercom.html

您会推荐为您的主要网站/应用使用您自己的 API 吗？

如果使用自己的 API 没问题，有什么方法可以避免性能问题？

Answer 1

关于使用您自己的 API:这是一个权衡取舍的问题。在 Twitter 示例中，通过使用他们自己的 API，他们能够“为 API 团队分配更多资源”。对他们来说，这种好处超过了性能损失。还有其他未提及的好处，例如，第一个审查您的 api 并拥有一个统一的系统入口点。您发布的链接中也提到了一些缺点。

对于您的应用程序，您应该查看您想要实现的架构质量，并在它与给定的限制之间取得平衡，然后做出自己的选择。如果超高性能是最重要的，那么制定您的解决方案来实现该目标。

关于使用您自己的 API 时的性能:这又要视情况而定。在 Twitter 案例中，他们知道他们将访问 JavaScript 中的 API。所以物理跳转是Browser --> Server --> DB。如果您正在进行客户端-服务器开发，则无法绕过这些跃点。在您发布的链接中，他们谈到直接进入数据库。是的，那样会更快，但我不确定如何从 JavaScript 客户端执行此操作。我想如果他们将 websockets 用于自定义 API，那会更快，但开发成本是多少。

总结 因此，性能受到影响的并不是他们使用自己的 API，而是他们希望客户端与 HTTP 跃点相距不远。请注意，这些评论都没有谈论服务器 --> 数据库调用的样子或它们的缓存策略，或任何其他可能成为瓶颈的事情