Overview of Traditional Three‑Tier, Cluster, Distributed, and Microservice Architectures for Java Web Applications

1. Traditional three‑tier architecture (all‑in‑one project) – Consists of presentation, business, and persistence layers. In a Struts MVC model the layers are model, view, controller; in Spring MVC a request passes through DispatcherServlet, then controller → service → DAO, finally returning data to a JSP view. Frameworks like Spring MVC, Struts2, MyBatis, and Hibernate simplify development of each layer.

2. Cluster architecture (horizontal scaling) – Deploys the same web application on multiple servers to achieve high availability. A reverse‑proxy (commonly Nginx) performs load balancing, forwarding requests to Tomcat instances. Session sharing is enabled via Tomcat’s Cluster configuration (SimpleTcpCluster, DeltaManager, etc.), allowing seamless failover and consistent user sessions across nodes.

3. Distributed architecture (vertical splitting) – Breaks a monolithic project into separate modules (sub‑systems) that can be deployed on different servers, each potentially forming its own cluster. This improves availability and efficiency but introduces management complexity, especially when a single module fails.

4. Microservice architecture (vertical splitting) – Further refines modules into independent services accessed via HTTP or RPC. Each service can be clustered for high availability. Sub‑sections:

4.1 SOA architecture – Uses service‑oriented design; Dubbo (now deprecated) or Spring Cloud provide RPC communication. Dubbo offers high‑performance socket‑based calls with registries like Zookeeper or Redis, while Spring Cloud relies on HTTP and Eureka.

4.2 Dubbo – Illustrates a typical Dubbo deployment diagram and notes its suitability for complex service call graphs.

4.3 Spring Cloud – Describes the Spring Cloud stack (API gateway Zuul, service registry Eureka, Ribbon load balancer, Feign client, Hystrix circuit breaker, Turbine monitoring) and compares it with Dubbo, highlighting differences in registry options and communication protocols.

Pros of cluster and distributed approaches include high availability and improved performance; cons involve increased complexity and potential unsuitability for very large, high‑concurrency projects.

Code example for Tomcat session sharing configuration:

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster" channelSendOptions="8">
    <Manager className="org.apache.catalina.ha.session.DeltaManager" expireSessionsOnShutdown="false" notifyListenersOnReplication="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>

Images illustrating each architecture are included throughout the original article.