重新设计 Amazon AWS 上的服务器架构答案

【问题标题】：Redesign of Server architecture on Amazon AWS重新设计 Amazon AWS 上的服务器架构
【发布时间】：2012-09-01 23:26:27
【问题描述】：

我们当前的项目架构如下。有 2 个亚马逊实例。两者都安装了 Ubuntu 10.10。

实例 1：(m1.large) -- 这个实例安装了 PHP、Apache 和 MySql。它包含主网站+API（用Php开发）+数据库（MySql）

实例 2：(t1.micro) -- 这个实例安装了 PHP、Apache 和 MySql。它包含一个 Javascript。

客户端-服务器交互： 在客户端，有一段 JS 代码在客户端加载 Instance 2 的 JS 文件。此 JS 文件创建请求并将其发送到 Instance 1 上的 API。实例 1 上的 API 生成响应并将其发送给客户端。

在实例 1 上，有每周运行的 cron 进程，即每周日运行大约 5-6 小时。

实例 1 上的最大 CPU 利用率约为 80%，而在周日，当 cron 设置为运行时，它会超过 95%。主实例每天的平均请求数约为 225k。

**There is no issue on instance 2 of CPU utilization.Size of database is 7.5 GB**

需要新架构： 正如我们所看到的，在当前架构中，CPU 利用率很高。如果我们想服务更多的请求，这种架构效率不高。随着我们客户端数量的增加，服务器上的请求数量和数据库大小也会增加。

您能建议新的架构设计吗？我们还计划将我们的数据库从 MySql 更改为 MongoDB。另外，将数据库与实例 1 分开。这是一个正确的决定吗？

任何人都可以建议我们可以为新架构（如 Memcached、nginx 等）实施的任何新技术。

谢谢。

【问题讨论】：

标签： architecture nginx amazon-ec2 amazon-web-services memcached

【解决方案1】：

这里有一个指向亚马逊Reference Architectures 的链接，可能会有所帮助：

简而言之：

将您的基础架构拆分为多个层（Web、应用程序、数据）
使用 Auto Scaling 组随着您的流量增加/减少而加速/减速
跨可用区拆分层以实现高可用性
使用 CloudFront 托管静态图像/javascript/等。对于速度敏感项目

【讨论】：

【解决方案2】：

这是一个非常笼统的问题，但这里有几点需要考虑：

从应用服务器中删除您的数据库。您可以将 Amazon RDS 用于 Amazon 托管的 MySQL 实例。
尝试为静态资源使用单独的网络服务器。 nginx 将是一个不错的选择。
nginx 也可以作为前端代理，将动态 PHP 请求转发到后端服务器。
此选项还为您提供了更轻松的可扩展性。如果您需要额外的计算能力，只需添加更多后端 PHP 服务器，将它们添加到您的 nginx 配置中即可。
在您的应用程序中，尝试使用连接到 memcache 的透明缓存层（可能应该安装在另一个实例上）。如果在缓存中找不到结果，则构建它（例如通过查询数据库）并将其存储在缓存中。以后的请求可以使用缓存中的结果。

【讨论】：

【解决方案3】：

好的，这里有几件事您可能需要考虑：

您需要知道您获得的最大连续请求数，而不是一天的平均请求数。您可以通过在 apache.conf 中设置（到某个限制）并增加 ec2 实例的配置/使用 autoscaling 来改进和测试 apache 处理的连续请求的数量。由于周日的 cron 作业导致您的 cpu 利用率上升，因此在 cpuutilization 上自动缩放是可行的方法。
您可以考虑使用 Cloudfront，它可以提高性能（如检索时间），并且还可以使应用程序具有高可用性。
如果您计划迁移到 MongoDb，您将无法使用 RDS。如果你坚持使用Mysql，你应该使用RDS。
在考虑 memcache 时，尝试在应用程序级别和数据库级别实现缓存，因为 memcache 可能会给您带来一些差异。
Nginx 是提供静态内容的不错选择，并且可以充当良好的代理服务器。

【讨论】：

【解决方案4】：

这里其他人的想法真的很好。我想我会加入关于静态内容的意见，因为其他答案中的共同主题是为此使用 Nginx 之类的东西。对我来说，我发现将图像、javascript、CSS 等放入 S3 存储桶并放入 Cloudfront 发行版要容易得多，而不必为这些内容提供 Web 服务器而烦恼。您可以在更接近最终用户的边缘节点上获取静态内容，而完全不必担心任何缩放方面的问题。

我还建议迁移到更新版本的 Ubuntu（可能来自 Canonical 的 12.04）。

我会尽量不在任何实际的生产网络服务器上运行大型 cron 进程（即那些消耗大量 CPU 或磁盘周期的进程）。可能会根据需要启动一个相同的实例，而不是在您的负载均衡器中）以执行这些任务。这也可以让您适当地调整 Web 服务器的大小/扩展（不适用于 cron 运行时的最坏情况）

究竟是使用 Mongo 还是 MySQL 取决于您的数据结构（即它更适合关系结构还是无模式结构）。

【讨论】：

【解决方案5】：

好吧，我同意@Mike Brant 的观点。这里每个人的意见都很好，底线是 - “是否使用 Mongo 和 MySQL 真的取决于你的数据结构（即它更适合关系结构还是无模式结构）。” 关于静态内容问题，我认为 Nginx 是一个不错的选择，但我不排除 Cloudfront（主要是因为缺乏足够的经验）。但是至于您的数据库选择，如果您选择 NoSQL，我认为 @987654321 @ 是一个不错的选择，如果您选择 MySQL，我建议您除了 RDS 之外，还可以查看 Xeround。干杯:)

【讨论】：