概述

单体应用有优点也有缺点，而所有缺点基本上都是一个原因导致的。

功能模块都耦合在一起了。

不同功能堆在一起了，会引发各种各样的问题，下面说一下自己体验过的单体应用的痛。

系统稳定性很不可控

目前公司有一个旧的后端应用，里面保罗万物，有订单、商品、支付、库存、定时任务、MQ，还有各种管理功能，在今年九月份的时候，其中一个模块出现了内存泄漏，最后导致了操作系统级别的oom killer，整个系统不可用了，而恰巧当时正在跑一个重要的且不支持幂等的批量指派任务，由于被强制停掉了，直接影响数据在前端的展现，且又不支持重新跑数据，运营人员直接就发飙了：怎么回事。后面研发只能边挨骂边修复数据，苦b的很。

单体应用耦合的模块多了，容易造成功能相互影响，真是躺着也中枪。

发布时间真的好长

单体应用耦合的模块多了，也会导致应用启动时间变长，像之前的一个内部应用，启动时间是2分多钟，且有10台机器，使用原始的滚动发布方式，线上发布完后要20分钟，非常漫长；而对于测试人员来说，在测试环境里，经常要验证bug是否修复好了，经常性的要发布应用，每次都要等很久，真是苦不堪言，极大的降低了测试效率。

另外，发布时间长，对于CI来说，也是灾难。

分支问题

当一个周期里，有多个功能要上线的时候，研发这边会基于主干分支拉出各个功能分支，这里会出现几个问题：

  • 各个功能分支合并到主干分支的时候，容易出冲突，除了处理冲突需要时间外，还容易处理出错，导致代码被覆盖，很容易造成线上故障；
  • 如果公司抠门，出于成本考虑，只有一台dev机器用于开发联调，这个时候只能使用另外一个叫dev_all分支，所有功能分支的代码都统一合并到dev_all分支，开发人员一多，又是各种合并问题，导致开发环境不稳定，前端开发每次都因为这个，屌后台研发。

会吓跑新人的

对于新手来说，看到了一坨庞大的代码，真心是无从下手，你让他接手或者干点活啥的，成本都贼高的，且容易犯错。对于有代码情操的人，是会立刻走人的。对于暂时忍受的了人，心理阴影也会逐渐加大，外面有啥风吹草动的，也会走人的。