现在的系统代码量50w，单体应用，但是拆分成微服务太麻烦了，领导不敢动，系统是金融管理基金托管计算的，太多复杂场景耦合，10几年的代码，好几个团队的代码堆积，俗话就是 又臭又硬的系统，只能不断维护，不敢重新搭建新的框架，不敢拆，拆不得，拆了谁负责，谁敢保证拆后所有功能按照原有一样逻辑呢？

唉，老员工都是吐槽，继续码代码，分支也多，团队也多，部署一次1小时，每次有代码提交就催着部署，意味着系统动不动挂一小时，部署相当麻烦，文件对比，打包等等

这个系统没救了

看了文章和留言，讲的很清楚，请教一个问题，之前也有同学问了。

对于典型的复杂web应用，当由单体应用改造成微服务时，一般会按照业务进行服务划分，彼此独立的业务拆分到不同的微服务中。但是在数据层面，涉及到下面两个问题:
1. 数据库是否拆分？从数据架构的角度看，可能有三个选择:1) 一个db实例，所有微服务在一个schema中，2) 一个db实例，每个微服务有自己的schema，3) 每个微服务有自己的db实例。我们在实际项目中应该如何取舍？
2. DAO层是否拆分？可能有两个选择: 1) DAO层保持不变或者单独部署成微服务，所有业务微服务通过引用jar包或者HTTP的方式和DAO进行交互。2) 把DAO进行拆分，每个业务微服务内部管理自己会用到的db数据。在所有微服务采用的技术栈相同的情况下，上面哪种方式更可取？

5 年的 php 单体应用，整个项目结构复杂混乱，php 前端和 php 后端各种函数调用。业务逻辑代码也穿插着大量已过期或无关的代码，项目可维护性越来越低。每次需求开发完毕合并分支时，需要花费大量的精力去解决代码冲突。开发的速度远跟不上需求的速度。

在去年所有新的需求使用 java 进行开发，同时一点一点将 php 的业务迁移到 java。
从一开始就没规划好，一股脑喊出了微服务化口号，前期也是真苦了运维和测试。

一年多过去了，项目现在的的状态：
1. 项目内结构依旧混乱，A 模块和 B 模块都依赖于 C 模块，我们的做法是，A 模块里写一次 C 模块，B 模块同样写一遍 C 模块。其中有两个原因，无法实现分布式事务，只好放到同一个系统内，整个流程可以同属于一个事务；另一个原因是模块的边界划分是很模糊的。
2. 项目之间的依赖关系就跟意大利面条一样，而且之间的接口，并没有想着去向下兼容，甚至发生过接口定义变更了，导致线上依赖的服务都无法正常提供服务。现在每次发布也是战战兢兢。

目前面临最大的问题便是分布式事务的问题，导致 DAO 层的代码，重复散落在各个模块之中，真是令人头大。