初始请求先发送到服务器小程序容器（譬如Tomcat），然后通过一系列过滤器传送。如果与Site Mesh插件等其他技术集成，可选的ActionContextCleanUp过滤器就很有用，要是用到这个过滤器，请求先通过它传送。

接着，调用请求的FilterDispatcher，它使用ActionMapper来确定要不要为这个请求调用动作。如果ActionMapper确定应当调用Action，FilterDispatcher就把控制权委托给ActionProxy。

ActionProxy使用了框架配置文件管理器，该管理器通过struts.xml文件来初始化。然后，ActionProxy创建ActionInvocation，它负责实现命令模式。ActionInvocation进程调用所需的拦截器，然后调用Action。一旦该Action执行，ActionInvocation就负责查寻与struts.xml中映射的Action结果代码相关的合理结果。

然后结果被执行，大多数时候，这会显示用FreeMarker或者Velocity编写的JSP或者模板。按照相反顺序完成Action之后，拦截器再次得到执行。最后，响应通过web.xml中配置的过滤器返回。如果ActionContextCleanUp过滤器经过配置，FilterDispatcher就不会清理ThreadLocal ActionContext（ActionContext拥有运行时请求和响应的全部细节，该框架使用ThreadLocal以及ActionContext类来提供配置及其他运行时细节）。如果ActionContextCleanUp过滤器未经配置，FilterDispatcher就会清理所有的当前ThreadLocal。图1描述了Struts 2框架的架构。

下面提供一个典型的架构请求流程，图2显示了这个顺序。

1．用户请求对Web应用执行某个动作后，Web浏览器将要求某些资源的请求发送到Web服务器。

2．服务器小程序过滤器调度程序接到请求后，分析请求，然后确定调用相应的动作，提供资源。

3．在Action被执行之前，经配置后把一些常见功能（如验证、工作流或者文件上传）作用到请求上的一组拦截器上，可自动作用到该请求上。

4．Action类的一个新实例被创建，然后执行动作方法，用于把信息存储到数据库，或从数据库获取信息。

5．结果显示输出——无论输出的是HTML、图像、PDF还是其他某种格式。

6．然后，请求按照相反顺序通过拦截器传送。返回的请求允许执行其他的处理或者清理操作。

7．最后，容器把输出发送到浏览器。