本發(fā)明涉及異步數(shù)據(jù)同步領(lǐng)域，特別涉及基于http服務(wù)切面與日志系統(tǒng)的異步數(shù)據(jù)同步方法和系統(tǒng)。

背景技術(shù)：

Bloor研究所2010的一項(xiàng)調(diào)查顯示，估計(jì)數(shù)據(jù)遷移市場(chǎng)將超過(guò)50億美元并且還正在日益增長(zhǎng)。現(xiàn)在許多公司有不同的方法進(jìn)行數(shù)據(jù)庫(kù)遷移，如抽取/轉(zhuǎn)換/裝載(簡(jiǎn)稱(chēng)ETL)，復(fù)制和手動(dòng)腳本。然而這些方法面臨著一些問(wèn)題，當(dāng)一方面數(shù)據(jù)量在增長(zhǎng)，而另一方面允許的停機(jī)時(shí)間在減少時(shí)，這項(xiàng)工作將變得更復(fù)雜。數(shù)據(jù)遷移下統(tǒng)計(jì)數(shù)據(jù)大致如下：

·16％的數(shù)據(jù)遷移部分項(xiàng)目取得了成功

·37％的預(yù)算超支

·64％沒(méi)有按時(shí)完成

所以，遷移要經(jīng)過(guò)精心策劃和執(zhí)行，以盡量減少停機(jī)時(shí)間并保持?jǐn)?shù)據(jù)的完整性和數(shù)據(jù)庫(kù)的性能，因?yàn)樵S多公司已經(jīng)遍布全球，并且每天24小時(shí)都要操作數(shù)據(jù)庫(kù)。

有些情況下公司會(huì)做異構(gòu)數(shù)據(jù)庫(kù)的遷移與切換：例如為了減少費(fèi)用與技術(shù)靈活度，很多公司會(huì)選擇從商用數(shù)據(jù)庫(kù)遷移到開(kāi)源數(shù)據(jù)庫(kù)。遷移是件很麻煩的事情，因?yàn)檫w移不可能一蹴而就而是一個(gè)慢慢變遷的過(guò)程，所以就需要同時(shí)運(yùn)營(yíng)新老兩套系統(tǒng)。同時(shí)，遷移還需要考慮老的應(yīng)用、其他服務(wù)的兼容。而兼容即包括：老系統(tǒng)接口的兼容、數(shù)據(jù)服務(wù)的兼容等。一般而言，接口的兼容容易實(shí)現(xiàn)，只需要對(duì)開(kāi)發(fā)人員進(jìn)行統(tǒng)一的約束、定期安排代碼審查即可。麻煩的是數(shù)據(jù)的協(xié)調(diào)、確保其他使用老系統(tǒng)數(shù)據(jù)的系統(tǒng)可以正常提供優(yōu)質(zhì)服務(wù)。因此，就需要打通數(shù)據(jù)環(huán)節(jié)。如何采用正確的方式來(lái)打通這個(gè)環(huán)節(jié)是現(xiàn)有技術(shù)中的難點(diǎn)。另外，由于新系統(tǒng)替換老系統(tǒng)需要時(shí)間去過(guò)度，所以數(shù)據(jù)同步就需要考慮是雙向同步、還是單向同步。一般而言，雙向同要比單向同步復(fù)雜很多。而數(shù)據(jù)同步需要考慮的問(wèn)題有很多，比如：同步的延遲不能太大、同步的數(shù)據(jù)要完備、數(shù)據(jù)不可丟失、對(duì)原有系統(tǒng)要有較低的侵入、數(shù)據(jù)庫(kù)無(wú)關(guān)性等等。

異構(gòu)數(shù)據(jù)庫(kù)遷移的方法包括：1)利用Power Builder的數(shù)據(jù)管道技術(shù)；2)利用ODBC技術(shù)和SQL語(yǔ)句；3)利用系統(tǒng)工具實(shí)現(xiàn)數(shù)據(jù)遷移。然而，這些方法大多操作較為復(fù)雜、靈活性差，不能夠?qū)崿F(xiàn)對(duì)數(shù)據(jù)的良好組織管理；不能自動(dòng)完成數(shù)據(jù)的遷移，用戶(hù)需要清楚地了解數(shù)據(jù)庫(kù)的儲(chǔ)存結(jié)構(gòu)，且需要花費(fèi)大量時(shí)間進(jìn)行調(diào)試；并且一旦數(shù)據(jù)庫(kù)結(jié)構(gòu)發(fā)生變化，代碼需要作大量改動(dòng)，后期維護(hù)很困難。另外，系統(tǒng)工具又有一定的局限性，比較依賴(lài)具體的數(shù)據(jù)庫(kù)產(chǎn)品，通用性欠缺，需要利用這些工具編寫(xiě)適當(dāng)?shù)倪w移程序。

