聊聊单体应用的 4 点不良影响，总有 1 点击中你
点击上方“Java基基”，选择“设为星标”
做积极的人，而不是积极废人！
源码精品专栏
来源：blog.csdn.net/linsongbin1/
article/details/99179649
0. 概述
1. 系统稳定性很不可控
2. 发布时间真的好长
3. 分支问题
4. 会吓跑新人的
0. 概述
单体应用有优点也有缺点，而所有缺点基本上都是一个原因导致的。
功能模块都耦合在一起了。
不同功能堆在一起了，会引发各种各样的问题，下面说一下自己体验过的单体应用的痛。
1. 系统稳定性很不可控
目前公司有一个旧的后端应用，里面保罗万物，有订单、商品、支付、库存、定时任务、MQ，还有各种管理功能，在今年九月份的时候，其中一个模块出现了内存泄漏，最后导致了操作系统级别的oom killer，整个系统不可用了，而恰巧当时正在跑一个重要的且不支持幂等的批量指派任务，由于被强制停掉了，直接影响数据在前端的展现，且又不支持重新跑数据，运营人员直接就发飙了：怎么回事。后面研发只能边挨骂边修复数据，苦b的很。
单体应用耦合的模块多了，容易造成功能相互影响，真是躺着也中枪。
2. 发布时间真的好长
单体应用耦合的模块多了，也会导致应用启动时间变长，像之前的一个内部应用，启动时间是2分多钟，且有10台机器，使用原始的滚动发布方式，线上发布完后要20分钟，非常漫长；而对于测试人员来说，在测试环境里，经常要验证bug是否修复好了，经常性的要发布应用，每次都要等很久，真是苦不堪言，极大的降低了测试效率。
另外，发布时间长，对于CI来说，也是灾难。
3. 分支问题
当一个周期里，有多个功能要上线的时候，研发这边会基于主干分支拉出各个功能分支，这里会出现几个问题：
各个功能分支合并到主干分支的时候，容易出冲突，除了处理冲突需要时间外，还容易处理出错，导致代码被覆盖，很容易造成线上故障；
如果公司抠门，出于成本考虑，只有一台
dev机器用于开发联调，这个时候只能使用另外一个叫dev_all分支，所有功能分支的代码都统一合并到dev_all分支，开发人员一多，又是各种合并问题，导致开发环境不稳定，前端开发每次都因为这个，屌后台研发。
4. 会吓跑新人的
对于新手来说，看到了一坨庞大的代码，真心是无从下手，你让他接手或者干点活啥的，成本都贼高的，且容易犯错。对于有代码情操的人，是会立刻走人的。对于暂时忍受的了人，心理阴影也会逐渐加大，外面有啥风吹草动的，也会走人的。
欢迎加入我的知识星球，一起探讨架构，交流源码。加入方式，长按下方二维码噢：
已在知识星球更新源码解析如下：
最近更新《芋道 SpringBoot 2.X 入门》系列，已经 20 余篇，覆盖了 MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。
提供近 3W 行代码的 SpringBoot 示例，以及超 4W 行代码的电商微服务项目。
获取方式：点“在看”，关注公众号并回复 666 领取，更多内容陆续奉上。