在政府機構中, 工商、公安等機構基本都擁有自己的門(mén)戶(hù)網(wǎng)站;在企事業(yè)單位中, 各中大型企業(yè)、醫院、學(xué)校等也有相應的辦公門(mén)戶(hù).在這些門(mén)戶(hù)網(wǎng)站中, 往往會(huì )碰到信息陳舊、板塊空缺、布局雜亂、進(jìn)入層次太深、系統更新緩慢、用戶(hù)很難找到自己關(guān)注信息等問(wèn)題.導致這些現象的因素很多, 有的因為經(jīng)費不足而缺少維護;有的因為測試不全面導致系統穩定性差;有的因為缺少規劃而趕不上發(fā)展速度;還有因為無(wú)法利用現有系統資源, 機構小而沒(méi)有內容支撐門(mén)戶(hù)網(wǎng)站建設等原因.
作為企事業(yè)單位中的信息部門(mén), 面對系統扁平化、個(gè)性化需求的增加, 導致系統定制化趨勢越來(lái)越明顯, 信息部門(mén)除了創(chuàng )建數量龐大的系統來(lái)滿(mǎn)足用戶(hù)不斷變化和增加的需求之外, 還有其他應對措施嗎?大多數人都知道, 傳統網(wǎng)站架構往往是根據業(yè)務(wù)需求、現有團隊等因素考慮設計, 主要解決的是通用需求和當前業(yè)務(wù), 團隊成員之間也相對了解, 能快速完成一個(gè)個(gè)獨立的信息系統.但這樣的系統設計與開(kāi)發(fā)團隊耦合性太緊密, 一旦團隊核心人員變動(dòng), 往往會(huì )導致系統可擴展性和穩定性受到極大的影響, 或一旦需求變化太大, 系統就必須大規模重新設計才能滿(mǎn)足需求.在越來(lái)越依賴(lài)信息化的今天, 需求快速變化是比較正常的, 這就導致上述各種現象.為了規避這些現象, 信息部門(mén)必須具備以下的能力才能夠應對挑戰:1) 持續提高創(chuàng )新能力, 使系統的技術(shù)含量越來(lái)越高, 以滿(mǎn)足客戶(hù)需求;2) 不斷縮短系統研發(fā)時(shí)間, 快速響應用戶(hù)需求;3) 不斷強化成本控制能力, 通過(guò)優(yōu)化產(chǎn)品生命周期內的各種成本來(lái)控制系統總成本, 取得投入產(chǎn)出比優(yōu)勢;4) 持續穩定的質(zhì)量改進(jìn)能力.
經(jīng)驗表明, 設計信息系統一方面必須利用業(yè)務(wù)模塊的批量化、標準化和通用化來(lái)縮短系統上線(xiàn)周期、降低研發(fā)成本、提高模塊重用性和系統穩定性, 另一方面還要不斷地進(jìn)行研發(fā)創(chuàng )新使系統越來(lái)越個(gè)性化, 滿(mǎn)足用戶(hù)的定制需求.這樣, 如何平衡系統的標準化、通用化與定制化、穩定性之間的矛盾, 成為贏(yíng)得競爭的關(guān)鍵因素.基于這兩方面的考慮, 設計一套基于模塊化的彈性擴展門(mén)戶(hù)網(wǎng)站架構.該設計把業(yè)務(wù)拆分為一個(gè)個(gè)模塊, 通過(guò)這些模塊的組合可以向分支機構、下屬單位、甚至崗位、人員提供相應的個(gè)性化門(mén)戶(hù)系統, 不僅解決了企事業(yè)單位整體的系統建設成本, 而且也解決了門(mén)戶(hù)網(wǎng)站內容不足、內容復用、組織機構之間信息交互等問(wèn)題.對軟件開(kāi)發(fā)團隊來(lái)說(shuō), 也解決了系統迭代的穩定性、模塊之間的耦合度、用戶(hù)需求的個(gè)性化、開(kāi)發(fā)團隊分工與協(xié)助等問(wèn)題.
1 系統分析與建模
1.1 架構需求
企業(yè)門(mén)戶(hù)是一個(gè)聯(lián)接企業(yè)內部和外部的網(wǎng)站, 它把各種應用系統、數據資源、業(yè)務(wù)處理與企業(yè)各部門(mén)、分支機構等需求統一集成到門(mén)戶(hù)之下, 可以為企業(yè)提供一個(gè)單一的訪(fǎng)問(wèn)企業(yè)各種信息資源的入口, 企業(yè)的員工、分支機構、合作伙伴等都可以通過(guò)這個(gè)門(mén)戶(hù)獲得個(gè)性化的信息和服務(wù).經(jīng)過(guò)多次整理歸納, 明確了企業(yè)及用戶(hù)對架構的主要需求內容如下:
1) 企業(yè)門(mén)戶(hù)統一入口地址, 針對特定節假日有換膚功能, 每個(gè)分支機構和部門(mén)有獨立的門(mén)戶(hù), 特定崗位和特定角色也有特定門(mén)戶(hù).
2) 企業(yè)門(mén)戶(hù)、部門(mén)門(mén)戶(hù)等內部常規門(mén)戶(hù)必須包含總公司的公告、郵件、流程審批等模塊.
3) 特定用戶(hù)可能在多個(gè)部門(mén)任職, 則該用戶(hù)的門(mén)戶(hù)可能是包含多部門(mén)信息的獨立門(mén)戶(hù), 也可能是采用切換的方式訪(fǎng)問(wèn)多個(gè)部門(mén)的門(mén)戶(hù).
4) 每個(gè)用戶(hù)登錄到門(mén)戶(hù)首頁(yè), “第一眼”就能看到自己當天的待辦工作和關(guān)注信息.
5) 每個(gè)模塊只開(kāi)發(fā)一次, 后期只是各模塊單獨升級, 可以重復利用, 不要重復開(kāi)發(fā).
6) 每個(gè)門(mén)戶(hù)的關(guān)注點(diǎn)和導航都不相同, 但是相同模塊在不同門(mén)戶(hù)里的具體內容相同, 導航頁(yè)面之間的切換不能改變用戶(hù)的默認選擇.
7) 每個(gè)模塊相對獨立, 不能影響其他模塊及整體系統的使用.
1.2 系統選型
無(wú)架構, 不系統, 架構選型是門(mén)戶(hù)系統成功的關(guān)鍵.面對清晰的業(yè)務(wù)架構, 而現有OA系統和零散業(yè)務(wù)系統無(wú)法滿(mǎn)足企業(yè)發(fā)展.在考察過(guò)單體式應用架構、分布式架構、SOA架構等架構后, 最后集中在OSGI框架平臺和自主研發(fā)基于模塊化的彈性擴展門(mén)戶(hù)網(wǎng)站架構的選擇上.
OSGi (open service gateway initiative) 技術(shù)是Java動(dòng)態(tài)化模塊化系統的一系列規范.基于該規范, 一些開(kāi)源社區和廠(chǎng)商實(shí)現具體的OSGI開(kāi)發(fā)平臺, 如Java開(kāi)發(fā)的Felix和Equinox, 以及.NET平臺實(shí)現的OSGi.NET.這些基于OSGI規范的架構, 基本解決了軟件復用、團隊協(xié)作、軟件可維護性、開(kāi)放性等問(wèn)題.但是基于這些架構開(kāi)發(fā)出來(lái)的產(chǎn)品, 很難解決系統美觀(guān)性和友好性問(wèn)題, 以及用戶(hù)個(gè)性化需求的問(wèn)題.基于開(kāi)源的OSGI架構平臺思路, 考慮到系統之間的集成和現有開(kāi)發(fā)團隊, 最終選擇自主研發(fā)基于模塊化的彈性擴展門(mén)戶(hù)網(wǎng)站架構.
1.3 系統建模
在本企業(yè)門(mén)戶(hù)中, 業(yè)務(wù)參與者包括各部門(mén)、分支機構、分 (子) 公司的全體人員.系統管理員指整個(gè)門(mén)戶(hù)系統的管理者.用例指各個(gè)業(yè)務(wù)場(chǎng)景, 不同的業(yè)務(wù)場(chǎng)景可能由不同團隊或人員獨立開(kāi)發(fā).圖1是以財務(wù)人員、人力人員、財務(wù)總監為例, 說(shuō)明各個(gè)模塊之間的關(guān)系.
2 定制首頁(yè)設計
門(mén)戶(hù)首頁(yè)是門(mén)戶(hù)的精華所在, 是企事業(yè)單位的辦公和精神集中地, 往往用戶(hù)記住和使用最多的是門(mén)戶(hù)首頁(yè).當用戶(hù)看到首頁(yè), 就知道門(mén)戶(hù)是做什么, 用戶(hù)從這里得到哪些服務(wù), 獲得哪些信息, 下一步用戶(hù)將到哪里去, 最終目的就是給用戶(hù)帶來(lái)極佳體驗, 并吸引足夠多的注意力.同樣引導什么功能呢, 用戶(hù)進(jìn)入門(mén)戶(hù)首頁(yè)不可能只停留在首頁(yè), 他會(huì )根據自己的工作和目的來(lái)決定去點(diǎn)擊鏈接.而如何引導用戶(hù)用最快的時(shí)間找到自己想要做和去的地方, 則是對門(mén)戶(hù)設計、用戶(hù)體驗和引導的綜合考量.門(mén)戶(hù)首頁(yè)模塊化設計的目的就是最大程度滿(mǎn)足多樣化用戶(hù)需求, 最大程度給每位用戶(hù)帶來(lái)極佳體驗.
網(wǎng)頁(yè)的模塊化和汽車(chē)生產(chǎn)是如出一轍, 首先把一個(gè)頁(yè)面的每一個(gè)部分按照內容的獨立性和關(guān)聯(lián)性分成不同的模塊, 這樣一個(gè)頁(yè)面就由背景和很多個(gè)模塊組成, 然后再將每個(gè)模塊按照業(yè)務(wù)類(lèi)別、外觀(guān)樣式等因素分配給不同的組員進(jìn)行開(kāi)發(fā), 并最終又將這些模塊按用戶(hù)所需拼合在一起, 形成一個(gè)完整的門(mén)戶(hù)首頁(yè)。
后臺配置設計
從定制首頁(yè)設計中可預知, 系統管理員需要在后臺把頁(yè)面主題、模板、?？?、模塊等信息配置完畢供門(mén)戶(hù)首頁(yè)呈現調用.下面先解釋幾者之間的關(guān)系, 再詳細說(shuō)明每一項的具體含義。
一個(gè)模板對應多個(gè)?？? 具體對應多少個(gè)?？蚴歉鶕脩?hù)首頁(yè)建模拆分出的?？蜓芯啃院蛣?chuàng )新性.?？蚺c模塊是一對一關(guān)系, 每個(gè)模塊都需要一個(gè)?？蜓b載才能在頁(yè)面上渲染.?？蛑皇菫榱诉_到模塊在設計和開(kāi)發(fā)上的分離和渲染上的融合, 以及模塊復用的功能才在模板和模塊之間抽象出的中間邏輯, 是模塊在模板上的一個(gè)預占位.對一個(gè)集體來(lái)說(shuō), 統一主題制作不僅節省主題開(kāi)發(fā)成本, 而且可以更好地適配頁(yè)面.對用戶(hù)來(lái)說(shuō), 能看到和關(guān)注的是模板上最終呈現的那些內容 (即那些模塊) .在常規頁(yè)面看似簡(jiǎn)單的開(kāi)發(fā), 但在模塊化的門(mén)戶(hù)首頁(yè)中, 門(mén)戶(hù)首頁(yè)渲染是通過(guò)系統、頁(yè)面、?？?、模塊層層入棧傳遞參數, 層層出棧構造頁(yè)面結果.首頁(yè)的渲染不只是模塊的規則組合, 而且還需頁(yè)面風(fēng)格、用戶(hù)語(yǔ)言等參數的搭配渲染.下面是幾項核心配置的簡(jiǎn)要說(shuō)明:
1) 主題配置:用于指定門(mén)戶(hù)CSS樣式、圖片、語(yǔ)言包等調用的文件夾, 主要屬性包括主題名稱(chēng)、主題語(yǔ)言、描述.
2) 模板配置:用于體現門(mén)戶(hù)首頁(yè)?？蛭恢玫墓袒团渲媚K的定位.主要屬性包括名稱(chēng)、模板文件名、URL地址、寬度、高度、?？蚩倲?、設計預覽圖、語(yǔ)言類(lèi)別.
3) ?？蚺渲?用于描述將來(lái)配置特定模塊呈現在頁(yè)面上的固定位置以及?？蚺c頁(yè)面的關(guān)系.主要屬性包括?？蛎Q(chēng)、標記、寬度、高度、適配說(shuō)明.圖4是模板、?？虻呐渲谜故?
4) 模塊配置:用于描述每個(gè)業(yè)務(wù)模塊基本信息, 主要供系統管理員或用戶(hù)選擇查看.主要屬性包括顯示名稱(chēng)、類(lèi)名、相對路徑、寬度、高度、類(lèi)型、是否異步加載、是否可調整、語(yǔ)言類(lèi)別.
5) 模塊與模板配置:用于配置首頁(yè)呈現的內容形態(tài), 主要是配置模板與門(mén)戶(hù)導航和模塊的關(guān)系.圖5是模板與模塊配置說(shuō)明圖.
6) 主題與模板配置:用于配置最終首頁(yè)呈現樣式, 一個(gè)模板可以配置多個(gè)主題, 一個(gè)主題可以配置多個(gè)模板.
后臺配置及用戶(hù)設置的最終目的是生成加載門(mén)戶(hù)首頁(yè)的配置信息。
根據以上“后臺配置設計”介紹, 結合“定制化首頁(yè)”設計思路, 推導出門(mén)戶(hù)首頁(yè)渲染過(guò)程如下:首先, 針對不同用戶(hù)的個(gè)性化需求進(jìn)行逐一建模, 并挖掘出不同首頁(yè)模板.然后, 在后臺根據首頁(yè)建模的布局和用戶(hù)崗位、角色、部門(mén)等信息進(jìn)行首頁(yè)模板、?？?、模塊的配置, 并最終生成不同的“門(mén)戶(hù)首頁(yè)配置信息”配置關(guān)系.最后, 不同的首頁(yè)模板根據相應配置文件渲染出個(gè)性化的首頁(yè).
4 模塊開(kāi)發(fā)
4.1 總體開(kāi)發(fā)思路
模塊是構成門(mén)戶(hù)的一部分, 一般具有獨立完整的功能, 具有一致的前后端接口和加載方式, 相同形態(tài)的模塊在門(mén)戶(hù)中可以相互替換, 不同模塊的按需組合就構成了最終個(gè)性化首頁(yè).為什么要這樣設計呢?我們發(fā)現在一個(gè)項目里, 需求提出者往往參照某一兩個(gè)系統而提出, 在這些系統頁(yè)面中, 都會(huì )存在內容和外觀(guān)相同或相似的部分, 如果我們按照模塊化來(lái)設計與開(kāi)發(fā), 不同的業(yè)務(wù)已經(jīng)變成了一個(gè)個(gè)的模塊, 那么這些相同業(yè)務(wù)或相似界面的模塊就可以分給同一個(gè)團隊或個(gè)人來(lái)開(kāi)發(fā).假如不同模塊之間互不影響, 或不同模塊相互之間交互都有相應規范, 那么不同開(kāi)發(fā)團隊可以同步進(jìn)行開(kāi)發(fā), 這樣效率必將有很大的提高, 且代碼的質(zhì)量和系統穩定性也會(huì )得到相應保證.由于每個(gè)模塊都是單獨存在的, 所以當任何門(mén)戶(hù)首頁(yè)需要用到這個(gè)模塊時(shí), 都可以很便捷地直接將這個(gè)模塊配置到首頁(yè)使用, 而不必再次重新開(kāi)發(fā), 大大增強了模塊復用性.
怎樣設計開(kāi)發(fā)出這種具有通用性、互換性、相對獨立性的模塊呢?在“后臺配置設計”中已經(jīng)了解模塊呈現過(guò)程關(guān)系設計的基礎上, 再簡(jiǎn)要介紹模塊的交互設計思路.首先把模塊類(lèi)型分為:列表自適應型、焦點(diǎn)圖型、導航條型、廣告型.其次在列表自適應型中, 已經(jīng)定義好模塊自適應?？虻臉邮胶凸┣岸苏{用的常用方法, 業(yè)務(wù)開(kāi)發(fā)人員不在關(guān)注怎樣適應?？?、模塊加載處理等共性問(wèn)題, 只需關(guān)注列表數據來(lái)源及列表對應二級、三級業(yè)務(wù)頁(yè)面, 而且在二級、三級等頁(yè)面開(kāi)發(fā)中, 業(yè)務(wù)開(kāi)發(fā)人員也只需關(guān)注頁(yè)面內容, 而頁(yè)面導航、風(fēng)格等共性問(wèn)題不需要花費精力.同樣, 焦點(diǎn)圖型的模塊基類(lèi)已經(jīng)定義好適配?？蚍椒ê蛨D片切換方法, 導航條型基類(lèi)已經(jīng)處理好相同的頁(yè)面在不同門(mén)戶(hù)自動(dòng)加載不同導航條的方法;只有廣告型模塊約束相對較少, 適合模塊擴展和特殊處理場(chǎng)景.針對不同的業(yè)務(wù)版塊, 不同團隊可以按照微服務(wù)的方式同步開(kāi)發(fā)首頁(yè)模塊和相應二級、三級頁(yè)面, 也可以按照常規方式開(kāi)發(fā)首頁(yè)模塊.
4.2 基本實(shí)現思路
在了解上面設計思路后, 下面以3個(gè)核心基類(lèi)來(lái)說(shuō)明主要實(shí)現思路. 門(mén)戶(hù)首頁(yè)基類(lèi)BaseHomePage、門(mén)戶(hù)首頁(yè)模塊基類(lèi)BaseUserControl、其他二三級頁(yè)面基類(lèi)BasePage.門(mén)戶(hù)首頁(yè)基類(lèi)除了當前主題、語(yǔ)言和用戶(hù)信息外, 其中最重要的方法就是加載模塊方法 (LoadControls) , 在頁(yè)面基類(lèi)方法中已經(jīng)實(shí)現了從緩存及配置文件中自動(dòng)加載模塊的方法, 后期開(kāi)發(fā)人員只需關(guān)注“定制首頁(yè)設計”中的首頁(yè)建模和特殊細節處理.門(mén)戶(hù)首頁(yè)模塊基類(lèi)主要目的是提供標準啟動(dòng)方法 (On Start) 供首頁(yè)通過(guò)反射的方式調用, 并把用戶(hù)及配置信息傳遞給具體模塊初始化使用;在常規模塊的開(kāi)發(fā)中, 模塊開(kāi)發(fā)人員只需考慮采用前端或后臺的方式獲取后端數據并進(jìn)行模塊渲染, 不再關(guān)心常規權限、換膚、日志等通用功能.二三級頁(yè)面基類(lèi)雖然只提供了當前用戶(hù)信息及配置信息供調用, 但在頁(yè)面前端提供了導航、樣式等動(dòng)態(tài)生成內容和通用處理方法.
對于業(yè)務(wù)復雜、流量及并發(fā)大的模塊, 團隊成員可以考慮采用微服務(wù)的方式處理模塊業(yè)務(wù)邏輯, 為了交互方便, 架構也提供了共享session和單點(diǎn)登錄集成方式.在整個(gè)項目開(kāi)發(fā)中, 為了提高開(kāi)發(fā)效率、系統穩定性、分工明確性.為此, 在本架構設計過(guò)程中, 同步編寫(xiě)了“門(mén)戶(hù)開(kāi)發(fā)規范及過(guò)程管控”的規范化文檔, 為開(kāi)發(fā)實(shí)踐打下了良好的基礎.
4.3 開(kāi)發(fā)實(shí)踐
有了以上的設計和開(kāi)發(fā)思路, 在進(jìn)行實(shí)際開(kāi)發(fā)過(guò)程中還需考慮基本規范、模塊前端、模塊后端及模塊交互等系列問(wèn)題.基本規范包括那些呢?首先, 在按照不同業(yè)務(wù)進(jìn)行團隊分工后, 需要防止不同開(kāi)發(fā)團隊的命名沖突, 否則可能導致模塊加載失敗;其次, 需要考慮不同模塊的并發(fā)控制;最后, 還需考慮模塊與系統間的集成.
在實(shí)際開(kāi)發(fā)過(guò)程中, 針對該架構制定了前端、后端及數據庫開(kāi)發(fā)規范.在進(jìn)行單個(gè)模塊開(kāi)發(fā)時(shí), 需要根據規劃確定模塊的簡(jiǎn)寫(xiě), 如系統模塊簡(jiǎn)寫(xiě)是“SYS”.規定命名空間 (java叫包) 以模塊簡(jiǎn)寫(xiě)單獨結尾, 這樣在加載模塊的時(shí)候就不會(huì )造成沖突.同樣, 在前端的css樣式文件和javascript腳本文件中也把不同模塊的文件放在以模塊簡(jiǎn)寫(xiě)的文件夾下面;并且在腳本中涉及相同的函數名稱(chēng)添加模塊前綴, 在樣式文件中涉及到樣式文件采用模塊簡(jiǎn)稱(chēng)的類(lèi)限定, 防止樣式文件沖突.在數據庫層面, 除了基本數據庫規范外, 主要是在表名的前綴添加模塊簡(jiǎn)寫(xiě)的方式區分和防止不必要的沖突;當然, 根據模塊流量和并非情況, 不同模塊數據可以放在同一數據庫, 也可以把單個(gè)模塊存放在一個(gè)或多個(gè)獨立數據庫中.
在模塊前端開(kāi)發(fā)過(guò)程中, 除了遵守基本前端規范之外, 本設計提煉出常用的前端模塊樣式和通用javascript函數, 如多種列表樣式、圖片切換樣式及相應的自適應樣式等, 當模塊開(kāi)發(fā)人員發(fā)現自己開(kāi)發(fā)的模塊存在對應模塊樣式時(shí), 只需按照前端文檔進(jìn)行調用, 減少前端調試時(shí)間.樣式文件、腳本及圖片等靜態(tài)文件按照規范統一放在主題包文件夾下面, 整個(gè)主題包可以單獨部署在單獨二級域名下的服務(wù)器上, 也可以部署在網(wǎng)站的子目錄下.當配置文件配置為相對路徑時(shí), 則模塊前端和后端調用相對路徑下的靜態(tài)文件;同理, 配置為二級域名時(shí), 前后端則自動(dòng)調用獨立服務(wù)器下的靜態(tài)資源.
在模塊后端開(kāi)發(fā)過(guò)程中, 我們推薦采用模塊后臺代碼輕量化方式, 結合微服務(wù)處理后端業(yè)務(wù)邏輯方式.當然沒(méi)有后臺業(yè)務(wù)代碼邏輯, 或把簡(jiǎn)單業(yè)務(wù)邏輯直接寫(xiě)在后臺也是可以正確進(jìn)行模塊渲染.主要是根據模塊業(yè)務(wù)復雜性和模塊并發(fā)大小來(lái)綜合考慮是否在后端采用微服務(wù)方式處理業(yè)務(wù)邏輯, 是否提供統一的API供模塊后臺調用, 以及后端數據庫是否分庫和集群等方式.在模塊與各系統交互過(guò)程中, 如果是自主開(kāi)發(fā)的系統, 推薦采用Session共享集成方式, 否則推薦采用單點(diǎn)登錄集成方式.