技術(shù)實(shí)現(xiàn)要素：

本發(fā)明要解決的技術(shù)問(wèn)題是，如何采用應(yīng)用日志的方式來(lái)實(shí)現(xiàn)數(shù)據(jù)同步。

解決上述技術(shù)問(wèn)題，本發(fā)明提供了基于http服務(wù)切面與日志系統(tǒng)的異步數(shù)據(jù)同步方法，包括如下步驟:

攔截客戶(hù)端的接口請(qǐng)求，并記錄接口訪(fǎng)問(wèn)日志，

將所述訪(fǎng)問(wèn)日志作為請(qǐng)求事件源傳遞至消息隊(duì)列，解析所述消息隊(duì)列中的訪(fǎng)問(wèn)日志，

解析后還原請(qǐng)求事件的入?yún)⒑?或出參，將數(shù)據(jù)轉(zhuǎn)換后進(jìn)行新老系統(tǒng)的數(shù)據(jù)映射后再寫(xiě)入新數(shù)據(jù)庫(kù)。

更進(jìn)一步，攔截客戶(hù)端的接口具體包括：采用切面技術(shù)來(lái)攔截接口請(qǐng)求。

更進(jìn)一步，所述切面技術(shù)采用：jaxrs的請(qǐng)求過(guò)濾器、servlet的過(guò)濾器、spring mvc的攔截器中的一種或者多種，用以提取所述接口請(qǐng)求中的入?yún)?、出參、url以及method的數(shù)據(jù)。

更進(jìn)一步，將所述訪(fǎng)問(wèn)日志作為請(qǐng)求事件源傳遞至消息隊(duì)列的方法具體為：采用log4j2的kafka組件直接將日志寫(xiě)入到kafka隊(duì)列。

更進(jìn)一步，將所述訪(fǎng)問(wèn)日志作為請(qǐng)求事件源傳遞至消息隊(duì)列的方法具體為：通過(guò)flume或者fluent的采集工具將數(shù)據(jù)提交到kafka隊(duì)列。

更進(jìn)一步，解析所述消息隊(duì)列中的訪(fǎng)問(wèn)日志的方法至少包括：一處理程序，用以將正確的消息保存到本地庫(kù)中，再去做同步，如果處理失敗則自動(dòng)重試，所述自動(dòng)重試的次數(shù)不大于3次，若大于3次則進(jìn)行人工處理。

更進(jìn)一步，方法還包括：在寫(xiě)方法上加注釋?zhuān)倬帉?xiě)處理程序。

更進(jìn)一步，將日志寫(xiě)入老系統(tǒng)的數(shù)據(jù)庫(kù)，然后配置flume或者fluent來(lái)sink日志到kafka隊(duì)列。

更進(jìn)一步，方法還包括：采用hibernate、mybatis或者任一db框架來(lái)進(jìn)行新老數(shù)據(jù)庫(kù)中數(shù)據(jù)的提取和寫(xiě)入。

基于上述，本申請(qǐng)還提供了基于http服務(wù)切面與日志系統(tǒng)的異步數(shù)據(jù)同步系統(tǒng)，包括：

一攔截單元，用以攔截客戶(hù)端的接口請(qǐng)求，并記錄接口訪(fǎng)問(wèn)日志，

一隊(duì)列單元，用以將所述訪(fǎng)問(wèn)日志作為請(qǐng)求事件源傳遞至消息隊(duì)列，解析所述消息隊(duì)列中的訪(fǎng)問(wèn)日志，

一處理程序，用以解析后還原請(qǐng)求事件的入?yún)⒑?或出參，將數(shù)據(jù)轉(zhuǎn)換后進(jìn)行新老系統(tǒng)的數(shù)據(jù)映射后再寫(xiě)入新數(shù)據(jù)庫(kù)。

