Apollo 3.0.0 发布说明深度解读Portal OpenAPI 全面迁移、用户令牌体系与 ServerConfig 多集群管理【免费下载链接】apolloApollo is a reliable configuration management system suitable for microservice configuration management scenarios.项目地址: https://gitcode.com/gh_mirrors/apoll/apolloApollo 3.0.0 是一次以管理面 API 化为主线的大版本升级Portal 的全部管理型 UI 操作从内部 WebAPI 迁移到 OpenAPI v1新增面向 AI Agent 与自动化的用户访问令牌User Token体系并让 ConfigDB 的 ServerConfig 支持按key cluster粒度管理。本文基于 CHANGES.md 中 3.0.0 版本的 22 条变更记录逐主题展开并结合仓库源码说明每一项变更的实际实现位置、默认行为与升级注意事项帮助运维和二次开发者评估升级影响面、快速启用新能力。版本基线Spring Boot 4.x 与 Java 17CHANGES.md 中 3.0.0 共包含两次基线升级记录先是将 Apollo Server 基线迁移到 Spring Boot 4.0.x 并对齐 Spring Cloud 服务发现集成PR 5585随后进一步升级到 Spring Boot 4.1.1 与 Spring Cloud 2025.1.3PR 5671。当前仓库根 pom.xml 中的属性可以确认最终基线revision3.0.0-SNAPSHOT即 3.0.0 开发线java.version17spring-boot.version4.1.1spring-cloud.version2025.1.3spring-cloud-alibaba.version2025.1.0.0配套 Java SDKapollo-java.version2.5.0从源码结构看3.0.0 的模块组成与 2.x 保持一致apollo-common、apollo-biz、apollo-configservice、apollo-adminservice、apollo-portal、apollo-assembly并新增了apollo-audit多模块审计子工程和apollo-build-sql-converter构建模块这也与本版引入的审计日志 OpenAPI 端点相呼应。官方包默认改用数据库服务发现3.0.0 的一个重要行为变更是官方发布的 Config/Admin 包默认改为数据库database服务发现。对从旧版 Eureka 方式部署升级而来的用户CHANGES.md 明确给出迁移约束——需要显式保留githubprofile 才能维持旧的服务发现行为。仓库中apollo-biz模块的registry包提供了多种注册中心实现eureka包仍保留 Eureka 相关配置类从源码结构看默认发现方式的切换正是在这一层完成的。与之配套CI 侧新增了外部服务发现冒烟工作流external discovery smoke workflow仓库中对应 e2e/discovery-smoke 目录包含run-smoke.sh与provider.sh脚本用于验证外部注册中心场景下的服务连通性。升级提示如果你此前依赖 Eureka 作为官方部署形态的服务发现升级前请先检查启动 profile保留githubprofile 或同步切换为数据库发现否则升级后 ConfigService/AdminService 之间的互相发现方式会发生变化。Portal 管理操作全面迁移至 OpenAPI这是 3.0.0 中数量最多、影响面最大的一组变更PR 5608–5618CHANGES.md 按领域分列了五个阶段Portal OpenAPI 迁移适配 apollo-openapi v0.2.0PR 5608配置项config itemUI 操作迁移到 OpenAPIPR 5610命名空间namespace核心 UI 操作迁移PR 5612发布release、分支branch、实例instanceUI 操作迁移PR 5616权限permission与 AccessKey UI 操作迁移PR 5617至此完成全部 Portal UI 管理操作迁移PR 5618。源码层面可以验证这条演进路线。PortalManagementController.java 是承接 Portal 管理类端点的新控制器它直接实现 OpenAPI 生成的接口PortalManagementApi并标注OpenAPI v1 controller for Portal UI-only management endpoints。同一个openapi/v1包下还有 AppController.java、NamespaceController.java、ItemController.java、NamespaceBranchController.java、AccessKeyController.java、ClusterController.java 等十余个控制器覆盖了 CHANGES.md 列出的各迁移领域。旧的内部 WebAPI 控制器则被统一标记为废弃但保留兼容。以 ServerConfigController.java 为例类上的注释写明/** * deprecated Portal UI uses /openapi/v1 endpoints. This legacy WebAPI controller is kept for * compatibility. */ Deprecated RestController public class ServerConfigController { ... }也就是说 3.0.0 采取的是新端点先行、旧端点冻结的策略Portal 前端请求走/openapi/v1旧的/server/...等路径仍可用为存量集成留出了过渡期。此外审计能力也在同一迁移中接入 OpenAPI——PortalManagementController注入了ApolloAuditLogApi与ApolloAuditProperties提供审计属性查询、审计日志分页搜索、按操作名/traceId/字段影响查询等超管端点与 apollo-audit 子模块annotation、api、impl、spring-boot-starter 四件套配套。权限语义修复超管纳入 hasAnyPermissionCHANGES.md 第一条修复PR 5568是让hasAnyPermission语义包含超级管理员。从源码结构看权限判定集中在 UnifiedPermissionValidator.java 及其PreAuthorize调用链上PortalManagementController中大量使用unifiedPermissionValidator.isSuperAdmin()/isAppAdmin(#appId)等表达式。该修复的意义在于此前若权限校验逻辑通过是否持有任何命名空间权限来放行部分操作超管在特定路径下可能不被识别修复后超管在hasAnyPermission语义下与持有任意权限的用户等价消除了管理类 API 对超管的漏判。Consumer Token 获得管理 Portal 用户的授权角色PR 5623 允许被显式授权的 consumer token 管理 Portal 用户。在PortalManagementController的createConsumer方法中可以看到对应的授权开关创建 consumer 时若请求体中allowManageUsers为 true则调用consumerService.assignManageUsersRoleToConsumer(...)为该 token 分配管理用户角色allowCreateApplication同理。该角色机制由 ConsumerRole 实体承载使机器身份consumer token在受控范围内可代管账号而不再仅限于读写配置。ServerConfig 支持按 key cluster 管理UI 具备集群感知PR 5601 让 ConfigDB 管理端的 ServerConfig 支持按key cluster创建/更新/删除并在 UI 上做到集群感知、补充了多集群安全测试。源码中有两处直接证据新版 OpenAPI 端点PortalManagementController中删除 ConfigDB 配置的方法签名携带了cluster参数PreAuthorize(value unifiedPermissionValidator.isSuperAdmin()) ApolloAuditLog(type OpType.DELETE, name ServerConfig.deleteConfigDBConfig) public ResponseEntityVoid deleteConfigDBConfig(String env, String key, String cluster) { requirePortalUserRequest(); serverConfigService.deleteConfigDBConfig(parseEnv(env), key, cluster, currentUserId()); return ResponseEntity.ok().build(); }旧的 ServerConfigController.java 中deleteConfigDBConfig同样接收key与cluster两个参数说明 cluster 维度在旧端点上同步补齐。值得注意的是PortalManagementController.validateServerConfig要求key与value均非空否则抛BadRequestException所有写操作都叠加了PreAuthorize(unifiedPermissionValidator.isSuperAdmin())与ApolloAuditLog审计注解。也就是说ServerConfig 的写权限收敛到超管且每次增删改都会落审计日志。AccessKey 自动签发新应用创建即获得每环境可用的 AccessKeyPR 5589 是 3.0.0 中一个对集成方非常实用的新特性创建新应用时可为每个环境自动签发一个已启用的 AccessKey由 ConfigDB 中ApolloConfigDB.ServerConfig表的apollo.access-key.auto-provision.enabled开关控制。配置项定义在 BizConfig.javapublic boolean isAccessKeyAutoProvisionEnabled() { return getBooleanProperty(apollo.access-key.auto-provision.enabled, false); }默认值为false即不启用升级不会改变现有行为。启用路径在 AppController.javaAdminService 的/apps创建端点adminService.createNewApp(entity)创建应用若bizConfig.isAccessKeyAutoProvisionEnabled()为 true则构造默认 AccessKeysecret 由UniqueKeyGenerator.generateId()生成、模式固定为AccessKeyMode.FILTER、enabled置为true操作人取值有回退链优先dataChangeCreatedBy其次dataChangeLastModifiedBy最后回落到ownerName关键点自动签发失败不会导致建应用失败异常仅被记录为 warn 日志Failed to auto-provision access key for appId...保证主流程的健壮性。对应的测试覆盖了开关默认关闭、开启后的建应用行为见 BizConfigTest.java 及 ControllerExceptionTest.java。配合本版的另一个权限修复看应用创建即自动具备 OpenAPI 访问凭证 consumer token 可被授权管理用户共同降低了机器接入 Apollo 的门槛。用户访问令牌User Token为 AI Agent 与自动化场景提供身份PR 5632 引入了面向 AI Agent 与自动化脚本的用户访问令牌PR 5637 则修复了限流场景下的响应行为——超限时返回 429 状态码而不是重定向到登录页这对程序化调用方是明确的协议约束。令牌的全生命周期管理在PortalManagementController中通过/openapi/v1/user-tokens端点族暴露源码位置端点方法说明权限/openapi/v1/user-tokensGET列出当前用户自己的令牌登录用户/openapi/v1/user-tokensPOST创建令牌名称、operations、appIds、envs、namespaces、rateLimit、expires登录用户/openapi/v1/user-tokens/{tokenId}/rotatePOST轮换令牌登录用户/openapi/v1/user-tokens/{tokenId}/revokePOST吊销令牌登录用户/openapi/v1/user-tokens/{tokenId}DELETE删除令牌登录用户/openapi/v1/user-tokens/capabilitiesGET查询可用操作集与默认/最大过期天数登录用户/openapi/v1/user-tokens/adminGET超管查询全量令牌可按 userId、status 过滤超管/openapi/v1/user-tokens/admin/{tokenId}/revoke、DELETE .../admin/{tokenId}—超管吊销/删除任意令牌超管几个实现细节值得注意作用域Scope令牌可限定appIds、envs和按环境划分的namespaces范围UserTokenNamespaceScope并可声明允许执行的operations集合能力边界通过/capabilities端点动态查询userTokenDefaultExpireDays/userTokenMaxExpireDays来自 Portal 配置 PortalConfig审计与元信息令牌摘要中带有lastUsedTime、lastUsedIp、lastUsedUserAgent以及吊销人与吊销时间实体层对应 UserToken.java 与 UserTokenAudit.java认证链请求侧由 UserTokenAuthenticationFilter.java 完成令牌认证并写入 Spring Security 上下文UserTokenAuthenticationToken权限判定由UserTokenPermissionValidator等组件按操作范围校验。这套机制让人用浏览器、Agent 用令牌成为一等公民自动化脚本、CI 流水线或 LLM 驱动的工具可以以受限、可吊销、可审计的令牌身份操作 Portal而不必借用某个人的会话。认证与身份OIDC 用户名声明可配置PR 5655 增加了spring.security.oidc.user-id-claim-name配置允许在 OIDC 登录场景下显式指定从 ID Token 中取哪个 claim 作为 Apollo 用户身份user id。此前用户身份默认绑定固定的 claim当企业 IdP 的 username 字段并非默认 claim 名时只能靠改代码适配该配置项使 Portal 用户登录扩展参见 用户登录功能扩展文档在 OIDC 场景下可直接配置完成无需定制。数据层与存储发布历史物理清理、严格格式校验与撤销改进3.0.0 在数据治理上有四条记录均能对应到仓库中的具体实现物理删除保留的发布历史与无引用 release 行PR 5641。与 BizConfig.java 中的两个配置项配套apollo.release-history.retention.size保留条数上限默认-1表示不限制DEFAULT_RELEASE_HISTORY_RETENTION_SIZE -1启用后取值范围为[1, MAX]apollo.release-history.retention.size.overrideJSON 形式的按 appId 覆盖配置例如可按应用单独调大保留量解析时值必须 0非法 JSON 只记录 error 日志并返回空 map不会中断服务。仓库中还提供了一整套存量数据迁移脚本 scripts/sql/migration/release-history-retention按预检需恢复的 release → 预检软删行 → 恢复被引用 release → 物理清除软删行四步组织01-precheck-releases-needing-restore.sql…04-purge-soft-deleted-rows.sql目录内 README.md 说明执行顺序。从源码结构看这套脚本与物理删除特性配套用于在启用清理策略前修正历史软删数据避免误删仍被引用如回滚目标的 release。撤销未发布变更时保留 item 类型PR 5646与支持非 properties 命名空间撤销未发布变更PR 5656。这两项作用于 Commit 撤销链路AdminService 的 CommitController.java修复了撤销操作导致 item 的 type 字段丢失的问题并把撤销能力从仅 properties 格式扩展到 yaml/json 等非 properties 命名空间。权威保存路径上的严格 JSON/YAML 合法性校验PR 5660。此前格式合法性可能依赖客户端或展示层本版在最终落库的保存路径上做了严格的 well-formedness 校验防止非法 JSON/YAML 内容进入命名空间——这是配合非 properties 命名空间能力扩张撤销、JSON 视图等的数据正确性兜底。Portal 增加格式化与原始 JSON 双视图PR 5657。json 格式命名空间在 Portal 中同时提供 formatted 与 raw 两种查看方式方便既需要可读结构又需要精确原文的场景。升级与迁移清单结合 CHANGES.md 与源码从 2.x 升级到 3.0.0 时建议按以下清单核对运行环境JDK 17、Spring Boot 4.1.1 / Spring Cloud 2025.1.3 基线依赖 Spring 生态的二次开发插件需确认与 Boot 4.xjakarta 命名空间的兼容服务发现默认改为数据库发现沿用 Eureka 的官方部署需显式保留githubprofileAPI 集成前端与脚本如直接调用 Portal 旧版 WebAPI/server/...等仍可工作已标记Deprecated但保留兼容但建议规划切换到/openapi/v1端点以对齐 apollo-openapi v0.2.0 的契约新能力开关apollo.access-key.auto-provision.enabledConfigDB ServerConfig默认 false按需开启发布历史保留策略通过apollo.release-history.retention.size默认 -1 不启用与 override 配置项开启自动化身份为 Agent/流水线创建受限 User Token 并定期 rotate利用 429 限流语义做客户端退避数据库迁移启用发布历史清理前按 release-history-retention 迁移目录 中的脚本顺序执行预检与数据修正。相关入口变更记录原文CHANGES.md各历史版本明细见 changes/ 目录changes-1.9.0.md 至 changes-2.5.0.md版本基线pom.xmlPortal OpenAPI 管理控制器PortalManagementController.java服务端配置项中心BizConfig.java用户令牌过滤器UserTokenAuthenticationFilter.java外部服务发现冒烟测试e2e/discovery-smoke【免费下载链接】apolloApollo is a reliable configuration management system suitable for microservice configuration management scenarios.项目地址: https://gitcode.com/gh_mirrors/apoll/apollo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Apollo 3.0.0 发布说明深度解读：Portal OpenAPI 全面迁移、用户令牌体系与 ServerConfig 多集群管理
Apollo 3.0.0 发布说明深度解读Portal OpenAPI 全面迁移、用户令牌体系与 ServerConfig 多集群管理【免费下载链接】apolloApollo is a reliable configuration management system suitable for microservice configuration management scenarios.项目地址: https://gitcode.com/gh_mirrors/apoll/apolloApollo 3.0.0 是一次以管理面 API 化为主线的大版本升级Portal 的全部管理型 UI 操作从内部 WebAPI 迁移到 OpenAPI v1新增面向 AI Agent 与自动化的用户访问令牌User Token体系并让 ConfigDB 的 ServerConfig 支持按key cluster粒度管理。本文基于 CHANGES.md 中 3.0.0 版本的 22 条变更记录逐主题展开并结合仓库源码说明每一项变更的实际实现位置、默认行为与升级注意事项帮助运维和二次开发者评估升级影响面、快速启用新能力。版本基线Spring Boot 4.x 与 Java 17CHANGES.md 中 3.0.0 共包含两次基线升级记录先是将 Apollo Server 基线迁移到 Spring Boot 4.0.x 并对齐 Spring Cloud 服务发现集成PR 5585随后进一步升级到 Spring Boot 4.1.1 与 Spring Cloud 2025.1.3PR 5671。当前仓库根 pom.xml 中的属性可以确认最终基线revision3.0.0-SNAPSHOT即 3.0.0 开发线java.version17spring-boot.version4.1.1spring-cloud.version2025.1.3spring-cloud-alibaba.version2025.1.0.0配套 Java SDKapollo-java.version2.5.0从源码结构看3.0.0 的模块组成与 2.x 保持一致apollo-common、apollo-biz、apollo-configservice、apollo-adminservice、apollo-portal、apollo-assembly并新增了apollo-audit多模块审计子工程和apollo-build-sql-converter构建模块这也与本版引入的审计日志 OpenAPI 端点相呼应。官方包默认改用数据库服务发现3.0.0 的一个重要行为变更是官方发布的 Config/Admin 包默认改为数据库database服务发现。对从旧版 Eureka 方式部署升级而来的用户CHANGES.md 明确给出迁移约束——需要显式保留githubprofile 才能维持旧的服务发现行为。仓库中apollo-biz模块的registry包提供了多种注册中心实现eureka包仍保留 Eureka 相关配置类从源码结构看默认发现方式的切换正是在这一层完成的。与之配套CI 侧新增了外部服务发现冒烟工作流external discovery smoke workflow仓库中对应 e2e/discovery-smoke 目录包含run-smoke.sh与provider.sh脚本用于验证外部注册中心场景下的服务连通性。升级提示如果你此前依赖 Eureka 作为官方部署形态的服务发现升级前请先检查启动 profile保留githubprofile 或同步切换为数据库发现否则升级后 ConfigService/AdminService 之间的互相发现方式会发生变化。Portal 管理操作全面迁移至 OpenAPI这是 3.0.0 中数量最多、影响面最大的一组变更PR 5608–5618CHANGES.md 按领域分列了五个阶段Portal OpenAPI 迁移适配 apollo-openapi v0.2.0PR 5608配置项config itemUI 操作迁移到 OpenAPIPR 5610命名空间namespace核心 UI 操作迁移PR 5612发布release、分支branch、实例instanceUI 操作迁移PR 5616权限permission与 AccessKey UI 操作迁移PR 5617至此完成全部 Portal UI 管理操作迁移PR 5618。源码层面可以验证这条演进路线。PortalManagementController.java 是承接 Portal 管理类端点的新控制器它直接实现 OpenAPI 生成的接口PortalManagementApi并标注OpenAPI v1 controller for Portal UI-only management endpoints。同一个openapi/v1包下还有 AppController.java、NamespaceController.java、ItemController.java、NamespaceBranchController.java、AccessKeyController.java、ClusterController.java 等十余个控制器覆盖了 CHANGES.md 列出的各迁移领域。旧的内部 WebAPI 控制器则被统一标记为废弃但保留兼容。以 ServerConfigController.java 为例类上的注释写明/** * deprecated Portal UI uses /openapi/v1 endpoints. This legacy WebAPI controller is kept for * compatibility. */ Deprecated RestController public class ServerConfigController { ... }也就是说 3.0.0 采取的是新端点先行、旧端点冻结的策略Portal 前端请求走/openapi/v1旧的/server/...等路径仍可用为存量集成留出了过渡期。此外审计能力也在同一迁移中接入 OpenAPI——PortalManagementController注入了ApolloAuditLogApi与ApolloAuditProperties提供审计属性查询、审计日志分页搜索、按操作名/traceId/字段影响查询等超管端点与 apollo-audit 子模块annotation、api、impl、spring-boot-starter 四件套配套。权限语义修复超管纳入 hasAnyPermissionCHANGES.md 第一条修复PR 5568是让hasAnyPermission语义包含超级管理员。从源码结构看权限判定集中在 UnifiedPermissionValidator.java 及其PreAuthorize调用链上PortalManagementController中大量使用unifiedPermissionValidator.isSuperAdmin()/isAppAdmin(#appId)等表达式。该修复的意义在于此前若权限校验逻辑通过是否持有任何命名空间权限来放行部分操作超管在特定路径下可能不被识别修复后超管在hasAnyPermission语义下与持有任意权限的用户等价消除了管理类 API 对超管的漏判。Consumer Token 获得管理 Portal 用户的授权角色PR 5623 允许被显式授权的 consumer token 管理 Portal 用户。在PortalManagementController的createConsumer方法中可以看到对应的授权开关创建 consumer 时若请求体中allowManageUsers为 true则调用consumerService.assignManageUsersRoleToConsumer(...)为该 token 分配管理用户角色allowCreateApplication同理。该角色机制由 ConsumerRole 实体承载使机器身份consumer token在受控范围内可代管账号而不再仅限于读写配置。ServerConfig 支持按 key cluster 管理UI 具备集群感知PR 5601 让 ConfigDB 管理端的 ServerConfig 支持按key cluster创建/更新/删除并在 UI 上做到集群感知、补充了多集群安全测试。源码中有两处直接证据新版 OpenAPI 端点PortalManagementController中删除 ConfigDB 配置的方法签名携带了cluster参数PreAuthorize(value unifiedPermissionValidator.isSuperAdmin()) ApolloAuditLog(type OpType.DELETE, name ServerConfig.deleteConfigDBConfig) public ResponseEntityVoid deleteConfigDBConfig(String env, String key, String cluster) { requirePortalUserRequest(); serverConfigService.deleteConfigDBConfig(parseEnv(env), key, cluster, currentUserId()); return ResponseEntity.ok().build(); }旧的 ServerConfigController.java 中deleteConfigDBConfig同样接收key与cluster两个参数说明 cluster 维度在旧端点上同步补齐。值得注意的是PortalManagementController.validateServerConfig要求key与value均非空否则抛BadRequestException所有写操作都叠加了PreAuthorize(unifiedPermissionValidator.isSuperAdmin())与ApolloAuditLog审计注解。也就是说ServerConfig 的写权限收敛到超管且每次增删改都会落审计日志。AccessKey 自动签发新应用创建即获得每环境可用的 AccessKeyPR 5589 是 3.0.0 中一个对集成方非常实用的新特性创建新应用时可为每个环境自动签发一个已启用的 AccessKey由 ConfigDB 中ApolloConfigDB.ServerConfig表的apollo.access-key.auto-provision.enabled开关控制。配置项定义在 BizConfig.javapublic boolean isAccessKeyAutoProvisionEnabled() { return getBooleanProperty(apollo.access-key.auto-provision.enabled, false); }默认值为false即不启用升级不会改变现有行为。启用路径在 AppController.javaAdminService 的/apps创建端点adminService.createNewApp(entity)创建应用若bizConfig.isAccessKeyAutoProvisionEnabled()为 true则构造默认 AccessKeysecret 由UniqueKeyGenerator.generateId()生成、模式固定为AccessKeyMode.FILTER、enabled置为true操作人取值有回退链优先dataChangeCreatedBy其次dataChangeLastModifiedBy最后回落到ownerName关键点自动签发失败不会导致建应用失败异常仅被记录为 warn 日志Failed to auto-provision access key for appId...保证主流程的健壮性。对应的测试覆盖了开关默认关闭、开启后的建应用行为见 BizConfigTest.java 及 ControllerExceptionTest.java。配合本版的另一个权限修复看应用创建即自动具备 OpenAPI 访问凭证 consumer token 可被授权管理用户共同降低了机器接入 Apollo 的门槛。用户访问令牌User Token为 AI Agent 与自动化场景提供身份PR 5632 引入了面向 AI Agent 与自动化脚本的用户访问令牌PR 5637 则修复了限流场景下的响应行为——超限时返回 429 状态码而不是重定向到登录页这对程序化调用方是明确的协议约束。令牌的全生命周期管理在PortalManagementController中通过/openapi/v1/user-tokens端点族暴露源码位置端点方法说明权限/openapi/v1/user-tokensGET列出当前用户自己的令牌登录用户/openapi/v1/user-tokensPOST创建令牌名称、operations、appIds、envs、namespaces、rateLimit、expires登录用户/openapi/v1/user-tokens/{tokenId}/rotatePOST轮换令牌登录用户/openapi/v1/user-tokens/{tokenId}/revokePOST吊销令牌登录用户/openapi/v1/user-tokens/{tokenId}DELETE删除令牌登录用户/openapi/v1/user-tokens/capabilitiesGET查询可用操作集与默认/最大过期天数登录用户/openapi/v1/user-tokens/adminGET超管查询全量令牌可按 userId、status 过滤超管/openapi/v1/user-tokens/admin/{tokenId}/revoke、DELETE .../admin/{tokenId}—超管吊销/删除任意令牌超管几个实现细节值得注意作用域Scope令牌可限定appIds、envs和按环境划分的namespaces范围UserTokenNamespaceScope并可声明允许执行的operations集合能力边界通过/capabilities端点动态查询userTokenDefaultExpireDays/userTokenMaxExpireDays来自 Portal 配置 PortalConfig审计与元信息令牌摘要中带有lastUsedTime、lastUsedIp、lastUsedUserAgent以及吊销人与吊销时间实体层对应 UserToken.java 与 UserTokenAudit.java认证链请求侧由 UserTokenAuthenticationFilter.java 完成令牌认证并写入 Spring Security 上下文UserTokenAuthenticationToken权限判定由UserTokenPermissionValidator等组件按操作范围校验。这套机制让人用浏览器、Agent 用令牌成为一等公民自动化脚本、CI 流水线或 LLM 驱动的工具可以以受限、可吊销、可审计的令牌身份操作 Portal而不必借用某个人的会话。认证与身份OIDC 用户名声明可配置PR 5655 增加了spring.security.oidc.user-id-claim-name配置允许在 OIDC 登录场景下显式指定从 ID Token 中取哪个 claim 作为 Apollo 用户身份user id。此前用户身份默认绑定固定的 claim当企业 IdP 的 username 字段并非默认 claim 名时只能靠改代码适配该配置项使 Portal 用户登录扩展参见 用户登录功能扩展文档在 OIDC 场景下可直接配置完成无需定制。数据层与存储发布历史物理清理、严格格式校验与撤销改进3.0.0 在数据治理上有四条记录均能对应到仓库中的具体实现物理删除保留的发布历史与无引用 release 行PR 5641。与 BizConfig.java 中的两个配置项配套apollo.release-history.retention.size保留条数上限默认-1表示不限制DEFAULT_RELEASE_HISTORY_RETENTION_SIZE -1启用后取值范围为[1, MAX]apollo.release-history.retention.size.overrideJSON 形式的按 appId 覆盖配置例如可按应用单独调大保留量解析时值必须 0非法 JSON 只记录 error 日志并返回空 map不会中断服务。仓库中还提供了一整套存量数据迁移脚本 scripts/sql/migration/release-history-retention按预检需恢复的 release → 预检软删行 → 恢复被引用 release → 物理清除软删行四步组织01-precheck-releases-needing-restore.sql…04-purge-soft-deleted-rows.sql目录内 README.md 说明执行顺序。从源码结构看这套脚本与物理删除特性配套用于在启用清理策略前修正历史软删数据避免误删仍被引用如回滚目标的 release。撤销未发布变更时保留 item 类型PR 5646与支持非 properties 命名空间撤销未发布变更PR 5656。这两项作用于 Commit 撤销链路AdminService 的 CommitController.java修复了撤销操作导致 item 的 type 字段丢失的问题并把撤销能力从仅 properties 格式扩展到 yaml/json 等非 properties 命名空间。权威保存路径上的严格 JSON/YAML 合法性校验PR 5660。此前格式合法性可能依赖客户端或展示层本版在最终落库的保存路径上做了严格的 well-formedness 校验防止非法 JSON/YAML 内容进入命名空间——这是配合非 properties 命名空间能力扩张撤销、JSON 视图等的数据正确性兜底。Portal 增加格式化与原始 JSON 双视图PR 5657。json 格式命名空间在 Portal 中同时提供 formatted 与 raw 两种查看方式方便既需要可读结构又需要精确原文的场景。升级与迁移清单结合 CHANGES.md 与源码从 2.x 升级到 3.0.0 时建议按以下清单核对运行环境JDK 17、Spring Boot 4.1.1 / Spring Cloud 2025.1.3 基线依赖 Spring 生态的二次开发插件需确认与 Boot 4.xjakarta 命名空间的兼容服务发现默认改为数据库发现沿用 Eureka 的官方部署需显式保留githubprofileAPI 集成前端与脚本如直接调用 Portal 旧版 WebAPI/server/...等仍可工作已标记Deprecated但保留兼容但建议规划切换到/openapi/v1端点以对齐 apollo-openapi v0.2.0 的契约新能力开关apollo.access-key.auto-provision.enabledConfigDB ServerConfig默认 false按需开启发布历史保留策略通过apollo.release-history.retention.size默认 -1 不启用与 override 配置项开启自动化身份为 Agent/流水线创建受限 User Token 并定期 rotate利用 429 限流语义做客户端退避数据库迁移启用发布历史清理前按 release-history-retention 迁移目录 中的脚本顺序执行预检与数据修正。相关入口变更记录原文CHANGES.md各历史版本明细见 changes/ 目录changes-1.9.0.md 至 changes-2.5.0.md版本基线pom.xmlPortal OpenAPI 管理控制器PortalManagementController.java服务端配置项中心BizConfig.java用户令牌过滤器UserTokenAuthenticationFilter.java外部服务发现冒烟测试e2e/discovery-smoke【免费下载链接】apolloApollo is a reliable configuration management system suitable for microservice configuration management scenarios.项目地址: https://gitcode.com/gh_mirrors/apoll/apollo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考