電子文檔聯(lián)機(jī)入庫(kù)系統(tǒng)升級(jí)改造方___20163(修改)-1

1、電子文檔系統(tǒng)升級(jí)改造方案1. 現(xiàn)狀描述電子文檔系統(tǒng)是局信息化系統(tǒng)的一個(gè)重要的組成部分，是XX局實(shí)現(xiàn)審批流程無(wú)紙化的基礎(chǔ)支撐系統(tǒng)之一。電子文檔系統(tǒng)作為基礎(chǔ)配套系統(tǒng)，為E系統(tǒng)、S系統(tǒng)、D系統(tǒng)管理圖形文檔并提供文檔入庫(kù)、文檔查詢獲取等服務(wù)。電子文檔系統(tǒng)的聯(lián)機(jī)文件入庫(kù)服務(wù)接收來(lái)自E系統(tǒng)、CEPCT系統(tǒng)、集成電路布圖系統(tǒng)的文件入庫(kù)請(qǐng)求，將文件的屬性信息和掃描件存儲(chǔ)在NAS存儲(chǔ)上，主要包括電子申請(qǐng)文件和通知書(shū)文件。對(duì)外獲取服務(wù)為E系統(tǒng)、S系統(tǒng)等提供實(shí)時(shí)的聯(lián)機(jī)交易。受限與當(dāng)前硬件資源，目前電子文檔的PC服務(wù)器需要同時(shí)兼顧聯(lián)機(jī)入庫(kù)交易和對(duì)外獲取服務(wù)緩存這兩項(xiàng)重要工作。硬件部署圖如下：電子文檔自2010年上線以

2、來(lái)，總體運(yùn)行穩(wěn)定，但是隨著電子申請(qǐng)的大批量增加，電子文檔也業(yè)務(wù)量也隨之大幅增加。目前系統(tǒng)運(yùn)行中存在著一些亟需解決的問(wèn)題：1.1. 入庫(kù)量趨勢(shì)分析通過(guò)分析近5年來(lái)的數(shù)據(jù)，聯(lián)機(jī)入庫(kù)數(shù)量逐年遞增，年均增長(zhǎng)量在18%左右，其中2012年更是比前一年增加了36%之多。如下圖所示：對(duì)比今年（2015）上半年和2014年上半年的入庫(kù)數(shù)量，同比增幅平均值達(dá)到15%。對(duì)比今年上半年和2014年上半年對(duì)外獲取訪問(wèn)量，可以看出來(lái)自E系統(tǒng)、D系統(tǒng)的訪問(wèn)壓力也與日俱增，同比平均增幅達(dá)到31%。其中6月份更是同比增幅達(dá)54%。未來(lái)預(yù)期S系統(tǒng)以及外網(wǎng)公眾查詢等系統(tǒng)對(duì)電子文檔系統(tǒng)的獲取會(huì)持續(xù)增加電子文檔的訪問(wèn)壓力。由于目前電

3、子文檔在用的PC服務(wù)器需要同時(shí)處理聯(lián)機(jī)入庫(kù)任務(wù)并緩存對(duì)外獲取的實(shí)體文件，由于機(jī)器數(shù)量不足以及配置陳舊，隨著業(yè)務(wù)量的不斷增加，性能日趨飽和，運(yùn)行效率明顯降低，甚至常常出現(xiàn)自動(dòng)關(guān)機(jī)等問(wèn)題，近一步影響了入庫(kù)效率及緩存ftp的訪問(wèn)速度。且根據(jù)2015年5月IBM工作組CIFA提出的觀點(diǎn)，建議入庫(kù)程序和緩存FTP放置在不同的機(jī)器上，但由于目前電子文檔PC服務(wù)器數(shù)量不足，無(wú)法進(jìn)行拆分。1.2. 聯(lián)機(jī)入庫(kù)壓力分析上一節(jié)主要討論當(dāng)下電子申請(qǐng)數(shù)量逐年遞增，聯(lián)機(jī)入庫(kù)數(shù)量逐年攀升的一個(gè)大的趨勢(shì)。本節(jié)具體分析電子文檔聯(lián)機(jī)入庫(kù)現(xiàn)狀以及其所面臨的壓力。電子文檔聯(lián)機(jī)入庫(kù)主要包括E系統(tǒng)文件及通知書(shū)入庫(kù)、CEPCT系統(tǒng)文件及通