本發(fā)明的有益效果：

由于本發(fā)明的方法包括攔截客戶(hù)端的接口請(qǐng)求，并記錄接口訪(fǎng)問(wèn)日志，將所述訪(fǎng)問(wèn)日志作為請(qǐng)求事件源傳遞至消息隊(duì)列，解析所述消息隊(duì)列中的訪(fǎng)問(wèn)日志，解析后還原請(qǐng)求事件的入?yún)⒑?或出參，將數(shù)據(jù)轉(zhuǎn)換后進(jìn)行新老系統(tǒng)的數(shù)據(jù)映射后再寫(xiě)入新數(shù)據(jù)庫(kù)。通過(guò)對(duì)接口記錄日志，將日志提交到任意一種數(shù)據(jù)源，由處理程序處理數(shù)據(jù)源的日志、做數(shù)據(jù)轉(zhuǎn)換、同步到新的庫(kù)中。從而可讓異步數(shù)據(jù)同步的延遲降低、復(fù)雜度可控。

此外，本發(fā)明提供的系統(tǒng)，并不針對(duì)特定的數(shù)據(jù)庫(kù)，同時(shí)可擴(kuò)展能力較高。

附圖說(shuō)明

圖1是本發(fā)明中的方法流程示意圖；

圖2是本發(fā)明中的系統(tǒng)的結(jié)構(gòu)示意圖；

圖3圖1中的進(jìn)一步處理步驟示意圖；

圖4是圖1中的請(qǐng)求接口數(shù)據(jù)的類(lèi)型示意圖；

圖5是圖1中的方法具體實(shí)施方式示意圖；

圖6是圖1中的方法另一具體實(shí)施方式示意圖。

具體實(shí)施方式

現(xiàn)在將參考一些示例實(shí)施例描述本公開(kāi)的原理?？梢岳斫猓@些實(shí)施例僅出于說(shuō)明并且?guī)椭绢I(lǐng)域的技術(shù)人員理解和實(shí)施例本公開(kāi)的目的而描述，而非建議對(duì)本公開(kāi)的范圍的任何限制。在此描述的本公開(kāi)的內(nèi)容可以以下文描述的方式之外的各種方式實(shí)施。

如本文中所述，術(shù)語(yǔ)“包括”及其各種變體可以被理解為開(kāi)放式術(shù)語(yǔ)，其意味著“包括但不限于”。術(shù)語(yǔ)“基于”可以被理解為“至少部分地基于”。術(shù)語(yǔ)“一個(gè)實(shí)施例”可以被理解為“至少一個(gè)實(shí)施例”。術(shù)語(yǔ)“另一實(shí)施例”可以被理解為“至少一個(gè)其它實(shí)施例”。

可以理解，本申請(qǐng)中的客戶(hù)端是指基于http協(xié)議的客戶(hù)端，如：瀏覽器、編程語(yǔ)言使用的http client等。HTTP協(xié)議(HyperText Transfer Protocol，超文本傳輸協(xié)議)是用于從www服務(wù)器傳輸超文本到本地瀏覽器的傳輸協(xié)議?？梢允篂g覽器更加高效，使網(wǎng)絡(luò)傳輸減少。它不僅保證計(jì)算機(jī)正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分，以及哪部分內(nèi)容首先顯示(如文本先于圖形)等。需要說(shuō)明的是，本申請(qǐng)的基于的HTTP協(xié)議是客戶(hù)端瀏覽器或其他程序與Web服務(wù)器之間的應(yīng)用層通信協(xié)議。在Internet上的Web服務(wù)器上存放的都是超文本信息，客戶(hù)機(jī)需要通過(guò)HTTP協(xié)議傳輸所要訪(fǎng)問(wèn)的超文本信息。HTTP包含命令和傳輸信息，不僅可用于Web訪(fǎng)問(wèn)，也可以用于其他因特網(wǎng)/內(nèi)聯(lián)網(wǎng)應(yīng)用系統(tǒng)之間的通信，從而實(shí)現(xiàn)各類(lèi)應(yīng)用資源超媒體訪(fǎng)問(wèn)的集成。

