主要观点：

• 工作在遗留代码库有挑战，新科技使企业难以用单体遗留应用保持竞争力，需持续演进应用，将其转变为微服务是最佳途径。
• 维护遗留应用繁琐，有缺乏单元测试、违反单一职责原则等多种原因导致额外工作。
• 多团队在单体应用中工作时，若一个团队部署坏代码会阻碍其他团队，依赖单一管道易导致团队间阻塞和功能交付延迟。
• 多年来代码复杂度增长，组件间紧耦合难以实施良好自动化测试，依赖少数关键人员导致审查延迟。
• 意识到单体应用模式不可持续后，决定将其分解为小的、松耦合的服务以更频繁部署。
• 重写大型单体应用风险大，理解遗留系统困难，且新系统开发期间业务需等待。
• 绞杀模式可降低风险，逐步替换功能，提供新功能价值更快，遵循单一职责原则和松耦合代码可简化后续重构。
• 绞杀模式需遵循转换、共存、消除三步，可选择简单组件、测试覆盖率高和技术债务少的组件等开始。
• 云迁移旅程有挑战，绞杀模式可使迁移更轻松无风险，减少应用复杂度可更快交付功能和扩展应用。
• 最终将单体应用分解为微服务，每个微服务有自己的数据存储和 CI/CD 管道。

关键信息：

• 遗留代码库维护难及原因。
• 多团队在单体应用中的问题。
• 重写单体应用的风险。
• 绞杀模式的定义及步骤。
• 选择绞杀组件的方法。
• 云迁移及绞杀模式的作用。

重要细节：

• 遗留应用维护难的具体表现，如缺乏单元测试等。
• 多团队工作时阻塞情况及影响。
• 重写单体应用风险的具体阐述。
• 绞杀模式中各阶段的操作及注意事项。
• 选择绞杀组件的不同考量因素。
• 分解为微服务后的架构特点。