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 專案。
後續步驟
除非另有註明，否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權，程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間：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"]],["上次更新時間：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)."]]