HTTP協(xié)議能夠支持客戶(hù)/服務(wù)器模式，客戶(hù)向服務(wù)器請(qǐng)求服務(wù)時(shí)，只需傳送請(qǐng)求方法和路徑。請(qǐng)求方法包括但不限于：GET、HEAD、POST。每種方法規(guī)定了客戶(hù)與服務(wù)器聯(lián)系的類(lèi)型不同。另外，HTTP協(xié)議允許傳輸任意類(lèi)型的數(shù)據(jù)對(duì)象，正在傳輸?shù)念?lèi)型由Content-Type加以標(biāo)記。

在本申請(qǐng)中的Flume是Cloudera提供的一個(gè)高可用的，高可靠的，分布式的海量日志采集、聚合和傳輸?shù)南到y(tǒng)，F(xiàn)lume支持在日志系統(tǒng)中定制各類(lèi)數(shù)據(jù)發(fā)送方，用于收集數(shù)據(jù)；同時(shí)，F(xiàn)lume提供對(duì)數(shù)據(jù)進(jìn)行簡(jiǎn)單處理，并寫(xiě)到各種數(shù)據(jù)接受方(可定制)的能力。Flume最早是Cloudera提供的日志收集系統(tǒng)，目前是Apache下的一個(gè)孵化項(xiàng)目，F(xiàn)lume支持在日志系統(tǒng)中定制各類(lèi)數(shù)據(jù)發(fā)送方，用于收集數(shù)據(jù)。數(shù)據(jù)處理方面：Flume提供對(duì)數(shù)據(jù)進(jìn)行簡(jiǎn)單處理，并寫(xiě)到各種數(shù)據(jù)接受方(可定制)的能力Flume提供了從console(控制臺(tái))、RPC(Thrift-RPC)、text(文件)、tail(UNIX tail)、syslog(syslog日志系統(tǒng)，支持TCP和UDP等2種模式)，exec(命令執(zhí)行)等數(shù)據(jù)源上收集數(shù)據(jù)的能力。

圖1是本發(fā)明中的方法流程示意圖；步驟S100攔截客戶(hù)端的接口請(qǐng)求，并記錄接口訪(fǎng)問(wèn)日志，所述攔截客戶(hù)端的接口具體包括：采用切面技術(shù)來(lái)攔截接口請(qǐng)求，所述切面技術(shù)采用：jaxrs的請(qǐng)求過(guò)濾器、servlet的過(guò)濾器、spring mvc的攔截器中的一種或者多種，用以提取所述接口請(qǐng)求中的入?yún)?、出參、url以及method的數(shù)據(jù)。如圖4是圖1中的請(qǐng)求接口數(shù)據(jù)的類(lèi)型示意圖；請(qǐng)求接口數(shù)據(jù)包括但不限于：請(qǐng)求ID、時(shí)間ID、請(qǐng)求URL、請(qǐng)求數(shù)據(jù)類(lèi)型、返回?cái)?shù)據(jù)類(lèi)型等。

步驟S101將所述訪(fǎng)問(wèn)日志作為請(qǐng)求事件源傳遞至消息隊(duì)列，解析所述消息隊(duì)列中的訪(fǎng)問(wèn)日志，在所述步驟S101中將所述訪(fǎng)問(wèn)日志作為請(qǐng)求事件源傳遞至消息隊(duì)列的方法具體為：采用log4j2的Kafka組件直接將日志寫(xiě)入到Kafka隊(duì)列。在一些實(shí)施例中，將所述訪(fǎng)問(wèn)日志作為請(qǐng)求事件源傳遞至消息隊(duì)列的方法具體為：通過(guò)flume或者fluent的采集工具將數(shù)據(jù)提交到Kafka隊(duì)列。

Kafka是一種分布式的基于發(fā)布/訂閱的消息系統(tǒng)，以時(shí)間復(fù)雜度為O(1)的方式提供消息持久化能力，并保證即使對(duì)TB級(jí)以上數(shù)據(jù)也能保證常數(shù)時(shí)間的訪(fǎng)問(wèn)性能。所以，在上述實(shí)施例中采用log4j2的Kafka組件直接將日志寫(xiě)入到Kafka隊(duì)列，由于Kafka具備高吞吐率，同時(shí)支持離線(xiàn)數(shù)據(jù)處理和實(shí)時(shí)數(shù)據(jù)處理，所以可以將所述訪(fǎng)問(wèn)日志作為請(qǐng)求事件源傳遞至消息隊(duì)列的優(yōu)選方法。

