10

这是一组问题，而不是一个非常具体的问题。在过去的几周/几天里，我将有关如何正确托管“在云中”的 JAVA PLAY 应用程序的信息拼凑在一起，因为很多这些信息分散在不同的服务中，我想把所有这些小块收集起来，因为很多事情在完整的背景下很重要。但是，我将我的考虑移到了问题的底部，因为它们主要是我的意见和主观发现，我不想为此负责。如果我有什么问题，请不要犹豫，指出这一点。

在 AWS 上托管 Java PLAY + MySQL 以实现全球可访问性

我们的场景：我们有一个在 Java PLAY 框架 ( https://www.playframework.com/ ) 中编写的非常简单的应用程序，在 iOS 和 Android 以及后端系统（用于管理、内容管理和 API）上工作)，将数据存储在 MySQL 数据库中。虽然大多数用户与服务器的交互都是快速和简单的（登录、同步一些数据），但还有一些数据密集型任务（下载一些 <100mb 的数据压缩包到手机，上传几个 mb 到服务器）。因此，我们正在寻找一种解决方案，为远离我们服务器的用户提供合理的响应时间。显而易见的下一步是在云中托管。

AWS 中的托管设置： AWS 中的托管设置

水平扩展：一开始，我们的应用程序中只有 1 个 EC2 实例将在 eu-1a 中运行。我们将需要评估一个实例实际需要多少资源，是否需要更多实例，以及是否更多实例实际上会受益于更快的响应时间。

跨区域水平扩展：一旦应用程序从另一个区域产生大量用户负载，整个 EC2 实例应该被复制并放到另一个区域，运行数据库只读副本（请参阅在亚马逊网络服务和https上设置全球可用的网络应用程序： //aws.amazon.com/de/blogs/aws/cross-region-read-replicas-for-amazon-rds-for-mysql/）。

EC2 实例的垂直扩展：在最近对旧托管设置的测试中，数据库被证明是瓶颈，而不是游戏应用程序及其服务器的硬件规格。因此，尚不完全清楚垂直缩放会影响响应时间的程度。如果 t2.micro 实例与 m3.xlarge 实例一样好，我们当然宁愿从这里的底部向上爬。

RDS 的垂直扩展：我们需要估计有多少流量到达数据库服务器以及需要多少 CPU/RAM/等。也许我们也会在这里工作。

全局重定向：使用 Amazon Route 53 (?) 完成。来自 Tokio 的用户应该被重定向到在亚洲运行的 EC2 实例；来自罗马的用户到欧洲的 EC2 实例。这不仅会影响应用程序内的 API 调用，还会影响内容交付（双向）。

关于设置的未决问题

  1. 这个设置是决定性的吗？我是否缺少关键组件？
  2. 关于全球重定向：Amazon Route 53 是正确的工具吗？它与 CloudFront 有何不同（这让我觉得纯粹是为了内容/媒体分发？）。
  3. 如何为我的应用程序定义正确的数据/api 端点？当然，我不想在应用部署期间定义数据库只读副本的数据库端点。在 AR53（问题 2）设置期间也会发生这种情况吗？API 调用也是如此，当然应用程序应该将它的调用定向到https://myurl.com/api并从那里重定向它。这是现实的吗？

我非常感谢各种想法（！），以及关于下面写的背景信息。如果您可以指点我进一步阅读以自行解决我的问题，我也非常感谢 - 有大量关于此的信息，但这使得很难缩小答案范围。我确实有托管/服务器方面的知识，但我很确定那里有真正的专家等着用知识给我耳光。:)

背景信息

当前主机设置：负载均衡器在 2 个根 Linux 服务器上分配流量，它们都运行 PLAY 应用程序，其中一个还保存 MySQL 安装。

当前托管设置（非云）

