代码架构优化顾问

结构优化方案

基于现状与目标，建议将“模块化单体”演进为“平台化内核 + 领域微服务”的架构。遵循单一职责、数据归属唯一、边界清晰、事件驱动优先的原则，结合多租户隔离与插件化扩展能力。

1. 平台内核（Platform Layer）

• Shared Kernel（极薄内核）
  • 职责：仅包含无业务语义的跨服务基元与约定，如 TenantId、UserId、OrgId、ResourceId、时间/分页模型、错误编码、事件信封格式、幂等键、追踪上下文。
  • 约束：不承载业务类型（User/Org 实体定义不得进入内核），避免服务间耦合。
• 通用基础设施
  • Messaging：统一事件总线抽象与消息规范（主题命名、分区键=TenantId、重试与死信策略）。
  • API Gateway/BFF：对外路由与协议适配、流量分级与金丝雀发布、跨租户隔离控制。
  • Observability：日志/指标/追踪的统一基建、租户级 SLO 视图。
  • Feature Flags：租户级开关，支持微服务切换与回退。
  • Policy/Config：租户级限流、配额与配置下发。

2. 身份与权限（IAM）

• 职责：认证（OIDC/Token）、租户解析（TenantContext）、统一授权策略（RBAC/ABAC，资源级与作用域级）。
• 接口：同步鉴权决策（低延迟）、异步事件（用户/角色/组织变更）。
• 数据归属：用户、组织、成员关系、角色与策略存储。
• 解耦要点：业务服务只依赖权限查询接口与令牌校验，不直接 import IAM 类型。

3. 租户与组织（Tenant/Org Service）

• 职责：租户生命周期（开通、配额、关停）、组织/工作区元数据。
• 接口：租户变更事件、配额与合规标签下发。
• 数据归属：租户、组织、工作区主数据。
• 说明：与 IAM 相邻但分离，避免单体化的“core”。

4. 工作协同域（Work Management）

• 职责：项目/任务/评论等核心协同对象的完整生命周期与权限判定挂钩点。
• 接口：
  • 同步：任务读写、查询。
  • 异步：ProjectCreated、TaskUpdated、CommentAdded 等领域事件。
• 数据归属：项目、任务、评论、状态流转、标签等。
• 说明：保持与计费、搜索、通知的弱耦合，通过事件驱动交互。

5. 文件与媒体（File/Media）

• 职责：对象存储元数据、权限校验、病毒扫描/合规检查、临时访问令牌。
• 接口：文件上传授权（同步）、FileUploaded 等（异步）。
• 数据归属：文件元信息、版本、内容指针。
• 说明：与搜索（索引）、审计（访问日志）通过事件解耦。

6. 搜索与索引（Search）

• 职责：多索引（项目/任务/文件等）构建与查询、按租户隔离索引或别名。
• 接口：仅查询为同步；索引构建全异步订阅领域事件。
• 数据归属：二级索引数据（可重建，不为权威真相源）。
• 说明：不暴露内部 schema，避免上游耦合。

7. 通知（Notification）

• 职责：站内、邮件、Webhook、移动推送；偏好与抑制策略；按租户限流与模板化。
• 接口：对上订阅事件，对外渠道驱动。
• 数据归属：通知模板与发送日志。

8. 计费与订阅（Billing/Subscription）

• 职责：套餐/价格、订阅状态、用量计量、结算与对账、发票与税务区域规则。
• 接口：
  • 同步：查询订阅、额度核验（低延迟）。
  • 异步：SubscriptionChanged、UsageReported 等。
• 数据归属：套餐、订阅、发票、用量记录。
• 说明：成为首个拆分的独立服务；通过事件对齐与反腐层避免与业务数据的耦合。

9. 合规与审计（Compliance/Audit）

• 职责：不可篡改审计日志、数据访问与变更追踪、保留策略与导出。
• 接口：写入为异步，查询受限；支持法律保留。
• 数据归属：审计日志与证据链。

10. 插件平台（Plugin Platform）

• 职责：插件注册/签名校验、能力声明（UI 扩展点、Webhook、事件订阅、数据读写能力）、沙箱与配额。
• 接口：事件下发/回调；细粒度权限委托。
• 数据归属：插件清单、租户安装与配置、审计轨迹。
• 说明：先以事件/Webhook 与 UI 扩展为主，后期增加安全的服务内扩展点。

11. 共享内核与公用模块约束

