为了实现可扩展性，需要遵循哪些规则？
客户经常坚持要求我确保我为他开发的任何网站都是为了可扩展性和更快的性能而设计的。我想知道这实际上意味着什么。我需要做什么才能满足这个要求？我主要使用 PHP/MySQL/AJAX 构建 Web 应用程序。
A client often insists that I make sure that any websites I develop for him are designed for scalability and faster performance. I'm wondering what that actually means, in practical terms. What do I have to do to fulfill this requirement? I mostly build web apps using PHP/MySQL/AJAX.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
无国籍！
（又名：不分享任何内容）。
让我解释一下：为了让您的应用程序能够轻松处理更多流量，您需要能够轻松地添加更多“东西”（servlet/服务器/处理器/句柄/响应程序，具体术语由您使用的技术决定）。为此，这些 servlet 不能假设它们总是会看到来自同一用户的请求（当您有许多相同的 servlet 时，给定的请求可能会出现在每个 servlet 中）。因此，servlet 无法“记住”先前请求中的某些内容。与当前请求相关的所有数据都应该是请求本身的一部分。
Statelessness!
(AKA: share nothing).
Let me explain: In order to allow you application to easily handle more traffic you need to be able to easily throw in more "thingies" (servlets/servers/processors/handles/responders exact terminology determined by the technology you use). For this to work those servlets cannot assume they will always see requests from the same user (when you have many identical servlets, a given request can end up in each one of them). Thus, a servlet cannot "remember" something from a previous request. All data pertaining to the current request should be part of the request itself.
可扩展性意味着当更多的用户请求到达您的服务器时，您的 Web 应用程序将如何表现。大多数时候，您运行的基本测试可能不会告诉您 Web 应用程序将面临的现实。因此，请在正常和更大的范围内测试应用程序的性能。
可能有助于您扩大规模的一些事情是：
1. 尽量减少代码中的阻塞点。
2. 对昂贵的计算使用记忆化（缓存代理），如果可能的话可以查找而不是重新计算。
3. 如有必要，使用客户端缓存。 （例如，这在 Flex、ActionScript 应用程序中是可能的）
4. 优化核心功能以处理更大的输入。
可扩展性也可能与硬件、数据库存储处理大输入的能力有关。
scalability means how your web app would behave as more number of user-requests hit your server. Most of the time basic tests that you run might not tell you the reality that the web app will face. So test for performance of your app in normal and bigger scales.
Few things that might help you scale up are:
1. try to minimize points of your code that block.
2. Use memoization (cache proxy) for expensive computations that can be looked up instead of recomputation if possible.
3. use client side cache if necessary. (eg this is possible in flex, actionscript apps)
4. optimize your core functionality for handling bigger input.
scalability might also be related to hardware, db storage's capacity to handle big input.
构建您的应用程序，使其适合跨多个服务器甚至多个站点进行负载平衡。我不确定 PHP 的预防措施是什么；对于基于 Java 的应用程序，这意味着严格遵循企业环境指南。
Build your apps so they are suitable for load balancing across multiple servers and perhaps even multiple sites. I'm not sure what the PHP precautions for that are; for Java based apps, that means strictly following the Enterprise Environment guidelines.
关键是每个请求都需要拥有服务该请求所需的所有信息，并且资源/响应是可缓存的。
http://en.wikipedia.org/wiki/Representational_State_Transfer
The key is that every request needs to have all the information necessary to service the request, and that resources/responses be cacheable.
http://en.wikipedia.org/wiki/Representational_State_Transfer
正如伊泰所指出的，无国籍现象是巨大的。尽可能计划向外扩展而不是向上扩展。松散耦合也促进并缓冲了可扩展性的道路。在适当的情况下采用并行性，无论是跨服务器并行执行，还是单个进程或服务内的多线程。避免在数据库服务器上投入过多的工作。考虑分区/分片策略。尽可能使用缓存。
另请注意：可扩展性！=可用性。如果可用性是一个问题，还需要解决其他问题。
还有一点要注意：仪器！仪器/可配置日志/可配置跟踪一切！如果您无法获得有关系统某个部分的行为的详细信息，那么扩展就会变得更加困难且成本更高。现在，这并不意味着在运行输入/离开跟踪代码的情况下运行您的生产系统，但它确实意味着确保您没有任何间隙，并在发现它们时解决它们，否则您将追着尾巴并且修复错误的问题。
Statelessness is huge, as noted by Itay. Plan to scale OUT rather then UP whenever possible. Loose coupling facilitates and buffers the path to scalability as well. Employ parallelism where appropriate, whether parallel execution across servers, or multithreading within a single process or service. Avoid putting too much work on the DB server(s). Consider partitioning/sharding strategies. Use caching wherever possible.
Also note: scalability != availability. There are other concerns to address if availability is an issue.
One more note: instrumentation! Instrument/configurably log/configurably trace EVERYTHING! If you can't get detailed information on the behavior of a piece of your system, scaling becomes more difficult and more expensive. Now, this doesn't mean run your production system with enter/leave trace code running, but it does mean make sure you don't have any gaps, and address them as you find them, otherwise you'll be chasing your tail and fixing the wrong problems.