一：之前在项目中都是使用此架构，简单来讲就是三层。表现层、业务层、持久层、数据库。
业务逻辑分层，比如持久层专门对数据库进行操作。
并且该项目属于一个工程，打成一个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面向服务的架构。就是将各个子工程在拆分成服务层、表现层。
服务层中包含业务逻辑，只需要对外提供服务。
表现层只需要处理和页面的交互，业务逻辑通过调用服务层的服务来实现。