用于在云中托管 Java PLAY 应用程序的服务器架构

Question

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

---

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

我们的场景：我们有一个在 Java PLAY 框架 (https://www.playframework.com/) 中编写的非常简单的应用程序，可在 iOS 和 Android 以及后端系统（用于管理、内容管理和 API），将数据存储在 MySQL 数据库中。虽然大多数用户与服务器的交互都是快速简单的（登录、同步一些数据），但还有一些数据密集型任务（下载一些

AWS 中的托管设置：

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

跨区域水平扩展：一旦应用从另一个区域产生大量用户负载，整个 EC2 实例应该被复制并放到另一个区域，运行一个数据库只读副本（参见 Setting up a globally available web app on amazon web services 和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://boxfuse.com/) 进行部署之后，我选择了 AWS，因为它绝对可以从 1 个来源提供我们所需的一切。 Boxfuse 的每月成本较低，但可以完美集成到 AWS。支持缩放以及 3 个常见环境（开发/测试/产品）。支持非常出色。

Answer 1

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

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

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

Answer 2

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

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

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