可扩展性 101：如何使用 PHP 设计可扩展的 Web 应用程序？
我正在构建一个网络应用程序，有几个简单的问题。根据我的了解，人们在最初构建应用程序时不应该担心可扩展性，而应该只在流量增加时才开始担心。然而，这是我的第一个 Web 应用程序，我不太确定是否应该采取一种方法，即以临时方式设计事物，然后“修复”它们。我一直在阅读有关人们如何开始使用一款应用程序并在一两周内吸引数百万用户的故事。并不是说我会面临同样的情况，但我不禁想知道，这些人是怎么做到的？
目前，我在 Lunarpages 上购买了一个共享托管帐户，这让我开始构建和测试该应用程序。然而，我有兴趣学习如何使用云以可扩展的方式构建相同的应用程序，例如亚马逊的 EC2。根据我的理解，我可以看到几个组件：
- 有一个负载均衡器，它首先接收请求，然后决定将每个请求路由到何处
- 该请求然后由服务器副本处理，然后服务器副本处理该请求并更新（如果需要）数据库并将响应发送回客户端
- 如果有类似的请求进来，那么像 memcached 这样的缓存机制就会启动并从缓存中返回对象
- 处理数据库复制的黑匣子
具体来说，我正在尝试执行以下操作
- ：负载均衡器（我的作业显示 HAProxy 就是这样一种负载均衡器）
- 设置复制以便可以同步数据库
- 使用 memcached
- 配置 Apache 以与多个 Web 服务器配合使用 对
- 应用程序进行分区以使用 Amazon EC2 和 Amazon S3（我的应用程序需要大量的存储）
- 最后，如何避免在使用亚马逊服务时烧伤自己？因为这只是一个学习阶段，我可能可以使用 2-3 台带有简单负载均衡器和复制的服务器，但直到我想避免意外支付大量资金为止。
我能够找到有关各个主题的资源，但无法找到从大局出发的资源。有人可以帮我开始吗？
I am building a web-application and have a couple of quick questions. From what I learnt, one should not worry about scalability when initially building the app and should only start worrying when the traffic increases. However, this being my first web-application, I am not quite sure if I should take an approach where I design things in an ad-hoc manner and later "fix" them. I have been reading stories about how people start off with an app that gets millions of users in a week or two. Not that I will face the same situation but I can't help but wonder, how do these people do it?
Currently, I bought a shared hosting account on Lunarpages and that got me started in building and testing the application. However, I am interested in learning how to build the same application in a scalable-manner using the cloud, for instance, Amazon's EC2. From my understanding, I can see a couple of components:
- There is a load balancer that first receives requests and then decides where to route each request
- This request is then handled by a server replica that then processes the request and updates (if required) the database and sends back the response to the client
- If a similar request comes in, then a caching mechanism like memcached kicks into picture and returns objects from the cache
- A blackbox that handles database replication
Specifically, I am trying to do the following:
- Setting up a load balancer (my homework revealed that HAProxy is one such load balancer)
- Setting up replication so that databases can be synchronized
- Using memcached
- Configuring Apache to work with multiple web servers
- Partitioning application to use Amazon EC2 and Amazon S3 (my application is something that will need great deal of storage)
- Finally, how can I avoid burning myself when using Amazon services? Because this is just a learning phase, I can probably do with 2-3 servers with a simple load balancer and replication but until I want to avoid paying loads of money accidentally.
I am able to find resources on individual topics but am unable to find something that starts off from the big picture. Can someone please help me get started?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
就我个人而言，我认为您应该考虑您的应用程序最初将如何扩展 - 否则您会遇到问题。
我并不是说您需要首先将其构建为多服务器系统，但如果您认为稍后需要这样做，请现在注意这些问题。
根据我的经验，这包括以下内容：
会话。除非您使用“粘性”负载平衡，否则您必须有某种方法在服务器之间共享会话状态。这可能意味着将会话数据存储在共享存储或数据库中。
文件上传和复制。如果您允许用户上传文件，或者您有一个允许您上传图像/文档的 CMS，则它需要考虑到这些文件还需要找到到集群中其他节点的方式。但是，如果您已经沿着上面提到的共享存储路线前进，这应该涵盖它。
数据库可扩展性。如果您使用传统的数据库服务器，您可能需要考虑如何在该级别实现可扩展性。这可能意味着对您的应用程序进行编码，以便您使用一个连接字符串进行读取，使用另一个连接字符串进行写入。然后，您可以自由地使用一个主节点来实现复制，该主节点处理插入/更新，将更改级联到处理大量工作的只读节点。
中间件。您甚至可能想要沿着实现某种面向消息的中间件解决方案的路线来完全移交业务逻辑功能 - 这将为您将来希望如何扩展此业务逻辑层提供很大的灵活性。尽管最初这会很复杂，而且回报不会很大。
Personally, I think you should be considering how your app will scale initially - as otherwise you'll run into problems down the line.
I'm not saying you need to build it initially as a multi-server system, but if you think you'll need to do it later, be mindful of the concerns now.
In my experience, this includes things like:
Sessions. Unless you use 'sticky' load balancing, you will have to have some way of sharing session state between servers. This probably means storing session data on either shared storage, or in a DB.
File uploads and replication. If you allow users to upload files, or you have a CMS that allows you to upload images/documents, it needs to cater for the fact that these files will also need to find their way onto other nodes in your cluster. However, if you've gone down the shared storage route mentioned above, this should cover it.
DB scalability. If you're using traditional DB servers, you might want to think about how you'll implement scalability at that level. This may mean coding your app so you use one connection string for reads, and another for writes. Then, you are free to implement replication with one master node handling the inserts/updates cascading the changes to read only nodes that handle the bulk of the work.
Middleware. You might even want to go down the route of implementing some kind of message oriented middleware solution to completely hand off business logic functions - this will give you a great level of flexibility in how you wish to scale this business logic layer in the future. Although initially this will be a lot of complication and work for not a great deal of payoff.
您是否考虑过先尝试一下虚拟机？您可以在本地计算机上运行 2-3 个虚拟机，并像实际服务器一样设置它们，它们只是无法处理实际流量水平。如果您所寻求的只是学习体验，那么这可能是一种理想的方式。
Have you considered playing around with VMs first? You can run 2-3 VMs on your local machine and set them up like you would actual servers, they just won't be able to handle real traffic levels. If all you're looking for is the learning experience, it might be an ideal way to go about it.