一个共享数据库的单体系统需要拆出订单服务，但业务要求迁移期间可灰度且随时回滚；你会如何划定拆分边界并安排数据迁移步骤？

我会把这次拆分看成“业务边界治理 + 数据迁移 + 流量灰度”三个问题一起处理，重点是保证迁移过程中新旧系统可以并行运行，并且任何阶段都能回滚。

拆分边界上，我不会简单按表拆，而是先按订单领域的业务职责划分。订单服务应该负责订单创建、状态流转、取消、查询，以及订单相关的核心规则；支付、库存、履约、营销等仍然通过明确的接口或事件协作。订单服务拥有订单主数据的写权限，其他服务不能直接修改订单表。原单体中的订单相关代码、表、事务边界和上下游调用都要梳理清楚，避免把强耦合的逻辑只搬了一半，形成新的分布式事务问题。

数据迁移我一般分几个阶段：

1. 先改造单体，建立兼容层

先把订单领域代码从单体内部抽成相对独立的模块，统一订单接口和状态机，同时补齐订单变更日志、操作审计和数据校验能力。新订单服务的接口要尽量兼容原有调用方，必要时在网关或单体内部增加路由层，让调用方不需要一次性全部改造。

2. 准备新库和全量数据迁移

按订单服务的模型设计新库，完成表结构、索引、分库分表策略以及历史字段映射。先做全量迁移，迁移过程中要记录迁移批次、主键范围和校验结果。数据量较