步驟S102解析后還原請(qǐng)求事件的入?yún)⒑?或出參，將數(shù)據(jù)轉(zhuǎn)換后進(jìn)行新老系統(tǒng)的數(shù)據(jù)映射后再寫(xiě)入新數(shù)據(jù)庫(kù)。

在上述步驟S101中，解析包括但不限于：日志以JSON的格式存儲(chǔ)，可以采用JSON庫(kù)將對(duì)應(yīng)的請(qǐng)求消息轉(zhuǎn)換成封裝好的對(duì)象。JSON是一種輕量級(jí)的數(shù)據(jù)格式，易于程序員閱讀和編寫(xiě)，同時(shí)也易于機(jī)器解析和生成。JSON可以將JavaScr ipt對(duì)象中表示的一組數(shù)據(jù)轉(zhuǎn)換為字符串，然后就可以在函數(shù)之間輕松地傳遞這個(gè)字符串，或者在異步應(yīng)用程序中將字符串從Web客戶(hù)機(jī)傳遞給服務(wù)器端程序。

在一些實(shí)施例中，解析所述消息隊(duì)列中的訪(fǎng)問(wèn)日志的方法至少包括：一處理程序，用以將正確的消息保存到本地庫(kù)中，再去做同步，如果處理失敗則自動(dòng)重試，所述自動(dòng)重試的次數(shù)不大于3次，若大于3次則進(jìn)行人工處理。

在一些實(shí)施例中，方法還包括：在寫(xiě)方法上加注釋?zhuān)倬帉?xiě)處理程序。在本申請(qǐng)中使用該注解的目的是用來(lái)找出需要做數(shù)據(jù)同步的服務(wù)，系統(tǒng)在做處理的時(shí)候會(huì)查看服務(wù)上有沒(méi)有該注解，如果有就輸出同步日志到隊(duì)列。如果沒(méi)有就不做處理。比如：會(huì)員模塊有注冊(cè)、更新、查詢(xún)等服務(wù)，這里只有注冊(cè)、更新需要做數(shù)據(jù)同步，而查詢(xún)是不需要的。這種情況下只需要對(duì)注冊(cè)、更新加上注解即可。

在本申請(qǐng)中，使用注解可以減少無(wú)效的日志寫(xiě)入隊(duì)列，同時(shí)，也可以提升同步處理效率。

在一些實(shí)施例中，將日志寫(xiě)入老系統(tǒng)的數(shù)據(jù)庫(kù)，然后配置flume或者fluent來(lái)sink日志到kafka隊(duì)列。

在一些實(shí)施例中，方法還包括：采用hibernate、mybatis或者任一db框架來(lái)進(jìn)行新老數(shù)據(jù)庫(kù)中數(shù)據(jù)的提取和寫(xiě)入。

上述實(shí)施例中，基于HTTP協(xié)議限制每次連接只處理一個(gè)請(qǐng)求，服務(wù)器處理完客戶(hù)的請(qǐng)求，并收到客戶(hù)的應(yīng)答后，即斷開(kāi)連接。采用這種方式可以節(jié)省傳輸時(shí)間。另外，HTTP協(xié)議是無(wú)狀態(tài)協(xié)議，即是指協(xié)議對(duì)于事務(wù)處理沒(méi)有記憶能力，在服務(wù)器不需要先前信息時(shí)的應(yīng)答就較快。另外，JSON格式可以表示數(shù)組和復(fù)雜的對(duì)象，而不僅僅是鍵和值的簡(jiǎn)單列表，對(duì)于異步數(shù)據(jù)同步而言具有更好地適應(yīng)性。

