【正文】 對 webx 層做接口測試 ， 就是對 action 與 screen 來做測試，它們的區(qū)別是： (1) screen 就相當于 select 查詢，比如請求一個鏈接 ，就會有 GetUserScreen 中的 execute 方法來獲得用戶信息，然后將其渲染到 ge 顯示到頁面。 淘寶的一個系統(tǒng)一般會有多個子工程，有個工程是 web 的，我們要做的接口測試就是在src/main/java/… /module 下 面，有 action 與 screen。 所有配置文件都放在 WEBINF 目錄下。這個文件定義了 Webx 所用到的所有 services 的配置。對于程序的排錯至關重要。 Screen 和 control 都可以有 java 類來驅動，但不是必須的， 第 17 頁 也就是說可以先寫模板，后寫類，也可以只寫模板，不用構造對應類。 2） 稱為 Servlet Path。 根據(jù) target 查找 screen 模板： /screen/ 假如 target 的值為： /xxx/yyy/ ，那么， valve 會： 1）在 /templates/screen 目錄下，找到 /xxx/yyy/ 模板。 webx3 包含的東西很多，也不依附于 struts、 webwork 或 spring mvc 等框架的原有模型，完全基于自己的一套模型和機制，但從主線條上看是非常簡單明 了的，總結為一點就是通過pipeline 與 valve 把各種處理和擴展串聯(lián)起來 ， 形成對 web 請求和返回過程中所有點的支持。 if (broken) { return。 if (executingIndex ) { Valve valve = valves[executingIndex]。 } catch (Exception e) { throw new PipelineException(Failed to invoke + descCurrentValve() + : + valve, e)。 executedIndex == executingIndex) { if (()) { ({} execution was interrupted by {}: {}, new Object[] { descCurrentPipeline(), descCurrentValve(), valve })。使得下一個 valve 能得力執(zhí)行，以上代碼細節(jié)無需太多解析，思路與 j2ee的 filter 和 webwork 的 interceptor 如出一轍 。 setLoggingContext / ! 分析 URL，取得 target。 plconditions:targetextensioncondition extension=null, vm, jsp / performAction / performTemplateScreen / renderTemplate / /when when ! 執(zhí)行不帶模板的 screen，默認無 layout。 breakUnlessTargetRedirected / /loop /services:pipeline 從以上配置代碼不然發(fā)現(xiàn)，這種 schema 還包含了流程控制的元素，除了各個 valve 的順序執(zhí)行，還可以進行循環(huán)和 條件控制。 透過細節(jié)看本質， webx3 在這兩塊的架構核心可以歸結為以下幾個點 。 } 不同的執(zhí)行器通過 Adapter 的模式統(tǒng)一為 Module， 實現(xiàn) execute 方法，完成對 Action 或Screen 的調用。 i 。 return。amp。 } catch (InvocationTargetException e) { throw (Exception) ()。 } 它的實現(xiàn)類有以下幾種： FormResolver：解析整個 Form GroupResolver：解析一個 group GroupsResolver：解析一組 group FieldResolver：用來解析 單個參數(shù) FieldsResolver：用來解析一組字段 ParameterResolver：用來解析單個參數(shù) ParametersResolver：用來解析一組參數(shù) TurbineRunDataResolver：用來注入各種環(huán)境信息，比如 request 和 response 具體的實現(xiàn)的基本思路就是通過 Annotation 得到各個參數(shù)的結構和配置，然后從 request 里組裝成需要注入的對象，以 FiledResolver 為例，源碼如下： public FieldResolver(DataResolverContext context, Class? paramType, FormField fieldAnnotation) { super(FieldResolver, context)。 skipIfInvalid = ()。 boolean valid = ()。 if (valid) { try { return (().getRawType(), 第 25 頁 context .getExtraObject(), null)。其他 Resolver 的實現(xiàn)類似，就不在累述。 Action 開發(fā) 作用： action 一般用于處理 form 提交，處理完之后再將結果給一個模板去進行渲染。 import 。 import 。 /** * 類目相關操作的 action * * author argan * */ public class CategoryAction extends TemplateAction {//0. 繼承基類 /** 。 import 。 import 。 （ 4） Action 類的實現(xiàn)如下： package 。 其開發(fā)分三部分，頁面層（ web）、業(yè)務處理層 (biz)、數(shù)據(jù)處理層 (dao)。 } } } return null。 return field。 Group group = (groupName, groupInstanceKey)。 // 確保 field 存在 fieldName = getFieldConfig(groupName, ()).getName()。 2） action 參數(shù)自動注入 以上代碼可以看出，反射調用中最核心的是對各種方法所需參數(shù)的自動注入，比如一個 action 的方法： public void doGreeting(FormGroup(simple) SimpleObject simple, Navigator nav) 第 24 頁 webx 可以自動通過用戶提交的 request 組裝成業(yè)務對象 SimpleObjec 和導航類 Navigator，這個特性非常神奇，也很實用。 } args[i] = value。 } // 特別處理：防止對 primitive 類型設置 null Class? paramType = ().getParameterTypes()[i]。 第 23 頁 try { value = resolvers[i].resolve()。 1） 類的反射與執(zhí)行 從上面分析可以得知，所有 Action 和 Screen 的調用都是通過 Module 來 execute 的，這樣勢必需要反射各個 Action 和 Screen， webx 通過構造 MethodInvoker 這個類來統(tǒng)一處理類的反射和執(zhí)行，它的核心方法是 invoke，源碼如下： public void invoke(Object moduleObject, Logger log) throws Exception { Object[] args = new Object[]。 webx 要達到的效果是開發(fā)者開發(fā)的 Action和 Screen 是簡單無累贅的 POJO，類似于 webwork。今后會對幾個核心的 valve 作進一步詳細分解，這樣才能有利于在具體開發(fā)中得心應手 。 plconditions:pathcondition name=/petstore/images/(.+) / getResource name=/petstore/images/$1 / /when otherwise ! 將控制交還給 servlet engine。假如 request 和 session 中的 token 不匹配， 則出錯，或顯示 expired 頁面。 prepareForTurbine / ! 預備 webx 所需的對象。 } } } finally { executingIndex。 } } if (executedIndex amp。 第 19 頁 } (this)。 if (executingIndex = executedIndex) { throw new IllegalStateException(descCurrentValve() + has already been invoked: + valves[executingIndex])。其實 webx 的 pipeline 和 j2ee 的 filter 和 webwork 的 interceptor 很類似，只不過 pipeline 與 valve 更加純粹，干脆就不區(qū)分哪些為攔截，哪些為核心業(yè)務處理，直接把所有處理都統(tǒng)一為 valve。 1）如果存在 layout 布局，則渲染 layout，執(zhí)行 screen 類，并渲染 screen 模板 2）根據(jù) target 查找 layout 模板 渲染 layout 模板 渲染在 layout 模板中引用的兩個 control： ： 在 中查找 /control/ ：在 中查找 /control/ 通過上面的步驟，一個請求就得到響應。 3） Webx Controller Servlet 激活 pipeline，繼而調用 AnalyzeURLValve 來分析 /logi 是什么意思。 分析 URL 的成分，取得 target： / 具體過稱如下： 1） fuwuxian 稱為 Context Path。 上面的為文件下的文件和我們的接口測試沒有太大關系，接口測試要測試的地方在下面的目錄中： src/main/java/… /module?？梢钥醋?webx 框架的總控文件。隨著應用變得 復雜，還會創(chuàng)建其它的配置文件。如圖： 其中 ，有個目錄是主要的 。 示例代碼： 按照 Webx 規(guī)范，是這么區(qū)分的，但是 action 與 screen 能做同樣的事，有時候開發(fā)可能不太會去嚴格的區(qū)別它們，有些開發(fā)主要關注能實現(xiàn)功能即可。 第 14 頁 頁頭 Head、 菜單 Menu、 頁腳 Foot，這些通常是變化不大的，都可以做成 control 小控件； 頁中 Middle，這塊通常是變化比較大的，可以做成 screen。持久層使用 ibatis， Bean 容器使用的是 Spring。幾乎所有的框架都會說自己的擴展性多高，性能多好，而很少會提到監(jiān)控有多強、排錯有多容易，很少提到在故障時怎么做隔離，怎么做降級；從這個角度看，商用的產品確實做得好很多；關于性能相關的文章搜索一下，很多，各種優(yōu)化策略，各種優(yōu)化方法，而可用性方面，找到的系統(tǒng)性的知識真的很少；希望是我了解的不多。天網(wǎng)在控制了所有的美軍的武器裝備后不久，獲得自我意識，并且認定人類是它存 在的威脅。究其根本，是對人的關注不夠，缺少的產品化的服務運維，缺少服務治理。 關注系統(tǒng)和人的交互 還有一個故事，在 數(shù)據(jù)層的前期版本，為了做到透明的路由，曾經(jīng)采用無 SQL 的方式，所有的數(shù)據(jù)庫訪問都是寫代碼來做。開始實施后一段時間，又仔細回想了一下商品的整體需求，突然發(fā)現(xiàn)商品其實不需要和訂單同等的要求，一定要采用高成本的主數(shù)據(jù)庫嗎？ 全部采用低成本的普通服務器來做數(shù)據(jù)庫是否可行？經(jīng)過仔細的