行業動态

在(zài)政府機構中, 工商、公安等機構基本都擁有自己的(de)門戶網站;在(zài)企事業單位中, 各中大(dà)型企業、醫院、學校等也(yě)有相應的(de)辦公門戶.在(zài)這(zhè)些門戶網站中, 往往會碰到(dào)信息陳舊、闆塊空缺、布局雜亂、進入層次太深、系統更新緩慢、用戶很難找到(dào)自己關注信息等問題.導緻這(zhè)些現象的(de)因素很多, 有的(de)因爲(wéi / wèi)經費不(bù)足而(ér)缺少維護;有的(de)因爲(wéi / wèi)測試不(bù)全面導緻系統穩定性差;有的(de)因爲(wéi / wèi)缺少規劃而(ér)趕不(bù)上(shàng)發展速度;還有因爲(wéi / wèi)無法利用現有系統資源, 機構小而(ér)沒有内容支撐門戶網站建設等原因.

作爲(wéi / wèi)企事業單位中的(de)信息部門, 面對系統扁平化、個(gè)性化需求的(de)增加, 導緻系統定制化趨勢越來(lái)越明顯, 信息部門除了(le／liǎo)創建數量龐大(dà)的(de)系統來(lái)滿足用戶不(bù)斷變化和(hé / huò)增加的(de)需求之(zhī)外, 還有其他(tā)應對措施嗎?大(dà)多數人(rén)都知道(dào), 傳統網站架構往往是(shì)根據業務需求、現有團隊等因素考慮設計, 主要(yào / yāo)解決的(de)是(shì)通用需求和(hé / huò)當前業務, 團隊成員之(zhī)間也(yě)相對了(le／liǎo)解, 能快速完成一(yī / yì ／yí)個(gè)個(gè)獨立的(de)信息系統.但這(zhè)樣的(de)系統設計與開發團隊耦合性太緊密, 一(yī / yì ／yí)旦團隊核心人(rén)員變動, 往往會導緻系統可擴展性和(hé / huò)穩定性受到(dào)極大(dà)的(de)影響, 或一(yī / yì ／yí)旦需求變化太大(dà), 系統就(jiù)必須大(dà)規模重新設計才能滿足需求.在(zài)越來(lái)越依賴信息化的(de)今天, 需求快速變化是(shì)比較正常的(de), 這(zhè)就(jiù)導緻上(shàng)述各種現象.爲(wéi / wèi)了(le／liǎo)規避這(zhè)些現象, 信息部門必須具備以(yǐ)下的(de)能力才能夠應對挑戰:1) 持續提高創新能力, 使系統的(de)技術含量越來(lái)越高, 以(yǐ)滿足客戶需求;2) 不(bù)斷縮短系統研發時(shí)間, 快速響應用戶需求;3) 不(bù)斷強化成本控制能力, 通過優化産品生命周期内的(de)各種成本來(lái)控制系統總成本, 取得投入産出(chū)比優勢;4) 持續穩定的(de)質量改進能力.

經驗表明, 設計信息系統一(yī / yì ／yí)方面必須利用業務模塊的(de)批量化、标準化和(hé / huò)通用化來(lái)縮短系統上(shàng)線周期、降低研發成本、提高模塊重用性和(hé / huò)系統穩定性, 另一(yī / yì ／yí)方面還要(yào / yāo)不(bù)斷地(dì / de)進行研發創新使系統越來(lái)越個(gè)性化, 滿足用戶的(de)定制需求.這(zhè)樣, 如何平衡系統的(de)标準化、通用化與定制化、穩定性之(zhī)間的(de)矛盾, 成爲(wéi / wèi)赢得競争的(de)關鍵因素.基于(yú)這(zhè)兩方面的(de)考慮, 設計一(yī / yì ／yí)套基于(yú)模塊化的(de)彈性擴展門戶網站架構.該設計把業務拆分爲(wéi / wèi)一(yī / yì ／yí)個(gè)個(gè)模塊, 通過這(zhè)些模塊的(de)組合可以(yǐ)向分支機構、下屬單位、甚至崗位、人(rén)員提供相應的(de)個(gè)性化門戶系統, 不(bù)僅解決了(le／liǎo)企事業單位整體的(de)系統建設成本, 而(ér)且也(yě)解決了(le／liǎo)門戶網站内容不(bù)足、内容複用、組織機構之(zhī)間信息交互等問題.對軟件開發團隊來(lái)說(shuō), 也(yě)解決了(le／liǎo)系統叠代的(de)穩定性、模塊之(zhī)間的(de)耦合度、用戶需求的(de)個(gè)性化、開發團隊分工與協助等問題.

