1.3.2　单体式架构的痛点

1.3.1节中提到了单体式架构的特点，就是所有的东西都在一起开发、维护和部署，这套系统就像一个大杂烩，什么都有。这样的系统很明显是难以维护的，举个最常见的例子，没有明确的边界和职责，重复的代码到处都是，改动一个逻辑，就要改动多处，如果单元测试做得不好，就可能或很容易遗漏而产生BUG。

当然，不能否认单体式架构的优点，而且在中小型项目中，它的开发效率和运维的简便性等好处，要远超微服务架构。但是，随着时间的推移，项目越做越大，代码越来越复杂，单体式架构的缺点逐渐暴露出来，有些问题会让团队越来越无法忍受，甚至导致项目的失败。

1. 单体式架构的优点

（1）前期开发效率高。在项目早期，单体式架构有着明显的优势，开发者只需维护一个工程，应用的测试和调试也非常简单。

（2）易于上手。单体式架构的学习成本相对较低，服务之间都是本地调用，不存在分布式事务、会话同步等复杂问题。

（3）易于部署。这个优势很明显，相比微服务或SOA，单体式架构无论是新部署还是升级部署，只要打好一个包在服务器上运行即可。

（4）易于水平扩展。这也是易于部署的一点，由于单体式架构所有的代码都在一个包中，只需完整地复制这个节点，前置一台代理服务器，很容易就能做到水平扩展、集群部署。

2. 单体式架构的缺点

（1）难以维护。代码大量冗余且耦合度高、逻辑松散，导致代码新增或修改困难。

（2）过载的IDE。几乎每个单体式架构到了后期，都没有一款IDE能够保证这样巨大的代码量可以流畅地进行开发和调试，甚至笔者见过一个开发了10年的产品代码，仅是IDE上运行起来就需要半个小时，严重影响开发和测试效率。

（3）过载的Web容器。这与IDE的情况相同，随着包的体积越来越大，Web容器的运行效率也将越来越差。

（4）资源浪费。前面提到过单体式架构易于水平扩展的优点，这也正是单体式架构在水平扩展时的缺点。大家知道，集群部署一般是解决用户并发量大的负载问题。可能只是想扩展应用的存储能力，需要一台I/O读写效率高的机器，但是单体式架构所有的代码都是一体的，且集群的各个节点都完全相等，因此需要提供能够支撑其他模块数据处理能力的CPU或者带宽等相同配置的机器。

（5）部署风险大。这是单体式架构相对比较大的痛点，每当有新功能上线，哪怕是很小的功能，都需要进行整包部署。如果是集群，那么工作量就更大了，而且重新部署了所有功能，可能导致本身没有打算更新的功能出现问题。

（6）很难追求技术创新。如果一个单体式架构经历了比较长的时间，那么它的技术一定是陈旧的，由于都在同一个工程下开发，技术选型会有很多的限制，而且更改之前的技术框架是很难的，除非团队有毅力和很多时间，还要加上领导和资金上的支持，而这对大部分项目而言几乎是不可能的。

大家很快认识到这些问题，所有人都觉得这样不行，然后开始想办法，紧接着MVC（Model–View–Controller，模型—视图—控制器）的概念——一种软件的架构模式被提出来。一时间，MVC似乎成了软件架构新的希望，并且迅速在整个软件业流行起来，而且持续了很长时间，包括现在仍有很多微服务的内部结构在采用MVC的模式进行开发。