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