关于java:你以为在做的是微服务不你只是做了个比单体还糟糕的分布式单体

35次阅读

共计 2008 个字符，预计需要花费 6 分钟才能阅读完成。

昨晚睡觉前，棘手撸了几个群聊的聊天记录。发现一个很有意思的名词“分布式单体”，顺藤摸瓜看了一下之前的聊天记录，因为内容骂骂咧咧，我就不贴出来了。。。大抵内容就是某公司在做微服务革新，但改的不三不四，模式上像微服务，而实质上仍然是单体，甚至连单体都不如。

这样的革新景象，其实在国内还是蛮多见的。上面就来聊聊这个乏味的话题：分布式单体。各位看官，看看你们公司是不是也犯了这样的谬误？

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

确定业务畛域，拆分存储，定义各微服务的边界
革新代码逻辑，将原来的外部 service 调用改成 dubbo 或 feign 这样的近程调用

通过这样的革新，咱们失去了很多益处，比方：

代码库离开了，缩小了麻烦的解决代码抵触的困扰
CI/CD 离开了，每个拆分后的服务都能够独立开发、部署、运行
数据库离开了，独立运行，不同业务模块不会相互影响

这样一顿操作，咱们把一个臃肿的单体利用变成了多个精炼的分布式应用，仿佛完满的实现了革新？但这样就实现了微服务的外围指标了吗？持续思考上面的问题：

代码库是离开了，但每个服务都在独立迭代吗？是不是每个需要都要协调一大堆同步接口？
CI/CD 是离开了，但每次公布都是自在的吗？是不是每次性能的公布都拖上了一大推的服务要一起公布？
数据库是离开了，但仿佛有个服务挂了，仍然导致很多性能就都不失常了？

看似咱们失去了很多益处，但咱们的开发效率真的失去了晋升吗？尽管咱们以前一个单体利用启动要 3 分钟，当初拆分后，一个我的项目启动 30 分钟，但每次开发调试要同时开好几个我的项目同时启动？这样的开发体验真的爽到了吗？

看似实现了微服务革新，实则仍然是个单体利用，只是从本来的集中式实现，变成是分布式实现。原来咱们只是做了一次无用功，真正的收益微不足道。

而实际上，这样的革新，除了收益不高之外，实际上还带出了更多的害处。如果你们公司是这样做的，有没有发现，这样做之后，如同系统故障的频率更高了？稳定性仿佛比单体利用还差？（如果没有，那肯定要感激你们的运维团队真的很给力，同时倡议把这篇转给运维团队，采访下这样的革新是不是他们变得更累了？！）

为什么这样的革新会导致系统更加不稳固呢？其实情理很简略，本来咱们在单体利用中，未拆分的近程调用都是外部调用，这个外部调用所能引发的故障率是微不足道的，而将这部分内容拆成了近程调用后，每一个调用都减少了网络 IO 的因素，每一次调用的故障率都减少了。那么零碎的整体故障率是随着零碎领有多少同步近程调用的数量减少而减少的。当运维团队与开发程度没有没有反对好这部分减少的复杂度的时候，那么革新的零碎，必然的稳定性会比原来的单体利用更差。

所以，这样革新的后果，岂但没有失去很多的收益，反而会带来很多稳定性上的损失。本文首发不三不四的微服务革新：分布式单体，禁止未经受权转载。

那么为什么会造成下面所说的问题呢？我感觉次要有两方面：

畛域拆分的不合理，引出了过多的同步近程调用

这个是最基本的问题，也是在革新过程中最常见的。这部分说实话是整个革新过程中最难的，因为须要对业务有十分深刻的意识，对系统设计的畛域模型、用户行为有足够的了解。在做拆分的时候，尽可能的缩小同步近程调用，取而代之的是走音讯的异步交互，同时依据业务须要也能够做适当的数据冗余。这样就能保障，每个被拆分后的微服务之间能够取得更低耦合度。

因为更低的耦合度，咱们能力在不做任何优化的状况下，取得更少的分布式所带来的稳定性损失。对于前面要将的第 2 点的工作量也就越少。同时，对于真正的独立开发、部署、运行也成为可能。

简略粗犷的实现，短少分布式的爱护机制

在很多团队里，因为业务需要多与人员配置少的矛盾之下下，开发人员很容易呈现对近程调用不做足够的爱护机制，比方：接口提供方的限流策略（爱护本人不被他人搞死），接口调用方的降级策略（爱护业务更高的可用性），接口调用方的熔断策略（爱护本人不被他人拖死）。只有认真对待每一个分布式环境下的依赖点，那么能力解决因为分布式革新所株连出的诸多问题。

但要做好这一点的外围，还是对第一点的把握，只有在畛域模型上做更正当的拆分布局，能力反对开发人员做好这个点，不然随便的拆分，一大堆接口调用压给本就压力很大的开发人员，那这部分的开发品质是很难保障了，自然而然的零碎稳定性就开始随着接口复杂度的减少而一直降落了。最初，开发人员就会开始来咱们群里吐槽了 … 甚至大家也开始狐疑微服务基本带不来效率的晋升！

最初，思考一下：你们的微服务改在有呈现这里我说的状况吗？还是有其余不一样的问题呢？退出咱们的 Spring 技术交换群，聊聊你的观点！