1 系統分析與建模

1.1 架構需求

企業門戶是(shì)一(yī / yì ／yí)個(gè)聯接企業内部和(hé / huò)外部的(de)網站, 它把各種應用系統、數據資源、業務處理與企業各部門、分支機構等需求統一(yī / yì ／yí)集成到(dào)門戶之(zhī)下, 可以(yǐ)爲(wéi / wèi)企業提供一(yī / yì ／yí)個(gè)單一(yī / yì ／yí)的(de)訪問企業各種信息資源的(de)入口, 企業的(de)員工、分支機構、合作夥伴等都可以(yǐ)通過這(zhè)個(gè)門戶獲得個(gè)性化的(de)信息和(hé / huò)服務.經過多次整理歸納, 明确了(le／liǎo)企業及用戶對架構的(de)主要(yào / yāo)需求内容如下:

1) 企業門戶統一(yī / yì ／yí)入口地(dì / de)址, 針對特定節假日有換膚功能, 每個(gè)分支機構和(hé / huò)部門有獨立的(de)門戶, 特定崗位和(hé / huò)特定角色也(yě)有特定門戶.

2) 企業門戶、部門門戶等内部常規門戶必須包含總公司的(de)公告、郵件、流程審批等模塊.

3) 特定用戶可能在(zài)多個(gè)部門任職, 則該用戶的(de)門戶可能是(shì)包含多部門信息的(de)獨立門戶, 也(yě)可能是(shì)采用切換的(de)方式訪問多個(gè)部門的(de)門戶.

4) 每個(gè)用戶登錄到(dào)門戶首頁, “第一(yī / yì ／yí)眼”就(jiù)能看到(dào)自己當天的(de)待辦工作和(hé / huò)關注信息.

5) 每個(gè)模塊隻開發一(yī / yì ／yí)次, 後期隻是(shì)各模塊單獨升級, 可以(yǐ)重複利用, 不(bù)要(yào / yāo)重複開發.

6) 每個(gè)門戶的(de)關注點和(hé / huò)導航都不(bù)相同, 但是(shì)相同模塊在(zài)不(bù)同門戶裏的(de)具體内容相同, 導航頁面之(zhī)間的(de)切換不(bù)能改變用戶的(de)默認選擇.

7) 每個(gè)模塊相對獨立, 不(bù)能影響其他(tā)模塊及整體系統的(de)使用.

1.2 系統選型

無架構, 不(bù)系統, 架構選型是(shì)門戶系統成功的(de)關鍵.面對清晰的(de)業務架構, 而(ér)現有OA系統和(hé / huò)零散業務系統無法滿足企業發展.在(zài)考察過單體式應用架構、分布式架構、SOA架構等架構後, 最後集中在(zài)OSGI框架平台和(hé / huò)自主研發基于(yú)模塊化的(de)彈性擴展門戶網站架構的(de)選擇上(shàng).

OSGi (open service gateway initiative) 技術是(shì)Java動态化模塊化系統的(de)一(yī / yì ／yí)系列規範.基于(yú)該規範, 一(yī / yì ／yí)些開源社區和(hé / huò)廠商實現具體的(de)OSGI開發平台, 如Java開發的(de)Felix和(hé / huò)Equinox, 以(yǐ)及.NET平台實現的(de)OSGi.NET.這(zhè)些基于(yú)OSGI規範的(de)架構, 基本解決了(le／liǎo)軟件複用、團隊協作、軟件可維護性、開放性等問題.但是(shì)基于(yú)這(zhè)些架構開發出(chū)來(lái)的(de)産品, 很難解決系統美觀性和(hé / huò)友好性問題, 以(yǐ)及用戶個(gè)性化需求的(de)問題.基于(yú)開源的(de)OSGI架構平台思路, 考慮到(dào)系統之(zhī)間的(de)集成和(hé / huò)現有開發團隊, 最終選擇自主研發基于(yú)模塊化的(de)彈性擴展門戶網站架構.

1.3 系統建模