4、知書(shū)入庫(kù)和集成電路布圖系統(tǒng)聯(lián)機(jī)入庫(kù)。其中E系統(tǒng)文件及通知書(shū)入庫(kù)是其中的重中之中，這不僅體現(xiàn)在入庫(kù)數(shù)量方面，也體現(xiàn)在對(duì)入庫(kù)實(shí)效性的要求方面。E系統(tǒng)文件和通知書(shū)入庫(kù)是兩套不同的程序，目前工作日日均入庫(kù)數(shù)量（文件和通知書(shū)分別計(jì)算）均在10萬(wàn)以上的量級(jí)。下圖顯示2015年某一時(shí)間區(qū)間電子文檔的聯(lián)機(jī)入庫(kù)數(shù)量統(tǒng)計(jì)。通過(guò)上圖可以看出，文件入庫(kù)量在工作日一般在10-15萬(wàn)，周末及假日的入庫(kù)量在3-5萬(wàn)。通知書(shū)入庫(kù)量主要取決于審查員的工作時(shí)間，周末入庫(kù)數(shù)量很少，基本在1萬(wàn)以下，工作日平均入庫(kù)數(shù)量在8-12萬(wàn)左右。但通知書(shū)可能會(huì)出現(xiàn)集中入庫(kù)的情況，而且在集中入庫(kù)的當(dāng)天，通知書(shū)入庫(kù)量甚至?xí)任募霂?kù)量還要多，例如1

5、0月27日和11月25日，這兩天當(dāng)日入庫(kù)量分別高達(dá)19.6萬(wàn)和17.6萬(wàn)。針對(duì)11月25日當(dāng)日通知書(shū)聯(lián)機(jī)入庫(kù)進(jìn)行分析，按照時(shí)段構(gòu)造入庫(kù)批次量圖表見(jiàn)下圖：如圖所示，當(dāng)日入庫(kù)高峰分布在1-3點(diǎn)，15-20點(diǎn)。其中1-3點(diǎn)主要是夜間批處理入庫(kù)，15-20點(diǎn)是工作日審查員入庫(kù)時(shí)段（由于軟掃存在一定的入庫(kù)時(shí)延）。高峰期每小時(shí)入庫(kù)批次量在9300左右。通知書(shū)批次內(nèi)文件數(shù)量在1-2件左右。以16點(diǎn)為例，入庫(kù)批次量為9366，目前電子文檔通知書(shū)聯(lián)機(jī)入庫(kù)的單次入庫(kù)時(shí)間平均為6秒，入庫(kù)程序共部署4套并行運(yùn)行。因此完成9366個(gè)批次需要耗費(fèi)的時(shí)間如下：由上述計(jì)算得知，全部完成9366個(gè)批次大約需要234.15分鐘，

6、這還是在理想的沒(méi)有任何時(shí)間損耗的狀態(tài)下，即需要4個(gè)小時(shí)消化這一個(gè)小時(shí)接收到的批次。因此在入庫(kù)峰值期間，已經(jīng)出現(xiàn)了較為嚴(yán)重的積壓狀況。入庫(kù)峰值期間積壓的批次只能通過(guò)閑時(shí)消化，或者維護(hù)人員加入PC機(jī)（非生產(chǎn)機(jī)）協(xié)助處理積壓，但這種方式需要人工干預(yù)，而且不能在非工作時(shí)間進(jìn)行。目前電子文檔PC服務(wù)器除了需要部署聯(lián)機(jī)入庫(kù)（E系統(tǒng)、CEPCT、集成電路布圖）程序，同時(shí)還要負(fù)責(zé)對(duì)外緩存FTP以及接收入庫(kù)請(qǐng)求、處理光盤(pán)入庫(kù)等。隨著聯(lián)機(jī)入庫(kù)量的不斷增加，諸如E系統(tǒng)通知書(shū)入庫(kù)部署4套程序并行運(yùn)行，已經(jīng)無(wú)法滿足工作的需要，而由于服務(wù)器已趨飽和，目前也無(wú)法部署更多的程序以緩解入庫(kù)壓力。1.3. 聯(lián)機(jī)入庫(kù)單點(diǎn)風(fēng)險(xiǎn)電子文

