Amazon EC2 上的 PHP 应用程序的架构
我最近在我创建的 Facebook 应用程序上经历了巨大的流量（主要是为了教育，而不是出于任何营销目的）
不用说，我在创建该应用程序时并没有考虑可扩展性。我现在的处境是，MediaTemple 托管的微薄虚拟服务器根本无法满足我的需求，而这实际上取决于机器的原始 I/O。由于到目前为止这个项目对我来说非常有教育意义，我想我应该以此为契机来了解 Amazon EC2 平台。
该应用程序本身是用 PHP（使用 Zend Framework）和 MySQL 后端创建的。我尽可能使用 memcached 进行应用程序缓存。我整个周末都在研究 EC2、启动实例、安装我想要的软件包以及将 EBS 卷安装到实例。
但是，下一个逻辑步骤是什么才能产生良好的可扩展性结果呢？我是否需要为 MySQL 启动一个 AMI 实例，并为 Apache 服务启动一个 AMI 实例？或者我是否只是根据需要多次复制实例，然后在前端进行某种负载平衡？理想情况下，我希望有一个集中式数据库，因为我会汇总所有数据库行的统计信息，但是，这不是一个硬性要求（我可能可以提出一些特定于应用程序的解决方案来解决这个问题）
我知道这一点可能不是一个直接的答案，因此欢迎提出意见和建议。
I recently experienced a flood of traffic on a Facebook app I created (mostly for the sake of education, not with any intention of marketing)
Needless to say, I did not think about scalability when I created the app. I'm now in a position where my meager virtual server hosted by MediaTemple isn't cutting it at all, and it's really coming down to raw I/O of the machine. Since this project has been so educating to me so far, I figured I'd take this as an opportunity to understand the Amazon EC2 platform.
The app itself is created in PHP (using Zend Framework) with a MySQL backend. I use application caching wherever possible with memcached. I've spent the weekend playing around with EC2, spinning up instances, installing the packages I want, and mounting an EBS volume to an instance.
But what's the next logical step that is going to yield good results for scalability? Do I fire up an AMI instance for the MySQL and one for the Apache service? Or do I just replicate the instances out as many times as I need them and then do some sort of load balancing on the front end? Ideally, I'd like to have a centralized database because I do aggregate statistics across all database rows, however, this is not a hard requirement (there are probably some application specific solutions I could come up with to work around this)
I know this is probably not a straight forward answer, so opinions and suggestions are welcome.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这么多问题——但所有问题都很好。
在扩展方面，您有几种选择。
第一个是从单个盒子开始。您可以向上扩展 - 使用更强大的盒子。 EC2 有各种大小的实例。每当您想要更大的盒子时，这都涉及到服务器迁移。
更简单的是添加服务器。您可以从 Apache & 的单个实例开始。 MySQL。然后，当流量增加时，为 MySQL 创建一个单独的实例，并将您的应用程序指向这个新实例。这在应用程序和数据库之间创建了一个很好的层。根据您的流量，这听起来像是一个很好的起点。
接下来，您可能需要更多的应用程序功能（Web 服务器）或更多的数据库功能（MySQL 集群等）。您可以让 DNS 记录指向几个运行某些负载平衡软件的前端设备（尝试 Pound） 。这些负载平衡服务器将请求分发到您的网络服务器。 EC2 有 Elastic Load Balancing，这是您自行管理的替代方案，而且可能更容易 - 我个人没用过。
其他需要注意的事情 - EC2 没有持久存储。您必须使用弹性块存储自行管理持久数据。 本指南是关于如何通过自动备份执行此操作的出色教程。
如果您认为 EC2 是前进的方向，我建议您购买一些预留实例。 3 年内您将节省约 50%！
最后，您可能对 RightScale 等提供收费管理服务的服务感兴趣。还有其他可用的提供商。
So many questions - all of them good though.
In terms of scaling, you've a few options.
The first is to start with a single box. You can scale upwards - with a more powerful box. EC2 have various sized instances. This involves a server migration each time you want a bigger box.
Easier is to add servers. You can start with a single instance for Apache & MySQL. Then when traffic increases, create a separate instance for MySQL and point your application to this new instance. This creates a nice layer between application and database. It sounds like this is a good starting point based on your traffic.
Next you'll probably need more application power (web servers) or more database power (MySQL cluster etc.). You can have your DNS records pointing to a couple of front boxes running some load balancing software (try Pound). These load balancing servers distribute requests to your webservers. EC2 has Elastic Load Balancing which is an alternative to managing this yourself, and is probably easier - I haven't used it personally.
Something else to be aware of - EC2 has no persistent storage. You have to manage persistent data yourself using the Elastic Block Store. This guide is an excellent tutorial on how to do this, with automated backups.
I recommend that you purchase some reserved instances if you decide EC2 is the way forward. You'll save yourself about 50% over 3 years!
Finally, you may be interested in services like RightScale which offer management services at a cost. There are other providers available.
第一步是分离关注点。我会用一个单独的 MySQL 服务器和一个专用的 memcached 盒子分开，这取决于你的负载有多高。然后我会监控每个机器上的内存和 CPU 使用情况，看看可以在哪里进行优化。这可以通过剥离新的 Media Temple 盒子来完成。我还建议使用 Slicehost 作为更便宜、对开发人员更友好的替代方案。
一些更低成本的 PHP 部署优化：
mod_rewrite和更简单的 Apache 模块，这可能是一个很好的选择。如果您更喜欢更高级的、自己动手的方法，您可能需要查看 Scalr (Scalr ="http://code.google.com/p/scalr/" rel="noreferrer">Google 代码中的代码）。他们网站上的视频值得一看。它使用 Amazon EC2 构建可扩展的托管环境。该技术是开源的，因此您可以下载它并在自己的管理服务器上自行实施。 （也许是您的 Media Temple 盒子？）Scalr 具有可用于某些常见用例的预构建 AMI（EC2 设备）。
Scalr 选项可能需要更多的配置更改，但如果您觉得扩展需要快速加速，那么可能值得花费时间和精力。
First step is to separate concerns. I'd split off with a separate MySQL server and possibly a dedicated memcached box, depending on how high your load is there. Then I'd monitor memory and CPU usage on each box and see where you can optimize where possible. This can be done with spinning off new Media Temple boxes. I'd also suggest Slicehost for a cheaper, more developer-friendly alternative.
Some more low-budget PHP deployment optimizations:
mod_rewriteand simpler Apache modules.If you prefer a more high-level, do-it-yourself approach, you may want to check out Scalr (code at Google Code). It's worth watching the video on their web site. It facilities a scalable hosting environment using Amazon EC2. The technology is open source, so you can download it and implement it yourself on your own management server. (Your Media Temple box, perhaps?) Scalr has pre-built AMIs (EC2 appliances) available for some common use cases.
The Scalr option will probably take some more configuration changes, but if you feel your scaling needs accelerating quickly it may be worth the time and effort.