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

Question

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

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

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

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 实例的垂直扩展:在最近对旧主机设置的测试中，事实证明数据库是瓶颈，而不是 Play 应用程序及其服务器的硬件规范。因此，尚不完全清楚垂直缩放会影响响应时间的程度。如果 t2.micro 实例和 m3.xlarge 实例一样好，我们当然宁愿从这里从底部爬上来。

RDS 的垂直缩放:我们需要估计访问数据库服务器的流量以及需要的 CPU/RAM/等。也许我们也会在这里工作。

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

关于设置的未决问题

这个设置是决定性的吗？我是否缺少关键组件？

关于全局重定向:Amazon Route 53 是正确的工具吗？它与 CloudFront 有何不同(这让我觉得纯粹是为了内容/媒体分发？)。

如何为我的应用程序定义正确的数据/api 端点？当然，我不想在应用程序部署期间定义 db 只读副本的数据库端点。在 AR53(问题 2)设置期间也会发生这种情况吗？ API 调用也是如此，当然应用程序应该将它的调用定向到 https://myurl.com/api从那里它应该被重定向。这是现实的吗？

我非常感谢各种想法(!)，也关于下面写的背景信息。如果你能指点我进一步阅读以自己解决我的问题，我也非常感谢——关于这方面的信息量很大，但这使得很难缩小答案的范围。我确实有托管/服务器方面的知识，但我很确定那里有真正的专家在等着给我知识。 :)

背景信息

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



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

没有垂直可扩展性:托管公司会为每个扩展步骤收取资金。目前服务器处于空闲状态，但如果应用程序蓬勃发展，我们可能很快就会出现容量不足的情况。运行空闲仍然像在满负荷下永久支付一样。这很贵!

不支持部署:目前，我们通过SSH连接，手动将正确的文件夹部署到文件系统，在服务器上重新编译，设置权限，应用数据库演变；对第二台服务器做同样的事情(使用不同的数据库连接参数)。什么可能出错。 ;)

没有全局可用性:在世界的另一个地区设置另一台服务器将意味着巨大的努力。可以完成我们数据库的同步副本，但再次部署将意味着停机、出错的空间以及时间和金钱。

Java PLAY 的托管选项:
关于这一点，有很多不同的博客文章。简而言之:

AWS:Amazon Web Services 是您首先开始寻找的地方之一。在这里，您可以以灵活的价格获得一切可能。您为自己设置了一个 EC2 实例、一个 MySQL RDS，然后就可以开始使用了 - 所有这些都在免费层中，因此您可以试验、玩耍和测试您的东西。

Microsoft Azure:在定价和可能性方面类似于 AWS。但是，我并没有深入研究设置和部署我们的应用程序以进行测试。

Heroku:从 PLAY 内部部署 super 简单，可扩展的服务器。然而(乍一看？)缺乏向偏远地区提供高速内容的可能性。

Jelastic :在 PLAY/IntelliJ IDEA 中更容易部署。您将应用程序镜像推送到 jelastic，jelastic 将其进一步分发给他们的基础设施提供商。

RedHat OpenShift ( https://www.openshift.com/ ):听起来很有希望，但不如 AWS 完整。

很多选择和可能的设置/价格。特别是在了解了使用 boxfuse ( https://boxfuse.com/ ) 进行部署后，我选择了 AWS，因为它从 1 个来源绝对提供了我们需要的一切。 Boxfuse 的每月成本较低，但已完美集成到 AWS 中。支持缩放以及 3 种常见环境 (dev/test/prod)。支持非常出色。

Answer 1

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

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

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