7、檔提供的E系統(tǒng)聯(lián)機(jī)入庫(kù)接口，在E系統(tǒng)剛上線之初，由于數(shù)據(jù)量不大，未設(shè)置負(fù)載均衡，目前隨著E系統(tǒng)業(yè)務(wù)量的增加，所面臨的壓力也越來(lái)越大，迫切需要增加負(fù)載均衡設(shè)備來(lái)減輕單個(gè)機(jī)器的壓力，同時(shí)也能解決目前該接口的的單點(diǎn)風(fēng)險(xiǎn)。2013年上線的CEPCT系統(tǒng)，集成電路系統(tǒng)接口目前均已通過(guò)班固實(shí)現(xiàn)負(fù)載均衡。由于E系統(tǒng)接口的歷史問(wèn)題（跟E系統(tǒng)溝通，目前電子文檔那個(gè)提供給他們的接口地址，由于在E系統(tǒng)的各個(gè)模塊都有調(diào)用，所以不能進(jìn)行更改），一直未能解決。1.4. 電子文檔生產(chǎn)庫(kù)故障風(fēng)險(xiǎn)電子文檔數(shù)據(jù)庫(kù)目前存在CPU過(guò)高的問(wèn)題，經(jīng)過(guò)近段時(shí)間的調(diào)整（通過(guò)我們優(yōu)化索引，遷移歷史表等操作），已有所下降，但是還是沒(méi)有達(dá)到理想結(jié)

8、果。電子文檔自2010年上線以來(lái)，除提供服務(wù)給E系統(tǒng)外，還新增了CEPCT系統(tǒng)，集成電路系統(tǒng)，D系統(tǒng)，未來(lái)還有可能提供給海牙系統(tǒng)等，隨著這些新系統(tǒng)的加入，也給電子文檔帶來(lái)了新的挑戰(zhàn)，對(duì)電子文檔的數(shù)據(jù)庫(kù)也提出了新的要求，目前電子文檔庫(kù)中，文件類數(shù)據(jù)已達(dá)到177,000,000 條，通知書(shū)數(shù)據(jù)已達(dá)到100,000,000條，億級(jí)的數(shù)量級(jí)也需要更高的硬件配置來(lái)支持。近一年來(lái)由于CPU使用率居高不下，導(dǎo)致數(shù)據(jù)庫(kù)硬件出現(xiàn)故障的概率也隨之增大，如4月份出現(xiàn)的穩(wěn)壓器故障等。通過(guò)我們應(yīng)用層面上的調(diào)整，只能降低CPU使用，不能從根本上解決CPU過(guò)高的問(wèn)題。1.5. 應(yīng)用內(nèi)部改造電子文檔聯(lián)機(jī)入庫(kù)程序和對(duì)外獲取應(yīng)用

