细数Java技术架构这些年的发展史

前言

Java一度被称为是应用最广泛的编程语言。尤其在Java web方面，Java作为后台服务器开发语言，尤其是它跨平台一次编译随处运行的特性，更是受到不少企业和工程师们的爱戴。作为应用开发的主要语言，Java也需要借助其他很多优秀的框架，来实现系统或程序的完整性。针对不同的业务场景，选择合适的框架，是每一个架构师和工程师在开发一项软件之前，必须首先要考虑的事情。随着时代的进步和科技的发展，Java技术框架也在日新月异的进化。

一、Struts1.0

Struts1.0是早期的应用很广泛的web框架了，很多企业的管理系统和网站都是基于这个技术架构做的。Struts的第一个版本是在2001年5月份发布的。它的最初设想是：通过结合JSP和Servlet，使Web应用的视图和业务/应用逻辑得以清晰地分离开来。在Struts之前，最常见的做法是在JSP中加入业务和应用逻辑，或者在Servlet中通过println()来生成视图。

整体框架结构
基本流程是：

• 客户端发送请求（Http Request），被struts1的核心控件器ActionServlet接收。
• ActionServlet根据struts-config.xml里的映射关系找到对就的Action，若找不到就返回500错误到JSP页面。若有就在Action里的 excute()方法里执行相应的逻辑操作，比如调用Model层的方法，然后通过ActionForward，跳转到对应的JSP页面。

具体图示如下：

详细的工作原理流程如下：

二、Struts2.0

自从第一版发布以来，Struts实际上已成为业界公认的Web应用标准。Struts2.0是对1.0的改进。更完美的提现了MVC的强大之处。它是在Struts1.0的成功经验基础上继续坚持对 前端控制器（Front Controller） 和 MVC（model-view-controller）模式 进行改进。

先来看看Struts官方站点，对于Struts2.0的架构介绍：

