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

这是一组问题，而不是一个非常具体的问题。在过去的几周/几天里，我迷惑了有关如何在“云中”正确托管JAVA PLAY应用程序的信息，因为许多此类信息分散在不同的服务中，所以我想将所有这些小片段收集在一起，因为充分了解上下文中的许多事情很重要。但是，我将考虑因素移至问题的底部，因为它们主要是我的观点和主观发现，我不希望对此负责。如果我做错了，请毫不犹豫地指出。

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

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

AWS内的托管设置：

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

跨区域的水平扩展：一旦应用程序从另一个区域产生了沉重的用户负载，则应复制整个EC2实例并将其放置到另一个区域，运行数据库只读副本（请参阅在Amazon Web Services和https上设置全球可用的Web应用程序： //aws.amazon.com/de/blogs/aws/cross-region-read-replicas-for-amazon-rds-for-mysql/）。

EC2实例的垂直扩展：在对旧主机设置的最新测试中，数据库被证明是瓶颈，而不是play应用及其服务器的硬件规格。因此，尚不完全清楚多少垂直缩放会影响响应时间。如果一个t2.micro实例与一个m3.xlarge实例一样好，那么我们当然希望从这里的底部开始。

RDS的垂直扩展：我们将需要估计有多少流量命中DB服务器，以及需要什么CPU / RAM / etc。也许我们也会在这里努力。

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

有关设置的未解决问题

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

我非常感谢各种各样的想法（！），也涉及下面写的背景信息。如果您可以指点我继续阅读以自己解决问题，我也非常感谢-与此相关的信息非常多，但这很难缩小答案的范围。我确实有托管/服务器方面的知识，但是我很确定那里有真正的专家正在等着我。:)

背景信息

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

当前的主机设置存在3个大缺陷：

1. 没有垂直可伸缩性：托管公司会为每个扩展步骤花钱。当前，服务器正在闲置，但是如果应用程序繁荣起来，我们可能会很快出现容量不足的情况。仍然要支付运行空闲时间，就好像永久处于满负荷状态一样。这很贵！
2. 没有部署支持：当前，我们通过SSH连接，将正确的文件夹手动部署到文件系统，在服务器上重新编译，设置权限，应用数据库演化；对第二台服务器执行相同的操作（具有不同的数据库连接参数）。可能出了什么问题。;）
3. No worldwide availability: to set up another server in another region of the world would mean a huge effort. To have a synchronized replica of our DB can be done, but once again deploying would mean downtime, room for errors and therefore time and money.

Hosting Options for Java PLAY: There are lot of different blog posts about this. In short:

1. AWS: Amazon Web Services is one of the first places you start looking. Here you get everything that's possible, at a flexible price. You set yourself up an EC2 instance, a MySQL RDS and you're good to go - all of this in the free tier, so you can experiment, play around, test your stuff.
2. Microsoft Azure: similar to AWS regarding pricing and possibilities. However, I did not dive into setting up and deploying our application for test purposes.
3. Heroku: super easy deployment from within PLAY, scalable servers. However (on the first glance?) lacks possibility to supply remote regions with high speed content.
4. Jelastic: even easier deployment from within PLAY / IntelliJ IDEA. You push your app image to jelastic, jelastic distributes it further to their infrastructure providers.
5. RedHat OpenShift (https://www.openshift.com/): sounds promising, yet not as complete as AWS.

Lots of choices and possible setups/prices. Especially after finding out about deployment using boxfuse (https://boxfuse.com/) I made my choice for AWS, as it offers absolutely all we need from 1 source. Boxfuse has low monthly costs but is perfectly integrated into AWS. Scaling is supported as well as the 3 common environments (dev/test/prod). Support is outstanding.