9、經(jīng)過(guò)多年的運(yùn)行與維護(hù)，目前基本穩(wěn)定，這些年來(lái)也進(jìn)行了許多次小版本升級(jí)，修改系統(tǒng)BUG或針對(duì)需求和硬件環(huán)境的變更進(jìn)行適應(yīng)性的升級(jí)。隨著業(yè)務(wù)量的不斷提升，以及NAS存儲(chǔ)硬件環(huán)境的變更，這些應(yīng)用需要從底層架構(gòu)進(jìn)行改造以適應(yīng)這方面的變化。具體參考2.4節(jié)中的描述。2. 改造方案2.1. 增加PC服務(wù)器目前處理聯(lián)機(jī)入庫(kù)和對(duì)外獲取緩存的服務(wù)器共有7臺(tái)，考慮到入庫(kù)和緩存的分離，建議增加5臺(tái)，該項(xiàng)預(yù)算每臺(tái)5萬(wàn)，共計(jì)25萬(wàn)。新增服務(wù)器每臺(tái)可部署3套應(yīng)用程序，即新增15套聯(lián)機(jī)入庫(kù)，考慮到新機(jī)器由于性能的提升，入庫(kù)處理速度在2倍以上。因此每小時(shí)可處理批次為：以目前E系統(tǒng)聯(lián)機(jī)入庫(kù)峰值每小時(shí)10000批計(jì)算，入庫(kù)年增速

10、10%，則：即以10%的增速，增加PC服務(wù)器后可滿足6年的業(yè)務(wù)需要?？紤]到目前專利申請(qǐng)量增速下降，不會(huì)一直保持年均10%的增速，因此本次升級(jí)配備大約可以滿足未來(lái)10年的業(yè)務(wù)需要。2.2. 增加負(fù)載均衡E系統(tǒng)入電子文檔庫(kù)接口在E系統(tǒng)剛上線時(shí)，提供的單點(diǎn)機(jī)器進(jìn)行接口，已滿足當(dāng)時(shí)E系統(tǒng)的業(yè)務(wù)量，但是隨著E系統(tǒng)業(yè)務(wù)的增長(zhǎng)，電子申請(qǐng)?jiān)絹?lái)越多，對(duì)電子文檔提供的入庫(kù)接口的要求也越來(lái)越嚴(yán)格，迫切需要通過(guò)負(fù)載均衡來(lái)減輕入庫(kù)壓力。以及在聯(lián)機(jī)入庫(kù)服務(wù)器前端增加2臺(tái)負(fù)載均衡服務(wù)器，來(lái)均衡E系統(tǒng)入庫(kù)壓力，避免單點(diǎn)故障。每臺(tái)預(yù)算25萬(wàn)，共計(jì)50萬(wàn)。2.3. 數(shù)據(jù)庫(kù)A28機(jī)器增加CPU近一段時(shí)間內(nèi)，電子文檔數(shù)據(jù)CPU持高不

11、下，跟日益增加的業(yè)務(wù)量是密不可分的，需要進(jìn)行升級(jí)。建議對(duì)新電子文檔的兩臺(tái)數(shù)據(jù)庫(kù)服務(wù)器的CPU進(jìn)行擴(kuò)容。目前IBM原廠給的報(bào)價(jià)1臺(tái)5萬(wàn)，共計(jì)10萬(wàn)，激活2顆物理CPU，共8核。2.4. 系統(tǒng)內(nèi)部改造2.4.1. 現(xiàn)狀描述. 電子文檔聯(lián)機(jī)入庫(kù)子系統(tǒng)電子文檔聯(lián)機(jī)入庫(kù)子系統(tǒng)包括E系統(tǒng)文件入庫(kù)及反饋、E系統(tǒng)通知書(shū)入庫(kù)及反饋、CEPCT文件入庫(kù)及反饋、CEPCT通知書(shū)入庫(kù)及反饋、集成電路布圖文件入庫(kù)及反饋、集成電路布圖通知書(shū)入庫(kù)及反饋等多套應(yīng)用，這些應(yīng)用由C#進(jìn)行開(kāi)發(fā)。其中，文件入庫(kù)及反饋應(yīng)用由上傳下載(OnlineBatchConsole)、反饋(OnlineSendXML)兩套程序組成，

