Java 谷歌云平台：我的架构解决方案正确吗？

我正在尝试制作一个简单的应用程序，并将其部署在Google云平台Flexible App Engine上，它将包含两个主要部分：

前端应用程序（基于Java8（Spring+Thymeleaf）的简单Web UI，具有来自不同外部站点的OAuth授权）

后端应用程序（基于登录的用户，在单独的线程中监视多个资源，并以某种方式对其输入作出反应（行为更改））

最初，我计划将它们作为一个应用程序进行开发，但我认为，潜在的繁重后台处理可能会导致我的前端应用程序出现故障。部分应用程序引擎文档称，已部署的服务的行为类似于微服务体系结构

我的问题是：

如果我需要尽快对用户输入做出反应，我真的需要将前端和后端分开吗？（但最长延迟2秒并不重要）

如果我确实需要将它们分开（我坚信我是这样做的），那么如何设置应用程序之间的交互

每个资源必须由后端上的一个线程精确跟踪-关于这一点的最佳实践是什么？我曾考虑过使用一个包含已获取资源列表的SQL表，但我看到的缺陷是，如果一个实例失败，我需要对该表进行某种清理，并重新确定实际获取的资源

我认为您很可能能够将所有东西部署为appengine应用程序，除非您使用一些未列入白名单的外来Java库。为了增加可配置性和多功能性，最好将其与计算引擎一起部署

您可以在compute engine中创建一个前端实例和一个后端实例，并像这样在它们之间分配资源。谷歌的文档中有一个例子，你可以这样做

我认为您很可能能够将所有东西部署为appengine应用程序，除非您使用一些未列入白名单的外来Java库。为了增加可配置性和多功能性，最好将其与计算引擎一起部署

您可以在compute engine中创建一个前端实例和一个后端实例，并像这样在它们之间分配资源。谷歌的文档中有一个例子，你可以这样做

---

出于以下原因，您提出的体系结构似乎是将这两种服务划分为不同服务的正确方法：

• 可以分别为每个版本部署代码，分别回滚版本，并分别拆分流量以进行实验或分阶段推出
• 可以调整每项服务的机器类型和内存分配，以更好地满足其需求。如果您正在后端执行内存密集型工作，则可以调整该服务的设置，以便为每个实例分配更多内存

• 允许每种类型的服务根据需求独立扩展，从而更好地利用服务，减少浪费。这也应该会降低您的总体开支，而不是在单个单一服务中尝试“一刀切”的方法

• 您可以跨服务混合不同的运行时环境。例如，您可以在项目中混合使用语言运行时，甚至可以在标准和灵活的环境中混合使用。假设您的前端代码在标准中更具成本效益，将该服务指定为标准环境服务，将您的后端指定为灵活的环境服务。或者说，您需要一个包含Perl的customer docker文件，您可以将其作为一个灵活的环境自定义运行时来实现，并使用Java 8作为前端

• 您仍然可以共享诸如云SQL、PubSub、云任务（当前为alpha）或Redis等用于内存缓存的公共服务。您的作品不需要驻留在App Engine中，如果它更适合您的需要，它们可以驻留在不同的产品中

---

总的来说，您可以更好地控制应用程序以将其分离。最大的好处可能是优化您的应用程序，使其只用于您需要的东西。

您提出的体系结构听起来是将两者分离为不同服务的正确方法，原因如下：

• 可以分别为每个版本部署代码，分别回滚版本，并分别拆分流量以进行实验或分阶段推出
• 可以调整每项服务的机器类型和内存分配，以更好地满足其需求。如果您正在后端执行内存密集型工作，则可以调整该服务的设置，以便为每个实例分配更多内存

• 允许每种类型的服务根据需求独立扩展，从而更好地利用服务，减少浪费。这也应该会降低您的总体开支，而不是在单个单一服务中尝试“一刀切”的方法

• 您可以跨服务混合不同的运行时环境。例如，您可以在项目中混合使用语言运行时，甚至可以在标准和灵活的环境中混合使用。假设您的前端代码在标准中更具成本效益，将该服务指定为标准环境服务，将您的后端指定为灵活的环境服务。或者说，您需要一个包含Perl的customer docker文件，您可以将其作为一个灵活的环境自定义运行时来实现，并使用Java 8作为前端

• 您仍然可以共享诸如云SQL、PubSub、云任务（当前为alpha）或Redis等用于内存缓存的公共服务。您的作品不需要驻留在App Engine中，如果它更适合您的需要，它们可以驻留在不同的产品中

总的来说，您可以更好地控制应用程序以将其分离。最大的好处可能是优化你的应用程序，只在你需要的东西上花费。

关于你的评论：1。贾弗