一个请求在Struts2框架中的处理大概分为以下几个步骤(可查看源码：https://github.com/apache/struts):
1 客户端初始化一个指向Servlet容器（例如Tomcat）的请求
2 这个请求经过一系列的过滤器（Filter）（这些过滤器中有一个叫做ActionContextCleanUp的可选过滤器，这个过滤器对于Struts2和其他框架的集成很有帮助，例如：SiteMesh Plugin）
3 接着FilterDispatcher（现已过时）被调用，FilterDispatcher询问ActionMapper来决定这个请是否需要调用某个Action
4 如果ActionMapper决定需要调用某个Action，FilterDispatcher把请求的处理交给ActionProxy
5 ActionProxy通过Configuration Manager询问框架的配置文件，找到需要调用的Action类
6 ActionProxy创建一个ActionInvocation的实例。
7 ActionInvocation实例使用命名模式来调用，在调用Action的过程前后，涉及到相关拦截器（Intercepter）的调用。
8 一旦Action执行完毕，ActionInvocation负责根据struts.xml中的配置找到对应的返回结果。返回结果通常是（但不总是，也可 能是另外的一个Action链）一个需要被表示的JSP或者FreeMarker的模版。在表示的过程中可以使用Struts2 框架中继承的标签。在这个过程中需要涉及到ActionMapper

在上述过程中所有的对象（Action，Results，Interceptors，等）都是通过ObjectFactory来创建的。

三、SSH框架

前几年，只要大家一说起Java，尤其是Java web编程，大家最先想到的技术便是SSH三大框架了。对于一些初级学者来说，只知其一不知其二，没有对SSH三大框架有更深入的研究和学习。

官方的说法：SSH是 struts+spring+hibernate的一个集成框架，是目前较流行的一种web应用程序开源框架。SSH不是一个框架，而是把多个框架（Struts、Spring以及Hibernate）紧密的结合在一起，用于构建灵活、易于扩展的多层Web应用程序。

Java EE架构大致分为以下几个层次：

• 实体层（POJO层）
• 数据访问层（DAO层）
• 业务逻辑层（Service层）
• 控制器层（Controller层）
• 表现层（View层）

其中SSH框架的系统从职能上分大致可以分为四层：表示层、业务逻辑层、数据持久层和域模块层(实体层)。

由SSH构建系统的基本业务流程是：

1、在表示层中，首先通过JSP页面实现交互界面，负责传送请求(Request)和接收响应(Response)，然后Struts根据配置文件(struts-config.xml)将ActionServlet接收到的Request委派给相应的Action处理。

2、在业务层中，管理服务组件的Spring IoC容器负责向Action提供业务模型(Model)组件和该组件的协作对象数据处理(DAO)组件完成业务逻辑，并提供事务处理、缓冲池等容器组件以提升系统性能和保证数据的完整性。

3、在持久层中，则依赖于Hibernate的对象化映射和数据库交互，处理DAO组件请求的数据，并返回处理结果。

采用上述开发模型，不仅实现了视图、控制器与模型的彻底分离，而且还实现了业务逻辑层与持久层的分离。这样无论前端如何变化，模型层只需很少的改动，并且数据库的变化也不会对前端有所影响，大大提高了系统的可复用性。而且由于不同层之间耦合度小，有利于团队成员并行工作，大大提高了开发效率。

四、Spring MVC

Spring MVC属于SpringFrameWork的后续产品，已经融合在Spring Web Flow里面。Spring 框架提供了构建 Web 应用程序的全功能 MVC 模块。SpringMVC是一种web层的mvc框架，用于替代servlet（处理响应请求，获取表单参数，表单验证等）

1. 整体流程

具体步骤：

• 首先用户发送请求到前端控制器，前端控制器根据请求信息（如 URL）来决定选择哪一个页面控制器进行处理并把请求委托给它，即以前的控制器的控制逻辑部分；图中的 1、2 步骤；
• 页面控制器接收到请求后，进行功能处理，首先需要收集和绑定请求参数到一个对象，这个对象在 Spring Web MVC 中叫命令对象，并进行验证，然后将命令对象委托给业务对象进行处理；处理完毕后返回一个 ModelAndView（模型数据和逻辑视图名）；图中的 3、4、5 步骤；
• 前端控制器收回控制权，然后根据返回的逻辑视图名，选择相应的视图进行渲染，并把模型数据传入以便视图渲染；图中的步骤 6、7；
• 前端控制器再次收回控制权，将响应返回给用户，图中的步骤 8；至此整个结束。

2. 核心流程

具体步骤：

• 第一步：发起请求到前端控制器(DispatcherServlet)
• 第二步：前端控制器请求HandlerMapping查找 Handler （可以根据xml配置、注解进行查找）
• 第三步：处理器映射器HandlerMapping向前端控制器返回Handler，HandlerMapping会把请求映射为HandlerExecutionChain对象（包含一个Handler处理器（页面控制器）对象，多个HandlerInterceptor拦截器对象），通过这种策略模式，很容易添加新的映射策略
• 第四步：前端控制器调用处理器适配器去执行Handler
• 第五步：处理器适配器HandlerAdapter将会根据适配的结果去执行Handler
• 第六步：Handler执行完成给适配器返回ModelAndView
• 第七步：处理器适配器向前端控制器返回ModelAndView （ModelAndView是springmvc框架的一个底层对象，包括 Model和view）
• 第八步：前端控制器请求视图解析器去进行视图解析 （根据逻辑视图名解析成真正的视图(jsp)），通过这种策略很容易更换其他视图技术，只需要更改视图解析器即可
• 第九步：视图解析器向前端控制器返回View
• 第十步：前端控制器进行视图渲染 （视图渲染将模型数据(在ModelAndView对象中)填充到request域）
• 第十一步：前端控制器向用户响应结果

五、分布式

到了最近几年，分布式框架中RPC和SOA等微服务架构中，主流的Java开发框架以SpringBoot/Cloud、Dubbo等分布式微服务尤为热门。

    1.RPC

RPC（Remote Process Call），即远程服务调用，被广泛地应用在很多企业应用中，是早期主要的服务治理方案，其流程较为简单，客户端consumer携带参数发送RPC请求到服务提供方provider，provider根据参数路由到具体函数，方法，并将执行获得的结果返回，至此一次RPC调用完成。

     2.SOA

由于简单的RPC调用已经不能随着时代发展满足需求，因此复杂的业务逻辑对于分布式应用架构体系的需求愈发强烈，业务希望自己的服务是分布式部署的，请求是分流的，对数据的操作是能读写分离的，同时能屏蔽许多复杂需要自己编写的底层服务，借助已有的公共服务，去快速的构建自己的应用，降低人力开发维护的成本和提高应用交付的效率，基因此，基于分布式服务思想的SOA（Service-Oriented Architecture）成了新的受追捧的架构。常见的SOA服务调用流程图如下：　

　　

五、业界服务治理方案

业界的互联网巨头公司，都有属于自己的分布式服务框架，如阿里巴巴的Dubbo，HSF，腾讯的Tars，京东的JSF，新浪的Motan，都已经是业界非常成熟的解决方案，其中开源的Dubbo和Motan受到了广大开发者的研究对象。

　　纵观这些服务框架，设计的基本思路都如上图，无非涉及provider发布注册，consumer订阅，调用发起，负载均衡，服务分流和监控等模块，并在此基础上增加了很多玩法，形成了各具特色的分布式服务框架设计，下面就Dubbo，JSF，Motan的设计做下简单的介绍。

（1）Dubbo：下图是Dubbo在服务治理方面的架构设计

　　初始化阶段：部署在Container的Provider启动后向服务中心Registry发布并注册自己的服务，客户端Consumer初始化时即向Registry订阅自己想要的服务，同时Registry对Consumer保持着一个长连接，当订阅的服务新增或减少节点时，会及时通知到客户端更新（此过程是异步进行的，不会影响Consumer的主流程），如此一来，客户端Consumer便有了Provider的所有实时信息，便可以发起服务调用了。

　　invoke阶段：客户端Consumer从获得的所有Provider列表中通过负载均衡等策略选出最适合调用的服务提供者Provider并发起同步调用。

　　Monitor阶段：Consumer和Provider通过异步的方式向监控中心上报自己的需要被监控的数据。

　　

　　（2）JSF：下图是JSF在服务治理方面的架构设计

　　初始化阶段：Provider启动后向服务注册中心发布注册自己的服务

　　invoke阶段：与Dubbo不同的是，JSF的注册中心不向Consumer推送Provider实时数据，而是在发起调用时Consumer向注册中心询问并获得对应的Provider，然后组织匹配JSF协议的报文发起调用。

　　Monitor阶段：Provider定期向监控中心发送性能统计数据，同时Provider还会上报事件给事件中心。

　　

　　（3）Motan：Motan是有名的轻量级服务框架，代码质量很高，下图是Motan在服务治理方面的架构设计

　　Motan的服务治理设计与Dubbo十分的相似，都是Provider发布注册，Consumer订阅与接受推送，之后发起调用。

　　

六、分布式服务框架主要模块名词释义

　　无论是那种SOA的架构设计，都离不开几个模块的功能，即Provider，Consumer，Registry，Gateway，负载均衡，服务分流，监控等，通过上述所讲，应该对这些功能模块有了初步的认识，下面就这些名词再作下介绍

　   （1）Provider：服务提供者，无论是业务服务，还是一个系统中公用的SAAS，都属于Provider

　　（2）Consumer：即发起调用的客户端

　　（3）Registry：服务注册中心，是分布式服务系统中的一个重要组成模块，管理Provider的Manager，在实际的运行环境中，服务注册中心Registry被动通知或Consumer主动询问，在Provider有节点宕机或新增节点时，客户端也可实时感知到，从而避免了某个Provider被无限调用或是无限闲置

　　（4）Gateway：网关也是分布式服务框架中不可或缺的部分，每种系统与框架都有自己的一套协议，当异构系统互相调用时，网关的作用即显现出来，Gateway接受各种外部HTTP请求，完成相应的权限校验，报文适配，路由转发到对应的Provider，再将Provider返回的结果传递给异构系统的Consumer，完成异构系统的互相调用

　　（5）负载均衡，服务分流：Consumer从Registry获得具体的Provider列表后，如何选取合适的Provider，取决与一定的负载均衡算法，常见的算法有轮询法，随机法，源地址哈希，加权轮询，加权随机等

　　（6）监控：接收来自Consumer和Provider异步上报的性能监控数据，对有风险的节点发出告警。

关注公众号： 程序大视界

觉得对你有帮助，关注博客和公众号。不定期分享最新前沿技术框架和bat大厂常用技术等，加群不定期分享行业内大牛直播讲课以及获得视频课件资料等。