門戶網站建設解決方案設計

在政府機構中，工商、公安等機構基本都擁有自己的門戶網站; 在企事業單位中，各中大型企業、醫院、學校等也有相應的辦公門戶． 在這些門戶網站中，往往會碰到信息陳舊、板塊空缺、布局雜亂、進入層次太深、系統更新緩慢、用戶很難找到自己關注信息等問題． 導致這些現象的因素很多，有的因為經費不足而缺少維護; 有的因為測試不全面導致系統穩定性差; 有的因為缺少規劃而趕不上發展速度; 還有因為無法利用現有系統資源，機構小而沒有內容支撐門戶網站建設等原因．

門戶網站建設

作為企事業單位中的信息部門，面對系統扁平化、個性化需求的增加，導致系統定制化趨勢越來越明顯，信息部門除了創建數量龐大的系統來滿足用戶不斷變化和增加的需求之外，還有其他應對措施嗎? 大多數人都知道，傳統網站架構往往是根據業務需求、現有團隊等因素考慮設計，主要解決的是通用需求和當前業務，團隊成員之間也相對了解，能快速完成一個個獨立的信息系統． 但這樣的系統設計與開發團隊耦合性太緊密，一旦團隊核心人員變動，往往會導致系統可擴展性和穩定性受到極大的影響，或一旦需求變化太大，系統就必須大規模重新設計才能滿足需求． 在越來越依賴信息化的今天，需求快速變化是比較正常的，這就導致上述各種現象．

為了規避這些現象，信息部門必須具備以下的能力才能夠應對挑戰:

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 系統建模

在本企業門戶中，業務參與者包括各部門、分支機構、分( 子) 公司的全體人員． 系統管理員指整個門戶系統的管理者． 用例指各個業務場景，不同的業務場景可能由不同團隊或人員獨立開發．

2 定制首頁設計

門戶首頁是門戶的精華所在，是企事業單位的辦公和精神集中地，往往用戶記住和使用最多的是門戶首頁． 當用戶看到首頁，就知道門戶是做什么，用戶從這里得到哪些服務，獲得哪些信息，下一步用戶將到哪里去，最終目的就是給用戶帶來極佳體驗，并吸引足夠多的注意力． 同樣引導什么功能呢，用戶進入門戶首頁不可能只停留在首頁，他會根據自己的工作和目的來決定去點擊鏈接． 而如何引導用戶用最快的時間找到自己想要做和去的地方，則是對門戶設計、用戶體驗和引導的綜合考量．

門戶首頁模塊化設計的目的就是最大程度滿足多樣化用戶需求，最大程度給每位用戶帶來極佳體驗．網頁的模塊化和汽車生產是如出一轍，首先把一個頁面的每一個部分按照內容的獨立性和關聯性分成不同的模塊，這樣一個頁面就由背景和很多個模塊組成，然后再將每個模塊按照業務類別、外觀樣式等因素分配給不同的組員進行開發，并最終又將這些模塊按用戶所需拼合在一起，形成一個完整的門戶首頁． 最后，不同的首頁模板根據相應配置文件渲染出個性化的首頁．

4 模塊開發