在(zài)本企業門戶中, 業務參與者包括各部門、分支機構、分 (子(zǐ)) 公司的(de)全體人(rén)員.系統管理員指整個(gè)門戶系統的(de)管理者.用例指各個(gè)業務場景, 不(bù)同的(de)業務場景可能由不(bù)同團隊或人(rén)員獨立開發.圖1是(shì)以(yǐ)财務人(rén)員、人(rén)力人(rén)員、财務總監爲(wéi / wèi)例, 說(shuō)明各個(gè)模塊之(zhī)間的(de)關系.

2 定制首頁設計

門戶首頁是(shì)門戶的(de)精華所在(zài), 是(shì)企事業單位的(de)辦公和(hé / huò)精神集中地(dì / de), 往往用戶記住和(hé / huò)使用最多的(de)是(shì)門戶首頁.當用戶看到(dào)首頁, 就(jiù)知道(dào)門戶是(shì)做什麽, 用戶從這(zhè)裏得到(dào)哪些服務, 獲得哪些信息, 下一(yī / yì ／yí)步用戶将到(dào)哪裏去, 最終目的(de)就(jiù)是(shì)給用戶帶來(lái)極佳體驗, 并吸引足夠多的(de)注意力.同樣引導什麽功能呢, 用戶進入門戶首頁不(bù)可能隻停留在(zài)首頁, 他(tā)會根據自己的(de)工作和(hé / huò)目的(de)來(lái)決定去點擊鏈接.而(ér)如何引導用戶用最快的(de)時(shí)間找到(dào)自己想要(yào / yāo)做和(hé / huò)去的(de)地(dì / de)方, 則是(shì)對門戶設計、用戶體驗和(hé / huò)引導的(de)綜合考量.門戶首頁模塊化設計的(de)目的(de)就(jiù)是(shì)最大(dà)程度滿足多樣化用戶需求, 最大(dà)程度給每位用戶帶來(lái)極佳體驗.

網頁的(de)模塊化和(hé / huò)汽車生産是(shì)如出(chū)一(yī / yì ／yí)轍, 首先把一(yī / yì ／yí)個(gè)頁面的(de)每一(yī / yì ／yí)個(gè)部分按照内容的(de)獨立性和(hé / huò)關聯性分成不(bù)同的(de)模塊, 這(zhè)樣一(yī / yì ／yí)個(gè)頁面就(jiù)由背景和(hé / huò)很多個(gè)模塊組成, 然後再将每個(gè)模塊按照業務類别、外觀樣式等因素分配給不(bù)同的(de)組員進行開發, 并最終又将這(zhè)些模塊按用戶所需拼合在(zài)一(yī / yì ／yí)起, 形成一(yī / yì ／yí)個(gè)完整的(de)門戶首頁。

後台配置設計

從定制首頁設計中可預知, 系統管理員需要(yào / yāo)在(zài)後台把頁面主題、模闆、模框、模塊等信息配置完畢供門戶首頁呈現調用.下面先解釋幾者之(zhī)間的(de)關系, 再詳細說(shuō)明每一(yī / yì ／yí)項的(de)具體含義。

一(yī / yì ／yí)個(gè)模闆對應多個(gè)模框, 具體對應多少個(gè)模框是(shì)根據用戶首頁建模拆分出(chū)的(de)模框研究性和(hé / huò)創新性.模框與模塊是(shì)一(yī / yì ／yí)對一(yī / yì ／yí)關系, 每個(gè)模塊都需要(yào / yāo)一(yī / yì ／yí)個(gè)模框裝載才能在(zài)頁面上(shàng)渲染.模框隻是(shì)爲(wéi / wèi)了(le／liǎo)達到(dào)模塊在(zài)設計和(hé / huò)開發上(shàng)的(de)分離和(hé / huò)渲染上(shàng)的(de)融合, 以(yǐ)及模塊複用的(de)功能才在(zài)模闆和(hé / huò)模塊之(zhī)間抽象出(chū)的(de)中間邏輯, 是(shì)模塊在(zài)模闆上(shàng)的(de)一(yī / yì ／yí)個(gè)預占位.對一(yī / yì ／yí)個(gè)集體來(lái)說(shuō), 統一(yī / yì ／yí)主題制作不(bù)僅節省主題開發成本, 而(ér)且可以(yǐ)更好地(dì / de)适配頁面.對用戶來(lái)說(shuō), 能看到(dào)和(hé / huò)關注的(de)是(shì)模闆上(shàng)最終呈現的(de)那些内容 (即那些模塊) .在(zài)常規頁面看似簡單的(de)開發, 但在(zài)模塊化的(de)門戶首頁中, 門戶首頁渲染是(shì)通過系統、頁面、模框、模塊層層入棧傳遞參數, 層層出(chū)棧構造頁面結果.首頁的(de)渲染不(bù)隻是(shì)模塊的(de)規則組合, 而(ér)且還需頁面風格、用戶語言等參數的(de)搭配渲染.下面是(shì)幾項核心配置的(de)簡要(yào / yāo)說(shuō)明:

