Java 8 已达到支持终止期限,并将于 2026 年 1 月 31 日
弃用。弃用后,您将无法部署 Java 8 应用,即使您的组织之前曾使用组织政策重新启用旧版运行时的部署,也无法部署。现有的 Java 8 应用在
弃用日期之后将继续运行并接收流量。我们建议您
迁移到最新支持的 Java 版本。
从单体式应用迁移到微服务
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
如果要从旧版单体式应用开始迁移,您必须找出可以拆分并转移到单独微服务的部分。通常,结构良好的单体应用具有非常自然的划分,并已有服务类作为数据存储层和业务逻辑层之间的接口。这些类是将客户端调用连接到微服务的理想位置。
对单体应用中的功能进行拆分
您可以通过几种方法来拆分应用:
- 在应用中查找可以拆分的业务逻辑。
- 查找自然隔离的代码,例如使用静态代码分析工具来识别这些部分。
- 检查应用中那些采用独立的扩缩配置或内存设置可能为您带来益处的逻辑部分。这也许可以节省成本,从而更好地使用资源。
您可能需要重构代码以移除非自然依赖项。我们建议您先重构旧代码并将其部署到生产环境,然后再尝试将应用拆分为单独的服务。
微服务的常见领域包括:
- 用户或账号信息
- 授权和会话管理
- 偏好或配置设置
- 通知和通信服务
- 照片和媒体,尤其是元数据
- 任务队列工作器
迁移应用的步骤
将一组类标识为可成为微服务的候选对象后,您需要执行以下步骤:
- 保留旧版应用中的现有代码并确保其能正常运行,以便在需要时回滚。
- 创建新的代码库,或者在现有代码库中至少创建一个子目录。
- 将相应类复制到新位置。
- 编写一个视图层来提供 HTTP API 钩子,并将响应文档设置为正确的格式。
- 将新代码组织为单独的应用(创建
app.yaml
)。
- 将新的微服务部署为服务或单独的项目。
- 测试代码以确保其运行正常。
- 将数据从旧版应用迁移到新的微服务。请参阅下文了解相关讨论。
- 更改现有的旧版应用以使用新的微服务应用。
- 部署更改后的旧版应用。
- 确认一切都按预期工作,并且您不需要回滚到旧版应用。
- 从旧版应用中移除所有不再需要的代码。
在运行中的应用上迁移数据
迁移运行中的应用上的数据可能很复杂,并且与您的具体情况密切相关。通常,为便于前滚和回滚,您需要编写代码以同时填充新旧 Cloud Datastore 实体(为此,可能需要在微服务上使用临时 API),然后编写代码以迁移现有数据集(例如,编写一个 MapReduce)。此过程通常涉及一些临时代码和冗余数据。根据您的具体情况,您可能还需要在发布后执行追加数据迁移。请务必小心,不要用旧数据覆盖新数据。
尽管这项工作看似繁琐,但却十分重要,也是一种常见的做法,这样可以在无法成功切换到新的微服务时,能够进行前滚和回滚。只有在确认一切都已正确迁移并且按预期运行后,才能移除临时代码并从旧存储位置中删除数据。请务必在此过程中进行备份。
后续步骤
如未另行说明,那么本页面中的内容已根据知识共享署名 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\u003eWhen transitioning from a monolithic application to microservices, identify and separate logical business units, naturally isolated code, or parts that require different scaling configurations.\u003c/p\u003e\n"],["\u003cp\u003eRefactor legacy code within the monolithic application and deploy those changes before extracting it into microservices to ensure a smoother transition.\u003c/p\u003e\n"],["\u003cp\u003eCommon microservice candidates include user information, authorization, preferences, notifications, media, and task queue workers.\u003c/p\u003e\n"],["\u003cp\u003eMigrating to microservices involves leaving original code operational, creating new code repositories, formulating a separate application, deploying, testing, migrating data, and updating the legacy app to use the new microservice.\u003c/p\u003e\n"],["\u003cp\u003eData migration for live applications often requires temporarily populating both old and new data stores to facilitate rollback, along with potential catch-up migrations, and ensuring backups are made during the transition.\u003c/p\u003e\n"]]],[],null,["# Migrating to Microservices from a Monolithic App\n\nWhen starting with a legacy, monolithic application, you must find parts that\ncan be carved off and moved to separate microservices. Often, a well-structured\nmonolithic app will have very natural divisions, and a service class will\nalready function as an interface to a layer of data storage and business logic.\nSuch classes are the ideal place to connect the client calls to the\nmicroservice.\n\nSeparating functionality in a monolithic app\n--------------------------------------------\n\nYou could take a couple approaches for how you separate your app:\n\n- Look for business logic in your application that can be separated.\n- Find code that is naturally isolated, such as by using static code analysis tools to identify the sections.\n- Examine your application for logic that you might benefit from different scaling configuration settings or memory requirements than the rest of your application. This could possibly result in cost savings that might lead to better resource utilization.\n\nYou might need to refactor your code to remove unnatural dependencies. We\nrecommend that you perform refactoring within your legacy code and deploy it to\nproduction before attempting to separate the app into separate services.\n\nCommon areas for microservices include the following:\n\n- User or account information\n- Authorization and session management\n- Preferences or configuration settings\n- Notifications and communications services\n- Photos and media, especially metadata\n- Task queue workers\n\nSteps for Migrating an App\n--------------------------\n\nAfter a set of classes has been identified as a candidate to become a\nmicroservice, the next steps include:\n\n- Leaving the existing code in place and operational in the legacy application to facilitate rollback.\n- Creating a new code repository, or at least a sub-directory in your existing repository.\n- Copying the classes into the new location.\n- Writing a view layer that provides the HTTP API hooks and formats the response documents in the correct manner.\n- Formulating the new code as a separate application (create an `app.yaml`).\n- Deploying your new microservice as a service or separate project.\n- Testing the code to ensure that it is functioning correctly.\n- Migrating the data from the legacy app to the new microservice. See below for a discussion.\n- Altering your existing legacy application to use the new microservices application.\n- Deploying the altered legacy application\n- Verifying that everything works as expected and that you don't need to roll back to the legacy application.\n- Removing any dead code from the legacy application.\n\nMigrating data on a live application\n------------------------------------\n\nData migration on a live application can be tricky and highly dependent on your\nsituation. Often, to facilitate roll-forward and rollback, you will need to\nwrite code that populates both the old and new Cloud Datastore entities,\npossibly by using a temporary API on the microservice, and then write code that\nmigrates\nthe existing set of data, for example as a MapReduce. This process will usually\ninvolve some amount of temporary code and redundant data. Depending on the\nspecifics of your situation, you may also need to execute a catch-up data\nmigration after you release. Be careful not to overwrite newer data with older\ndata.\n\nWhile this seems like a lot of work, it's a common occurrence and is important\nto allow for rolling forward and rolling back in the event that the cutover to\nthe new microservice does not succeed. You can remove your temporary code and\ndelete the data from the old storage location only after you have verified that\neverything is migrated correctly and everything is operating as expected. Be\nsure to make backups along the way.\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- Understand how to [create and name dev, test, qa, staging, and production environments with microservices in App Engine](/appengine/docs/legacy/standard/java/creating-separate-dev-environments).\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)."]]