用于在云中托管 Java PLAY 应用程序的服务器架构
Server Architecture for hosting Java PLAY application in the cloud
这是一组问题，而不是一个非常具体的问题。在最后一对 weeks/days 中，我对如何在“云中”正确托管 JAVA PLAY 应用程序的信息感到困惑，因为很多信息分散在不同的服务中，我想收集所有这些小块对一，因为很多事情在完整的上下文中很重要。但是，我将我的考虑移到了问题的底部，因为它们主要是我的意见和主观发现，我不想对此负责。如果我有什么不对的地方，请随时指出。
在 AWS 上托管 Java PLAY + MySQL 以实现全球访问
我们的场景： 我们在 Java PLAY 框架 (https://www.playframework.com/) 中编写了一个非常简单的应用程序，正在 iOS和 Android 以及后端系统（用于管理、内容管理和 API），将数据存储在 MySQL 数据库中。虽然大多数用户与服务器的交互都快速而简单（登录、同步一些数据），但也有一些数据密集型任务（下载一些 <100mb 的数据压缩包到手机 phone，上传几个mb 到服务器）。因此，我们一直在寻找一种解决方案，为远离我们服务器的用户提供合理的响应时间。显而易见的下一步是在云中托管。
AWS 内的托管设置：
水平缩放： 首先，我们的应用程序只有 1 个 EC2 实例 运行ning 在 eu-1a 中。我们将需要评估一个实例实际需要多少资源，是否需要更多实例，以及更多实例是否真正有益于更快的响应时间。
跨区域水平扩展：一旦应用程序从另一个区域产生大量用户负载，应复制整个 EC2 实例并放到另一个区域，运行ning数据库只读副本（参见 Setting up a globally available web app on amazon web services and 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/etc。可能我们也会在这里努力。
全局重定向： 使用 Amazon Route 53 (?) 完成。来自 Tokio 的用户应该被重定向到亚洲的 EC2 实例 运行ning；从罗马到欧洲的 EC2 实例的用户。这不仅会影响应用内的 API 调用，还会影响内容交付（双向）。
关于设置的开放问题
- 这个设置是决定性的吗？我是否缺少关键组件？
- 关于全局重定向：Amazon Route 53 是正确的工具吗？它与 CloudFront（我觉得它纯粹用于内容/媒体分发？）有何不同？
- 如何为我的应用程序定义正确的 data/api 端点？当然，我不想在应用程序部署期间定义数据库只读副本的数据库端点。在 AR53（问题 2）设置期间也会发生这种情况吗？ API 调用也是如此，当然应用程序应该将它的调用定向到 https://myurl.com/api 并且应该从那里重定向。这现实吗？
我非常感谢各种想法 (!)，也包括下面写的背景信息。如果您能指点我进一步阅读以自行解决我的问题，我也非常感谢 - 有大量关于此的信息，但这使得很难缩小答案范围。我确实有 hosting/servers 方面的知识，但我很确定那里有真正的专家等着用知识来打击我。 :)
背景资料
当前主机设置： 负载均衡器将流量分配到 2 个根 linux 服务器上，它们都 运行 运行 PLAY 应用程序，其中一个他们还持有 MySQL 安装。
当前的托管设置有 3 个大缺陷：
- 没有垂直可扩展性：托管公司会为每个扩展步骤付费。目前服务器 运行 处于闲置状态，但如果应用程序蓬勃发展，我们可能会很快 运行 出现容量不足的情况。 运行 闲置仍然支付，就好像永久处于满负荷状态一样。这个好贵！
- 不支持部署：目前，我们通过 SSH 连接，手动将正确的文件夹部署到文件系统，在服务器上重新编译，设置权限，应用数据库演化；对第二台服务器执行相同操作（具有不同的数据库连接参数）。可能会出什么问题。 ;)
- 没有全球可用性：在世界的另一个地区设置另一个服务器将意味着巨大的努力。可以完成我们数据库的同步副本，但再次部署将意味着停机时间、错误空间以及时间和金钱。
Java PLAY 的托管选项：
关于这个有很多不同的博客文章。简而言之：
- AWS：Amazon Web Services 是您最先开始寻找的地方之一。在这里，您可以以灵活的价格获得一切可能的东西。您自己设置了一个 EC2 实例、一个 MySQL RDS，一切顺利 - 所有这些都在免费套餐中，因此您可以试验、玩耍、测试您的东西。
- Microsoft Azure：在定价和可能性方面类似于 AWS。但是，我没有深入研究为测试目的设置和部署我们的应用程序。
- Heroku：从 PLAY 中部署超级简单，可扩展的服务器。然而（乍一看？）无法为偏远地区提供高速内容。
- Jelastic：在 PLAY / IntelliJ IDEA 中更容易部署。您将您的应用程序图像推送到 jelastic，jelastic 将其进一步分发给他们的基础设施提供商。
- RedHat OpenShift (https://www.openshift.com/)：听起来很有前途，但不如 AWS 完整。
很多选择和可能 setups/prices。尤其是在了解了使用 boxfuse (https://cloudcaptain.sh/) 进行部署之后，我选择了 AWS，因为它从一个来源提供了我们所需的一切。 Boxfuse 每月费用低廉，但已完美集成到 AWS 中。支持缩放以及 3 种常见环境 (dev/test/prod)。支持非常出色。
您对垂直服务器扩展的关注可能无法在 AWS 上很好地为您服务。我会开始考虑在 Elastic Load Balancer 后面横向扩展应用程序服务器，并且可能会研究 Elastic Beanstalk。
我不确定您是否可以通过 RDS 在另一个区域设置只读副本，您可能必须在标准 EC2 实例上通过 MySQL 服务器 运行 进行设置.即使可以，那也将是一些昂贵且高延迟的数据传输。
如果你担心的只是文件上传和下载，你只需要将CloudFront（Amazon的CDN服务）放在你的应用程序前面，让它通过它来处理文件上传和下载全球边缘服务器。您甚至可以在不将整个应用程序移至 AWS 的情况下执行此操作。我建议先阅读 this blog post。
设置看起来不错。然而，我会做一个改变：你的大量上传和下载。由于移动速度可能不理想，您应该避免让您的应用服务于 运行 长的请求，因为这会不必要地占用服务器线程。相反，请考虑让用户使用预签名 URL 直接从 S3 上传和下载。然后，您可以稍后在经济上合理的情况下将 CloudFront 添加到组合中。
R53 可以很好地为每个最终用户挑选最佳服务器。
对于 EC2，请考虑设置 ELB + Auto-Scaling 组。即使只是一个实例，您也可以获得永久健康监控和自动重生的好处。如果您期望更多负载，则可以根据预期的瓶颈（cpu、网络 i/o）自动缩放。与根据您自己的监控分析手动放大和缩小相比，这将为您提供更加自主和稳健的设置（即使如果您坚持使用不可变的基础架构和 blue/green 部署，扩展部分非常容易 Boxfuse 个报价）。
这是一组问题，而不是一个非常具体的问题。在最后一对 weeks/days 中，我对如何在“云中”正确托管 JAVA PLAY 应用程序的信息感到困惑，因为很多信息分散在不同的服务中，我想收集所有这些小块对一，因为很多事情在完整的上下文中很重要。但是，我将我的考虑移到了问题的底部，因为它们主要是我的意见和主观发现，我不想对此负责。如果我有什么不对的地方，请随时指出。
在 AWS 上托管 Java PLAY + MySQL 以实现全球访问
我们的场景： 我们在 Java PLAY 框架 (https://www.playframework.com/) 中编写了一个非常简单的应用程序，正在 iOS和 Android 以及后端系统（用于管理、内容管理和 API），将数据存储在 MySQL 数据库中。虽然大多数用户与服务器的交互都快速而简单（登录、同步一些数据），但也有一些数据密集型任务（下载一些 <100mb 的数据压缩包到手机 phone，上传几个mb 到服务器）。因此，我们一直在寻找一种解决方案，为远离我们服务器的用户提供合理的响应时间。显而易见的下一步是在云中托管。
AWS 内的托管设置：
水平缩放： 首先，我们的应用程序只有 1 个 EC2 实例 运行ning 在 eu-1a 中。我们将需要评估一个实例实际需要多少资源，是否需要更多实例，以及更多实例是否真正有益于更快的响应时间。
跨区域水平扩展：一旦应用程序从另一个区域产生大量用户负载，应复制整个 EC2 实例并放到另一个区域，运行ning数据库只读副本（参见 Setting up a globally available web app on amazon web services and 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/etc。可能我们也会在这里努力。
全局重定向： 使用 Amazon Route 53 (?) 完成。来自 Tokio 的用户应该被重定向到亚洲的 EC2 实例 运行ning；从罗马到欧洲的 EC2 实例的用户。这不仅会影响应用内的 API 调用，还会影响内容交付（双向）。
关于设置的开放问题
- 这个设置是决定性的吗？我是否缺少关键组件？
- 关于全局重定向：Amazon Route 53 是正确的工具吗？它与 CloudFront（我觉得它纯粹用于内容/媒体分发？）有何不同？
- 如何为我的应用程序定义正确的 data/api 端点？当然，我不想在应用程序部署期间定义数据库只读副本的数据库端点。在 AR53（问题 2）设置期间也会发生这种情况吗？ API 调用也是如此，当然应用程序应该将它的调用定向到 https://myurl.com/api 并且应该从那里重定向。这现实吗？
我非常感谢各种想法 (!)，也包括下面写的背景信息。如果您能指点我进一步阅读以自行解决我的问题，我也非常感谢 - 有大量关于此的信息，但这使得很难缩小答案范围。我确实有 hosting/servers 方面的知识，但我很确定那里有真正的专家等着用知识来打击我。 :)
背景资料
当前主机设置： 负载均衡器将流量分配到 2 个根 linux 服务器上，它们都 运行 运行 PLAY 应用程序，其中一个他们还持有 MySQL 安装。
当前的托管设置有 3 个大缺陷：
- 没有垂直可扩展性：托管公司会为每个扩展步骤付费。目前服务器 运行 处于闲置状态，但如果应用程序蓬勃发展，我们可能会很快 运行 出现容量不足的情况。 运行 闲置仍然支付，就好像永久处于满负荷状态一样。这个好贵！
- 不支持部署：目前，我们通过 SSH 连接，手动将正确的文件夹部署到文件系统，在服务器上重新编译，设置权限，应用数据库演化；对第二台服务器执行相同操作（具有不同的数据库连接参数）。可能会出什么问题。 ;)
- 没有全球可用性：在世界的另一个地区设置另一个服务器将意味着巨大的努力。可以完成我们数据库的同步副本，但再次部署将意味着停机时间、错误空间以及时间和金钱。
Java PLAY 的托管选项： 关于这个有很多不同的博客文章。简而言之：
- AWS：Amazon Web Services 是您最先开始寻找的地方之一。在这里，您可以以灵活的价格获得一切可能的东西。您自己设置了一个 EC2 实例、一个 MySQL RDS，一切顺利 - 所有这些都在免费套餐中，因此您可以试验、玩耍、测试您的东西。
- Microsoft Azure：在定价和可能性方面类似于 AWS。但是，我没有深入研究为测试目的设置和部署我们的应用程序。
- Heroku：从 PLAY 中部署超级简单，可扩展的服务器。然而（乍一看？）无法为偏远地区提供高速内容。
- Jelastic：在 PLAY / IntelliJ IDEA 中更容易部署。您将您的应用程序图像推送到 jelastic，jelastic 将其进一步分发给他们的基础设施提供商。
- RedHat OpenShift (https://www.openshift.com/)：听起来很有前途，但不如 AWS 完整。
很多选择和可能 setups/prices。尤其是在了解了使用 boxfuse (https://cloudcaptain.sh/) 进行部署之后，我选择了 AWS，因为它从一个来源提供了我们所需的一切。 Boxfuse 每月费用低廉，但已完美集成到 AWS 中。支持缩放以及 3 种常见环境 (dev/test/prod)。支持非常出色。
您对垂直服务器扩展的关注可能无法在 AWS 上很好地为您服务。我会开始考虑在 Elastic Load Balancer 后面横向扩展应用程序服务器，并且可能会研究 Elastic Beanstalk。
我不确定您是否可以通过 RDS 在另一个区域设置只读副本，您可能必须在标准 EC2 实例上通过 MySQL 服务器 运行 进行设置.即使可以，那也将是一些昂贵且高延迟的数据传输。
如果你担心的只是文件上传和下载，你只需要将CloudFront（Amazon的CDN服务）放在你的应用程序前面，让它通过它来处理文件上传和下载全球边缘服务器。您甚至可以在不将整个应用程序移至 AWS 的情况下执行此操作。我建议先阅读 this blog post。
设置看起来不错。然而，我会做一个改变：你的大量上传和下载。由于移动速度可能不理想，您应该避免让您的应用服务于 运行 长的请求，因为这会不必要地占用服务器线程。相反，请考虑让用户使用预签名 URL 直接从 S3 上传和下载。然后，您可以稍后在经济上合理的情况下将 CloudFront 添加到组合中。
R53 可以很好地为每个最终用户挑选最佳服务器。
对于 EC2，请考虑设置 ELB + Auto-Scaling 组。即使只是一个实例，您也可以获得永久健康监控和自动重生的好处。如果您期望更多负载，则可以根据预期的瓶颈（cpu、网络 i/o）自动缩放。与根据您自己的监控分析手动放大和缩小相比，这将为您提供更加自主和稳健的设置（即使如果您坚持使用不可变的基础架构和 blue/green 部署，扩展部分非常容易 Boxfuse 个报价）。