1) 主題配置:用于(yú)指定門戶CSS樣式、圖片、語言包等調用的(de)文件夾, 主要(yào / yāo)屬性包括主題名稱、主題語言、描述.

2) 模闆配置:用于(yú)體現門戶首頁模框位置的(de)固化和(hé / huò)配置模塊的(de)定位.主要(yào / yāo)屬性包括名稱、模闆文件名、URL地(dì / de)址、寬度、高度、模框總數、設計預覽圖、語言類别.

3) 模框配置:用于(yú)描述将來(lái)配置特定模塊呈現在(zài)頁面上(shàng)的(de)固定位置以(yǐ)及模框與頁面的(de)關系.主要(yào / yāo)屬性包括模框名稱、标記、寬度、高度、适配說(shuō)明.圖4是(shì)模闆、模框的(de)配置展示.

4) 模塊配置:用于(yú)描述每個(gè)業務模塊基本信息, 主要(yào / yāo)供系統管理員或用戶選擇查看.主要(yào / yāo)屬性包括顯示名稱、類名、相對路徑、寬度、高度、類型、是(shì)否異步加載、是(shì)否可調整、語言類别.

5) 模塊與模闆配置:用于(yú)配置首頁呈現的(de)内容形态, 主要(yào / yāo)是(shì)配置模闆與門戶導航和(hé / huò)模塊的(de)關系.圖5是(shì)模闆與模塊配置說(shuō)明圖.

6) 主題與模闆配置:用于(yú)配置最終首頁呈現樣式, 一(yī / yì ／yí)個(gè)模闆可以(yǐ)配置多個(gè)主題, 一(yī / yì ／yí)個(gè)主題可以(yǐ)配置多個(gè)模闆.

後台配置及用戶設置的(de)最終目的(de)是(shì)生成加載門戶首頁的(de)配置信息。

根據以(yǐ)上(shàng)“後台配置設計”介紹, 結合“定制化首頁”設計思路, 推導出(chū)門戶首頁渲染過程如下:首先, 針對不(bù)同用戶的(de)個(gè)性化需求進行逐一(yī / yì ／yí)建模, 并挖掘出(chū)不(bù)同首頁模闆.然後, 在(zài)後台根據首頁建模的(de)布局和(hé / huò)用戶崗位、角色、部門等信息進行首頁模闆、模框、模塊的(de)配置, 并最終生成不(bù)同的(de)“門戶首頁配置信息”配置關系.最後, 不(bù)同的(de)首頁模闆根據相應配置文件渲染出(chū)個(gè)性化的(de)首頁.

4 模塊開發

4.1 總體開發思路

模塊是(shì)構成門戶的(de)一(yī / yì ／yí)部分, 一(yī / yì ／yí)般具有獨立完整的(de)功能, 具有一(yī / yì ／yí)緻的(de)前後端接口和(hé / huò)加載方式, 相同形态的(de)模塊在(zài)門戶中可以(yǐ)相互替換, 不(bù)同模塊的(de)按需組合就(jiù)構成了(le／liǎo)最終個(gè)性化首頁.爲(wéi / wèi)什麽要(yào / yāo)這(zhè)樣設計呢?我們發現在(zài)一(yī / yì ／yí)個(gè)項目裏, 需求提出(chū)者往往參照某一(yī / yì ／yí)兩個(gè)系統而(ér)提出(chū), 在(zài)這(zhè)些系統頁面中, 都會存在(zài)内容和(hé / huò)外觀相同或相似的(de)部分, 如果我們按照模塊化來(lái)設計與開發, 不(bù)同的(de)業務已經變成了(le／liǎo)一(yī / yì ／yí)個(gè)個(gè)的(de)模塊, 那麽這(zhè)些相同業務或相似界面的(de)模塊就(jiù)可以(yǐ)分給同一(yī / yì ／yí)個(gè)團隊或個(gè)人(rén)來(lái)開發.假如不(bù)同模塊之(zhī)間互不(bù)影響, 或不(bù)同模塊相互之(zhī)間交互都有相應規範, 那麽不(bù)同開發團隊可以(yǐ)同步進行開發, 這(zhè)樣效率必将有很大(dà)的(de)提高, 且代碼的(de)質量和(hé / huò)系統穩定性也(yě)會得到(dào)相應保證.由于(yú)每個(gè)模塊都是(shì)單獨存在(zài)的(de), 所以(yǐ)當任何門戶首頁需要(yào / yāo)用到(dào)這(zhè)個(gè)模塊時(shí), 都可以(yǐ)很便捷地(dì / de)直接将這(zhè)個(gè)模塊配置到(dào)首頁使用, 而(ér)不(bù)必再次重新開發, 大(dà)大(dà)增強了(le／liǎo)模塊複用性.

