我正在尝试制作简单的应用程序并将其部署在 Google Cloud Platform灵活应用引擎上，其中包含两个主要部分:
- 前端应用程序(基于 Java 8 (Spring + Thymeleaf) 的简单 Web UI，具有来自不同外部站点的 OAuth 授权)
- 后端应用程序(根据登录的用户监控单独线程中的多个资源并以某种方式对其输入使用react(行为变化))
Initially I was planning to make them as one app, but I think that potentially heavy background processing may cause failures in my front end application part + App Engine docs says that deployed services behave similar to microservice architecture.
我的问题是:
- 如果我需要尽快对用户输入使用react，我真的需要将前端与后端分开吗？ (但最多 2 秒的延迟并不那么重要)
- 如果我确实需要将它们分开(并且我坚信我需要这样做) - 如何在应用程序之间设置交互？
- 每项资源必须由后端的一个线程精确跟踪 - 对此的最佳实践是什么？我考虑过使用一个包含已获取资源列表的 SQL 表，但我看到的缺陷是，如果实例失败，我将需要对该表进行某种清理并重新确定实际获取了哪些资源。
最佳答案
您提出的架构听起来是将两者分离为不同服务的正确方法，原因如下:
- 可以分别为每个版本部署代码、单独回滚版本以及单独拆分流量以进行实验或分阶段部署。
可以调整每个服务的机器类型和内存分配，以更好地满足其需求。如果您在后端执行内存密集型工作，则可以调整该服务的设置以为每个实例分配更多内存。
允许每种类型的服务根据需求独立扩展，这样可以更好地利用服务并减少浪费。与尝试在单一整体服务中采用一刀切的方法相比，这也应该会降低您的总体支出。
您可以跨服务混合不同的运行时环境。例如，您可以在项目中混合语言运行时，或者甚至可以在标准环境和灵活环境之间混合。假设您的前端代码在标准中更具成本效益，请将该服务指定为标准环境服务，将后端指定为灵活环境服务。或者说您需要一个包含 Perl 的客户 docker 文件，您可以将其作为灵活的环境自定义运行时并使用 Java 8 来实现前端。
您仍然可以共享常见服务，例如 Cloud SQL、PubSub、Cloud Tasks(目前处于 Alpha 版)或用于内存缓存的 Redis。您的作品不必驻留在 App Engine 中，如果更适合您的需求，它们可以驻留在不同的产品中。
总体而言，您可以更好地控制应用程序并将其拆分。最大的好处可能归结为优化您的应用程序，仅将支出用于您需要的内容。
关于java - 谷歌云平台: are my architectural solutions correct?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/46507296/