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