Per user feedback, the relationships of the 4 new services to the existing backend are different than previously described:
- admin: SHARES database with current system (direct DB connection, not API). Access control via DB account/RBAC.
- review: CALLED BY current backend (gateway/assetservice invokes its API for submission; result returns via callback/message/shared table)
- ai-image-gen: CALLED BY current backend (gateway originally called MiniMax directly, now calls ai-image-gen's API)
- ai-chat: CALLED BY current backend/frontend (extracted from aichatservice)
Section 1.3 rewritten to make this distinction explicit.
Section 11.4.3 expanded to describe the different cross-namespace patterns:
- admin: no API calls, connects to same RDS via ExternalName
- review: needs cross-ns Dubbo to read content from each group
- ai-image-gen / ai-chat: receive calls, may indirectly call userservice via short DNS
This also has implications for the data-layer multi-tenancy in §11.4.4 — admin still needs group_id to filter across groups when reading the shared DB.
Fixed 7 issues found during self-audit:
1. §4.2.4: stale reference to '$4.2.5 旧内容' (that section is now Secrets, not healthcheck). Pointed to §10.4 instead.
2. §6 Step 3: wrong cross-reference §10.2 (which is Secret strategy). Should be §10.1 (image registry).
3. §5 directory tree: hpa was duplicated in both gateway/ and hpa/. Unified to single hpa/ directory.
4. §5 directory tree: .gitignore was placed under k8s/. Moved indication to repo root with clearer comment.
5. §5 principles: added '关注点分离' (separation of concerns) for HPA/Ingress/Secret dirs.
6. §6 Step 4: title was '灰度切换' (gradual cutover) but content said 'single namespace, all traffic switched at once'. Renamed to '流量切换'.
7. §6 Step 4 + Step 5: sequence sync step was duplicated with unclear timing. Consolidated into Step 4 as a hard blocker. Step 5 now just stops VM.
8. §4.4 (data layer multi-tenancy): duplicated §11.4.4. Deleted §4.4; kept pointer in §4.3.
9. §3 comparison table: '后续按组隔离成本' for B was undersold as 'low (helm values)'. Corrected to '中' with reference to §11.5 (~2-3 months).
Advisory items left as-is (not blocking): §1.1 '腰部明星' line, §11.4.3 '方式 2' detail.
Per user feedback, split into two phases:
Phase 1 (this task): Merged deployment to reduce cost. All services in single topfans namespace, single gateway, external DB (RDS/ElastiCache), HPA for high-load services. Focus on getting off single VM and using K8s elasticity.
Phase 2 (future, not in this task): Per-group namespace isolation. Triggered by scale/isolation needs. Sketch included as future reference.
Removed from this spec (moved to Phase 2 or out of scope):
- per-group namespace architecture (was the original main design)
- ResourceQuota / LimitRange
- per-group gateway with cross-ns Dubbo
- application-layer group_id changes
- new services (admin/review/ai-*) implementation
Updated:
- Section 0: New 'Phased Strategy' section at top
- Section 2: Three candidates reframed for Phase 1 (don't migrate / single-namespace / per-group from day 1)
- Section 4: Detailed design is now single-namespace with all services merged
- Section 5: Single chart (topfans/) instead of two (topfans-shared + topfans-group)
- Section 6: Migration plan is Phase 1 only
- Section 10: Refinements trimmed to Phase 1-relevant items
- Section 11 (NEW): Phase 2 future design sketch for reference
Per user feedback: admin/review/ai-image-gen/ai-chat are completely new independent systems with their own codebases and DBs, not reusing existing services. They only have API-level calls between each other and to existing services. Section 1.3 table and 'key clarification' paragraph updated. Other 'shared' references in the document refer to the platform-architecture sense (shared services for all groups), not code reuse, so no other changes needed.
Three approaches analyzed (single-tenant, hybrid, full-isolation), with detailed pros/cons comparison. Recommended: shared platform services + per-group data services isolation via namespaces and Helm chart.