4． 1 總體開發思路 模塊是構成門戶的一部分，一般具有獨立完整的功能，具有一致的前后端接口和加載方式，相同形態的模塊在門戶中可以相互替換，不同模塊的按需組合就構成了最終個性化首頁． 為什么要這樣設計呢? 我們發現在一個項目里，需求提出者往往參照某一兩個系統而提出，在這些系統頁面中，都會存在內容和外觀相同或相似的部分，如果我們按照模塊化來設計與開發，不同的業務已經變成了一個個的模塊，那么這些相同業務或相似界面的模塊就可以分給同一個團隊或個人來開發． 假如不同模塊之間互不影響，或不同模塊相互之間交互都有相應規范，那么不同開發團隊可以同步進行開發，這樣效率必將有很大的提高，且代碼的質量和系統穩定性也會得到相應保證． 由于每個模塊都是單獨存在的，所以當任何門戶首頁需要用到這個模塊時，都可以很便捷地直接將這個模塊配置到首頁使用，而不必再次重新開發，大大增強了模塊復用性．怎樣設計開發出這種具有通用性、互換性、相對獨立性的模塊呢? 在“后臺配置設計”中已經了解模塊呈現過程關系設計的基礎上，再簡要介紹模塊的交互設計思路． 首先把模塊類型分為: 列表自適應型、焦點圖型、導航條型、廣告型． 其次在列表自適應型中，已經定義好模塊自適應?？虻臉邮胶凸┣岸苏{用的常用方法，業務開發人員不在關注怎樣適應?？?、模塊加載處理等共性問題，只需關注列表數據來源及列表對應二級、三級業務頁面，而且在二級、三級等頁面開發中，業務開發人員也只需關注頁面內容，而頁面導航、風格等共性問題不需要花費精力． 同樣，焦點圖型的模塊基類已經定義好適配?？蚍椒ê蛨D片切換方法，導航條型基類已經處理好相同的頁面在不同門戶自動加載不同導航條的方法; 只有廣告型模塊約束相對較少，適合模塊擴展和特殊處理場景． 針對不同的業務版塊，不同團隊可以按照微服務的方式同步開發首頁模塊和相應二級、三級頁面，也可以按照常規方式開發首頁模塊．

4． 2 基本實現思路

在了解上面設計思路后，下面以 3 個核心基類來說明主要實現思路． 3 個核心類分別是: 門戶首頁基類 BaseHomePage、門戶首頁模塊基類其他二三級頁面基類 BasePage． 門戶首頁基類除了當前主題、語言和用戶信息外，其中最重要的方法就是加載模塊方法( LoadControls) ，在頁面基類方法中已經實現了從緩存及配置文件中自動加載模塊的方法，后期開發人員只需關注“定制首頁設計”中的首頁建模和特殊細節處理． 門戶首頁模塊基類主要目的是提供標準啟動方法( On Start) 供首頁通過反射的方式調用，并把用戶及配置信息傳遞給具體模塊初始化使用; 在常規模塊的開發中，模塊開發人員只需考慮采用前端或后臺的方式獲取后端數據并進行模塊渲染，不再關心常規權限、換膚、日志等通用功能． 二三級頁面基類雖然只提供了當前用戶信息及配置信息供調用，但在頁面前端提供了導航、樣式等動態生成內容和通用處理方法．對于業務復雜、流量及并發大的模塊，團隊成員可以考慮采用微服務的方式處理模塊業務邏輯，為了交互方便，架構也提供了共享 session 和單點登錄集成方式． 在整個項目開發中，為了提高開發效率、系統穩定性、分工明確性． 為此，在本架構設計過程中，同步編寫了“門戶開發規范及過程管控”的規范化文檔，為開發實踐打下了良好的基礎．

4． 3 開發實踐

有了以上的設計和開發思路，在進行實際開發過程中還需考慮基本規范、模塊前端、模塊后端及模塊交互等系列問題． 基本規范包括那些呢? 首先，在按照不同業務進行團隊分工后，需要防止不同開發團隊的命名沖突，否則可能導致模塊加載失敗; 其次，需要考慮不同模塊的并發控制; 最后，還需考慮模塊與系統間的集成．在實際開發過程中，針對該架構制定了前端、后端及數據庫開發規范． 在進行單個模塊開發時，需要根據規劃確定模塊的簡寫，如系統模塊簡寫是“SYS”． 規定命名空間( java 叫包) 以模塊簡寫單獨結尾，這樣在加載模塊的時候就不會造成沖突． 同樣，在前端的 css 樣式文件和 javascript 腳本文件中也把不同模塊的文件放在以模塊簡寫的文件夾下面; 并且在腳本中涉及相同的函數名稱添加模塊前綴，在樣式文件中涉及到樣式文件采用模塊簡稱的類限定，防止樣式文件沖突． 在數據庫層面，除了基本數據庫規范外，主要是在表名的前綴添加模塊簡寫的方式區分和防止不必要的沖突; 當然，根據模塊流量和并非情況，不同模塊數據可以放在同一數據庫，也可以把單個模塊存放在一個或多個獨立數據庫中．在模塊前端開發過程中，除了遵守基本前端規范之外，本設計提煉出常用的前端模塊樣式和通用javascript 函數，如多種列表樣式、圖片切換樣式及相應的自適應樣式等，當模塊開發人員發現自己開發的模塊存在對應模塊樣式時，只需按照前端文檔進行調用，減少前端調試時間． 樣式文件、腳本及圖片等靜態文件按照規范統一放在主題包文件夾下面，整個主題包可以單獨部署在單獨二級域名下的服務器上，也可以部署在網站的子目錄下． 當配置文件配置為相對路徑時，則模塊前端和后端調用相對路徑下的靜態文件; 同理，配置為二級域名時，前后端則自動調用獨立服務器下的靜態資源．在模塊后端開發過程中，我們推薦采用模塊后臺代碼輕量化方式，結合微服務處理后端業務邏輯方式． 當然沒有后臺業務代碼邏輯，或把簡單業務邏輯直接寫在后臺也是可以正確進行模塊渲染． 主要是根據模塊業務復雜性和模塊并發大小來綜合考慮是否在后端采用微服務方式處理業務邏輯，是否提供統一的 API 供模塊后臺調用，以及后端數據庫是否分庫和集群等方式． 在模塊與各系統交互過程中，如果是自主開發的系統，推薦采用 Session 共享集成方式，否則推薦采用單點登錄集成方式．

5 總結

本文中針對模塊在門戶網站中的設計研究，提出基于模塊化的彈性擴展門戶網站架構設計，并將該架構設計在華夏航空企業門戶中進行應用． 3 年的實際應用表明確實解決了用戶需求個性化、團隊分工、開發效率、系統擴展性和穩定性等關鍵問題． 本設計只是軟件模塊化在具體行業中的一次成功應用思路分享，軟件模塊化的目的是建立可重用的軟件組件，在不需要修改或僅作少量修改的情況下，可再次用來組建新的軟件系統，提高軟件的開發周期和可靠性． 模塊化的彈性擴展框架設計可以在保持系統較高通用性的同時提供產品的多樣化配置，因此基于模塊化的彈性擴展是解決定制設計和批量化開發這對矛盾的一條出路，是企事業單位門戶開發設計的一條出路．