構建高延展性的WEB互動式系統（上），構建高延展性web

構建高延展性的WEB互動式系統（上），構建高延展性web

文章來源：http://www.zaojuzi.com/nirenju/1287.html

延展性是一種對軟體系統處理能力的設計指標，高延展性代表一種彈性，在系統擴充過程中，能夠保證旺盛的生命力，通過很少的改動，就能實現整個系統處理能力的增長。

　　在系統設計的時候，充分地考慮系統的延展性，一方面能夠極大地減少日後的維護開銷，並協助決策者對於投資所能獲得的回報進行更加精準的估計；另一方面，高延展性的系統往往會具有更好的容災能力，從而提供更好的使用者體驗。

　　WEB互動式系統的延展性主要體現在兩個方面：

• 平台的延展性：隨著WEB技術的發展，越來越多的平台開始使用WEB技術來構建系統，一方面不同的平台提供的環境支援存在著各種差異；另一方面隨著平台的發展，不斷的會有一些舊平台退出曆史舞台，新平台轉而成為主流平台；因此構建的WEB系統需要能夠快速的響應此類變化就需要其具備良好的平台伸縮性
• 模組的延展性：隨著系統功能不斷增刪更新需求的變化，系統可能會變得越來越複雜，冗餘資訊也可能會越來越多，改動所帶來的影響範圍也可能會越來越大，因此良好的模組伸縮性可保證系統具有良好的可維護性，讓系統始終處於最佳狀態

　　WEB互動式系統的主要應用程式套件括：

• 案頭端/移動端網站類系統（如 網易雲課堂、易信WebIM、Lofter移動WEB版等）
• 移動混合應用（如 網易雲相簿IPad版、Lofter等）
• 案頭混合應用（如 網易雲音樂PC版、網易郵箱助手等）

　　本系列文章主要分為兩個主要部分對延展性進行闡述，分別是平台的延展性和模組的延展性。本文是系列文章的第一篇，討論平台的延展性。

　　平台的延展性

　　WEB互動式系統對平台的延展性主要表現為：

• 可擴充性：對於新興平台能夠快速進行支援
• 可縮減性：對於過時的平台冗餘資訊能夠以最小的修改方式剔除

　　我們先介紹一下WEB互動式系統的目標平台的情況。

　　平台分類

　　根據系統所在容器的差異，我們將平台分為瀏覽器平台和混合應用平台兩大類。各分類的詳細說明見下文所述。

　　瀏覽器平台

　　按引擎劃分

　　瀏覽器平台，按照主流引擎可以劃分為以下幾類：

　　混合應用平台

　　根據混合應用的宿主平台的差異，我們將混合應用的目標平台分為以下幾類：

宿主	說明
Android	Android系統的混合應用，瀏覽器引擎會自動適配至Webkit
iOS	iOS系統的混合應用，瀏覽器引擎會自動適配至Webkit
WinPhone	Windows Phone系統的混合應用，瀏覽器引擎會自動適配至Trident
PC	案頭應用，採用CEF做為容器，瀏覽器引擎會自動適配至Webkit

　　平台適配

　　AOP（Aspect-Oriented Programming）：面向切面的編程範式，其核心思想是將橫切關注點從主關注點中分離出來，因此特定領域的問題代碼可以從標準商務邏輯中分離出來，從而使得主商務邏輯和領域性商務邏輯之間不會存在任何耦合性。

　　這裡我們可以借鑒AOP思想來實現平台的適配策略，結合不同的平台實現邏輯，我們可以認為對於使用規範、標準來實現商務邏輯的部分為我們的主關注點，而不同平台可以做為若干的切面關注點進行封裝，各平台只需關注自己平台下對標準的修正邏輯即可，因此可以通過增加、刪除平台修正的切面邏輯來實現對不同平台的適配。

　　實現時我們首先提取標準商務邏輯，然後各平台根據實際情況實現對商務邏輯的修正：

• 標準商務邏輯：主關注點，這裡主要是使用根據W3C、ES標準來實現的商務邏輯
• 前置平台修正邏輯：領域特定關注點，主要是根據平台特性對標準在該平台下的修正，修正邏輯會先於標準邏輯執行
• 後置平台修正邏輯：同前置平台修正邏輯，也是領域特定關注點，修正邏輯會在標準邏輯執行後再執行

　　根據此思路我們對比以下兩段代碼：

　　代碼一：目前常用的平台適配方式

