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

Question

这是一组问题,而不是一个非常具体的问题.在过去的几周/几天里,我一起困惑地了解了如何在"云端"正确托管JAVA PLAY应用程序,因为很多这些信息分散在不同的服务上,我觉得要将所有这些小块收集到一个,因为在完整的背景下,很多事情都很重要.但是,我把我的考虑转移到问题的底部,因为它们主要是我的意见和主观发现,我不想对此负责.如果我弄错了,请不要犹豫,指出这一点.

---

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

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

AWS内的托管设置:

水平缩放:首先,我们的app只有1个EC2实例将在eu-1a中运行.如果需要更多实例,并且更多实例实际上有利于更快的响应时间,我们将需要评估一个实例实际需要多少资源.

跨区域的水平扩展:一旦应用程序从另一个区域生成大量用户负载,整个EC2实例应该被复制并放到另一个区域,运行db read副本(请参阅在amazon Web服务和https 上设置全局可用的Web应用程序: //aws.amazon.com/de/blogs/aws/cross-region-read-replicas-for-amazon-rds-for-mysql/).

EC2实例的垂直扩展:在最近的旧主机设置测试中,数据库被证明是瓶颈而不是播放应用程序及其服务器的硬件规格.因此,尚不完全清楚垂直缩放会对响应时间产生多大影响.如果t2.micro实例与m3.xlarge实例一样好,当然我们宁愿从这里向上攀爬.

RDS的垂直扩展:我们需要估计有多少流量到达DB服务器以及需要什么CPU/RAM /等.也许我们也会在这里努力工作.

全局重定向:使用Amazon Route 53(？)完成.来自Tokio的用户应该被重定向到在亚洲运行的EC2实例; 从罗马到欧洲EC2实例的用户.这不仅会影响应用内的API调用,还会影响内容传送(双向).

打开有关设置的问题

1. 这个设置是决定性的吗？我错过了关键组件吗？
2. 关于全局重定向:Amazon Route 53是正确的工具吗？它与CloudFront有何不同(让我感到纯粹是为了内容/媒体发布？).
3. 如何为我的应用定义正确的数据/ api端点？当然,我不希望在应用程序部署期间定义db read副本的数据库端点.这也会在AR53(问题2)设置期间发生吗？对于API调用也是如此,当然应用程序应该将它的调用指向https://myurl.com/api,然后应该重定向.这是现实的吗？

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

---

背景资料

当前主机设置:负载均衡器在2个根Linux服务器上分配流量,两个服务器都运行PLAY应用程序,其中一个也持有MySQL安装.

目前的托管设置有三大缺陷:

1. 没有垂直可扩展性:托管公司会为每个扩展步骤花钱.目前服务器正在空闲运行,但如果应用程序蓬勃发展,我们可能会很快耗尽容量.正在运行闲置仍然需要永久满负荷运行.这很贵!
2. 没有部署支持:目前,我们通过SSH连接,手动将正确的文件夹部署到文件系统,在服务器上重新编译,设置权限,应用数据库演进; 对第二个服务器执行相同操作(具有不同的数据库连接参数).什么可能出错.;)
3. 没有全球可用性:在世界其他地区建立另一台服务器将意味着巨大的努力.可以完成我们的数据库的同步副本,但再次部署将意味着停机,错误的空间,因此时间和金钱.

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

1. AWS:亚马逊网络服务是您开始寻找的第一个地方.在这里,您可以灵活的价格获得所有可能的东西.你为自己设置了一个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种常见环境(dev/test/prod).支持非常出色.

Answer 1

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

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

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