圖2是本發(fā)明中的系統(tǒng)的結(jié)構(gòu)示意圖；系統(tǒng)包括：攔截單元1，用以攔截客戶(hù)端的接口請(qǐng)求，并記錄接口訪(fǎng)問(wèn)日志，隊(duì)列單元2，用以將所述訪(fǎng)問(wèn)日志作為請(qǐng)求事件源傳遞至消息隊(duì)列，解析所述消息隊(duì)列中的訪(fǎng)問(wèn)日志，以及，處理程序3，用以解析后還原請(qǐng)求事件的入?yún)⒑?或出參，將數(shù)據(jù)轉(zhuǎn)換后進(jìn)行新老系統(tǒng)的數(shù)據(jù)映射后再寫(xiě)入新數(shù)據(jù)庫(kù)。在所述攔截單元1采用切面技術(shù)來(lái)攔截接口請(qǐng)求。具體地，所述切面技術(shù)采用：jaxrs的請(qǐng)求過(guò)濾器、servlet的過(guò)濾器、spring mvc的攔截器中的一種或者多種，用以提取所述接口請(qǐng)求中的入?yún)?、出參、url以及method的數(shù)據(jù)。在所述隊(duì)列單元2中將所述訪(fǎng)問(wèn)日志作為請(qǐng)求事件源傳遞至消息隊(duì)列的方法具體為：采用log4j2的kafka組件直接將日志寫(xiě)入到kafka隊(duì)列。和/或，將所述訪(fǎng)問(wèn)日志作為請(qǐng)求事件源傳遞至消息隊(duì)列的方法具體為：通過(guò)flume或者fluent的采集工具將數(shù)據(jù)提交到kafka隊(duì)列，也可以將日志寫(xiě)入老系統(tǒng)的數(shù)據(jù)庫(kù)，然后配置flume或者fluent來(lái)sink日志到kafka隊(duì)列。作為本實(shí)施例中的優(yōu)選，在所述處理程序3中，解析所述消息隊(duì)列中的訪(fǎng)問(wèn)日志的方法至少包括：一處理程序，用以將正確的消息保存到本地庫(kù)中，再去做同步，如果處理失敗則自動(dòng)重試，所述自動(dòng)重試的次數(shù)不大于3次，若大于3次則進(jìn)行人工處理。

本實(shí)施例中的系統(tǒng)，由于采用了隊(duì)列單元2，可以有效地降低延遲，同時(shí)具備高可擴(kuò)展能力。由于處理程序3解析后還原請(qǐng)求事件的入?yún)⒑?或出參，將數(shù)據(jù)轉(zhuǎn)換后進(jìn)行新老系統(tǒng)的數(shù)據(jù)映射后再寫(xiě)入新數(shù)據(jù)庫(kù)，使得整個(gè)系統(tǒng)復(fù)雜度可控、數(shù)據(jù)庫(kù)無(wú)關(guān)。另外，由于攔截單元1，攔截客戶(hù)端的接口請(qǐng)求，并記錄接口訪(fǎng)問(wèn)日志降低了應(yīng)用侵入性。

圖3圖1中的進(jìn)一步處理步驟示意圖；解析所述消息隊(duì)列中的訪(fǎng)問(wèn)日志的方法至少包括：一處理程序，用以將正確的消息保存到本地庫(kù)中，再去做同步，如果處理失敗則自動(dòng)重試，所述自動(dòng)重試的次數(shù)不大于3次，若大于3次則進(jìn)行人工處理。

具體包括步驟為：

步驟S200從kafka提取數(shù)據(jù)同步的日志

步驟S201解析日志

步驟S202提取URL等數(shù)據(jù)放入exchange頭

步驟S203保存數(shù)據(jù)同步請(qǐng)求事件

步驟S204根據(jù)URL匹配到對(duì)應(yīng)的處理程序

步驟S205調(diào)用對(duì)應(yīng)的處理程序處理同步請(qǐng)求

若處理失敗且失敗次數(shù)小于3，則進(jìn)入步驟S206數(shù)據(jù)放回隊(duì)列

若處理成功或者失敗的次數(shù)不小于3，則進(jìn)入步驟S207處理完成更新完成數(shù)據(jù)

圖5是圖1中的方法具體實(shí)施方式示意圖；

step1客戶(hù)發(fā)起寫(xiě)入請(qǐng)求到新的系統(tǒng)；

step 2系統(tǒng)接收請(qǐng)求后分析該請(qǐng)求是否需要做數(shù)據(jù)同步；

step 3如果需要做數(shù)據(jù)同步，則DataSyncFilter數(shù)據(jù)同步過(guò)濾器會(huì)將對(duì)應(yīng)的請(qǐng)求和響應(yīng)信息進(jìn)行封裝，然后寫(xiě)入隊(duì)列；

step 4處理程序會(huì)從隊(duì)列里提取消息；

