ARCHITECTURE PRACTICE / 01
技术实践示例 · 非客户案例从一个业务模块开始，设计一条可验证、可回退、可交接的改造路径。
以下背景、架构与实施安排均为示例设计，未声明客户经历、上线事实或实测性能结果。
01 / CONTEXT
假设一个已有研发团队的 SaaS 系统：账户、订单与后台管理集中在同一应用中，共用数据库，通过手工操作发布。随着业务迭代，模块间依赖和发布协调成为需要评估的问题。
先检查模块化整理、数据库优化与发布自动化能否解决问题。只有在独立迭代或扩展确有需要时，才推进服务拆分。
负责约定范围内的架构评估、试点工程、交付流水线设计与交接说明。
提供业务规则与现有系统信息，参与边界评审、业务改造和验收，决定上线窗口。
此处为协作建议；实际职责、访问权限及交付边界应在项目开始前明确。
02 / ARCHITECTURE
目标架构示意。箭头表示主要请求或事件方向，不代表所有服务都必须拆分。
发布流程依赖手工操作
日志缺少统一请求关联
迁移过程中避免服务绕过接口直接访问彼此数据；数据切换、事件一致性与回滚条件需要单独设计。Redis 仅在明确的缓存场景引入。
选择依赖较少、验收明确的业务模块作为试点，先建立接口契约，再迁移实现。
YARP 承接入口路由；消息队列用于确有异步协作需求的流程，配套幂等、重试和补偿设计。
先实现可重复的容器化部署。是否使用 Kubernetes，取决于服务规模及团队运维能力。
03 / IMPLEMENTATION
梳理模块依赖、数据归属、部署步骤及故障排查流程。记录发布耗时等基线，明确试点目标。
阶段产物：依赖清单、风险清单、试点范围建立服务骨架、认证接入、网关路由与接口契约。保留现有系统入口和必要的兼容策略。
阶段产物：可运行骨架、路由与认证配置迁移约定的业务流程，验证接口兼容、数据归属与一致性；为切换失败设计回退条件。
阶段产物：试点服务、数据迁移与补偿方案贯通构建、镜像、部署与健康检查，关联日志和链路，在测试环境演练发布失败与回滚。
阶段产物：流水线、观测配置、演练记录完成业务验收后再决定生产切换，约定观察窗口与回退责任人，交接源码、配置和操作文档。
阶段产物：验收清单、上线方案、交接手册04 / VALIDATION
以下为预期目标与验收方式，尚无实测结果，不作为效果承诺。
| 预期目标 | 如何验证 | 应留存的依据 |
|---|---|---|
| 部署流程标准化 | 通过同一流水线完成约定环境的构建与部署 | 流水线配置、构建与发布记录 |
| 试点服务独立发布 | 仅更新试点服务，检查保留模块及关键业务流程 | 版本记录、回归验证清单 |
| 请求可追踪 | 用同一 Trace ID 关联入口、服务与日志，演示一次故障排查 | 链路截图、排查过程记录 |
| 失败可回退 | 在测试环境演练发布失败与恢复，检查数据兼容性 | 回滚记录、数据核对结果 |
| 团队可以接手 | 由团队成员按文档独立完成一次部署与排查 | 操作手册、交接确认清单 |
上线周期、发布耗时及故障定位改善，应在真实项目中记录前后数据后再对外展示。本示例不预设改善比例。
YOUR NEXT STEP
从现有架构和发布流程开始，讨论适合你的改造路径。