什么是单体架构

在软件设计的时候经常提到和使用经典的3层模型,即表现层,业务逻辑层,数据访问层。虽然在软件设计中划分了3层模型,但是对业务场景没有划分,一个典型的单体架构就是将所有的业务场景的表现层,业务逻辑层,数据访问层放在一个工程中最终经过编译,打包,部署在一台服务器上。此时服务架构如图:
在这里插入图片描述

单体架构存在的不足

在一些小型应用的初期,访问量小的时候,这种架构的性价比还是比较高的,开发速度快,成本低,但是随着业务的发展,逻辑越来越复杂,代码量越来越大,代码的可读性和可维护性越来越低。用户的增加,访问量越来越多单体架构的应用并发能力十分有限。可能会有人想到将单体应用进行集群部署,并增加负载均衡服务器,再来个缓存服务器和文件服务器,数据库再搞个读写分离。这种架构如图:
在这里插入图片描述
这种架构虽然有一定的并发能力,及应对一定复杂业务,但是依然没有改变系统为单体架构的事实。大量的业务必然会有大量的代码,代码得可读性和可维护性依然很差。如果面对海量的用户,它的并发能力依然不够。

总结

单体架构的好处是便于管理,所有代码都在同一个项目当中。但是当产品规模越来越大,其坏处也很明显:

1.项目过于臃肿 - 当大大小小的功能模块都集中在同一项目的时候,整个项目必然会变的臃肿,让开发者难以维护。

2.资源无法隔离 - 整个单体系统各个功能模块都依赖于同样的数据库,内存等资源,一旦某个功能模块对资源使用不当,整个系统都会被拖垮。

3.无法灵活扩展 - 当系统的访问量越来越大的时候,单个系统固然可以进行水平扩展,部署在多台机器上组成集群:在这里插入图片描述

但这种扩展并非灵活的扩展。比如我们现在的性能瓶颈是支付模块,希望只针对支付模块做水平扩展,这一点在单体系统是做不到的。

转载:https://blog.csdn.net/sunming709424/article/details/80578559

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