什么是单体架构
在软件设计的时候经常提到和使用经典的3层模型，即表现层，业务逻辑层，数据访问层。虽然在软件设计中划分了3层模型，但是对业务场景没有划分，一个典型的单体架构就是将所有的业务场景的表现层，业务逻辑层，数据访问层放在一个工程中最终经过编译，打包，部署在一台服务器上。此时服务架构如图：
单体架构存在的不足
在一些小型应用的初期，访问量小的时候，这种架构的性价比还是比较高的，开发速度快，成本低，但是随着业务的发展，逻辑越来越复杂，代码量越来越大，代码的可读性和可维护性越来越低。用户的增加，访问量越来越多单体架构的应用并发能力十分有限。可能会有人想到将单体应用进行集群部署，并增加负载均衡服务器，再来个缓存服务器和文件服务器，数据库再搞个读写分离。这种架构如图：
这种架构虽然有一定的并发能力，及应对一定复杂业务，但是依然没有改变系统为单体架构的事实。大量的业务必然会有大量的代码，代码得可读性和可维护性依然很差。如果面对海量的用户，它的并发能力依然不够。
总结
单体架构的好处是便于管理，所有代码都在同一个项目当中。但是当产品规模越来越大，其坏处也很明显：
1.项目过于臃肿 - 当大大小小的功能模块都集中在同一项目的时候，整个项目必然会变的臃肿，让开发者难以维护。
2.资源无法隔离 - 整个单体系统各个功能模块都依赖于同样的数据库，内存等资源，一旦某个功能模块对资源使用不当，整个系统都会被拖垮。
3.无法灵活扩展 - 当系统的访问量越来越大的时候，单个系统固然可以进行水平扩展，部署在多台机器上组成集群：
但这种扩展并非灵活的扩展。比如我们现在的性能瓶颈是支付模块，希望只针对支付模块做水平扩展，这一点在单体系统是做不到的。
转载：https://blog.csdn.net/sunming709424/article/details/80578559
