应用架构的演变
简单来说我们以前传统的应用的就是单体架构,即所有的模块,组件等都在一个应用中应用最终打成一个(war,jar)包使用一个容器(Tomcat)进行部署,通常一个应用享用一个数据库。
在单体应用中我们通常把应用分为三个组成部分:持久层,业务层,表现层,这样的应用结构在项目初期业务较少的情况下没有任何问题,但是随着业务需求不断的增加,要求单体应用中的业务逻辑,业务组件等日益扩张,应用将会变得越来越臃肿,往后的开发和维护就会变得特别麻烦,再加上越来越大访的问量,并发越来越高,面对海量的用户无论从应用性能还是从数据库方面都有吃不消的时候。所以单体应用在数据量,并发量到一定程度的时候一定会遇到瓶颈。如下图:
1.1.2、单体应用的缺点
-
对于高并发、大数据量 ,处理不占优势
-
开发时间越长,代码越多,项目越臃肿,杂乱无章
-
模块与模块,业务与业务耦合高 :比如一个模块挂了,其他模块也挂,一个模块升级,其他模块也要重启
-
技术选型单一,数据库选型单一
-
项目体积庞大的时候,会造成,编译慢,项目打包等也慢。
-
二次开发,维护难
-
新的程序员对项目需要花很长时间去熟悉,成本高。
-
不方便局部拓展,只能整体做集群
1.1.3、单体应用的优点
-
项目初期,项目的搭建,开发都比较快
-
技术成本低,对程序员的要求相对低 , 开发成本较低
-
项目的部署相对简单 - 就一个tomcat