12、通知書(shū)入庫(kù)及反饋應(yīng)用由下載(NoticeTransConsole-1)、上傳(NoticeTransConsole-2)、反饋(NoticeSendXML)三套程序組成。因此，聯(lián)機(jī)入庫(kù)是一套異步進(jìn)行的過(guò)程，各程序之間通過(guò)數(shù)據(jù)庫(kù)中的狀態(tài)標(biāo)識(shí)進(jìn)行消息傳遞。E系統(tǒng)、CEPCT及集成電路的聯(lián)機(jī)入庫(kù)應(yīng)用均遵循此架構(gòu)。在電子文檔的生產(chǎn)服務(wù)器109、110、113、114上，針對(duì)文件入庫(kù)和通知書(shū)入庫(kù)各部署兩套，因此每臺(tái)服務(wù)器會(huì)同時(shí)運(yùn)行10個(gè)電子文檔入庫(kù)應(yīng)用。在目前的維護(hù)過(guò)程中發(fā)現(xiàn)，這些應(yīng)用常常自動(dòng)停止響應(yīng)，并彈出windows出錯(cuò)的對(duì)話框。對(duì)于這種情況，需要重新啟動(dòng)應(yīng)用。在非工作時(shí)間，應(yīng)用出錯(cuò)關(guān)閉以后就會(huì)造

13、成案件積壓。有時(shí)會(huì)出現(xiàn)一個(gè)周末積壓上萬(wàn)個(gè)批次的情況。聯(lián)機(jī)入庫(kù)程序在執(zhí)行過(guò)程中會(huì)產(chǎn)生大量的臨時(shí)文件。這些臨時(shí)文件存儲(chǔ)在服務(wù)器的磁盤(pán)分區(qū)上，需要進(jìn)行切換和清理。尤其是這些文件主要是入庫(kù)的xml描述文件和待存NAS的臨時(shí)實(shí)體文件，文件小，數(shù)量多，在windows的文件系統(tǒng)之下，動(dòng)輒上萬(wàn)個(gè)文件夾，上百萬(wàn)個(gè)小文件。因此隨著數(shù)據(jù)磁盤(pán)使用量的增加，磁盤(pán)訪問(wèn)性能呈指數(shù)形趨勢(shì)下降，最終清理數(shù)據(jù)時(shí)甚至需要整盤(pán)格式化才能夠完成。而且入庫(kù)程序在自身目錄下也會(huì)產(chǎn)生許多臨時(shí)文件，這些文件不及時(shí)進(jìn)行清理也會(huì)影響運(yùn)行速度。每個(gè)生產(chǎn)服務(wù)器在運(yùn)行2-3月后，都需要進(jìn)行一次徹底地清除工作，否則可能會(huì)出現(xiàn)服務(wù)器異常重啟的情況。文件入

14、庫(kù)及通知書(shū)入庫(kù)的上傳實(shí)體文件部分采用連接NAS存儲(chǔ)FTP的方式，通過(guò)FTP協(xié)議實(shí)現(xiàn)上傳過(guò)程。通過(guò)FTP連接NAS被認(rèn)為是一種效率低下的方式，目前許多應(yīng)用在存儲(chǔ)和讀取NAS數(shù)據(jù)時(shí)均采用掛載或直聯(lián)的方式，這樣效率更高，容錯(cuò)率更強(qiáng)，如E系統(tǒng)即采用此方式。同時(shí)，由于目前采用FTP連接NAS的需求萎縮，NAS廠商在其產(chǎn)品中對(duì)于FTP服務(wù)支持的意愿也不夠強(qiáng)烈，因此相應(yīng)的技術(shù)支持和BUG修復(fù)也很難及時(shí)響應(yīng)。在2013年電子文檔使用Netapp的NAS存儲(chǔ)時(shí)，曾出現(xiàn)FTP連接隨機(jī)中斷的問(wèn)題，后來(lái)通過(guò)與廠商溝通，發(fā)布新的NAS固件解決該問(wèn)題。2014年局存儲(chǔ)換用華為NAS后，電子文檔入庫(kù)應(yīng)用出現(xiàn)FTP連接兼容性

