你以为在做的是微服务?不!你只是做了个比单体还糟糕的分布式单体!
芋道源码 文章源自JAVA秀-https://www.javaxiu.com/37718.html
以下文章来源于程序猿DD,作者翟永超文章源自JAVA秀-https://www.javaxiu.com/37718.html
文章源自JAVA秀-https://www.javaxiu.com/37718.html 文章源自JAVA秀-https://www.javaxiu.com/37718.html 程序猿DD文章源自JAVA秀-https://www.javaxiu.com/37718.html 一线技术工作者的学习、生活与见闻文章源自JAVA秀-https://www.javaxiu.com/37718.html
点击上方“芋道源码”,选择“设为星标”文章源自JAVA秀-https://www.javaxiu.com/37718.html
管她前浪,还是后浪?文章源自JAVA秀-https://www.javaxiu.com/37718.html
能浪的浪,才是好浪!文章源自JAVA秀-https://www.javaxiu.com/37718.html
每天 8:55 更新文章,每天掉亿点点头发...文章源自JAVA秀-https://www.javaxiu.com/37718.html
文章源自JAVA秀-https://www.javaxiu.com/37718.html 源码精品专栏文章源自JAVA秀-https://www.javaxiu.com/37718.html
原创 | Java 2020 超神之路,很肝~文章源自JAVA秀-https://www.javaxiu.com/37718.html
中文详细注释的开源项目文章源自JAVA秀-https://www.javaxiu.com/37718.html
RPC 框架 Dubbo 源码解析文章源自JAVA秀-https://www.javaxiu.com/37718.html
网络应用框架 Netty 源码解析文章源自JAVA秀-https://www.javaxiu.com/37718.html
消息中间件 RocketMQ 源码解析文章源自JAVA秀-https://www.javaxiu.com/37718.html
数据库中间件 Sharding-JDBC 和 MyCAT 源码解析文章源自JAVA秀-https://www.javaxiu.com/37718.html
作业调度中间件 Elastic-Job 源码解析文章源自JAVA秀-https://www.javaxiu.com/37718.html
分布式事务中间件 TCC-Transaction 源码解析文章源自JAVA秀-https://www.javaxiu.com/37718.html
Eureka 和 Hystrix 源码解析文章源自JAVA秀-https://www.javaxiu.com/37718.html
Java 并发源码文章源自JAVA秀-https://www.javaxiu.com/37718.html
文章源自JAVA秀-https://www.javaxiu.com/37718.html
分布式单体为什么不好文章源自JAVA秀-https://www.javaxiu.com/37718.html
改造走样的元凶文章源自JAVA秀-https://www.javaxiu.com/37718.html
1. 领域拆分的不合理,引出了过多的同步远程调用文章源自JAVA秀-https://www.javaxiu.com/37718.html
2. 简单粗暴的实现,缺少分布式的保护机制文章源自JAVA秀-https://www.javaxiu.com/37718.html
文章源自JAVA秀-https://www.javaxiu.com/37718.html
昨晚睡觉前,顺手撸了几个群聊的聊天记录。发现一个很有意思的名词“分布式单体 ”,顺藤摸瓜看了一下之前的聊天记录,由于内容骂骂咧咧,我就不贴出来了。大致内容就是某公司在做微服务改造,但改的不伦不类,形式上像微服务,而本质上依然是单体,甚至连单体都不如。文章源自JAVA秀-https://www.javaxiu.com/37718.html
这样的改造现象,其实在国内还是蛮多见的。今天我们就来聊聊这个有趣的话题:分布式单体 。各位看官,看看你们公司是不是也犯了这样的错误?文章源自JAVA秀-https://www.javaxiu.com/37718.html
分布式单体为什么不好
先思考一个问题:从单体改造到微服务的时候,你们是不是按这样的步骤来的?文章源自JAVA秀-https://www.javaxiu.com/37718.html
确定业务领域,拆分存储,定义各微服务的边界文章源自JAVA秀-https://www.javaxiu.com/37718.html
改造代码逻辑,将原来的内部service调用改成dubbo或feign这样的远程调用文章源自JAVA秀-https://www.javaxiu.com/37718.html
通过这样的改造,我们得到了很多好处,比如:文章源自JAVA秀-https://www.javaxiu.com/37718.html
代码库分开了,减少了麻烦的解决代码冲突的困扰文章源自JAVA秀-https://www.javaxiu.com/37718.html
CI/CD分开了,每个拆分后的服务都可以独立开发、部署、运行文章源自JAVA秀-https://www.javaxiu.com/37718.html
数据库分开了,独立运行,不同业务模块不会互相影响文章源自JAVA秀-https://www.javaxiu.com/37718.html
这样一顿操作,我们把一个臃肿的单体应用变成了多个精炼的分布式应用,似乎完美的实现了改造?但这样就实现了微服务的核心目标了吗?继续思考下面的问题:文章源自JAVA秀-https://www.javaxiu.com/37718.html
代码库是分开了,但每个服务都在独立迭代吗?是不是每个需求都要协调一大堆同步接口?文章源自JAVA秀-https://www.javaxiu.com/37718.html
CI/CD是分开了,但每次发布都是自由的吗?是不是每次功能的发布都拖上了一大推的服务要一起发布?文章源自JAVA秀-https://www.javaxiu.com/37718.html
数据库是分开了,但似乎有个服务挂了,依然导致很多功能就都不正常了?文章源自JAVA秀-https://www.javaxiu.com/37718.html
看似我们得到了很多好处,但我们的开发效率真的得到了提升吗?虽然我们以前一个单体应用启动要3分钟,现在拆分后,一个项目启动30秒,但每次开发调试要同时开好几个项目同时启动?这样的开发体验真的爽到了吗?文章源自JAVA秀-https://www.javaxiu.com/37718.html
看似完成了微服务改造,实则依然是个单体应用,只是从原本的集中式实现,变成是分布式实现。原来我们只是做了一次无用功,真正的收益微乎其微。文章源自JAVA秀-https://www.javaxiu.com/37718.html
而实际上,这样的改造,除了收益不高之外,还带出了更多的坏处。如果你们公司是这样做的,有没有发现,这样做之后,好像系统故障的频率更高了?稳定性似乎比单体应用还差?(如果没有,那一定要感谢你们的运维团队真的很给力,同时建议把这篇转给运维团队,采访下这样的改造是不是他们变得更累了?!)文章源自JAVA秀-https://www.javaxiu.com/37718.html
为什么这样的改造会导致系统更加不稳定呢?其实道理很简单,原本我们在单体应用中,未拆分的远程调用都是内部调用,这个内部调用所能引发的故障率是微乎其微的,而将这部分内容拆成了远程调用后,每一个调用都增加了网络IO的因素,每一次调用的故障率都增加了。那么系统的整体故障率是随着系统拥有多少同步远程调用的数量增加而增加的。当运维团队与开发水平没有支持好这部分增加的复杂度时,那么改造的系统,必然稳定性会比原来的单体应用更差。文章源自JAVA秀-https://www.javaxiu.com/37718.html
所以,这样改造的结果,不但没有得到很多的收益,反而会带来很多稳定性上的损失。文章源自JAVA秀-https://www.javaxiu.com/37718.html
改造走样的元凶
那么为什么会造成上面所说的问题呢?我觉得主要有两方面:文章源自JAVA秀-https://www.javaxiu.com/37718.html
1. 领域拆分的不合理,引出了过多的同步远程调用
这个是最根本的问题,也是在改造过程中最常见的。这部分说实话是整个改造过程中最难的,因为需要对业务有非常深入的认识,对系统设计的领域模型、用户行为有足够的理解。在做拆分的时候,尽可能的减少同步远程调用,取而代之的是走消息的异步交互,同时根据业务需要也可以做适当的数据冗余。这样就能保证,每个被拆分后的微服务之间可以获得更低耦合度。文章源自JAVA秀-https://www.javaxiu.com/37718.html
因为更低的耦合度,我们才能在不做任何优化的情况下,获得更少的分布式所带来的稳定性损失。对于后面要将的第2点的工作量也就越少。同时,对于真正的独立开发、部署、运行也成为可能。文章源自JAVA秀-https://www.javaxiu.com/37718.html
2. 简单粗暴的实现,缺少分布式的保护机制
在很多团队里,因为业务需求多与人员配置少的矛盾之下,开发人员很容易出现对远程调用不做足够的保护机制,比如:接口提供方的限流策略(保护自己不被别人搞死),接口调用方的降级策略(保护业务更高的可用性),接口调用方的熔断策略(保护自己不被别人拖死)。只有认真对待每一个分布式环境下的依赖点,那么才能解决因为分布式改造所牵连出的诸多问题。文章源自JAVA秀-https://www.javaxiu.com/37718.html
但要做好这一点的核心,还是对第一点的把握,只有在领域模型上做更合理的拆分规划,才能支持开发人员做好这个点,不然随意的拆分,一大堆接口调用压给本就压力很大的开发人员,那这部分的开发质量肯定很难保障了,自然而然的系统稳定性就开始随着接口复杂度的增加而不断下降了。最后,开发人员就会开始来我们群里吐槽了...甚至大家也开始怀疑微服务根本带不来效率的提升!文章源自JAVA秀-https://www.javaxiu.com/37718.html
最后,思考一下,你们的微服务改造有出现这里我说的情况吗?还是有其他不一样的问题呢?欢迎留言区说说你们的问题,聊聊你的观点!文章源自JAVA秀-https://www.javaxiu.com/37718.html
- END -文章源自JAVA秀-https://www.javaxiu.com/37718.html
欢迎加入我的知识星球,一起探讨架构,交流源码。加入方式,长按下方二维码噢:文章源自JAVA秀-https://www.javaxiu.com/37718.html
文章源自JAVA秀-https://www.javaxiu.com/37718.html
已在知识星球更新源码解析如下:文章源自JAVA秀-https://www.javaxiu.com/37718.html
文章源自JAVA秀-https://www.javaxiu.com/37718.html
文章源自JAVA秀-https://www.javaxiu.com/37718.html
文章源自JAVA秀-https://www.javaxiu.com/37718.html
文章源自JAVA秀-https://www.javaxiu.com/37718.html
最近更新《芋道 SpringBoot 2.X 入门》系列,已经 20 余篇,覆盖了 MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。文章源自JAVA秀-https://www.javaxiu.com/37718.html
提供近 3W 行代码的 SpringBoot 示例,以及超 4W 行代码的电商微服务项目。文章源自JAVA秀-https://www.javaxiu.com/37718.html
获取方式:点“在看”,关注公众号并回复 666 领取,更多内容陆续奉上。文章源自JAVA秀-https://www.javaxiu.com/37718.html
文章源自JAVA秀-https://www.javaxiu.com/37718.html
文章有帮助的话,在看,转发吧。谢谢支持哟 (*^__^*)文章源自JAVA秀-https://www.javaxiu.com/37718.html
阅读原文文章源自JAVA秀-https://www.javaxiu.com/37718.html

评论