Web applications 一个典型的中大型web应用程序是如何运行的；“成长”；基础设施方面？

瘦小的人：当Facebook/Twitter/Youtube（无论什么）从软件的基本理念转变为。。。规模更大（可能有10万用户？），他们是如何成长的

中型web应用程序是否有“最佳实践”增长路径

真正的问题：在指定或投标中型web应用程序项目时，最大的问题是什么？在本例中，我们将使用一个PHP框架，但似乎这些框架主要适用于任何语言

因此，核心应用程序的程序员（对我来说）是最明显的部分。我们得到了用户管理、用户界面和处理应用程序的特殊类。然而，在我看来，这还不到实际项目的一半

最终，随着良好的增长，基础设施和元用户界面问题将成为您的主要关注点，对吗

1） 基础设施：云应用空间、数据存储、多数据中心情况下的数据库同步

2） 语言和文化问题：使一个应用程序看起来“可爱”或至少在主要的“文化市场”中可用

3） 数据索引问题

4） API/互操作性问题（嵌入式应用程序和facebook以及最终用户和搜索引擎等主要参与者的外部数据访问）

…所以，我确信我错过了其中的一半，我不知道它们是如何优先排序的

---

被接受的答案是我寻求答案的一个很好的起点。

从你的列表中展开第一项似乎是非常关键的，它将帮助你决定你将要面对什么样的扩展问题，甚至是什么类型的技术可能是有用的。这样做也会涉及项目3和4，因为它们是相互关联的

下面是一大堆问题，这些问题可能会帮助你进入探索性思维，扩展你的可伸缩性想法，这不是对你问题的直接回答，而是一个起点：

你在应用程序中的功能是什么？他们读得重还是写得重，或者两者都重？ 查看数据时，是否需要始终处于最新的实时状态？还是可以推迟？可以推迟多久？缓存有帮助吗？缓存是最简单的部分，还要考虑如何使缓存过期，这是最难的部分。您正在处理的数据是什么样子的？它是高度相关的，还是更像独立的文档

您的性能要求是什么应用程序是否主要在后台生成报告并通过电子邮件发送？或者它需要在twitter上显示所有当前推文的完美实时地图吗？用户的更新是否需要立即传播到其他用户？每个用户，还是只是其中的一个子集？它必须以多快的速度完成？页面是否需要在300ms或2s以下加载

外部服务是否有任何类型的限制，可能是请求限制或费率限制？这意味着您需要对请求进行排队和批处理。您的一些外部数据提供商是否以比您处理数据更快的速度向您发送数据？您可能需要对其进行排队，您可能需要使系统的这一部分本身具有可伸缩性，具有可上下移动的可变数量的“工作者”。考虑将“单独可扩展”的主体应用到系统的其他部分，它在大型安装中支付红利。

---

希望这能有所帮助：）

是的。。。实际上，这已经帮助我更清楚地看到有问题的应用程序。谢谢你的想法。根据这个[1]facebook在拥有超过5000万用户之前没有添加西班牙语、法语和德语版本（！？）。换句话说，正如我所读到的，他们并没有为非英语市场制定计划。有趣的是（很明显？），这些市场占fb用户的70%。[1]