15、異常，因此無(wú)法使用華為NAS存儲(chǔ)，直到修改了相應(yīng)的入庫(kù)應(yīng)用后才解決這個(gè)問(wèn)題。. 電子文檔對(duì)外獲取服務(wù)電子文檔對(duì)外獲取服務(wù)由三臺(tái)應(yīng)用服務(wù)器部署相同的對(duì)外獲取應(yīng)用，并經(jīng)由兩臺(tái)般固負(fù)載均衡向外部提供服務(wù)。目前對(duì)外獲取應(yīng)用的處理方式采用先緩存再返回緩存FTP地址的方式。緩存過(guò)程通過(guò)FTP訪問(wèn)NAS存儲(chǔ)，將實(shí)體文件復(fù)制到緩存服務(wù)器上，并在緩存表中記錄緩存地址。由于緩存過(guò)程依賴NAS提供的FTP服務(wù)，從性能角度考慮要低于掛載直聯(lián)的方式。同樣隨著FTP技術(shù)在NAS上的式微，可以預(yù)見(jiàn)未來(lái)幾年NAS廠商對(duì)FTP的技術(shù)支持和版本升級(jí)工作會(huì)越來(lái)越少。綜合考慮這兩方面原因，在緩存過(guò)程中應(yīng)替換原有的采用F

16、TP連接NAS的方式。2.4.2. 改造方案根據(jù)目前維護(hù)中遇到的情況，我們決定對(duì)電子文檔聯(lián)機(jī)入庫(kù)子系統(tǒng)和電子文檔對(duì)外獲取服務(wù)進(jìn)行升級(jí)改造。改造主要分為三個(gè)方面：1. 重新梳理和優(yōu)化業(yè)務(wù)流程，使用JAVA重寫(xiě)聯(lián)機(jī)入庫(kù)子系統(tǒng)中的相關(guān)應(yīng)用。2. 開(kāi)發(fā)新的上傳功能采用直連NAS的方式，逐步減少對(duì)FTP的依賴。3. 修改的對(duì)外獲取服務(wù)的緩存功能，改用NAS直聯(lián)的方式進(jìn)行文件緩存。聯(lián)機(jī)入庫(kù)子系統(tǒng)包含多套程序（文件入庫(kù)2套，通知書(shū)入庫(kù)3套，分別對(duì)應(yīng)E系統(tǒng)、集成電路、CEPCT三個(gè)版本），且各程序之間并沒(méi)有直接的依賴關(guān)系，僅通過(guò)數(shù)據(jù)庫(kù)狀態(tài)字段進(jìn)行流程之間的通信。因此本次改造優(yōu)先重寫(xiě)文件入庫(kù)及反饋中的上傳與下載

17、程序（OnlineBatchConsole），并在重寫(xiě)的同時(shí)開(kāi)發(fā)直連NAS的上傳方式。在這方面的開(kāi)發(fā)需要考慮與現(xiàn)有程序的兼容性，在上傳實(shí)體文件方面需要使FTP上傳和直連上傳這兩種方式能夠同時(shí)存在，并且不影響對(duì)外獲取服務(wù)對(duì)實(shí)體文件的獲取。對(duì)外獲取服務(wù)的修改需要考慮已有NAS卷需全部重新采用掛載直聯(lián)的方式實(shí)現(xiàn)，目前電子文檔已使用120卷，涉及數(shù)十個(gè)NAS機(jī)頭需要掛載。程序描述預(yù)計(jì)人月聯(lián)機(jī)入庫(kù)子系統(tǒng)OnlineBatchConsoleE系統(tǒng)文件入庫(kù)2OnlineSendXMLE系統(tǒng)文件反饋1NoticeBatchOncoleE系統(tǒng)通知書(shū)入庫(kù)2NoticeSendXMLE系統(tǒng)通知書(shū)反饋1CEPCT-O