function doSomething(){    if(isTrident){        // TODO trident implement    }else if(isWebkit){        // TODO webkit implement    }else if(isGecko){        // TODO gecko implement    }else if(isPresto){        // TODO presto implement    }else{        // TODO w3c implement    }}// 上層應用使用doSomething(1,2,3);

　　此方式對所有平台的修正邏輯均在主邏輯中實現，存在以下弊端：

• 對平台特有的修正邏輯耦合在主邏輯中，平台特有的更新必然引起主邏輯的更新
• 對於新增或刪除平台的支援必須修改到主商務邏輯
• 無法分離不必要的平台修正，比如基於webkit引擎的移動平台應用不需要其他平台的修正邏輯

　　代碼二：借鑒AOP思想的平台適配方式

function doSomething(){    // TODO w3c/es implement}// 上層應用使用doSomething(1,2,3);

　　針對Trident平台適配的邏輯，比如 trident.js中

// trident implementdoSomething = doSomething._$aop(    function(_event){        // TODO trident implement    },    function(_event){        // TODO trident implement    });

　　對比代碼一，我們可以發現借鑒AOP思想的介面適配方式分離了標準商務邏輯和平台特有商務邏輯，是否增加平台特有商務邏輯並不會影響主商務邏輯的執行，而對於平台修正邏輯的切入則可以直接通過配置的方式靈活的進行增刪，因此我們可以從中得到以下好處：

• 主邏輯和平台特有邏輯無耦合性，可隨意分離、整合
• 對於新增平台適配只需新加平台特有邏輯即可，而無需影響到主商務邏輯
• 可通過配置控制支援的目標平台，有選擇性的匯出平台特有商務邏輯

　　實現舉例

　　NEJ架構借鑒AOP思想提供了配置式的平台適配系統，對於這部分的詳細資料可參閱NEJ的《依賴管理系統》和《平台適配系統》瞭解更為詳細的資訊，以下僅舉例說明NEJ中適配的使用方式。

　　一個典型的適配控制項結構如所示：

　　這裡的widget.js是控制項商務邏輯實現檔案，在此控制項的實現中會依賴到存在平台差異的API，其依賴代碼如下所示

NEJ.define([    'util/event',    '{platform}api.js'],function(t,h,p){    // TODO});

　　這裡對 {platform}api.js 的處理方式如所示，這裡的./相對於當前的代碼檔案即widget.js檔案所在的目錄

　　這裡的api.js檔案為需平他適配API的標準實現邏輯，而api.patch.js檔案則利用NEJ.patch介面對各平台做按需適配邏輯，同時打包時也根據NEJ.patch介面中對平台的條件識別做按需輸出，由於api.patch.js檔案最終會按需輸出，因此在此檔案中除了使用NEJ.patch做平台適配邏輯外，不允許包含其它商務邏輯。

// 此檔案只能定義NEJ.patch不可執行其他商務邏輯// 打包輸出時僅根據平台配置輸出所需處理邏輯// 實際情況看需求，可將平台相關部分邏輯獨立到單獨的模組中NEJ.define([    './hack.js'],function(h){    // 針對trident平台的處理邏輯    NEJ.patch('TR',function(){        // TODO    });    // 針對gecko平台的處理邏輯    NEJ.patch('GR',[        './hack.firefox.js'    ],function(fh){        // TODO    });    // 針對IE6平台的處理邏輯    NEJ.patch('TR==2.0',['./hack.ie6.js']);    // 針對IE7-IE9的處理邏輯    NEJ.patch('3.0<=TR<=5.0',function(){        // TODO    });    // 這裡必須同hack.js檔案的返回值一致    return h;});

　　最後我們只需要配置產品的目標平台即可輸出平台對應的適配，而不會存在其他平台的額外影響：

<script src="/path/to/nej/define.js?p=wkgktd"></script><script src="/path/to/nej/define.js?p=cef"></script>

　　平台變更

　　通過以上實現舉例我們可以看到當平台發生變更時我們可以快速進行擴充或縮減

　　平台擴充

　　當有新平台需要作為系統目標平台時，我們只需要做以下工作：

• 增加平台配置識別符，如nxw
• 識別該平台與標準存在的差異，增加平台特有商務邏輯至patch

• 系統對平台配置部分增加新添的識別符，如

  原平台適配：<script src="/path/to/nej/define.js?p=wkgktd"></script>

  新增平台適配：<script src="/path/to/nej/define.js?p=wkgktdnxw"></script>

　　即可完成對平台的擴充，而不會影響到原有的商務邏輯。

　　平台縮減

　　當系統適配的目標平台由於某種原因退出曆史舞台時，系統也需要將該平台的冗餘代碼從系統中剔除，我們只需要做以下工作：

• 系統對平台配置部分刪除要剔除的平台標識，如：

  原平台適配：<script src="/path/to/nej/define.js?p=wkgktd"></script>

  縮減後平台適配：<script src="/path/to/nej/define.js?p=wk"></script>

　　即可完成對平台的縮減，而無需修改任何商務邏輯。

　　以上即是有關平台可擴充性的介紹。下一篇將闡述模組的可擴充性，敬請期待！

　　本作品採用知識共用署名 4.0 國際許可協議進行許可。

原文連結地址：http://www.zaojuzi.com/nirenju/1287.html