先思考一个问题：从单体改造到微服务的时候，你们是不是按这样的步骤来的？

1. 确定业务领域，拆分存储，定义各微服务的边界

2. 改造代码逻辑，将原来的内部 service 调用改成 dubbo 或 feign 这样的远程调用

通过这样的改造，我们得到了很多好处，比如：

1. 代码库分开了，减少了麻烦的解决代码冲突的困扰

2. CI/CD 分开了，每个拆分后的服务都可以独立开发、部署、运行

3. 数据库分开了，独立运行，不同业务模块不会互相影响

这样一顿操作，我们把一个臃肿的单体应用变成了多个精炼的分布式应用，似乎完美的实现了改造？但这样就实现了微服务的核心目标了吗？继续思考下面的问题：

1. 代码库是分开了，但每个服务都在独立迭代吗？是不是每个需求都要协调一大堆同步接口？

2. CI/CD 是分开了，但每次发布都是自由的吗？是不是每次功能的发布都拖上了一大推的服务要一起发布？

3. 数据库是分开了，但似乎有个服务挂了，依然导致很多功能就都不正常了？

看似我们得到了很多好处，但我们的开发效率真的得到了提升吗？虽然我们以前一个单体应用启动要 3 分钟，现在拆分后，一个项目启动 30 秒，但每次开发调试要同时开好几个项目同时启动？这样的开发体验真的爽到了吗？

看似完成了微服务改造，实则依然是个单体应用，只是从原本的集中式实现，变成是分布式实现。原来我们只是做了一次无用功，真正的收益微乎其微。

而实际上，这样的改造，除了收益不高之外，实际上还带出了更多的坏处。如果你们公司是这样做的，有没有发现，这样做之后，好像系统故障的频率更高了？稳定性似乎比单体应用还差？（如果没有，那一定要感谢你们的运维团队真的很给力，同时建议把这篇转给运维团队，采访下这样的改造是不是他们变得更累了？！）

为什么这样的改造会导致系统更加不稳定呢？其实道理很简单，原本我们在单体应用中，未拆分的远程调用都是内部调用，这个内部调用所能引发的故障率是微乎其微的，而将这部分内容拆成了远程调用后，每一个调用都增加了网络 IO 的因素，每一次调用的故障率都增加了。那么系统的整体故障率是随着系统拥有多少同步远程调用的数量增加而增加的。当运维团队与开发水平没有没有支持好这部分增加的复杂度的时候，那么改造的系统，必然的稳定性会比原来的单体应用更差。

所以，这样改造的结果，不但没有得到很多的收益，反而会带来很多稳定性上的损失。

改造走样的元凶

最后

再免费分享一波我的JAVA架构专题面试真题+解析+JAVA学习书籍：戳这里免费领取