怎樣設計開發出(chū)這(zhè)種具有通用性、互換性、相對獨立性的(de)模塊呢?在(zài)“後台配置設計”中已經了(le／liǎo)解模塊呈現過程關系設計的(de)基礎上(shàng), 再簡要(yào / yāo)介紹模塊的(de)交互設計思路.首先把模塊類型分爲(wéi / wèi):列表自适應型、焦點圖型、導航條型、廣告型.其次在(zài)列表自适應型中, 已經定義好模塊自适應模框的(de)樣式和(hé / huò)供前端調用的(de)常用方法, 業務開發人(rén)員不(bù)在(zài)關注怎樣适應模框、模塊加載處理等共性問題, 隻需關注列表數據來(lái)源及列表對應二級、三級業務頁面, 而(ér)且在(zài)二級、三級等頁面開發中, 業務開發人(rén)員也(yě)隻需關注頁面内容, 而(ér)頁面導航、風格等共性問題不(bù)需要(yào / yāo)花費精力.同樣, 焦點圖型的(de)模塊基類已經定義好适配模框方法和(hé / huò)圖片切換方法, 導航條型基類已經處理好相同的(de)頁面在(zài)不(bù)同門戶自動加載不(bù)同導航條的(de)方法;隻有廣告型模塊約束相對較少, 适合模塊擴展和(hé / huò)特殊處理場景.針對不(bù)同的(de)業務版塊, 不(bù)同團隊可以(yǐ)按照微服務的(de)方式同步開發首頁模塊和(hé / huò)相應二級、三級頁面, 也(yě)可以(yǐ)按照常規方式開發首頁模塊.

4.2 基本實現思路

在(zài)了(le／liǎo)解上(shàng)面設計思路後, 下面以(yǐ)3個(gè)核心基類來(lái)說(shuō)明主要(yào / yāo)實現思路. 門戶首頁基類BaseHomePage、門戶首頁模塊基類BaseUserControl、其他(tā)二三級頁面基類BasePage.門戶首頁基類除了(le／liǎo)當前主題、語言和(hé / huò)用戶信息外, 其中最重要(yào / yāo)的(de)方法就(jiù)是(shì)加載模塊方法 (LoadControls) , 在(zài)頁面基類方法中已經實現了(le／liǎo)從緩存及配置文件中自動加載模塊的(de)方法, 後期開發人(rén)員隻需關注“定制首頁設計”中的(de)首頁建模和(hé / huò)特殊細節處理.門戶首頁模塊基類主要(yào / yāo)目的(de)是(shì)提供标準啓動方法 (On Start) 供首頁通過反射的(de)方式調用, 并把用戶及配置信息傳遞給具體模塊初始化使用;在(zài)常規模塊的(de)開發中, 模塊開發人(rén)員隻需考慮采用前端或後台的(de)方式獲取後端數據并進行模塊渲染, 不(bù)再關心常規權限、換膚、日志等通用功能.二三級頁面基類雖然隻提供了(le／liǎo)當前用戶信息及配置信息供調用, 但在(zài)頁面前端提供了(le／liǎo)導航、樣式等動态生成内容和(hé / huò)通用處理方法.

對于(yú)業務複雜、流量及并發大(dà)的(de)模塊, 團隊成員可以(yǐ)考慮采用微服務的(de)方式處理模塊業務邏輯, 爲(wéi / wèi)了(le／liǎo)交互方便, 架構也(yě)提供了(le／liǎo)共享session和(hé / huò)單點登錄集成方式.在(zài)整個(gè)項目開發中, 爲(wéi / wèi)了(le／liǎo)提高開發效率、系統穩定性、分工明确性.爲(wéi / wèi)此, 在(zài)本架構設計過程中, 同步編寫了(le／liǎo)“門戶開發規範及過程管控”的(de)規範化文檔, 爲(wéi / wèi)開發實踐打下了(le／liǎo)良好的(de)基礎.

