MVC框架，webx 流程解读
写在前面的话 写这篇文章的目的，主要还是站在一个新人的角度做一些沉淀，同样也为了方便后面的人快速熟悉集团web开发常用技术。这篇文章，将分析一个请求发到服务端，经tomcat容器、webx映射直到最后调用controller入口的过程，对java web基础知识结合webx做一个整体回顾。同时，也将简单分析集团web的基本分层方式，以及VO、DTO、DO等数据实例在各层所起的作用。 Web容器 理解web容器，也是理解我们程序的运行平台，同时也是了解servlet处理流程的基础所在。tomcat的主要结构如下图： Connector Connector是tomcat的连接器。Tomcat在监听80端口的时候，一个HTTP请求访问过来，实际上是通过在80端口用socket来输入HTTP报文。Connector通过socket读取报文文本并进行解析，然后将报文内容封装为request实体，并将响应结果利用response进行封装，新起一个线程，并交给container容器进行处理。 Container container是所有子容器的父接口。Engine主要负责对请求进行分发，而Host就是tomcat虚拟host功能的实体，Context就是我们一个应用服务的完整环境，每次一个请求对应的一个新的servlet，都是封装在Context中的。 Tomcat在处理Connector传来的request和response时，就是通过责任链模式，一层一层的去调用Engine、Host、Context并封装出一个servletWrapper来进行doService操作。 Servlet处理流程及WebX的调用 上面简单介绍了一下Tomcat的容器结构，接下来具体分析处理一个请求的过程。 tomcat容器执行过程 请求到达后，会新起一个线程并由Container进行处理。 Container中的Engine、Host、Context、Wrapper都继承了ValveBase抽象类并实现了其invoke方法。这也类似于webx的pipeline，对请求进行流水线处理。 首先是StandardEngineValve的invoke。engine通过对请求host域名的解析，映射到合适的host容器中去，然后调用host的invoke方法。 StandardEngine engine = (StandardEngine)this.getContainer(); Host host = (Host)engine.map(request, true); if(host == null) { ((HttpServletResponse)response.getResponse()).sendError(400, sm.getString("standardEngine.noHost", request.getRequest().getServerName())); } else { host.invoke(request, response); } 在host的invoke中，实际是调用了流水线的invoke方法： public void invoke(Request request, Response response) throws IOException, ServletException { this.pipeline.invoke(request, response); } 最终又调用到standardPipeline中的invokeNext： public void invokeNext(Request request, Response response) throws IOException, ServletException { Integer current = (Integer)this.state.get(); int subscript = current.intValue(); this.state.set(new Integer(subscript + 1)); if(subscript < this.valves.length) { this.valves[subscript].invoke(request, response, this); } else { if(subscript != this.valves.length || this.basic == null) { throw new ServletException(sm.getString("standardPipeline.noValve")); } this.basic.invoke(request, response, this); } } 可以看到流水线的设计模式是将engine、host、context等容器的实例放进一个数组中，并在运行时依次执行。 然后就到了StandardHostValve中，同样实行invoke方法： StandardHost host = (StandardHost)this.getContainer(); Context context = (Context)host.map(request, true); 逻辑也类似，就是找到对应的context，也就是我们的应用并调用invoke方法。 context的invoke主要做了两件事： 1、获取session并绑定 2、找到该url对应的wrapper，并调用wrapper的invoke方法。 这里先略过session的获取绑定过程，直接来到wrapper的调用中去。在servletWrapper中，我们可以看到几个熟悉的对象： StandardWrapper wrapper = (StandardWrapper)this.getContainer(); ServletRequest sreq = request.getRequest(); ServletResponse sres = response.getResponse(); Servlet servlet = null; HttpServletRequest hreq = null; servlet会通过wrapper进行分配： servlet = wrapper.allocate(); 从allocate方法中，我们可以看到servlet实际是通过类加载器记载的，并且当servlet加载完毕后，会调用初始化方法init。 classClass = classLoader.loadClass(actualClass); ... servlet = (Servlet)classClass.newInstance(); ... servlet.init(this.facade); 有了servlet以后，就开始出现另一个重要角色：ApplicationFilterChain。FilterChain会传入request和response并对servlet进行过滤： filterChain.doFilter(sreq, sres); 在doFilter中，会调用到internalDoFilter 方法。该方法对filters进行遍历调用： this.iterator = this.filters.iterator(); ... filter.doFilter(request, response, this); 可以看到，FilterChain 采用链式模式，通过多次调用chain.doFilter(request, response)方法会多次调用internalDoFilter方法，从而通过Iterator调用所有注册的Filter。 Webx执行流程 以一个简单的接口为例子，来看一看webX最终是如何调用到我们的execute方法的。 public class DemoScreen extends BmsBaseModule { public void execute(@Param('param') String param) { ... } } 首先，继续上一部分的Filter开始看。Filter是servlet的标准过滤器，而上部分最后提到的filters则封装了web.xml文件中关于Filter的配置： <filter> <filter-name>webx</filter-name> <filter-class>com.alibaba.citrus.webx.servlet.WebxFrameworkFilter</filter-class> <init-param> <param-name>excludes</param-name> <param-value>*/checkpreload.htm<!-- 需要被“排除”的URL路径，以逗号分隔，如/static, *.jpg。适合于映射静态页面、图片。 --></param-value> </init-param> <init-param> <param-name>passthru</param-name> <param-value><!-- 需要被“略过”的URL路径，以逗号分隔，如/myservlet, *.jsp。适用于映射servlet、filter。 对于passthru请求，webx的request-contexts服务、错误处理、开发模式等服务仍然可用。 --></param-value> </init-param> </filter> 上面是一个典型的webx配置，可以看到，设置的过滤器WebXFrameworkFilter会被ApplicationFilterChain执行。来看其中的doFilter方法： if (isExcluded(path)) { log.debug("Excluded request: {}", path); chain.doFilter(request, response); return; } 校验我们设置的excluded参数，如果需要排除，那么通过doFilter的internalDoFilter来链式调用下一个过滤器。 关键语句在此： getWebxComponents().getWebxRootController().service(request, response, chain); 调用webx RootController的service方法。service中首先对HttpServletRequest 和 HttpServletResponse 实例封装进RequestContext中。后续会调用 WebxRootControllerImpl 的 handleRequest 方法： 然后，会根据路径找到WebxComponent： WebxComponent component = getComponents().findMatchedComponent(path); 在findMatchedComponent中会依据url来进行匹配： for (WebxComponent component : this) { if (component == defaultComponent) { continue; } String componentPath = component.getComponentPath(); if (!path.startsWith(componentPath)) { continue; } // path刚好等于componentPath，或者path以componentPath/为前缀 if (path.length() == componentPath.length() || path.charAt(componentPath.length()) == '/') { matched = component; break; } } webx在Spring启动的时候，通过对文件目录的扫描，装配进符合规则的组件Component，比如xxx.module.screen下的类，来和url做匹配。找到对应的component后： served = component.getWebxController().service(requestContext); 然后就到了webx的pipeline处理流程： public boolean service(RequestContext requestContext) throws Exception { PipelineInvocationHandle handle = pipeline.newInvocation(); handle.invoke(); // 假如pipeline被中断，则视作请求未被处理。filter将转入chain中继续处理请求。 return !handle.isBroken(); } pipeline 同样是链式模式，会依次调用注册的valve。常用的valve可能包括url检查、登录检查、csrfToken校验等，同样pipeline中的一些条件语句比如Choose、Loop等同样也是一个valve，调用其invoke方法其实也是生成了一个新的pipeline并执行invoke。比如这样一个when-otherwise语句中就会有如下代码： if (!satisfied && otherwiseBlock != null) { otherwiseBlock.newInvocation(pipelineContext).invoke(); } 此外，比较重要的valve就是负责处理表单的PerformActionVavle、负责执行screen的PerformScreenValve。 因为screen在应用中经常是一个接口的入口，并最终调用到业务逻辑部分的代码。所以这里我们分析一下PerformScreenValve这个阀门是如何调用到我们的业务逻辑代码的。screenValve的invoke最终调用了performScreenModule函数。显示依据规则找到了我们的module，然后执行了execute方法： Module module = finder.getScreenModule(); ... module.execute(); 然后调用了DataBindingAdapter的execute方法： private final MethodInvoker executeMethod; ... executeMethod.invoke(moduleObject, log); 在MethodInvoker这个类里面，我们可以看到装配execute方法参数的过程。 首先，在扫描类中注解的时候，webX会为每一个execute方法中有@Param注解的参数生成一个DataResolver。MethodInvoker中会有如下代码获取参数，最终会调用FastMethod的invoke方法。 Object[] args = new Object[resolvers.length]; for (int i = 0; i < args.length; i++) { Object value; value = resolvers[i].resolve(); } ... fastMethod.invoke(moduleObject, args); 最后就是反射调用的过程了，我们的接口object即为moduleObject，而args即为带有@Param注解的参数。最终的整体调用流程如下图： 项目分层 关于web层、service层、manager层与DAO层 执行到我们发布的接口后，再来简单的说一下web项目常见分层手段。 在我们的项目中，常见的是依次调用web层，service层，manager，dao层。数据实体在VO、DTO、DO之间流转。 因为在执行某个业务的时候，可能需要查询多个表的数据并进行拼接。比如现在需要这样一条数据D，由A，B，C组成。如果仅仅提供一个方法查询A、B、C并拼接为D返回，那么下次如果又有一个需求为E（A+B)的数据，无疑又要重新写查询A和B的代码并拼接。 这样，我们把代码分层，使各部分职责独立。其中service负责拼接，manager负责查询，这样不同的service可以对manager进行复用。同时，由于DTO和DO不是完全对应，查询的时候往往要把DTO转换成DO查询条件去调用DAO，而DAO返回的结果DO又和web层所需要的数据格式不一致，所以常常要转换成DTO。 manager的作用，就是处理DTO到DO，然后DAO生成DO再到DTO的过程。如下就是一个manager： BmsPurchaseOrderQuery purchaseOrderQuery = new BmsPurchaseOrderQuery(); purchaseOrderQuery.setPurchaseCode(purchaseCode); List<BmsPurchaseOrderDO> orderDOList = bmsPurchaseOrderDAO.select(purchaseOrderQuery); Assert.notEmpty(orderDOList); return orderDOList.get(0); 假设查询了订单的数据。然后再来一个manger查询订单明细的数据： @Override public List<BmsPurchaseOrderTransOutInfoDO> getTranOutInfoListByCode(String subscribeCode) { //查询子单明细 BmsPurchaseOrderTransOutInfoDO transOutInfoQuery = new BmsPurchaseOrderTransOutInfoDO(); transOutInfoQuery.setSubscribeCode(subscribeCode); List<BmsPurchaseOrderTransOutInfoDO> transOutInfoDOList = bmsPurchaseOrderTransOutInfoDAO.select(transOutInfoQuery); Assert.notNull(transOutInfoDOList); return transOutInfoDOList; } 然后，在service对订单和明细进行拼接。 总而言之，分层如下： web层（也就是webX中的screen）：处理表单，调用服务，返回结果 service层：业务逻辑，数据拼接 manager层：粒度比较细的查询 dao层：sql语句映射 分层可能会导致代码量增大，但是可以提高程序的可复用性，方便程序维护。 总结 至此为止，关于webx服务的请求处理的来龙去脉简单的分析了一遍。了解大致处理流程还是比较有必要的，这样当我们的程序出现异常，可以及时的定位问题。当打断点时，面对层层的调用栈也不会显得不知所措。当然，在这里也是对自己经常接触到的技术做一个简单的沉淀。