18、nline/NoticeCEPCT文件通知書(shū)入庫(kù)及反饋2V-Online/Notice集成電路文件通知書(shū)入庫(kù)及反饋2對(duì)外獲取服務(wù)GetFilewWS對(duì)外獲取服務(wù)2合計(jì) 12可優(yōu)先重寫(xiě)文件入庫(kù)及反饋上傳下載程序（OnlineBatchConsole）并開(kāi)發(fā)新的NAS直連上傳功能，預(yù)估工作量3人月。3. 附錄3.1. 功能說(shuō)明與架構(gòu)圖3.1.1. 功能說(shuō)明電子文檔系統(tǒng)包括人工文件處理子系統(tǒng)、對(duì)外服務(wù)子系統(tǒng)、電子形式文件處理子系統(tǒng)、CEPCT系統(tǒng)文件處理子系統(tǒng)、集成電路布圖文件處理子系統(tǒng)，如下圖所示：各子系統(tǒng)之間通過(guò)企業(yè)服務(wù)總線（ESB）來(lái)數(shù)據(jù)交換。由于，保密子系統(tǒng)部署在涉密網(wǎng)內(nèi)，涉密網(wǎng)與其他網(wǎng)絡(luò)是

19、完全物理隔離的，因此，只能通過(guò)文件拷貝的方式手工來(lái)與其他系統(tǒng)交換數(shù)據(jù)。但是，都是使用企業(yè)服務(wù)總線（ESB）作為唯一的交換入口。部署概念模型如下圖所示：3.1.2. 總體架構(gòu)電子文檔系統(tǒng)的總體架構(gòu)如下圖所示。電子文檔系統(tǒng)的總體架構(gòu)系統(tǒng)包含以下主要部件 電子文檔裝載服務(wù)，管理電子文件的裝庫(kù)過(guò)程，保證電子文件能夠正確、及時(shí)地裝載到電子文檔系統(tǒng)中去，并且提供裝庫(kù)過(guò)程的控制和管理； 電子文檔核心服務(wù)包括存儲(chǔ)管理、文件目錄服務(wù)和文件登記服務(wù)等幾部分，管理電子文檔的實(shí)質(zhì)內(nèi)容以及登記信息的存儲(chǔ)和訪問(wèn)； 電子文檔瀏覽服務(wù)，通過(guò)B/S結(jié)構(gòu)提供對(duì)電子文檔的訪問(wèn)功能，可以通過(guò)程序接口，直接展示在瀏覽器中、或通過(guò)客戶端

20、程序提供展示、或?yàn)槠渌麘?yīng)用系統(tǒng)提供訪問(wèn)電子文檔的方法。3.1.3. 邏輯架構(gòu). 電子文檔系統(tǒng)生態(tài)環(huán)境外圍系統(tǒng)梳理電子文檔系統(tǒng)為專利電子審批系統(tǒng)提供訪問(wèn)電子文檔的接口。文件的獲取、修改、刪除、拆分和合并等操作，電子申請(qǐng)聯(lián)機(jī)入庫(kù)、通知書(shū)文件聯(lián)機(jī)入庫(kù)、其它文件聯(lián)機(jī)入庫(kù)及入庫(kù)情況的通知反饋與查詢。. 外圍系統(tǒng)與電子文檔系統(tǒng)各子系統(tǒng)關(guān)系電子文檔系統(tǒng)包括人工文件處理子系統(tǒng)、對(duì)外服務(wù)子系統(tǒng)、電子形式文件處理子系統(tǒng)、CEPCT系統(tǒng)文件處理子系統(tǒng)、集成電路布圖文件處理子系統(tǒng)。其中人工處理子系統(tǒng)與E系統(tǒng)的主要接口包括文件的獲取、文件屬性的修改、文件實(shí)體的修改、文件的拆分與合并；對(duì)外服務(wù)

