21｜微服务拆分（一）：迈出遗留系统现代化第一步

作者回复: 对于大型遗留系统，动辄几百万行代码，很难通读，所以还是先梳理业务，识别业务边界，找出精益切片，再对这个切片进行代码分析。如果用活文档等工具，一两个人来分析就行（可以结对），把活文档注解标记好，生成脑图，这样其他人就可以不用再分析代码了。 另外，每一个人领取的改造任务，比如单个API，还是要自己仔细分析代码的。

作者回复: 参考第十一节课，用触发器或轮询事务日志，这两种方法是通用的，跟具体数据库无关。

作者回复: 双写的确是最直观最简单的，更好的办法其实就是在拆分数据所有权的时候，并不拆分数据库本身，而是先保留在单体库中。微服务通过DBLink来访问单体数据库，或者如果数据库不支持DBLink，就直接在单体库中创建视图（参考第十五节课）。

作者回复: 好问题，这一点我没有在课程里说得太清楚。通过战术分叉拆分出服务来，基本上就完成了代码部分的拆分，剩下的绝大部分任务就是数据拆分了。因为遗留系统没有数据所有权的概念，所以在一个模块内是可以访问任何表的，像本节课中说的用API调用取代代码依赖的场景是非常少的，因为大部分情况可能就连表查询了，这一点在下一节课也会提到。

作者回复: 是需要补消息的，但是没必要在拆之前就全部做好，可以是当前这个API拆分任务的一部分

作者回复: DBLink的好处在于，在拆分代码时，可以当成是已经拆好了数据库，可以分离关注点。 PS：你指的传统的不停机的套路是什么？

作者回复: 1. 如果业务人员能参与验收，当然是最好的，可以通过开关做A/B测试 2. 我在课程中不会介绍分布式事务，而是通过消息机制实现最终一致。关于分布式事务，极客时间已经有很多内容了。