双系统并行与切换窗口

双系统并行是不是两边都能接单？

并行可能指新系统只读取旧数据作对比，也可能指部分页面流量进入新系统，或不同业务范围分别由两套系统承担。必须先明确是哪一种模式。若两边同时对同一订单、付款或库存拥有写入权，就会产生冲突，不能靠后续批量同步自动消除。

对于影子核对，用户真实业务仍由原系统执行，新系统只观察经过授权的数据并比较结果。对于有限范围切换，需要把用户、商城或业务对象的归属规则写清，并验证不会跨范围混用。每种模式都应有退出条件，避免“临时并行”无限延长后形成无人掌握的双重规则。

项目不能仅以新站页面可打开判断已经进入业务并行。需要看订单在哪里生成、付款在哪个商户环境发生、仓库任务由谁发起，以及回调通知进入哪套系统。只切换前台入口而保留不明确的后台归属，会让用户看到新界面，但交易仍在两套系统之间摇摆。

哪些业务应该先留在旧系统？

待处理售后、已付款未完成履约、资金结果未知或外部任务尚未终止的业务，需要按实际条件判断。较早创建的订单可能在切换后继续退款或收到出库回执，不能简单用创建日期把它归为“历史只读”。

可以保留旧系统完成某类在途业务，再向新系统提供受控查询；也可以经核验后明确接管。接管需要带原业务编号、当前状态和未完成动作，并确保旧系统不再继续执行相同操作。客户外部系统若不能暂停或重定向通知，应提前纳入方案约束。

会员、商品和运营内容的更新也需要归属。新系统开始维护展示资料后，旧系统的后续全量导入不能无条件覆盖它。并行期间应明确哪些属性继续由旧系统提供，哪些已经由新系统维护，并保留最后应用版本或截止点，避免资料回退。

全量和增量怎么约定同一个截止点？

全量快照需要说明覆盖的业务时间或可靠游标，增量从对应位置接续。仅记录导出文件生成时间不一定能证明范围，因为导出过程可能持续一段时间，而业务仍在变化。源系统需要提供可解释的一致性方案，项目再据此制定接续方法。

增量可能包括新增、修改、停用和删除等事件。若只同步新建记录，取消订单、修改地址或注销会员等变化就会遗漏。应列出所有影响后续业务的变更类型，保存原编号和版本，并设计异常隔离与重复应用规则。

结构与业务导入也要分开。迁移资源归所属业务域，包含 SQL 与 Java Flyway 迁移；已发布迁移字节及 Java identity/checksum 需要保留，运行与迁移角色分开。 这类结构升级约束不能替代旧系统增量抽取和目标业务接续。项目应分别保留应用版本、结构状态、数据规则和输入批次，让差异能够定位到具体层次。

切换窗口应由哪些结果决定？

窗口取决于客户可接受的业务暂停方式、最后增量处理、关键对账、外部配置和岗位确认。不能在没有预演资料时承诺固定停机时长。先执行授权范围内的隔离演练，记录每个步骤的实际条件、失败原因和恢复办法，再制定正式窗口。

正式切换前，需要知道如何限制旧系统的新写入，怎样确认最后业务截止，以及新系统何时获得写入权。只改域名解析并不会自动暂停后台任务、渠道回调或仓库同步。各入口和任务必须有明确状态，才能避免暂停了消费者页面却仍在后台产生交易。

如果关键条件没有达到，应按事先约定保持原业务或退出切换。决定岗位应具有实际业务权限，技术人员提供证据，不代替财务或运营批准尚未解释的资金与库存差异。判断标准应在窗口之前确定，避免现场为了赶时间临时降低要求。

一份切换决策表应怎样记录？

以下表格组织职责和证据，所有时间与状态由实际项目填写；不是固定时效承诺。

步骤	执行前需要确认	形成的证据	由谁决定继续	失败后的动作
切换准备	版本、备份、访问与外部配合已具备	环境及资料清单	项目授权岗位	保持原系统运行并处理缺项
原系统写入限制	消费者入口、后台任务与外部调用有归属	各入口实际状态	业务与运行负责人	撤销限制或进入已批准维护方案
最后增量处理	快照与增量截止可靠	批次、游标、隔离记录	数据负责人	修正规则或补查缺口
关键核对	身份、订单、库存及资金口径一致	对账结果与差异决定	业务和财务岗位	处理差异或按条件退出
新写入开启	旧系统不会重复执行同类动作	路由、任务与回调状态	切换负责人	关闭新写入并保留已发生业务
观察与交接	未完成任务可查询、岗位可处理	运行检查和事件记录	运行与业务负责人	按原编号查证并执行恢复决定

每一步应有清楚的开始、结束和未完成状态。记录中不要放真实账号口令；配置是否有效可以通过受控位置和验证结果说明。不能把“文件已复制”当成“数据已对账”，也不能把“域名已变更”当成“新业务已验收”。

回退为什么不只是把域名改回去？

新系统一旦接受订单、付款、退款或库存动作，就产生需要保留的业务事实。将入口改回旧系统，并不会让这些动作消失。回退方案需要说明怎样接续新业务、避免重复执行资金动作，以及谁继续处理已经发出的仓库任务。

可以通过受控导出、已确认接口或限定业务范围形成接续，但每种方法都需预先验证。不能临时将新库覆盖到旧库，也不能把没有对应字段的业务忽略。回退记录应保存新系统期间的对象集合、外部编号、当前状态和后续负责系统。

对无法安全回退的阶段，应提前标注决定点及替代恢复方法。某些问题适合保持新系统运行并修复，而不是强行恢复旧入口。业务负责人应了解这些边界，实施团队提供风险和证据，双方据此决定操作，不能统一承诺所有切换随时可逆。

外部回调和晚到事件怎么安排？

付款、退款和仓库回执可能晚于入口切换。按交易所属系统、原操作编号和商户配置确定归属，不能只根据当前域名把全部事件交给新系统。接收方查询不到对象时，应保留受控隔离记录并通知指定岗位查证，而不是直接新建交易。

切换前应明确旧回调入口是否保留、由谁维护证书和网络可达性，以及多久仍需要处理旧任务。具体保留安排根据未终止业务和渠道条件确认，不设置未经核验的统一期限。外部账号更换也应检查对历史交易查询和退款能力的影响。

观察结束后如何宣布业务切换完成？

需要分别确认新业务正常、旧在途任务有归属、关键对账差异关闭，以及运行资料和权限已经交接。仍存在未执行渠道或资料缺口时，应公开保留问题，不使用“观察了一段时间没投诉”代替验收。

使用迁移字段映射与对账模板记录截止点和决策岗位，按迁移专题规划整体工作，通过迁移沟通服务确认预演与窗口条件。系统升级与回退的源码边界可在升级文档核对；旧系统接续属于客户项目工程。