• Shared Kernel：仅保留非业务基元、事件信封与上下文类型。
• Anti-Corruption Layer（ACL）：各服务对外暴露契约（API/事件）与内部模型隔离；禁止共享 dto/* 与业务实体类型。
• Utils/Tenant 替换为 Tenant Context 平台库（纯上下文解析与传播，无业务逻辑）。

多租户隔离策略（数据/缓存/队列一致贯彻）

• 数据隔离
  • 短期：单库多租户，所有表强制 TenantId，启用行级安全（RLS）与租户级唯一约束。严禁跨服务外键，改为应用层约束与引用快照。
  • 中期：按租户热度分片（哈希/范围基于 TenantId），项目/任务等高写入域优先分片。为大租户提供独立 schema 或库（同构迁移）。
  • 长期：关键服务（Billing、Audit）可独立库与备份策略；敏感数据加密分离。
• 缓存隔离
  • 统一前缀：{tenant}:{service}:{resource}:{key}；租户级 TTL/配额/限流；对高敏感域支持物理实例隔离或命名空间隔离。
• 队列隔离
  • 事件信封包含 TenantId、Idempotency-Key、Schema-Version；以 TenantId 作为分区键，保障租户内有序与背压独立；必要时为大租户独立主题或消费组。

跨服务通信与鉴权

• 通信协议
  • 同步：内部推荐 gRPC 或轻量 REST（幂等键、超时/重试、熔断）；仅用于读与必要的强一致查询。
  • 异步：事件驱动为主，Outbox + CDC 或事务消息，确保“写主库 + 发事件”的最终一致。
• 合约与版本
  • 事件 Schema 固化与向后兼容（版本号/演进策略）；同步接口采用语义版本与兼容窗口；消费方本地校验器与死信策略。
• 鉴权
  • 统一令牌携带 TenantId、Scopes、资源范围；服务间采用短寿命服务令牌与 mTLS；策略评估集中于 IAM（外加本地缓存），各服务执行本地强制访问控制。

依赖关系图

现状（关键耦合与循环）：

graph LR
  A[api] --> B[billing]
  B --> C[core]
  C --> B
  A --> C
  A --> D[project]
  D --> C
  A --> E[file]
  A --> F[search]
  A --> G[notification]
  subgraph Shared
    H[utils/tenant.ts]
    I[dto/*]
  end
  A --> H
  B --> H
  C --> H
  D --> H
  E --> H
  F --> H
  G --> H
  A --> I
  B --> I
  C --> I
  D --> I
  E --> I
  F --> I
  G --> I
  subgraph Infra
    J[infra/message]
  end
  D --> J
  F --> J

目标（平台化内核 + 解耦微服务）：

graph LR
  subgraph Platform
    P1[API Gateway/BFF]
    P2[Messaging]
    P3[Observability]
    P4[Feature Flags]
    P5[Shared Kernel (IDs, Envelope, Errors)]
  end

  subgraph Identity
    I1[IAM]
    I2[Tenant/Org]
  end

  subgraph Domain
    W[Work Management<br/>(Project/Task/Comment)]
    F[File/Media]
    S[Search]
    N[Notification]
    B[Billing/Subscription]
    A[Audit/Compliance]
    X[Plugin Platform]
  end

  P1 --> I1
  P1 --> W
  P1 --> F
  P1 --> S
  P1 --> N
  P1 --> B

  I1 -.-> W
  I1 -.-> F
  I1 -.-> B
  I2 -.-> W

  W -- events --> P2
  F -- events --> P2
  B -- events --> P2
  P2 -- subscribe --> S
  P2 -- subscribe --> N
  P2 -- subscribe --> A
  P2 -- subscribe --> X

  W --> P5
  F --> P5
  B --> P5
  S --> P5
  N --> P5
  A --> P5
  I1 --> P5
  I2 --> P5

  classDef dashed stroke-dasharray: 5 5
  linkStyle 7,8,9,10,11,12 stroke-dasharray: 5 5

依赖约束规则

• 只允许面向 Shared Kernel 的依赖；禁止跨域直接依赖业务模型。
• 服务间同步调用经 API Gateway 或内部服务发现，强制超时/重试与幂等。
• 领域协作优先用事件；搜索、通知、审计仅消费事件，不做主写入路径。

重构策略

阶段化演进与回退可控，优先解决高耦合与高风险点（计费、循环依赖、共享 DTO、外键、鉴权散落）。

阶段 0：基线与护栏

• 建立租户级 Feature Flags、流量路由与观测（错误率、延迟、事件堆积、租户热点）。
• 统一 TenantContext 中间层替换 utils/tenant.ts（仅上下文解析与传播）。
• 规范事件信封、主题命名、幂等键与死信策略；为 monolith 配置 Outbox。
• 测试基线：外部依赖替换为可控模拟；引入契约测试（API 与事件）。

阶段 1：去循环与 API 解耦

• 取消 api 直接 import billing，改为经网关调用与事件交互；在 monolith 内先以接口适配层替代直接引用。
• 拆分 core：将 User/Org 从 core 中抽离到 IAM 与 Tenant/Org；其他服务只消费其契约。
• 逐步移除 dto/* 跨模块共享，改为各服务自定义输入/输出契约与映射层（ACL）。
• 将内存事件替换为统一消息总线；先镜像发布（内存 + 总线）验证一致性，再切换只用总线。

阶段 2：计费服务优先拆分（高风险高收益）

• 数据边界：
  • 计费独立存储（库/Schema），作为权威真相源；业务侧不再存放计费状态。
  • 去除跨模块外键：改为引用快照与一致性校验任务。
• 交互模式：
  • 用量上报与订阅变更通过事件；额度校验走同步低延迟接口（带缓存和降级）。
• 发布策略：
  • 双写/影子读：在 monolith 中保留读路径，逐步切换至服务调用；异常时可回退。
  • 按租户灰度：先小租户再大租户，设定失败阈值触发自动回退。
• 回退预案：
  • 功能开关切回 monolith 路径；事件消费保留但不生效（幂等吞吐）；保留数据镜像窗口。

阶段 3：搜索与文件拆分

• 搜索：全面改为事件驱动索引；读路径由 Gateway 直达 Search；失败可回退到 monolith 搜索实现或降级为 DB 查询。
• 文件：文件元数据与访问控制独立；上传授权与扫描异步化；对审计与通知发事件；回退保持旧直传路径。

阶段 4：通知与审计服务

• 通知：标准化模板、租户偏好与配额；消费领域事件触发；渠道失败独立重试与死信监控。
• 审计：写入仅异步，WORM 存储策略；全链路操作产生审计事件；查询受限与索引优化。回退不影响主交易路径。

阶段 5：IAM/权限集中化与路由收口

• 将分散权限中间件聚合到 IAM 策略服务；各服务执行本地校验并定期拉取策略快照。
• BFF/Gateway 收口外部入口，聚合跨服务查询；移除 api 模块对各服务的直接引用。

阶段 6：数据库与外键治理

• 跨服务外键全部下线，替换为应用层约束、引用快照、定期一致性校验任务与修复流程。
• 引入按租户分片策略；为大租户提供独库/独 schema 迁移工具（在线迁移、双写校验、回滚计划）。

阶段 7：插件平台

• 第一阶段提供事件订阅与 Webhook、UI 扩展点；租户级安装与权限委托；限流与配额。
• 第二阶段引入受控执行环境（沙箱），暴露有限能力集与审计。

阶段 8：测试与运维成熟度

• 契约测试覆盖率达标；引入事件回放与幂等审计工具。
• SLO 落地：按服务与按租户双维度；容量与背压策略完善。

关键风险与控制

• 数据一致性：全部跨服务写入采用 Outbox + 事件驱动；同步接口仅用于读或校验；Saga/编排仅限必要场景（如订阅升级）。
• 兼容窗口：事件与 API 保持双版本兼容窗口；消费者先行升级，生产者后切换。
• 回退策略：功能开关、路由回切、降级读、事件重放；计费等关键域保留只读逃生通道。
• 热点租户：分区键为 TenantId，消费组按租户扩展；热点租户可独立主题与缓存命名空间。
• 外部服务：与第三方集成全部经适配层，支持模拟/隔离环境与熔断降级。

短期可落地清单（2–4 周）

• 建立 Shared Kernel、TenantContext、Messaging 标准；替换内存事件。
• 解除 api→billing 直依，拆 core 的 User/Org 到 IAM/Tenant 合约。
• 去共享 DTO，建立 ACL 映射层雏形。
• 为计费域补齐 Outbox、事件契约与用量上报通道；开启影子发布。
• 汇总权限中间件到统一鉴权中间层，形成迁移路径。

中期（1–3 个月）

• 完成 Billing 独立服务化与灰度/回退方案；搜索、文件抽离；通知与审计上线。
• 去跨模块外键、引入一致性校验作业；分片策略落地。
• Gateway/BFF 全量接管对外请求路由与聚合查询。

长期（3–6 个月）

• 插件平台第一阶段上线；大租户独库/独 schema 迁移工具与流程完善。
• 权限策略集中化与缓存；全链路 SLO、容量与成本优化。

总结

• 明确边界：以 Shared Kernel 为最薄内核，围绕 IAM、Tenant/Org、Work、File、Search、Notification、Billing、Audit、Plugin 切分服务，每个服务拥有自己的权威数据与契约。
• 系统性解耦：取消跨服务共享 DTO 与直接依赖，采用 ACL 与事件驱动；用 Outbox 确保最终一致性；同步只用于必要读与校验。
• 多租户隔离：统一在数据、缓存、队列三层按 TenantId 隔离；支持热租户独立与分片扩展。
• 可控演进：以计费为切分突破口，配合灰度、影子发布与功能开关的回退方案；逐步迁出搜索/文件/通知/审计；清退跨模块外键。
• 可操作性：给出阶段化路线、风险点与控制手段，确保在不影响现有业务的前提下，持续提升可维护性、扩展性与合规性。

结构优化方案

• 热点链路与耦合问题定位

  • 写入链路热点
    • agg 使用 ORM 逐条 upsert，形成 N+1 往返与大量索引随机写，成为“落库延迟 5–8s”的首要放大器。
    • stream 与 agg 通过 common 的工具相互 import，形成隐式耦合，难以独立演进写入策略。
  • 查询链路热点
    • query 每次请求解码全量告警规则并串行执行“缓存→数据库”，导致 P99 2.8s 高尾延迟。
    • 告警规则引擎与查询共进程、共享线程池与连接池，产生抖动与资源争抢。
    • 批作业与在线查询共用连接池，引入“外部干扰流量”，放大尾延迟。
  • 工程与可观测性短板
    • common 既含 DTO 又含落库工具，跨层穿透，形成双向依赖。
    • 缺少端到端追踪与性能基线，改造无回归护栏、无法量化收益。

• 模块划分与职责边界（目标形态）

  1. domain-contracts
     • 职责：跨进程稳定契约（事件/DTO/查询与告警规则模型、版本与兼容策略）。
     • 边界：只含纯模型与接口定义，禁止任何存储、网络与工具实现。
  2. ingest
     • 职责：HTTP/MQ 接入、限流/鉴权、粗粒度排队与分片键计算；只向 stream 输出标准化事件。
     • 边界：与 stream 仅通过事件契约与消息通道交互。
  3. stream
     • 职责：清洗、校验、轻度规则预过滤（非状态性）、时间戳与设备字段标准化。
     • 边界：只向 agg 发规范化事件；不直接写库。
  4. agg
     • 职责：按设备与时间窗口聚合、窗口内去重与归并、分片缓冲与批量落库；负责写入策略与幂等。
     • 边界：通过 repository-writer 与底层存储交互；不依赖 query 或规则实现。
  5. repository-writer（新）
     • 职责：面向写入的存储访问层，提供分区感知、批量 upsert/merge、回压与重试策略；屏蔽 ORM 逐条写。
     • 边界：只被 agg 使用；不暴露给 stream/query。
  6. repository-reader（新）
     • 职责：只读的数据访问层，提供时间范围扫描、二级索引查询、分页与限流；独立连接池与只读账号。
     • 边界：只被 query 使用；与 writer 物理/逻辑隔离。
  7. query-api
     • 职责：GraphQL/REST 查询与仪表盘接口；采用多级缓存（L1 进程内、L2 分布式）；并行/竞速读取策略。
     • 边界：不包含规则引擎执行；通过 rules-service 获取已编译规则快照与增量变更。
  8. rules-service（新）
     • 职责：告警规则管理、解析与编译、依赖图与触发条件维护；对 query 提供只读已编译视图。
     • 边界：独立进程与线程池；通过事件或流式接口向 query 推送规则变更。
  9. batch-jobs（新）
     • 职责：离线回填、重算、重建索引与归档；独立连接池与资源配额，避免影响在线。
  10. cache-layer（新）
      • 职责：统一缓存抽象（键空间、失效策略、二级缓存、热点保护），兼容读写旁路与写后缓存。
  11. observability
      • 职责：端到端追踪、指标与日志规范；提供请求/写入/队列与窗口级别的 SLI/SLO 采集。

• 数据模型与存储设计（与模块配合）

  • 热表/冷表分层
    • 热表：承载最近 N 小时数据，优化写入（尽量少索引、聚簇主键、顺序追加/批量合并）。
    • 冷表：周期性搬迁历史数据，建立更丰富的查询索引，降低热表写入放大与成本。
  • 分区与主键建议
    • 时间桶 + 设备/分片键的复合主键；窗口对齐写入，减少碎片。
    • 写路径只维护必要索引；查询使用覆盖索引或物化索引表。
  • 二级索引与物化索引表
    • 面向常用过滤维度（设备、标签、规则分组）构建稀疏二级索引或独立索引表，减少主表扫描。
    • 仅在冷层或异步构建，避免阻塞写入。
  • 去重与幂等
    • 聚合窗口内基于事件指纹去重；落库采用“窗口键 + 设备键”幂等合并策略。
  • TTL 与归档
    • 热层短 TTL + 归档任务；降低存储成本与查询路径写入放大。

依赖关系图

• 现状（问题态）

graph LR
  A[ingest] --> B[stream]
  B --> C[agg]
  C -->|ORM 逐条写| D[(DB)]
  E[query] --> D
  E --> F[rules engine(同进程)]
  F --> E
  G[batch jobs] --> D
  subgraph common
    H[DTO+写库工具]
  end
  B --> H
  C --> H
  E --> H
  E -->|串行:缓存→DB| I[Cache]
  E -.->|解码全量规则/每次| F

• 目标（解耦态）

graph LR
  A[ingest] --> B[stream]
  B --> C[agg]
  C --> J[repository-writer]
  J --> D[(Storage: 热/冷)]
  E[query-api] --> K[repository-reader]
  K --> D
  E --> I[L2 Cache]
  E --> L[L1 Cache]
  M[rules-service] -->|已编译规则快照/增量| E
  N[batch-jobs] --> D
  subgraph domain-contracts
    O[事件/DTO/规则契约]
  end

  A-->O; B-->O; C-->O; E-->O; M-->O
  style J fill:#eef,stroke:#55f
  style K fill:#eef,stroke:#55f
  style M fill:#efe,stroke:#2a2
  style O fill:#ffd,stroke:#aa0

重构策略

• 阶段化计划与优先级

  • Phase 0 基线与可观测性（最高优先级，低风险）
    • 建立端到端追踪：ingest→stream→agg→writer→DB→reader→query，全链路 span 与关键标签（设备/分片/窗口）。
    • 指标与基线：采集写入延迟（窗口结束到持久化）、队列滞留、批大小、DB 等待、查询 P50/P95/P99、缓存命中率、规则加载耗时。
    • 压测与回归护栏：固定典型看板与规则集作为基准场景，形成对照曲线。
  • Phase 1 快速收益（改动小，收益大）
    • query 路径
      • 规则“预解析+版本化快照”：进程内持久化已编译规则，按版本增量更新，禁止每请求全量解码。
      • 读路径并行与降尾：L1 与 L2/DB 采用竞速策略与超时切换；热门看板结果短 TTL 缓存；对长查询启用分片并行。
      • 资源隔离：query 与 rules-service 进程/线程池隔离；reader 使用独立只读连接池与账号。
    • 写入路径
      • agg 引入内存窗口缓冲与批量提交接口（经 repository-writer），减少 N+1。
    • 作业隔离：batch-jobs 使用独立连接池与限速器，避免冲击在线。
    • 预期影响：查询 P99 显著下降（尾延迟降低），写入稳定性提升（抖动减少）。
  • Phase 2 写入策略与数据模型优化（中风险，显著收益）
    • repository-writer 落地批量 upsert/merge、幂等键与回压策略；按设备或时间桶分片缓冲，批量落库。
    • 热/冷分层：将现有大表按时间分区与热表策略切分；热表仅保留必要索引。
    • 二级索引策略：把高频过滤维度迁至物化索引表或稀疏索引，异步构建/更新。
    • 预期影响：落库延迟从秒级高位收敛到低秒/亚秒级批次提交；成本下降（索引写放大降低）。
  • Phase 3 规则与查询解耦（中等复杂度）
    • rules-service 独立服务化：维护已编译规则与依赖图；向 query 通过推送或拉取接口暴露快照与增量。
    • 查询端只做规则匹配与读操作；规则执行重活转移至服务或预计算通道。
    • 预期影响：查询路径 CPU 降低、抖动减少，容量提升。
  • Phase 4 结构固化与扩展（长期）
    • 按分片/租户水平扩展：ingest/stream/agg/query 的无共享扩容。
    • 冷数据归档与再索引流水线自动化；离峰重建索引。
    • 成本优化：冷热数据比例、缓存层大小、批大小与分区大小调优。

• 解耦与依赖治理清单

  • common 改造为 domain-contracts（纯模型/契约）与 infra-utils（仅工具，不可被业务层依赖）。
  • 引入 ports-adapters（接口/实现）分层：stream/agg/query 只依赖接口，具体存储由 repository-* 提供。
  • 通过消息通道/事件契约解耦 ingest→stream→agg 的运行时关系，禁止跨层直接 import 写库工具。
  • 资源隔离
    • 连接池：reader/writer/batch 三套物理池与账号；设置请求配额与突发限制。
    • 线程池：query、规则、批作业独立线程池与队列；设置最大排队与拒绝策略。
  • 缓存策略
    • 多级缓存：L1（进程内短 TTL）+ L2（分布式）；明确键空间与失效策略。
    • 结果缓存：看板固定查询采用键规范化与时间桶对齐；启用“只缓存成功且可复用”的策略。
    • 失效：基于 CDC/事件对二级索引与结果缓存做选段失效，而非全量清空。
  • 查询优化
    • 避免串行 I/O：对远程缓存与存储采用并行/竞速；超时与重试使用幂等读语义。
    • 限流与防雪崩：热门键加抖动 TTL、请求合并、单飞保护。
  • 写入优化
    • 聚合窗口对齐写：窗口结束或批量阈值触发落库；大批次合并降低索引写放大。
    • 幂等与去重：窗口键+设备键；重复到达事件合并更新而非重复写。
    • 回压：当存储背压上升时，agg 按分片降速并扩容缓冲，防止级联雪崩。

• 回归风险控制

  • 迁移策略
    • 双写/影子写：新写路径与旧路径并行，比较窗口级聚合结果与落库延迟，达到阈值后切流。
    • 影子读：query 在后台调用新 reader 与新索引，比较行数/聚合值与延迟分布，不影响用户响应。
    • 分片灰度：按租户/设备分片逐步切换；失败自动回滚到旧路径。
  • 正确性校验
    • 聚合一致性：对比窗口汇总、计数与去重率；定义阈值报警。
    • 规则一致性：新旧规则执行结果抽样比对（命中数/触发延迟）。
  • 压测与容量
    • 基于基准看板与规则集的回归压测；记录 P50/P95/P99 与成本指标（CPU、IO）。
    • 连接池与线程池的上限保护，防止资源耗尽。
  • 可观测性门槛
    • 若无追踪/指标采集，禁止执行下一阶段改造。
    • 变更前后需有至少一周对照数据。

• 分阶段性能提升目标（预期区间）

  • Phase 1：缓存与并行读、资源隔离
    • 查询 P99 预期下降 30–50%；抖动显著降低。
    • 写入尾延迟受 N+1 影响仍然较高，但稳定性提升。
  • Phase 2：批量写与热表
    • 落库延迟预期下降 40–70%，收敛到低秒级；成本随索引写放大下降而降低。
  • Phase 3：规则服务化
    • 查询 CPU 与平均耗时再降 15–30%；P99 进一步改善。
  • Phase 4：水平扩展与归档
    • 在相同成本下吞吐提升，尾延迟在高负载下保持稳定。

总结

• 通过把 common 拆分为 domain-contracts 与独立的 repository-* 层，消除了跨层耦合与循环依赖，使 stream/agg/query 仅依赖稳定契约。
• 在写入侧用批量聚合与热/冷表分层，配合最小化索引与幂等合并，直击 ORM N+1 与高写放大的根因，显著降低落库延迟与成本。
• 在查询侧以规则快照化、并行/竞速读与多级缓存，加上读写资源完全隔离，显著降低 P99 与抖动。
• 以可观测性为前置护栏，采用双写/影子读、灰度与自动回滚，管理结构性改造的回归风险。
• 最终形态实现模块职责清晰、依赖单向化、资源隔离与数据分层，支持秒级延迟目标与成本可控的持续扩展。