你以为在做的是微服务？不！你做的只是分布式单体！
共 2115字，需浏览 5分钟
·
2022-08-04 08:29
早上在群里（点击加群）看到有小伙伴在讨论微服务，想到之前写过一篇相关的文章，顺手再发一下，给没有读过的小伙伴。
昨晚睡觉前，顺手撸了几个群聊的聊天记录。发现一个很有意思的名词“分布式单体”，顺藤摸瓜看了一下之前的聊天记录，由于内容骂骂咧咧，我就不贴出来了。大致内容就是某公司在做微服务改造，但改的不伦不类，形式上像微服务，而本质上依然是单体，甚至连单体都不如。
这样的改造现象，其实在国内还是蛮多见的。今天我们就来聊聊这个有趣的话题：分布式单体。各位看官，看看你们公司是不是也犯了这样的错误？
分布式单体为什么不好
先思考一个问题：从单体改造到微服务的时候，你们是不是按这样的步骤来的？
确定业务领域，拆分存储，定义各微服务的边界 改造代码逻辑，将原来的内部service调用改成dubbo或feign这样的远程调用
通过这样的改造，我们得到了很多好处，比如：
代码库分开了，减少了麻烦的解决代码冲突的困扰 CI/CD分开了，每个拆分后的服务都可以独立开发、部署、运行 数据库分开了，独立运行，不同业务模块不会互相影响
这样一顿操作，我们把一个臃肿的单体应用变成了多个精炼的分布式应用，似乎完美的实现了改造？但这样就实现了微服务的核心目标了吗？继续思考下面的问题：
代码库是分开了，但每个服务都在独立迭代吗？是不是每个需求都要协调一大堆同步接口？ CI/CD是分开了，但每次发布都是自由的吗？是不是每次功能的发布都拖上了一大推的服务要一起发布？ 数据库是分开了，但似乎有个服务挂了，依然导致很多功能就都不正常了？
看似我们得到了很多好处，但我们的开发效率真的得到了提升吗？虽然我们以前一个单体应用启动要3分钟，现在拆分后，一个项目启动30分钟，但每次开发调试要同时开好几个项目同时启动？这样的开发体验真的爽到了吗？
看似完成了微服务改造，实则依然是个单体应用，只是从原本的集中式实现，变成是分布式实现。原来我们只是做了一次无用功，真正的收益微乎其微。
而实际上，这样的改造，除了收益不高之外，实际上还带出了更多的坏处。如果你们公司是这样做的，有没有发现，这样做之后，好像系统故障的频率更高了？稳定性似乎比单体应用还差？（如果没有，那一定要感谢你们的运维团队真的很给力，同时建议把这篇转给运维团队，采访下这样的改造是不是他们变得更累了？！）
为什么这样的改造会导致系统更加不稳定呢？其实道理很简单，原本我们在单体应用中，未拆分的远程调用都是内部调用，这个内部调用所能引发的故障率是微乎其微的，而将这部分内容拆成了远程调用后，每一个调用都增加了网络IO的因素，每一次调用的故障率都增加了。那么系统的整体故障率是随着系统拥有多少同步远程调用的数量增加而增加的。当运维团队与开发水平没有没有支持好这部分增加的复杂度的时候，那么改造的系统，必然的稳定性会比原来的单体应用更差。
所以，这样改造的结果，不但没有得到很多的收益，反而会带来很多稳定性上的损失。
改造走样的元凶
那么为什么会造成上面所说的问题呢？我觉得主要有两方面：
领域拆分的不合理，引出了过多的同步远程调用
这个是最根本的问题，也是在改造过程中最常见的。这部分说实话是整个改造过程中最难的，因为需要对业务有非常深入的认识，对系统设计的领域模型、用户行为有足够的理解。在做拆分的时候，尽可能的减少同步远程调用，取而代之的是走消息的异步交互，同时根据业务需要也可以做适当的数据冗余。这样就能保证，每个被拆分后的微服务之间可以获得更低耦合度。
因为更低的耦合度，我们才能在不做任何优化的情况下，获得更少的分布式所带来的稳定性损失。对于后面要将的第2点的工作量也就越少。同时，对于真正的独立开发、部署、运行也成为可能。
简单粗暴的实现，缺少分布式的保护机制
在很多团队里，因为业务需求多与人员配置少的矛盾之下下，开发人员很容易出现对远程调用不做足够的保护机制，比如：接口提供方的限流策略（保护自己不被别人搞死），接口调用方的降级策略（保护业务更高的可用性），接口调用方的熔断策略（保护自己不被别人拖死）。只有认真对待每一个分布式环境下的依赖点，那么才能解决因为分布式改造所牵连出的诸多问题。
但要做好这一点的核心，还是对第一点的把握，只有在领域模型上做更合理的拆分规划，才能支持开发人员做好这个点，不然随意的拆分，一大堆接口调用压给本就压力很大的开发人员，那这部分的开发质量是很难保障了，自然而然的系统稳定性就开始随着接口复杂度的增加而不断下降了。最后，开发人员就会开始来我们群里吐槽了...甚至大家也开始怀疑微服务根本带不来效率的提升！
最后，思考一下，你们的微服务改在有出现这里我说的情况吗？还是有其他不一样的问题呢？欢迎留言区说说你们的问题，聊聊你的观点！