ARTICLE · 软件编程
硬停止规则：从 3 个 HCM 单体应用到 120 个领域微服务
一语总结Paycor 团队通过「硬停止改动单体」规则，将每次产品变更自然拆分为新领域微服务，五年内从 3 个 HCM 单体迁移到 120 多个微服务且零停机。
文章介绍了 Paycor 在没有专项迁移预算的约束下，如何用「基于拉动的迁移」策略将三个 HCM 单体应用逐步拆分为 120 多个领域微服务。核心做法是制定一条硬规则：任何涉及单体应用的改动都必须拆出独立服务，从而把迁移成本分摊到日常路线图中。文章详细拆解了三项关键平台投资：按域 Azure 订阅（实现成本归属与故障隔离）、APIM 路由层（实现无感流量切换）、带 Redis 缓存的功能开关层（支持渐进式发布与秒级回滚）。在架构层面，考勤系统通过 Service Bus + 持久化记录 + Event Hub 扇出 + 确定性回填的组合保证打卡数据不丢失；薪资系统采用双区域 Active-Active 部署。文章还分享了应对早高峰流量峰值的成本优化策略（定时预热 + 反应式扩缩 + 无服务器扇出 + 多层缓存），以及重复执行 100 多次的标准切换流程。最后，作者坦承该方法无法处理「冷角」代码（约 20%），并给出 90 天启动计划与组织层面的关键举措（代码审查门禁、架构接缝映射、前期成本指标）。
- 「硬停止改动单体」规则把迁移成本分摊到日常路线图，绕开预算竞争。
不再申请独立迁移项目，而是规定任何涉及单体的改动必须拆出服务，4 小时变 6 小时的额外成本被分摊到数百个用户故事中，五年完成 120+ 微服务迁移且零停机。
- 三项平台投资是拉动式迁移的前提：按域订阅、APIM 路由、功能开关层。
按域订阅实现成本归属与故障隔离；APIM 让客户端无感切换；带 Redis 缓存的功能开关层支持渐进式发布与秒级回滚，缺一不可。
- 考勤数据通过「队列→持久化记录→确认」保证不丢失，下游故障可确定性回填。
十个数据源先入 Service Bus 队列，写入表存储后才确认；Event Hub 扇出到四个独立消费者，每个消费者维护水印实现幂等回放，下游中断不会丢数据。
- 突发流量场景下，定时预热 + 反应式扩缩 + 无服务器扇出可将峰值成本削减约 70%。
定时规则在峰值前 15 分钟预热 AKS 容量，反应式扩缩吸收波动，Event Hub 消费者用 Azure Functions 按调用计费，避免为五分钟峰值支付全天常驻资源。
- 拉动式迁移的局限：约 20% 的「冷角」代码无人改动，永远不会自动迁移。
运行正常但无人触碰的功能不会触发拆分，需要单独项目或接受其永远留在单体中，这是该方法必须正视的边界。
硬停止规则：从 3 个 HCM 单体应用到 120 个领域微服务
文章介绍了 Paycor 在没有专项迁移预算的约束下，如何用「基于拉动的迁移」策略将三个 HCM 单体应用逐步拆分为 120 多个领域微服务。核心做法是制定一条硬规则：任何涉及单体应用的改动都必须拆出独立服务，从而把迁移成本分摊到日常路线图中。文章详细拆解了三项关键平台投资：按域 Azure 订阅（实现成本归属与故障隔离）、APIM 路由层（实现无感流量切换）、带 Redis 缓存的功能开关层（支持渐进式发布与秒级回滚）。在架构层面，考勤系统通过 Service Bus + 持久化记录 + Event Hub 扇出 + 确定性回填的组合保证打卡数据不丢失；薪资系统采用双区域 Active-Active 部署。文章还分享了应对早高峰流量峰值的成本优化策略（定时预热 + 反应式扩缩 + 无服务器扇出 + 多层缓存），以及重复执行 100 多次的标准切换流程。最后，作者坦承该方法无法处理「冷角」代码（约 20%），并给出 90 天启动计划与组织层面的关键举措（代码审查门禁、架构接缝映射、前期成本指标）。
文章金句
"我们停止了对单体架构的改动。
"如果搭建新服务需要三周时间，工程师们就绝不会为此支付 50% 的前期成本；但如果新服务只需十分钟就能上线，他们就会愿意支付这笔钱。
"在没有持久化记录之前，我们无法确认该数据已经被接收。
"如果没有对「迁移完成」的明确定义，团队就会无休止地对新服务进行微调，并依靠单体应用作为后备方案来规避风险，从而永远无法完全投入到新服务中。