一:之前在项目中都是使用此架构,简单来讲就是三层。表现层、业务层、持久层、数据库。
业务逻辑分层,比如持久层专门对数据库进行操作。
并且该项目属于一个工程,打成一个war包,部署在一个tomcat上,上线。
二:上线之后,进行推广。
随着访问用户越来越多,并发量越来越大。
举个例子:此时系统具有1000个并发,一个tomcat撑不住了。
(一个tomcat理论最多支持500个并发,但是在实际应用中能够支持300就已经不错了!)
解决办法:加一个服务器,加一个tomcat(此处假设一个tomcat支持的并发数是理论值)。并且需要负载均衡服务器。
新的问题:两台服务器的session共享。
解决办法:tomcat集群,配置session复制。广播形式,每一个节点向其他节点广播自己的session信息。上线。
三:上线之后,进行推广。
并发量持续增加。
举个例子:此时系统具有10000个并发。难道需要20台服务器做tomcat集群?显然是不可行的(原因:每台服务器都向其他19台服务器广播自己的session信息,但是每台服务器的带宽就那么大,此时这个带宽都被tomcat广播session给占用,根本没有精力再去做自己的服务)。
解决办法:按照功能点把系统进行拆分成N个独立的子系统。单独为每一个独立的子系统添加服务器。需要系统之间配合才能完成整个业务逻辑。(分布式,分布式中每一个子系统配置集群,此时tomcat数量无上限)
优点:1、把模块拆分,使用接口进行通信(webservice/socket),降低模块之间的耦合度。
2、将系统拆分成若干个子系统,不同的团队负责不同的子系统。
3、增加功能时只需要增加一个子系统,调用其他系统的接口即可。
4、灵活的进行分布式部署。
缺点:1、系统之间的交互需要远程通信,接口开发增加工作量。
2、各个子系统有一些通用的业务逻辑无法共用。
四:上线之后,进行推广。
新的问题:一些通用的业务逻辑无法共用。
解决办法:将分布式的系统在横切,形成基于一种基于soa的架构。
SOA:Service Oriented Architecture面向服务的架构。就是将各个子工程在拆分成服务层、表现层。
服务层中包含业务逻辑,只需要对外提供服务。
表现层只需要处理和页面的交互,业务逻辑通过调用服务层的服务来实现。