新聞動態基於模塊化的彈性擴展門戶網站架構設計


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