step 5處理程序解析消息，將其轉(zhuǎn)換回封裝的對(duì)象；

step 6處理程序根據(jù)請(qǐng)求和響應(yīng)去新的庫(kù)里提取數(shù)據(jù)；

step 7處理程序?qū)⑿碌臄?shù)據(jù)映射成老的數(shù)據(jù)；

step 8處理程序保存老的數(shù)據(jù)到老系統(tǒng)的數(shù)據(jù)庫(kù)。

首先，攔截應(yīng)用系統(tǒng)的接口日志。這里采用切面技術(shù)(切面如：jaxrs的請(qǐng)求過(guò)濾器、servlet的過(guò)濾器、spring mvc的攔截器等)來(lái)攔截系統(tǒng)的請(qǐng)求，通過(guò)過(guò)濾器來(lái)提取請(qǐng)求的入?yún)?、出參、url、method等數(shù)據(jù)。其次，本方案采用log4j2的kafka組件直接將日志寫(xiě)入到kafka隊(duì)列的。當(dāng)然，也可以通過(guò)flume、fluent這樣的采集工具將數(shù)據(jù)提交到kafka。接著，構(gòu)建處理程序從kafka提取數(shù)據(jù)進(jìn)行處理、做好數(shù)據(jù)轉(zhuǎn)換、保存數(shù)據(jù)到新的庫(kù)里。處理程序會(huì)將正確的消息保存到本地庫(kù)中，然后再去做同步，如果處理失敗會(huì)自動(dòng)重試。重試是有次數(shù)限制的，系統(tǒng)默認(rèn)的重試次數(shù)是3次，大于3次說(shuō)明需要人工介入進(jìn)行特殊處理了。大于3次的原因有很多，可能是數(shù)據(jù)映射做錯(cuò)了，或者是數(shù)據(jù)庫(kù)磁盤(pán)滿(mǎn)了等。

最后，接入并使用數(shù)據(jù)同步呢，在需要做數(shù)據(jù)同步的寫(xiě)方法上加@DataSyncLogged，然后編寫(xiě)處理程序即可。這里的處理程序需要接入者完成新老表的數(shù)據(jù)映射，保存數(shù)據(jù)到新的庫(kù)。使用@DataSyncLogged該注解的目的是用來(lái)找出需要做數(shù)據(jù)同步的服務(wù)，系統(tǒng)在做處理的時(shí)候會(huì)查看服務(wù)上有沒(méi)有該注解，如果有就輸出同步日志到隊(duì)列。如果沒(méi)有就不做處理。

優(yōu)選地，接入者如果覺(jué)得使用log4j2直接寫(xiě)入日志到kafka對(duì)應(yīng)用有比較大的影響，可以考慮將日志寫(xiě)入本低文件系統(tǒng)。然后配置flume或者fluent來(lái)sink日志到kafka隊(duì)列也可以。

優(yōu)選地，接入者如果不想使用kafka，那么可以更換掉。只是要注意下對(duì)應(yīng)的處理程序的數(shù)據(jù)來(lái)源需要調(diào)整為新的數(shù)據(jù)源，如：hbase等。

優(yōu)選地，接入者可以選擇自己喜歡的數(shù)據(jù)庫(kù)框架來(lái)做數(shù)據(jù)的提取和寫(xiě)入，hibernate、mybatis或者其他的db框架任君選擇。

上述方法，可以適用于本申請(qǐng)中的系統(tǒng)，攔截單元1，用以攔截客戶(hù)端的接口請(qǐng)求，并記錄接口訪(fǎng)問(wèn)日志，隊(duì)列單元2，用以將所述訪(fǎng)問(wèn)日志作為請(qǐng)求事件源傳遞至消息隊(duì)列，解析所述消息隊(duì)列中的訪(fǎng)問(wèn)日志，以及，處理程序3，用以解析后還原請(qǐng)求事件的入?yún)⒑?或出參，將數(shù)據(jù)轉(zhuǎn)換后進(jìn)行新老系統(tǒng)的數(shù)據(jù)映射后再寫(xiě)入新數(shù)據(jù)庫(kù)。

圖6是圖1中的方法另一具體實(shí)施方式示意圖。

Step1客戶(hù)發(fā)起寫(xiě)入請(qǐng)求到新的系統(tǒng)；

