本發(fā)明涉及互聯(lián)網(wǎng)領(lǐng)域，特別涉及一種分布式API網(wǎng)關(guān)、管理方法及管理系統(tǒng)。
背景技術(shù)：
：基于互聯(lián)網(wǎng)的應(yīng)用正變得越來越普及，在這個過程中，有更多的站點將自身的資源開放給開發(fā)者來調(diào)用。對外提供的API(API，ApplicationProgrammingInterface，應(yīng)用程序編程接口)調(diào)用使得站點之間的內(nèi)容關(guān)聯(lián)性更強，同時這些開放的平臺也為用戶、開發(fā)者和中小網(wǎng)站帶來了更大的價值。為了對外提供統(tǒng)一的API接口，需要對開發(fā)者開放資源調(diào)用API的站點提供開放統(tǒng)一的API接口環(huán)境，來幫助使用者訪問站點的功能和資源?，F(xiàn)有技術(shù)中，分布式API網(wǎng)關(guān)是一種常見的使用方式，給開發(fā)者提供注冊API路由信息功能。API網(wǎng)關(guān)通過核心的路由轉(zhuǎn)發(fā)功能成為后端服務(wù)的統(tǒng)一入口，將服務(wù)以API的形式安全的開放給各類用戶、應(yīng)用等，采用多個路由裝置在存儲裝置與用戶客戶端之間相連，能夠?qū)崿F(xiàn)并行運算，網(wǎng)絡(luò)擴(kuò)展性好，初始配置要求少，部署速度快，而且分布式網(wǎng)關(guān)是流量轉(zhuǎn)發(fā)路徑最優(yōu)，但隨之帶來的問題是，當(dāng)其中一個用戶發(fā)送API修改請求后，只能修改相應(yīng)的路由裝置和API數(shù)據(jù)庫，難以保證其他設(shè)備的API被更新，因此無法保證數(shù)據(jù)的一致性。技術(shù)實現(xiàn)要素：有鑒于此，本發(fā)明的目的在于提供一種分布式API網(wǎng)關(guān)管理方法，以保證數(shù)據(jù)的一致性。其具體方案如下：一種分布式網(wǎng)關(guān)API管理方法，包括：接收用戶終端通過分布式網(wǎng)關(guān)中的目標(biāo)路由裝置轉(zhuǎn)發(fā)的目標(biāo)API修改請求，并修改API數(shù)據(jù)庫中的目標(biāo)API，記錄修改痕跡，其中，所述目標(biāo)路由裝置當(dāng)接收到用戶終端發(fā)送的目標(biāo)API修改請求，則修改自身緩存有的目標(biāo)API；利用所述修改痕跡，生成目標(biāo)API修改通知；向所述分布式網(wǎng)關(guān)中其余的路由裝置發(fā)送所述目標(biāo)API修改通知，以使其余的路由裝置利用所述目標(biāo)API修改通知，修改自身緩存的目標(biāo)API。優(yōu)選的，所述分布式網(wǎng)關(guān)中的路由裝置緩存的目標(biāo)API獲得過程，包括：接收所述用戶終端通過所述目標(biāo)路由裝置轉(zhuǎn)發(fā)的目標(biāo)API調(diào)用請求，將所述API數(shù)據(jù)庫中的目標(biāo)API發(fā)送給所述目標(biāo)路由裝置。優(yōu)選的，所述修改API數(shù)據(jù)庫中的目標(biāo)API的過程，包括：修改所述API數(shù)據(jù)庫中的目標(biāo)API，記錄修改痕跡，得到第一修改日志。優(yōu)選的，所述向所述分布式網(wǎng)關(guān)中其余的路由裝置發(fā)送所述目標(biāo)API修改通知后，還包括：接收其余的路由裝置發(fā)送的修改結(jié)果，并記錄在第二修改日志中；利用所述第二修改日志，判斷是否修改成功；如果未成功，則繼續(xù)發(fā)送所述目標(biāo)API修改通知直至修改成功。優(yōu)選的，所述利用所述修改痕跡，生成目標(biāo)API修改通知的過程包括：利用所述第一修改日志，生成對應(yīng)的key-value，得到目標(biāo)key-value；按照預(yù)設(shè)的周期，定期監(jiān)測key-value數(shù)據(jù)庫；當(dāng)監(jiān)測到所述key-value數(shù)據(jù)庫中已添加所述目標(biāo)key-value，則生成包括所述目標(biāo)key-value的所述目標(biāo)API通知。本發(fā)明還公開了一種分布式網(wǎng)關(guān)API管理系統(tǒng)，包括：請求接收模塊，用于接收用戶終端通過分布式網(wǎng)關(guān)中的目標(biāo)路由裝置轉(zhuǎn)發(fā)的目標(biāo)API修改請求，其中，所述目標(biāo)路由裝置當(dāng)接收到用戶終端發(fā)送的目標(biāo)API修改請求，則修改自身緩存有的目標(biāo)API；API修改模塊，用于修改API數(shù)據(jù)庫中的目標(biāo)API，記錄修改痕跡；通知生成模塊，用于利用所述修改痕跡，生成目標(biāo)API修改通知；第一通知發(fā)送模塊，用于向所述分布式網(wǎng)關(guān)中其余的路由裝置發(fā)送所述目標(biāo)API修改通知，以使其余的路由裝置利用所述目標(biāo)API修改通知，修改自身緩存的目標(biāo)API。優(yōu)選的，所述API修改模塊具體用于修改所述API數(shù)據(jù)庫中的目標(biāo)API，記錄修改痕跡，得到第一修改日志。優(yōu)選的，還包括：結(jié)果接收模塊，用于接收其余的路由裝置發(fā)送的修改結(jié)果，并記錄在第二修改日志中；修改判斷模塊，用于利用所述第二修改日志，判斷是否修改成功；第二通知發(fā)送模塊，用于如果未成功，則繼續(xù)發(fā)送所述目標(biāo)API修改通知直至修改成功。優(yōu)選的，所述第一通知生成模塊包括：key-value生成單元，用于利用所述第一修改日志，生成對應(yīng)的key-value，得到目標(biāo)key-value；key-value數(shù)據(jù)庫監(jiān)測單元，用于按照預(yù)設(shè)的周期，定期監(jiān)測key-value數(shù)據(jù)庫；通知生成單元，用于當(dāng)監(jiān)測到所述key-value數(shù)據(jù)庫中已添加所述目標(biāo)key-value，則生成包括所述目標(biāo)key-value的所述目標(biāo)API通知。本發(fā)明進(jìn)一步公開了一種分布式API網(wǎng)關(guān)，包括前述的分布式API網(wǎng)關(guān)管理系統(tǒng)。本發(fā)明中，分布式API網(wǎng)關(guān)管理方法，包括：接收用戶終端通過分布式網(wǎng)關(guān)中的目標(biāo)路由裝置轉(zhuǎn)發(fā)的目標(biāo)API修改請求，并修改API數(shù)據(jù)庫中的目標(biāo)API，記錄修改痕跡，其中，目標(biāo)路由裝置當(dāng)接收到用戶終端發(fā)送的目標(biāo)API修改請求，則修改自身緩存有的目標(biāo)API；利用修改痕跡，生成目標(biāo)API修改通知；向分布式網(wǎng)關(guān)中其余的路由裝置發(fā)送目標(biāo)API修改通知，以使其余的路由裝置利用目標(biāo)API修改通知，修改自身緩存的目標(biāo)API?？梢?，本發(fā)明在接收到用戶終端的修改請求后，不僅修改與用戶終端相應(yīng)的路由裝置中的目標(biāo)API和API數(shù)據(jù)庫中的目標(biāo)API，還利用API數(shù)據(jù)庫修改目標(biāo)API時，記錄的修改痕跡，向其余的路由裝置發(fā)送目標(biāo)API修改通知，使得其余的路由裝置利用目標(biāo)API修改通知，修改自身緩存的目標(biāo)API，因此，保證了分布式網(wǎng)關(guān)中每個路由裝置中的API都能夠一致，解決了數(shù)據(jù)一致性的問題。附圖說明為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對實施例或現(xiàn)有技術(shù)描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的實施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)提供的附圖獲得其他的附圖。圖1為本發(fā)明實施例提供的一種分布式API網(wǎng)關(guān)管理方法流程示意圖；圖2為本發(fā)明實施例提供的一種RestAPI在路由裝置中的緩存形式示意圖；圖3為本發(fā)明實施例提供的另一種分布式API網(wǎng)關(guān)管理方法流程示意圖；圖4為本發(fā)明實施例提供的一種分布式API網(wǎng)關(guān)管理系統(tǒng)結(jié)構(gòu)示意圖。具體實施方式下面將結(jié)合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術(shù)方案進(jìn)行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領(lǐng)域普通技術(shù)人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護(hù)的范圍。本發(fā)明實施例公開了一種分布式網(wǎng)關(guān)API管理方法，參見圖1所示，該方法包括：步驟S11：接收用戶終端通過分布式網(wǎng)關(guān)中的目標(biāo)路由裝置轉(zhuǎn)發(fā)的目標(biāo)API修改請求，并修改API數(shù)據(jù)庫中的目標(biāo)API，記錄修改痕跡。具體的，與分布式網(wǎng)關(guān)連接的用戶通過用戶終端，向分布式網(wǎng)關(guān)中的一個目標(biāo)路由裝置發(fā)送目標(biāo)API修改請求，由于目標(biāo)路由裝置中預(yù)先緩存有目標(biāo)API，所以目標(biāo)路由裝置當(dāng)接收到用戶終端發(fā)送的目標(biāo)API修改請求，則利用目標(biāo)API修改請求中相應(yīng)的修改內(nèi)容，修改自身緩存有的目標(biāo)API，同時，將用戶發(fā)送的目標(biāo)API修改請求轉(zhuǎn)發(fā)給服務(wù)器，服務(wù)器接收到目標(biāo)API修改請求后，利用目標(biāo)API修改請求中相應(yīng)的修改內(nèi)容，修改API數(shù)據(jù)庫中的目標(biāo)API，且服務(wù)器記錄下修改痕跡。其中，為了保證用戶調(diào)用API時，能夠快速的將API發(fā)送給用戶，以達(dá)到近實時轉(zhuǎn)發(fā)的效果，使路由裝置中預(yù)先緩存API，路由裝置中緩存的API，是在路由裝置第一次啟動后，接收到用戶對API的調(diào)用或修改請求后，向服務(wù)器中的API數(shù)據(jù)庫發(fā)送API獲取請求，服務(wù)器接收到獲取請求后，將API發(fā)送給路由裝置，路由裝置緩存從API數(shù)據(jù)庫中獲取的API。步驟S12：利用修改痕跡，生成目標(biāo)API修改通知。具體的，修改痕跡中，記錄著修改目標(biāo)API時的各種數(shù)據(jù)變動，能夠利用修改痕跡修改API，因此利用修改痕跡，生成相應(yīng)的目標(biāo)API修改通知，使得能夠根據(jù)修改通知對API進(jìn)行修改。步驟S13：向分布式網(wǎng)關(guān)中其余的路由裝置發(fā)送目標(biāo)API修改通知，以使其余的路由裝置利用目標(biāo)API修改通知，修改自身緩存的目標(biāo)API。具體的，服務(wù)器生成目標(biāo)API修改通知后，為保證各路由裝置中目標(biāo)API的一致性，向分布式網(wǎng)關(guān)中其余的路由裝置發(fā)送目標(biāo)API修改通知，以使其余的路由裝置利用目標(biāo)API修改通知，修改自身緩存的目標(biāo)API，使得用戶對一個路由裝置發(fā)送修改請求后，使全網(wǎng)關(guān)中的路由裝置中的API均進(jìn)行了相應(yīng)的修改?？梢姡景l(fā)明在接收到用戶終端的修改請求后，不僅修改與用戶終端相應(yīng)的路由裝置中的目標(biāo)API和API數(shù)據(jù)庫中的目標(biāo)API，還利用API數(shù)據(jù)庫修改目標(biāo)API時，記錄的修改痕跡，向其余的路由裝置發(fā)送目標(biāo)API修改通知，使得其余的路由裝置利用目標(biāo)API修改通知，修改自身緩存的目標(biāo)API，因此，保證了分布式網(wǎng)關(guān)中每個路由裝置中的API都能夠一致，解決了數(shù)據(jù)一致性的問題。可以理解的是，本發(fā)明中的分布式網(wǎng)關(guān)可以是在Restful架構(gòu)下構(gòu)建的，API為RestAPI，參見圖2所示，在路由裝置中的緩存形式可以為：RestAPIUrl：http://localhost:8888/serv1/a/b/cGEThttp://localhost:8888/serv1/a/b/dGEThttp://localhost:8888/serv1/b/c/dGEThttp://localhost:8888/serv1/b/c/dPOSThttp://localhost:8888/serv2/a/b/cPOST其中，API數(shù)據(jù)庫中的RestAPI保存形式可以為：http://localhost:8888/serv1/a/b/cGEThttp://localhost:8888/serv2/a/b/dPOSTRestAPI文本記錄方式如表1所示：表1idservurlactionenable1serv1a/b/cGETtrue2serv2a/b/dPOSTfalse在實際應(yīng)用中，路由裝置可能會收到用戶終端發(fā)送的不合理請求、錯誤信息和無用信息等垃圾信息，因此可以預(yù)先設(shè)置過濾信息表，將垃圾信息的類型記錄在過濾信息表中，當(dāng)路由裝置再次接收到過濾信息表中記錄的垃圾信息，則不進(jìn)行響應(yīng)，并且還可以返回給用戶終端錯誤提示；可以使用socket、http長連接或者RPC協(xié)議接收服務(wù)器發(fā)送的各類信息。本發(fā)明實施例公開了一種具體的分布式網(wǎng)關(guān)管理方法，相對于上一實施例，本實施例對技術(shù)方案作了進(jìn)一步的說明和優(yōu)化。參見圖3所示，具體的：步驟S21：接收用戶終端通過分布式網(wǎng)關(guān)中的目標(biāo)路由裝置轉(zhuǎn)發(fā)的目標(biāo)API修改請求，修改API數(shù)據(jù)庫中的目標(biāo)API，記錄修改痕跡，得到第一修改日志。具體的，API數(shù)據(jù)庫修改目標(biāo)API后，以修改日志的形式記錄修改痕跡，得到第一修改日志，其中修改日志的記錄形式可以如表2所示：表2步驟S22：利用第一修改日志，生成對應(yīng)的key-value，得到目標(biāo)key-value。具體的，利用第一修改日志中記錄的key-value內(nèi)容，生成對應(yīng)的key-value，得到目標(biāo)key-value，目標(biāo)key-value中保存有修改目標(biāo)API的信息。例如：更新通知消息體：刪除通知消息體：插入通知消息體：步驟S23：按照預(yù)設(shè)的周期，定期監(jiān)測key-value數(shù)據(jù)庫。具體的，服務(wù)器長期保存有key-value數(shù)據(jù)庫，以防止再對路由裝置進(jìn)行修改時，未能接收到路由裝置返回的信息，而重新進(jìn)行修改等不必要的錯誤，當(dāng)對路由裝置進(jìn)行修改時，需要將利用修改日志生成的key-value存儲到key-value數(shù)據(jù)庫中，因此，可以按照預(yù)設(shè)的周期，定期監(jiān)測key-value數(shù)據(jù)庫或?qū)崟r監(jiān)測key-value數(shù)據(jù)庫中的key-value變動，當(dāng)監(jiān)測到key-value數(shù)據(jù)庫發(fā)生變動，則進(jìn)入步驟S24。其中，按照預(yù)設(shè)的周期，定期監(jiān)測key-value數(shù)據(jù)庫，可以將周期設(shè)定為每分鐘進(jìn)行一次監(jiān)測，當(dāng)監(jiān)測到當(dāng)前key-value數(shù)據(jù)庫與前一分鐘key-value數(shù)據(jù)庫發(fā)生改變，則進(jìn)入步驟S24。步驟S24:當(dāng)監(jiān)測到key-value數(shù)據(jù)庫中已添加目標(biāo)key-value，則生成包括目標(biāo)key-value的目標(biāo)API通知。當(dāng)監(jiān)測到key-value數(shù)據(jù)庫中已添加目標(biāo)key-value，則生成目標(biāo)API修改通知，該修改通知中包含目標(biāo)key-value，以用來使路由裝置利用目標(biāo)API修改通知修改自身緩存的API。步驟S25：接收其余的路由裝置發(fā)送的修改結(jié)果，并記錄在第二修改日志中。具體的，服務(wù)器發(fā)送目標(biāo)API修改通知后，還可以接收其余的路由裝置發(fā)送的修改結(jié)果，修改結(jié)果為已成功修改API或未成功修改API，服務(wù)器將路由裝置發(fā)送的修改結(jié)果保存在第二修改日志中。步驟S26：利用第二修改日志，判斷是否修改成功。步驟S27：如果未成功，則繼續(xù)發(fā)送目標(biāo)API修改通知直至修改成功。具體的，如果利用第二修改日志，判斷路由裝置未能成功修改自身緩存的API，則服務(wù)器繼續(xù)發(fā)送目標(biāo)API修改通知直至路由裝置返回的修改結(jié)果判定為修改成功。需要說明的是，目標(biāo)路由裝置在接收用戶的修改請求時，對自身API進(jìn)行修改后，也可以發(fā)送修改結(jié)果到服務(wù)器，服務(wù)器將目標(biāo)路由裝置的修改結(jié)果與其余的路由裝置的修改結(jié)果集中進(jìn)行判斷，如果目標(biāo)路由裝置的修改結(jié)果為未成功，則向目標(biāo)路由裝置發(fā)送目標(biāo)API修改通知直至目標(biāo)路由裝置返回的修改結(jié)果判定為修改成功。相應(yīng)的，本發(fā)明實施例還公開了一種分布式網(wǎng)關(guān)管理系統(tǒng)，參見圖4所示，該系統(tǒng)包括：請求接收模塊11，用于接收用戶終端通過分布式網(wǎng)關(guān)中的目標(biāo)路由裝置轉(zhuǎn)發(fā)的目標(biāo)API修改請求，其中，目標(biāo)路由裝置當(dāng)接收到用戶終端發(fā)送的目標(biāo)API修改請求，則修改自身緩存有的目標(biāo)API；API修改模塊12，用于修改API數(shù)據(jù)庫中的目標(biāo)API，記錄修改痕跡；通知生成模塊13，用于利用修改痕跡，生成目標(biāo)API修改通知；第一通知發(fā)送模塊14，用于向分布式網(wǎng)關(guān)中其余的路由裝置發(fā)送目標(biāo)API修改通知，以使其余的路由裝置利用目標(biāo)API修改通知，修改自身緩存的目標(biāo)API。具體的，上述API修改模塊12具體用于修改API數(shù)據(jù)庫中的目標(biāo)API，記錄修改痕跡，得到第一修改日志。上述第一通知生成模塊13包括key-value生成單元、監(jiān)測key-value數(shù)據(jù)庫單元和通知生成單元；其中，key-value生成單元，用于利用第一修改日志，生成對應(yīng)的key-value，得到目標(biāo)key-value；key-value數(shù)據(jù)庫監(jiān)測單元，用于按照預(yù)設(shè)的周期，監(jiān)測key-value數(shù)據(jù)庫；通知生成單元，用于當(dāng)監(jiān)測到key-value數(shù)據(jù)庫中已添加目標(biāo)key-value，則生成包括目標(biāo)key-value的目標(biāo)API通知。其中，請求接收模塊11也可以用來接收用戶終端通過目標(biāo)路由裝置轉(zhuǎn)發(fā)的目標(biāo)API調(diào)用請求；第一通知發(fā)送模塊14可以將API數(shù)據(jù)庫中的目標(biāo)API發(fā)送給目標(biāo)路由裝置。在本發(fā)明實施例的一種應(yīng)用情況下，還可以包括：結(jié)果接收模塊，用于接收其余的路由裝置發(fā)送的修改結(jié)果，并記錄在第二修改日志中；修改判斷模塊，用于利用第二修改日志，判斷是否修改成功；第二通知發(fā)送模塊，用于如果未成功，則繼續(xù)發(fā)送目標(biāo)API修改通知直至修改成功。另外，本發(fā)明還公開了一種分布式API網(wǎng)關(guān)，包括前述實施例中公開的一種分布式網(wǎng)關(guān)系統(tǒng)。關(guān)于該分布式API網(wǎng)關(guān)的具體構(gòu)造可參考前述實施例的相關(guān)內(nèi)容，在此不再贅述。最后，還需要說明的是，在本文中，諸如第一和第二等之類的關(guān)系術(shù)語僅僅用來將一個實體或者操作與另一個實體或操作區(qū)分開來，而不一定要求或者暗示這些實體或操作之間存在任何這種實際的關(guān)系或者順序。而且，術(shù)語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者設(shè)備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者設(shè)備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括所述要素的過程、方法、物品或者設(shè)備中還存在另外的相同要素。以上對本發(fā)明所提供的一種分布式API網(wǎng)關(guān)、管理方法及管理系統(tǒng)進(jìn)行了詳細(xì)介紹，本文中應(yīng)用了具體個例對本發(fā)明的原理及實施方式進(jìn)行了闡述，以上實施例的說明只是用于幫助理解本發(fā)明的方法及其核心思想；同時，對于本領(lǐng)域的一般技術(shù)人員，依據(jù)本發(fā)明的思想，在具體實施方式及應(yīng)用范圍上均會有改變之處，綜上所述，本說明書內(nèi)容不應(yīng)理解為對本發(fā)明的限制。當(dāng)前第1頁1 2 3