21、子系統(tǒng)包括的接口主要是電子申請(qǐng)裝庫(kù)接口、通知書(shū)裝庫(kù)接口、其他聯(lián)機(jī)文件入庫(kù)接口；人工處理子系統(tǒng)包括的接口主要是受理信息訪問(wèn)、裝庫(kù)情況通知接口、電子文檔系統(tǒng)裝庫(kù)情況查詢接口。. 電子文檔系統(tǒng)維護(hù)邏輯電子文檔系統(tǒng)能夠正常地運(yùn)轉(zhuǎn)，為審查提供電子文檔服務(wù)，需要高質(zhì)量的維護(hù)工作作為保障。一方面系統(tǒng)出現(xiàn)故障時(shí)，能夠得到及時(shí)有效的處理，盡快排除故障，盡可能不影響為審查提供電子文檔的服務(wù)。另一方面，電子文檔作為海量數(shù)據(jù)存儲(chǔ)系統(tǒng)，需要對(duì)數(shù)據(jù)進(jìn)行備份，在系統(tǒng)中出現(xiàn)數(shù)據(jù)錯(cuò)誤時(shí)，能夠及時(shí)將數(shù)據(jù)恢復(fù)到已知的狀態(tài)。電子文檔系統(tǒng)中的數(shù)據(jù)需要納入到磁帶庫(kù)自動(dòng)備份中去。目前XX局已經(jīng)建立了磁帶庫(kù)備份系統(tǒng)，需要考慮將

22、電子文檔數(shù)據(jù)的備份也納入其自動(dòng)備份策略中。這將使用磁帶庫(kù)系統(tǒng)中相應(yīng)容量的磁帶，需要根據(jù)磁帶庫(kù)系統(tǒng)的容量和目前的規(guī)劃，調(diào)整其自動(dòng)備份策略。電子文檔系統(tǒng)的人工備份也是必不可少的，一方面是臨時(shí)文件登記和文件目錄管理服務(wù)器、文件目錄服務(wù)器和文件登記服務(wù)器必須能夠人工備份到磁帶中，保證系統(tǒng)的可靠性；另一方面需要通過(guò)人工備份將電子文檔中的數(shù)據(jù)備份到磁帶中并上架保存。3.1.4. 體系架構(gòu)系統(tǒng)的主要功能如下圖所示，主要包括電子文檔裝載服務(wù)、電子文檔核心服務(wù)和電子文檔瀏覽服務(wù)三部分。電子文檔核心服務(wù)提供了對(duì)電子文檔的統(tǒng)一管理功能。通過(guò)電子文檔裝載服務(wù)功能，將各種不同來(lái)源的電子文件裝入電子文檔系統(tǒng)。通過(guò)電子文檔

23、瀏覽服務(wù)功能，可以從電子文檔系統(tǒng)中獲取所需要的電子文件。3.2. 存儲(chǔ)區(qū)設(shè)計(jì)電子文檔系統(tǒng)使用NAS存儲(chǔ)作為存儲(chǔ)介質(zhì)，存放實(shí)體文件。NAS存儲(chǔ)地址對(duì)用戶透明，由電子文檔系統(tǒng)負(fù)責(zé)統(tǒng)一管理。對(duì)外服務(wù)時(shí)將實(shí)體文件置于緩存服務(wù)器上，并以FTP方式向用戶提供文件實(shí)體。3.3. 接口設(shè)計(jì)3.3.1. 對(duì)外服務(wù)接口說(shuō)明對(duì)外服務(wù)使用WebService， 主要包含文件的獲取、文件屬性修改、文件實(shí)體修改、文件拆分及合并。3.3.2. E系統(tǒng)電子形式文件數(shù)據(jù)交換接口對(duì)于申請(qǐng)人依據(jù)電子申請(qǐng)模式提交的文件，E系統(tǒng)將電子文件拆分成標(biāo)準(zhǔn)格式之后，生成文件標(biāo)識(shí)符，然后按照格式生成文件屬性。PCT一處通過(guò)對(duì)此類文件進(jìn)行軟掃，生成TI