Java 8 已达到支持终止期限，并将于 2026 年 1 月 31 日
弃用。弃用后，您将无法部署 Java 8 应用，即使您的组织之前曾使用组织政策重新启用旧版运行时的部署，也无法部署。现有的 Java 8 应用在
弃用日期之后将继续运行并接收流量。我们建议您
迁移到最新支持的 Java 版本。
命名开发者环境
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
云端软件项目会用到多种环境。这些环境通常使用 dev、qa、staging、prod 等名称。必须确保这些环境相互之间完全隔离，并且通常使用完全不同的操作员访问权限。例如，开发团队可能对 dev 环境具有完整访问权限，但对 prod 环境仅具有部分访问权限，且所有代码部署仅通过自动化脚本执行。此外，确保不同环境中的数据相互隔离也至关重要。
使用多个 Google Cloud 项目完全可以满足这些要求，因为这些项目可以确保代码和数据完全隔离，而且可以单独管理操作员权限。由于 App Engine 可以自动扩缩其服务实例，因此您只需要为您使用的部分付费。例如，如果您每四周中只有一周需要模拟环境，则无需支付任何服务实例在剩下三周内产生的费用。但请注意，如果您有数据存储在这些项目中，则需要支付这部分费用。
命名环境
如果您选择仅使用多项服务来创建微服务应用，则可以为每个环境创建一个 Google Cloud 项目，并相应地为其命名，例如 web-app-dev、web-app-qa 和 web-app-prod。
或者，如果您选择使用多个项目创建微服务应用，也可以在环境之间实现同样的隔离，但需要使用更多项目，例如 web-app-dev、web-app-prod、user-service-dev、user-service-prod。您将需要使用代码模式来确保 dev 项目仅调用其他 dev 项目，而 prod 项目仅调用其他 prod 项目。
后续步骤
如未另行说明，那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可，并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情，请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2025-09-04。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-09-04。"],[[["\u003cp\u003eCloud-based software projects should utilize multiple, isolated environments like \u003ccode\u003edev\u003c/code\u003e, \u003ccode\u003eqa\u003c/code\u003e, \u003ccode\u003estaging\u003c/code\u003e, and \u003ccode\u003eprod\u003c/code\u003e, each with distinct operator-access permissions.\u003c/p\u003e\n"],["\u003cp\u003eEmploying multiple Google Cloud projects provides complete isolation of code and data across different environments, allowing for separate management of operator permissions.\u003c/p\u003e\n"],["\u003cp\u003eUsing App Engine's automatic scaling ensures you only pay for serving instances when they're in use, but data storage costs still apply.\u003c/p\u003e\n"],["\u003cp\u003eMicroservice applications can create separate Google Cloud projects for each environment, such as \u003ccode\u003eweb-app-dev\u003c/code\u003e, \u003ccode\u003eweb-app-qa\u003c/code\u003e, and \u003ccode\u003eweb-app-prod\u003c/code\u003e, or they can use multiple projects for multiple services, like \u003ccode\u003euser-service-dev\u003c/code\u003e.\u003c/p\u003e\n"],["\u003cp\u003eCode patterns are required to ensure \u003ccode\u003edev\u003c/code\u003e and \u003ccode\u003eprod\u003c/code\u003e projects call other projects in the same environment.\u003c/p\u003e\n"]]],[],null,["# Naming Developer Environments\n\nCloud-based software projects should employ multiple environments. These\nenvironments typically have names like `dev`, `qa`, `staging`, and `prod`.\nIt's vital that these environments be completely isolated from one another,\nand they typically have very different operator-access permissions.\nFor example, the development team might have full access to the `dev`\nenvironment, but only limited access to the `prod` environment, with all\ncode deployment driven only by automated scripts. Further, it's\nabsolutely essential that the data in the different environments stay isolated.\n\nUsing multiple [Google Cloud projects](/resource-manager/docs/creating-managing-projects) suits these requirements perfectly\nas the projects provide complete isolation of code and data, and operator\npermissions can be managed separately. Because App Engine automatically scales\nits serving instances, you only pay for what you use. For example, if your\nstaging environment is only required one week out of every four, you won't pay\nfor any serving instance costs for the other three. However, keep in mind that\nyou will be billed for any data stored in these projects.\n\nNaming environments\n-------------------\n\nIf you choose to create your microservices application by using only multiple\nservices, you can create a single Google Cloud project for each of your\nenvironments and name them accordingly, such as `web-app-dev`, `web-app-qa`,\nand `web-app-prod`.\n\nAlternatively, if you choose to create your microservices application by\nusing multiple projects, you can achieve the same separation between\nenvironments, but you'll need to use more projects, such as\n`web-app-dev`, `web-app-prod`, `user-service-dev`, and `user-service-prod`.\nYou will need to use code patterns to ensure that the `dev` projects only\ncall other `dev` projects and the `prod` projects only call\nother `prod` projects.\n\nWhat's next\n-----------\n\n- Get an overview of [microservice architecture on App Engine](/appengine/docs/legacy/standard/java/microservices-on-app-engine).\n- Learn the [best practices for designing APIs to communicate between microservices](/appengine/docs/legacy/standard/java/designing-microservice-api).\n- Learn the [best practices for microservice performance](/appengine/docs/legacy/standard/java/microservice-performance).\n- Learn how to [Migrate an existing monolithic application to one with microservices](/appengine/docs/legacy/standard/java/microservice-migration)."]]