Step2系統(tǒng)接收請(qǐng)求后分析該請(qǐng)求是否需要做數(shù)據(jù)同步；

Step3如果需要做數(shù)據(jù)同步，那么DataSync Filter數(shù)據(jù)同步過(guò)濾器會(huì)將對(duì)應(yīng)的請(qǐng)求和響應(yīng)信息進(jìn)行封裝，然后寫(xiě)入日志文件；

Step4采集程序(如：flume、fluent)會(huì)采集日志并寫(xiě)入隊(duì)列；

Step5處理程序會(huì)從隊(duì)列里提取消息；

Step6處理程序解析消息，將其轉(zhuǎn)換回封裝的對(duì)象；

Step7處理程序根據(jù)請(qǐng)求和響應(yīng)去新的庫(kù)里提取數(shù)據(jù)；

Step8處理程序?qū)⑿碌臄?shù)據(jù)映射成老的數(shù)據(jù)；

Step9處理程序保存老的數(shù)據(jù)到老系統(tǒng)的數(shù)據(jù)庫(kù)。

首先，攔截應(yīng)用系統(tǒng)的接口日志。這里采用切面技術(shù)(切面如：jaxrs的請(qǐng)求過(guò)濾器、servlet的過(guò)濾器、spring mvc的攔截器等)來(lái)攔截系統(tǒng)的請(qǐng)求，通過(guò)過(guò)濾器來(lái)提取請(qǐng)求的入?yún)?、出參、url、method等數(shù)據(jù)。其次，本方案采用log4j2的kafka組件直接將日志寫(xiě)入到kafka隊(duì)列的。當(dāng)然，也可以通過(guò)flume、fluent這樣的采集工具將數(shù)據(jù)提交到kafka。接著，構(gòu)建處理程序從kafka提取數(shù)據(jù)進(jìn)行處理、做好數(shù)據(jù)轉(zhuǎn)換、保存數(shù)據(jù)到新的庫(kù)里。處理程序會(huì)將正確的消息保存到本地庫(kù)中，然后再去做同步，如果處理失敗會(huì)自動(dòng)重試。重試是有次數(shù)限制的，系統(tǒng)默認(rèn)的重試次數(shù)是3次，大于3次說(shuō)明需要人工介入進(jìn)行特殊處理了。大于3次的原因有很多，可能是數(shù)據(jù)映射做錯(cuò)了，或者是數(shù)據(jù)庫(kù)磁盤(pán)滿(mǎn)了等。

最后，接入并使用數(shù)據(jù)同步呢，在需要做數(shù)據(jù)同步的寫(xiě)方法上加@DataSyncLogged，然后編寫(xiě)處理程序即可。這里的處理程序需要接入者完成新老表的數(shù)據(jù)映射，保存數(shù)據(jù)到新的庫(kù)。使用@DataSyncLogged該注解的目的是用來(lái)找出需要做數(shù)據(jù)同步的服務(wù)，系統(tǒng)在做處理的時(shí)候會(huì)查看服務(wù)上有沒(méi)有該注解，如果有就輸出同步日志到隊(duì)列。如果沒(méi)有就不做處理。

上述方法，可以適用于本申請(qǐng)中的系統(tǒng)，攔截單元1，用以攔截客戶(hù)端的接口請(qǐng)求，并記錄接口訪(fǎng)問(wèn)日志，隊(duì)列單元2，用以將所述訪(fǎng)問(wèn)日志作為請(qǐng)求事件源傳遞至消息隊(duì)列，解析所述消息隊(duì)列中的訪(fǎng)問(wèn)日志，以及，處理程序3，用以解析后還原請(qǐng)求事件的入?yún)⒑?或出參，將數(shù)據(jù)轉(zhuǎn)換后進(jìn)行新老系統(tǒng)的數(shù)據(jù)映射后再寫(xiě)入新數(shù)據(jù)庫(kù)。

雖然本公開(kāi)以具體結(jié)構(gòu)特征和/或方法動(dòng)作來(lái)描述，但是可以理解在所附權(quán)利要求書(shū)中限定的本公開(kāi)并不必然限于上述具體特征或動(dòng)作。而是，上述具體特征和動(dòng)作僅公開(kāi)為實(shí)施權(quán)利要求的示例形式。