JavaEE架构之传统三层架构，集群架构，分布式架构，微服务架构
的的JavaEE的架构
1.传统三层架构（all in one项目）
传统三层架构大致可以分为表现层，业务层和持久层（数据访问层）。其中表现层负责接受请求和转发请求。业务层负责处理请求（注：事务管理，日志记录等AOP类型的操作均封装在这一层）持久层主要负责数据库与实体之间的操作。
支柱典型的MVC三层架构：模型层，视图层，控制层。
用SpringMVC中的MVC指的是什么：当一个请求到达服务器时，由*控制器的DispatcherServlet（控制层）查找要访问的控制器，然后控制器 - >调用服务 - >调用道，之后将获取的数据返回到JSP页面（视图层）。
即：严格来说在用用用SpringMVC中控制器是DispacterServlet，模型层是控制器（即该模型层又可以看成一个MVC架构），视图层是JSP页面。
另外，利用框架可以简化各层的开发：表现层使用用用用SpringMVC或者Struts2的中的，持久层使用的MyBatis的的或休眠，使用弹簧管理表现层，业务层和持久层三层之间的关系。
2.集群架构（属于水平拓展）
由于传统的三层架构中存在许多问题，比如业务层中的不同模块占用系统资源相差太大，导致占用系统资源，可以使用集群解决问题。（相当于备份多个文件，多台服务器反问的是同一个项目资源，集群架构的目的也是为了系统资源的高可用性。）
在集群架构中存在一个重要的角色就是反向代理服务器，他的任务是实现负载均衡，接收用户请求，转发到目标服务器，其中反向代理服务器可以使用的nginx的的实现（简单来说也就是一个实现负载均衡的算法）。
说明：
（1）集群架构相当于把同一个项目部署到多个服务器上（相当于复制备份），然后通过负载均衡服务器的nginx的的将请求分别均衡的派发到不同的的Tomcat的的服务器上，实际上不同服务器上运行的是同一个网络项目。
（2）大部分能企业通过nginx的的的实现负载均衡算法。
软件层面负载均衡项目：nginx的的，阿帕奇的httpd的的;
硬件负载均衡器：F5。
（2）已经存在两台服务器，如果其中一台服务器的挂掉了，第二台服务器是正常的状态，负载均衡服务器会将所有请求转到第二台服务器，所以访问第二台服务器没有问题。
（4）如果你在访问第一台服务器时，正在购物，此时已经有多件商品被加入购物车了，且购物车数据是通过会话存储的，倘若此时你访问的这台服务器挂掉了，那么负载均衡服务器将你的请求派送到另一台服务器上，那么此时你的购物车里面的数据依然还存在，因为集群的服务器之间的会话是共享的。
（5）不同的的Tomcat的的服务器之间如何做到会话共享？
Tomcat的的的服务器本身就支持会话共享，但是需要在集群的tomcat的的的服务器的配置文件的server.xml中中中做相同的如下配置：
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster" channelSendOptions="8">
<Manager className="org.apache.catalina.ha.session.DeltaManager"
expireSessionsOnShutdown="false"
otifyListenersOnReplication="true"/>
<Channel className="org.apache.catalina.tribes.group.GroupChannel">
<Membership className="org.apache.catalina.tribes.membership.McastService"
address="228.0.0.4"
port="45564"
frequency="500"
dropTime="3000"/>
<Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
address="auto"
port="4000"
autoBind="100"
selectorTimeout="5000"
maxThreads="6"/>
<Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
<Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
</Sender>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
</Channel>
<Valve className="org.apache.catalina.ha.tcp.ReplicationValve"
filter=""/>
<Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
<Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
tempDir="/tmp/war-temp/"
deployDir="/tmp/war-deploy/"
watchDir="/tmp/war-listen/"
watchEnabled="false"/>
<ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
</Cluster>
好处：高可用。
弊端：如果该项目很大，且并发量高，包含多个可拆分的模块（子系统）那就不适用集群架构了。
3.分布式架构（垂直拆分）
分布式架构特点：多个模块完成一个功能，每个模块又可以搭建集群，从而实现高可用。
说明：
分布式架构与集群架构的区别：
（1）集群架构是将同一个完整的项目部署到多台服务器上，通过负载均衡完成请求的派发。而分布式架构是将项目拆分成不同的模块（子系统），然后将不同模块存放在不同的服务器上，所以分布式架构很大的一个特点就是分开还能合作完成一个请求（注：现在云计算就有分布式的的概念）。
（2）简单的分布式架构仍然存在问题，如果其中一个的Tomcat的的服务器挂掉了，则其中一个模块则不可运行了，所以考虑到分布式集群架构，即将一个大系统分成多个独立的模块，部署到多个服务器上，每个模块再考虑存放在多个服务器上形成一个集群，如此才能实现高可用性如下图：
好处：高可用，效率高。
弊端：模块之间的关系不易于管理。
4.微服务架构（垂直划分）
根据产品的业务功能模块划分服务的种类，客户端可以通过基于HTTP或者RPC的方式调用微服务，目的是为了降低所产生的性能开销。同时每个模块仍然可以搭建集群，从而实现高可用。
3.1 SOA架构
说明：
（1）由于基于SOA架构的项目，表现层和服务层是不同的工程，所以要相应一个请求需要两个系统之间进行通信，SOA架构实现系统之间的通信有三种方式：
（2）的网络服务通信：网络服务通信是基于SOA介意的，效率低，项目中不建议使用。
（3）使用宁静形式的服务：HTTP + JSON的方式，很多项目中都有应用，但是当服务过多时，服务之间调用关系复杂混乱，不利于维护。
（4）使用使用RPC协议进行远程调用达博。，直接使用插座通信。传输效率高，并且可以统计系统之间的调用关系，调用次数。（由于多宝阿里公司已经停止更新，建议使用springcloud） 。
3.2 Dobbo
如下图：dubbo体系结构图：
如下是一个典型的基于SOA的电商项目架构图：
说明：如果服务与服务之间存在调用，dobbo可以通过名字去鉴别因为编码时每个模块之间都有调用关系，且该关系也被dobbo掌握。
3.3 SpringCloud
SpringCloud是一个基于Spring Boot实现的服务治理工具包; Spring Boot专注于快速，方便集成的单个微服务个体; Spring Cloud关注全局的服务治理框架。
解释一下这张图中各组件的运行流程：
（1）所有请求都统一通过API网关（Zuul）来访问内部服务。
（2）网关接收到请求后，从注册中心（尤里卡）获取可用服务。
（3）由色带进行均衡负载后，分发到后端的具体实例。
（4）微服务之间通过佯进行通信处理业务。
（5）猬负责处理服务超时熔断。
（6）涡轮监控服务间的调用和熔断相关指标。
SpringCloud和Dobbo的区别：
（1）多宝的注册中心可以选择动物园管理员，redis的的的等多种;
Spring Cloud：的注册中心只能用eureka或者自研;
（2）多宝通过RPC协议远程调用，直接通过插座通信，效率高
SpringCloud通过HTTP协议调用。