4.3 開發實踐

有了(le／liǎo)以(yǐ)上(shàng)的(de)設計和(hé / huò)開發思路, 在(zài)進行實際開發過程中還需考慮基本規範、模塊前端、模塊後端及模塊交互等系列問題.基本規範包括那些呢?首先, 在(zài)按照不(bù)同業務進行團隊分工後, 需要(yào / yāo)防止不(bù)同開發團隊的(de)命名沖突, 否則可能導緻模塊加載失敗;其次, 需要(yào / yāo)考慮不(bù)同模塊的(de)并發控制;最後, 還需考慮模塊與系統間的(de)集成.

在(zài)實際開發過程中, 針對該架構制定了(le／liǎo)前端、後端及數據庫開發規範.在(zài)進行單個(gè)模塊開發時(shí), 需要(yào / yāo)根據規劃确定模塊的(de)簡寫, 如系統模塊簡寫是(shì)“SYS”.規定命名空間 (java叫包) 以(yǐ)模塊簡寫單獨結尾, 這(zhè)樣在(zài)加載模塊的(de)時(shí)候就(jiù)不(bù)會造成沖突.同樣, 在(zài)前端的(de)css樣式文件和(hé / huò)javascript腳本文件中也(yě)把不(bù)同模塊的(de)文件放在(zài)以(yǐ)模塊簡寫的(de)文件夾下面;并且在(zài)腳本中涉及相同的(de)函數名稱添加模塊前綴, 在(zài)樣式文件中涉及到(dào)樣式文件采用模塊簡稱的(de)類限定, 防止樣式文件沖突.在(zài)數據庫層面, 除了(le／liǎo)基本數據庫規範外, 主要(yào / yāo)是(shì)在(zài)表名的(de)前綴添加模塊簡寫的(de)方式區分和(hé / huò)防止不(bù)必要(yào / yāo)的(de)沖突;當然, 根據模塊流量和(hé / huò)并非情況, 不(bù)同模塊數據可以(yǐ)放在(zài)同一(yī / yì ／yí)數據庫, 也(yě)可以(yǐ)把單個(gè)模塊存放在(zài)一(yī / yì ／yí)個(gè)或多個(gè)獨立數據庫中.

在(zài)模塊前端開發過程中, 除了(le／liǎo)遵守基本前端規範之(zhī)外, 本設計提煉出(chū)常用的(de)前端模塊樣式和(hé / huò)通用javascript函數, 如多種列表樣式、圖片切換樣式及相應的(de)自适應樣式等, 當模塊開發人(rén)員發現自己開發的(de)模塊存在(zài)對應模塊樣式時(shí), 隻需按照前端文檔進行調用, 減少前端調試時(shí)間.樣式文件、腳本及圖片等靜态文件按照規範統一(yī / yì ／yí)放在(zài)主題包文件夾下面, 整個(gè)主題包可以(yǐ)單獨部署在(zài)單獨二級域名下的(de)服務器上(shàng), 也(yě)可以(yǐ)部署在(zài)網站的(de)子(zǐ)目錄下.當配置文件配置爲(wéi / wèi)相對路徑時(shí), 則模塊前端和(hé / huò)後端調用相對路徑下的(de)靜态文件;同理, 配置爲(wéi / wèi)二級域名時(shí), 前後端則自動調用獨立服務器下的(de)靜态資源.

在(zài)模塊後端開發過程中, 我們推薦采用模塊後台代碼輕量化方式, 結合微服務處理後端業務邏輯方式.當然沒有後台業務代碼邏輯, 或把簡單業務邏輯直接寫在(zài)後台也(yě)是(shì)可以(yǐ)正确進行模塊渲染.主要(yào / yāo)是(shì)根據模塊業務複雜性和(hé / huò)模塊并發大(dà)小來(lái)綜合考慮是(shì)否在(zài)後端采用微服務方式處理業務邏輯, 是(shì)否提供統一(yī / yì ／yí)的(de)API供模塊後台調用, 以(yǐ)及後端數據庫是(shì)否分庫和(hé / huò)集群等方式.在(zài)模塊與各系統交互過程中, 如果是(shì)自主開發的(de)系統, 推薦采用Session共享集成方式, 否則推薦采用單點登錄集成方式.