我希望我的问题简单明了。我确信设置步骤很复杂，所以我想了解一些事情。我们有一个团队一直在开发一个即将完成的优秀平台。我们一直在开发标准灯安装，没有什么特别的。我们在架构上遇到的问题是如何规划灯配置的增长。只需购买一台服务器并在其上加载应用程序就很容易了，但是我们如何规划何时需要 3、4、5 台服务器并继续添加到此方案中而不会每次都破坏网站或将其关闭？本质上需要避免停机。我们更愿意购买自己的服务器并通过共置进行维护。
本质上我们如何设置站点以便从一开始就实现并行性（我相信是这个词？）。
答案1
我希望我问的是一个简单的问题。
抱歉，但这完全是相反的。可扩展性是一大套设计选择，如果你想让它变得非常简单，那么从一开始就必须考虑到这一点。这通常需要做很多额外的工作，如果你以前从未构建过这样的系统，那么通过“成长的烦恼”来学习通常会更容易。
我们对这些问题的通用回答是：以后再处理可扩展性问题。构建您的网站/应用程序/任何东西，并尽可能为其配备更强大的服务器。一旦该选项用尽，就开始担心如何拆分逻辑层（这通常是最简单的），例如将前端 Web 服务器与数据库服务器分开。然后弄清楚如何同时运行两个 Web 服务器，等等。
问题的主要部分是，虽然我可以挥手说“数据库分片”或“主动-主动集群”，但这些技术的实际实现在很大程度上取决于应用程序内部的工作方式。LAMP 甚至不是很“标准”——我假设你指的是 PHP 或 Perl，它们都不能很好地处理开箱即用的并发性（并且可能是你要处理的第一个瓶颈之一；至少这些是常见问题，并且有很多关于如何处理它的文章）。
更新： 我在寻找可扩展性主题的简明提纲时遇到了一些麻烦。我遇到了这个：
- 无状态应用程序
- 松耦合
- 异步
- 延迟加载
- 缓存
- 并行性
- 分区
- 路由
来自不同来源的类似概述：
- 关注点分离（表示、逻辑/应用、数据、传输/路由、管理）
- 最小化状态分布（即状态不跨越上述分离）
- 冗余
- 独立环境（开发、QA、阶段、生产）
- 建造
- 自动化（脚本编写、构建、管理等）
- 配置管理
- 中央身份管理
- 部署管理
- 跑步
- 监视器
- 重新评估能力，规划
- 日志，日志，日志
- 持续改进周期（敏捷开发为极致）
我可以写一本书，将第一个列表中的每个主题分解成单独的技术。每个主题都可以有一本书介绍如何在各种平台、不同模型等上实现（许多主题已经有关于它们的书了）。
如果有人想添加更多内容或添加详细信息，请随意。