当前的托管设置有 3 个大缺陷：

  1. 没有垂直可扩展性：托管公司会为每个扩展步骤花钱。目前服务器处于闲置状态，但如果应用程序蓬勃发展，我们可能很快就会出现容量不足的情况。闲置运行仍然是有偿的，就好像永久处于满负荷状态一样。这很贵！
  2. 不支持部署：目前我们通过SSH连接，手动将正确的文件夹部署到文件系统，在服务器上重新编译，设置权限，应用数据库演进；对第二台服务器执行相同操作（使用不同的数据库连接参数）。什么可能出错。;)
  3. 没有全球可用性：在世界的另一个地区设置另一台服务器将意味着巨大的努力。可以完成我们数据库的同步副本，但再次部署将意味着停机、错误空间以及时间和金钱。

Java PLAY 的托管选项： 有很多关于此的不同博客文章。简而言之：

  1. AWS：Amazon Web Services 是您最先开始寻找的地方之一。在这里，您可以以灵活的价格获得一切可能。您为自己设置了一个 EC2 实例、一个 MySQL RDS，一切顺利 - 所有这些都在免费层中，因此您可以试验、玩耍、测试您的东西。
  2. Microsoft Azure：在定价和可能性方面类似于 AWS。但是，我并没有深入研究设置和部署我们的应用程序以进行测试。
  3. Heroku：在 PLAY 中超级容易部署，可扩展的服务器。然而（乍一看？）缺乏为偏远地区提供高速内容的可能性。
  4. Jelastic：在 PLAY / IntelliJ IDEA 中更容易部署。您将应用程序映像推送到 jelastic，jelastic 将其进一步分发给他们的基础设施提供商。
  5. RedHat OpenShift ( https://www.openshift.com/ )：听起来很有希望，但不如 AWS 完整。

很多选择和可能的设置/价格。尤其是在了解了使用 boxfuse ( https://cloudcaptain.sh/ ) 进行部署之后，我选择了 AWS，因为它绝对提供了我们从 1 个来源所需要的一切。Boxfuse 的每月成本较低，但可以完美集成到 AWS。支持缩放以及 3 个常见环境（开发/测试/产品）。支持非常出色。

4

2 回答 2

2

设置看起来不错。然而，我会做一个改变：你的大型上传和下载。由于移动速度可能并不理想，因此您应该避免让您的应用程序服务于长时间运行的请求，因为这会不必要地占用服务器线程。而是考虑让用户使用预签名 URL 直接从 S3 上传和下载。然后，您可以稍后在具有财务意义时将 CloudFront 添加到组合中。

R53 可以很好地为每个最终用户选择最好的服务器。

对于 EC2，请考虑设置 ELB + Auto-Scaling Group。即使只是单个实例，您也可以获得永久健康监控和自动重生的好处。如果您期望更多负载，您可以根据您的预期瓶颈（cpu、网络 i/o）自动扩展。这将为您提供更自主和更强大的设置，而不是根据您自己的监控分析手动扩展和缩减（即使扩展部分非常容易，如果您坚持使用不可变的基础架构和蓝/绿部署，如Boxfuse提供的）。

于 2015-12-08T17:37:54.547 回答
1

  • 您对垂直服务器扩展的关注可能无法在 AWS 上为您提供很好的服务。我会开始考虑在 Elastic Load Balancer 后面横向扩展应用服务器，并且可能会研究 Elastic Beanstalk。

  • 我不确定您是否可以通过 RDS 在另一个区域设置只读副本，您可能必须通过在标准 EC2 实例上运行的 MySQL 服务器进行设置。即使可以，这也将是一些昂贵且高延迟的数据传输。

  • 如果您只担心文件上传和下载，您只需将 CloudFront（亚马逊的 CDN 服务）放在您的应用程序前面，并允许它通过其全球边缘服务器处理文件上传和下载。您甚至可以在不将整个应用程序移至 AWS 的情况下执行此操作。我建议您先阅读这篇博文。

于 2015-12-08T16:58:47.907 回答