TW201828093A - 訪問請求轉換的方法和裝置 - Google Patents

Abstract

本發明關於一種訪問請求轉換的方法和裝置，該方法包括：接收客戶端發送的訪問請求，訪問請求包括同一資源定位符URL和參數資訊；根據URL和參數資訊，確定訪問請求的目標服務類型；根據目標服務類型轉換訪問請求；向目標服務類型對應的伺服器端發送根據目標服務類型轉換後的訪問請求，以用於伺服器端，根據目標服務類型轉換後的訪問請求返回結果資訊。採用本發明提供的訪問請求轉換的方法，通過根據接收的訪問請求，確定訪問請求的目標服務類型，將訪問請求解析為目標服務類型相對應的資料結構，並提供給相應的伺服器端，實現了大數據平臺環境下的多網路統一請求介面的功能，解耦了系統之間的依賴性，提高了系統對各模組的管理機制功能。

Description

訪問請求轉換的方法和裝置

本發明涉及資料開發，尤其涉及一種訪問請求轉換的方法和裝置。

在大數據平臺系統中，需要多個模組來實現各自的功能，而這個模組需要不同的開發人員設計開發，由於功能和性能的需求，開發人員設計的模組介面的形式也有多種類型，例如：遠程過程調用協議(Remote Procedure Call Protocol，RPC)，自定義二進制協議等，開發人員需要根據每種協議的交互方式進行開發，造成模組之間有很高的耦合性。

為了降低模組之間的耦合性，目前，大數據平臺中應用一些協議中間轉換裝置，例如：Nginx Module和ServiceMix。在Nginx Module體系中，如圖1所示，當接收到請求時，通過查找配置文件將接收的請求映射到局域資料表中，以觸發局域資料表中儲存的指令，指示handler模組和多個filter模組完成各自的工作，其中handler模組負責處理請求，完成響應內容的產生；filter 模組對響應內容進行處理。在ServiceMix系統中，雖然可以支持較多的協議，也可以根據需求進行協議擴展。

但是，在Nginx Module系統和ServiceMix系統中，系統之間的依賴性比較大，且對系統中各模組的集群管理機制功能較弱，例如：負載的均衡、容錯等。

本發明實施例提供一種訪問請求轉換的方法和裝置，以解決系統之間的依賴性，提高系統對各模組的管理機制功能。

第一方面，本發明提供了一種訪問請求轉換的方法，該方法包括：接收客戶端發送的訪問請求，所述訪問請求包括統一資源定位符URL和參數資訊；根據所述URL和所述參數資訊，確定所述訪問請求的目標服務類型；根據所述目標服務類型轉換所述訪問請求；向所述目標服務類型對應的伺服器端發送根據所述目標服務類型轉換後的訪問請求，以用於所述伺服器端，根據所述目標服務類型轉換後的訪問請求返回結果資訊。

第二方面，本發明實施例提供了一種裝置，該裝置包括：接收模組，用於接收客戶端發送的訪問請求，所述訪問請求包括統一資源定位符URL和參數資訊； 確定模組，用於根據所述URL和所述參數資訊，確定所述訪問請求的目標服務類型；轉換模組，用於根據所述目標服務類型轉換所述訪問請求；發送模組，用於向所述目標服務類型對應的伺服器端發送根據所述目標服務類型轉換後的訪問請求，以用於所述伺服器端，根據所述目標服務類型轉換後的訪問請求返回結果資訊。

基於本發明實施例提供的一種訪問請求轉換的方法和裝置，通過根據接收的訪問請求，確定訪問請求的目標服務類型，將訪問請求解析為目標服務類型相對應的資料結構，並提供給相應的伺服器端，實現了大資料平臺環境下的多網路統一請求介面的功能，解耦了系統之間的依賴性，提高了系統對各模組的管理機制功能。

510‧‧‧接收模組

520‧‧‧確定模組

530‧‧‧轉換模組

540‧‧‧發送模組

為了更清楚地說明本發明實施例的技術方案，下面將對本發明實施例中所需要使用的附圖作簡單地介紹，顯而易見地，下面所描述的附圖僅僅是本發明的一些實施例，對於本領域普通技術人員來講，在不付出創造性勞動的前提下，還可以根據這些附圖獲得其他的附圖。

圖1為現有技術中Nginx Lua系統的結構示意圖；圖2為本發明實施例提供的一種訪問請求轉換方法的流程圖； 圖3為本發明實施例提供的一種裝置結構示意圖；圖4為本發明另一實施例提供的訪問請求轉換方法的流程圖；圖5為本發明另一實施例提供的一種裝置結構示意圖。

下面將結合本發明實施例中的附圖，對本發明實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例是本發明的一部分實施例，而不是全部實施例。基於本發明中的實施例，本領域普通技術人員在沒有做出創造性勞動的前提下所獲得的所有其他實施例，都應屬於本發明保護的範圍。

本發明實施例提供的一種訪問請求轉換的方法和裝置，適用於大資料平臺場景下，訪問請求轉換的裝置通過接收客戶端發送的一種協議的訪問請求，例如http/https協議的訪問請求，可以去訪問支持多種協議的伺服器端，例如：支持遠程過程調用協議(Remote Procedure Call Protocol，RPC)，自定義二進制協議等，以完成客戶端對目的資源的需求。

需要說明的是，在本發明實施例中，客戶端是指與伺服器端相對應，為客戶提供本地服務的程序，也可以稱作客戶端(Client)或者用戶端，客戶端一般安裝在普通的客服機上。客戶端可以通過不同的協議，例如：socket、 http/https、RPC等協議與其他客戶端進行交互。訪問請求為客戶端與伺服器端之間通過協議請求應答模式進行交互時，產生的請求消息。伺服器端，從廣義上來講是伺服器，是網路中能對其他設備提供服務的計算機系統。伺服器端需要根據接收到的訪問請求做出響應，並進行處理，伺服器端具備承擔訪問服務並保證服務質量的能力。根據服務類型的不同，伺服器端可以分為資料庫伺服器端，應用程序伺服器端，Web伺服器端等。

為便於說明，結合圖2對本發明實施例的技術方案進行詳細的說明。應理解，這僅是用以說明本發明實施例的技術方案的一個例子，並不對本發明實施例構成任何的限定。

圖2為本發明實施例提供的一種訪問請求轉換方法的流程圖。該方法的執行主體可以為具有處理能力的設備：系統或者裝置，例如協議中間轉換裝置。如圖2所示，該方法具體包括：

步驟210，接收客戶端發送的訪問請求，所述訪問請求包括統一資源定位符URL和參數資訊。

該訪問請求為客戶端通過某種協議發送的請求消息，例如，http請求，在該請求消息中可以包括統一資源定位符(Uniform Resource Locator，URL)，參數資訊和消息體。其中，URL是對可以從互聯網上得到的資源的位置和訪問方法的一種簡潔的表示，是互聯網上標準資源的地址。互聯網上的每一個文件都有一個唯一的URL，URL 的資訊包括資源的位置資訊和客戶端的處理方式。參數資訊可以包括獲取對應URL標識的資源的參數GET，在URL標識的資源後附加新資料的參數POST，訪問請求獲取由URL所標識的資源的響應消息報頭HEAD，以及與安全資訊相關的訪問請求的身份驗證參數等相關參數。

可選地，當接收到訪問請求之後，對該訪問請求進行解析，從該訪問請求中獲取URL，參數資訊和消息體等相應的資訊。

在獲取到訪問請求中的相應資訊之後，該方法可以包括以下步驟：對訪問請求進行預定義處理，該預定義處理包括對訪問請求進行身份驗證；當身份驗證通過時，根據URL和參數資訊，確定訪問請求的目標服務類型。

具體的，對訪問請求進行預定義加工處理，可以包括預定義的資料修改，對訪問請求的身份驗證等處理。例如該步驟可以通過註冊在該裝置中，開發者自定義開發Filter組件來實現，如圖3所示。

在本發明實施例中，對訪問請求進行身份驗證可以包括：將訪問請求中的身份驗證參數資訊與令牌中心的令牌資訊進行匹配；當身份驗證參數資訊與所述令牌資訊相匹配時，訪問請求身份驗證通過。

具體的，Filter組件將訪問請求發送給令牌(Token)中心，以便於令牌中心根據訪問請求中的資訊進行計算，得到令牌資訊，並將該令牌資訊與訪問請求中的身份驗證 參數資訊進行匹配，當兩者相匹配時，則該訪問請求的身份驗證通過，以表示該訪問請求通過合法驗證，反之，則未通過驗證。

當訪問請求的身份驗證未通過時，向終端返回向客戶端返回資訊錯誤，以向用戶表示該訪問請求的身份驗證未通過，便於加快客戶端資訊的獲取。當訪問請求的身份驗證通過時，執行步驟220。

步驟220，根據所述URL和所述參數資訊，確定所述訪問請求的目標服務類型。

具體的，在申請實施例中，目標服務類型為伺服器端可以支持的協議類型，如HSF、Mock和Protobuffer協議類型，在本發明實施例中還可以擴展其他的協議類型，在本發明實施例中對此不作任何限制。

在本發明實施例中，根據URL和參數資訊，確定訪問請求的目標服務類型，具體包括：根據URL確定是否存在URL路徑對應的服務；當存在URL路徑對應的服務時，根據參數資訊確定訪問請求的目標服務類型。

具體的，裝置可以通過查表的方式確定URL路徑是否有對應的服務，例如表1，可以根據URL的路徑查找表中是否有相應的路徑存在，比如，訪問請求中的URL路徑為路徑1，通過查表確定是否存在路徑1。當訪問請求中的URL路徑存在與表中時，確定該URL路徑對應的服務存在，反之，在不存在。

應理解，在本發明實施例中，表1只是為了詳細的描述本發明的技術方案，表1中的內容並不構成本發明實施例的限制，在本發明實施例中對此也不作任何限制。

當根據URL確定URL路徑存在對應的服務時，根據參數資訊確定訪問請求轉換的目標服務類型。例如可以通過查表的方式確定目標服務類型，如表1所示，根據確定存在的路徑1查詢相對應的目標服務類型為HSF。具體可以通過如圖3所示的引擎路由組件完成該目標服務的確定，該引擎路由組件可以為開發人員開發的具有根據訪問請求中的URL和參數資訊確定目標服務類型功能的程序，包括分區(sharding)組件和容錯(failover)組件，分區組件用於對訪問請求的伺服器端(HSF_Provider1，HSF_Provider2，PBService_1和PBService_2)配置的容錯、負載均衡(Load Balance)策略，根據確定的目標服務類型進行訪問請求的分發，將訪問請求發送給相應目標服務類型的引擎組件，例如HSF、Mock和Protobuffer。其中，容錯是指當裝置中的資料、文件損壞或者丟失時，裝置能夠自動將損壞或者丟失的文件、資料恢復到發生事 故以前的狀態，以保證裝置能夠正常運行。負載均衡是說將訪問請求分發給多個引擎組件對應的伺服器端進行處理，例如HSF_Provider1，HSF_Provider2，PBService_1和PBService_2等伺服器端，從而實現共同完成訪問請求的處理任務。

在本發明實施例中，容錯組件有記錄伺服器管配置的功能，以便於路由引擎通過查詢容錯組件中的伺服器端的配置情況，將訪問請求分發給響應目標服務類型的引擎組件上，實現負載均衡。也就是說，在向目標服務類型對應的伺服器端發送根據目標服務類型轉換後的訪問請求之前，該方法還包括：根據目標服務類型，查詢容錯組件中記錄的目標服務類型對應的伺服器端，以便於根據伺服器端的配置情況將訪問請求資訊根據目標服務類型分發到響應的伺服器端，以實現負載均衡。

在本發明實施例中，當裝置根據URL確定是否存在URL路徑對應的服務，或者根據參數資訊確定訪問請求的目標服務類型過程中，如果不存在URL路徑對應的服務或者目標服務類型，則向客戶端返回資訊錯誤，表明出錯的原因，以使使用該客戶端的用戶清楚出錯的原因。

步驟230，根據所述目標服務類型轉換所述訪問請求。

具體的，當引擎組件接收到訪問請求時，根據目標服務類型，將接收到的訪問請求的資料結構進行轉換，轉換為伺服器端可以支持的協議類型，例如圖3所示，訪問請 求可以通過引擎組件HSF、Mock或Protobuffer進行轉換，轉換為HSF_Provider1、HSF_Provider2，Mock伺服器端，PBService_1和PBService_2可以支持的協議類型。其中，PBService為Protobuffer Service的簡寫。

步驟240，向所述目標服務類型對應的伺服器端發送根據所述目標服務類型轉換後的訪問請求，以用於所述伺服器端，根據所述目標服務類型轉換後的訪問請求返回結果資訊。

具體的，當引擎組件將訪問請求轉換為相應目標服務類型的訪問請求時，將轉換後的訪問請求分別發送給相應的伺服器端，以便於相應的伺服器端根據響應的訪問請求作出響應，並返回結果資訊。該結果資訊為客戶端訪問請求的資源資訊，可以是文字、圖像、視頻等資訊。

在本發明實施例中，該方法還可以包括：接收結果資訊；對結果資訊進行加工處理；向客戶端發送加工處理後的結果資訊，以用於客戶端根據加工後的結果資訊進行相應的操作。

具體的，引擎組件接收服務端發送的結果資訊，併發送給引擎路由組件。引擎路由組件將接收到的不同引擎組件發送的結果資訊的資料結構化為統一的資料結構，並返回給如圖3所述的Handler組件，該組件為開發人員開發的，具有將返回的結果資訊加工處理為客戶端可以接收的資料結構功能的程序，例如，可以針對訪問請求的結果資訊進行壓縮、log記錄、資料修改，脫敏等。其中，log記 錄可以記錄訪問請求從客戶端發出至該訪問請求的結果資訊返回客戶端所用的時間資訊。脫敏為將結果資訊中的敏感資訊通過脫敏規則進行資料變形，實現敏感隱私資料的可靠性保護。在本發明實施例中，可以根據需求設置多個Handler組件，在對結果資訊進行加工處理的過程中，可以依次將結果資訊傳輸給下一個Handler組件，實現靈活、透明的改變結果資訊的資料。

在本發明實施例中，例如，訪問請求為1+1=？，返回結果為2，Handler組件根據預定義的處理方式對返回的結果2進行處理，例如，壓縮，以用於客戶端接收到資訊後，根據資訊進行相應的處理。當返回結果為其他數字，例如3，則Handler組件根據預定義的處理方式可以將返回結果3與附加的結果錯誤資訊發送給客戶端。

基於本發明實施例提供的訪問請求轉換方法，通過根據接收的訪問請求，確定訪問請求的目標服務類型，將訪問請求解析為目標服務類型相對應的資料結構，並提供給相應的伺服器端，實現了大資料平臺環境下的多網路統一請求介面的功能，解耦了系統之間的依賴性，提高了系統對各模組的管理機制功能。

應理解，在本發明實施例中，圖3中的Filter組件和Handler組件可以依插件的方式進行加載，開發者可以根據需求，開發基於該訪問請求，即http請求的資料修改、身份認證，統計，壓縮等功能。用戶提供基本的資訊，就可以註冊到Filter組件和Handler組件鏈路中，當啟動該 裝置時，系統會動態加載具有預定義功能的組件。

在本發明實施例中，裝置會把訪問請求轉換成通用的中間資料結構，可以針對不同的伺服器端支持的通信協議進行對接，通過開發的各個引擎組件自動實現通用資料結構到固定結構的轉換，可以讓開發者自由開發支持特定協議的體系。相對Nginx Lua的開發而言，本發明實施例不需要在Filter組件和Handler組件中實現多種資料結構，節省了開發週期，並且也不需要同Nginx Lua開發一樣，對系統的資料結構進行深入的瞭解，節省了開發成本。

需要說明的是，在本發明實施例中，客戶端可以提供http/https，socket，RPC(例如HSF和Protobuffer)協議的訪問請求，伺服器端可以支持HSF、Mock和Protobuffer協議，在本發明實施例中客戶端和伺服器端還可以支持其他的協議，在本發明實施例中，對此不作任何限制。

還需要說明的是，本發明實施例可以通過Jave語言來實現。

可選地，在本發明另一實施例中，如圖4所示，該方法可以在裝置獲取到訪問請求中的相應資訊之後，先執行根據URL確定是否存在URL路徑對應的服務，以加快客戶端快速獲取訪問請求所需的資源資訊。

當確定URL路徑對應的服務存在時，對訪問請求進行相應的預處理和身份驗證，在訪問請求的身份驗證通過時，裝置執行根據參數資訊確定訪問請求的目標服務類 型。

具體步驟可以通過圖2中的步驟220來實現，為了簡潔，在此不再贅述。

需要說明的是，在本發明實施例中，當裝置根據URL確定是否存在URL路徑對應的服務，或者根據參數資訊確定訪問請求的目標服務類型過程中，如果不存在URL路徑對應的服務或者目標服務類型，則向客戶端返回資訊錯誤，表明出錯的原因，以使使用該客戶端的用戶清楚出錯的原因。

上文中結合圖2至圖4，詳細描述了根據本發明實施例訪問請求轉換的方法，下面將結合圖5，詳細描述根據本發明實施例提供的裝置。

圖5為本發明提供的一種裝置的結構示意圖，如圖5所示，該裝置包括：接收模組510、確定模組520、轉換模組530和發送模組540。

接收模組510，用於接收客戶端發送的訪問請求，訪問請求包括同一資源定位符URL和參數資訊；確定模組520，用於根據URL和所述參數資訊，確定訪問請求的目標服務類型；轉換模組530，用於根據目標服務類型轉換訪問請求；發送模組540，用於向目標服務類型對應的伺服器端發送根據目標服務類型轉換後的訪問請求，以用於伺服器端，根據目標服務類型轉換後的訪問請求返回結果資訊。

可選地，作為本發明另一實施例，確定模組520還用於，對訪問請求進行預定義處理，預定義處理包括對訪問請求進行身份驗證；當身份驗證通過時，根據URL和參數資訊，確定訪問請求的目標服務類型。

可選地，作為本發明另一實施例，確定模組520具體用於，將訪問請求中的身份驗證參數資訊與令牌中心的令牌資訊進行匹配；當身份驗證參數資訊與令牌資訊相匹配時，訪問請求身份驗證通過。

可選地，作為本發明另一實施例，確定模組具體用於，根據URL確定是否存在URL路徑對應的服務；當存在URL路徑對應的服務時，根據參數資訊確定訪問請求的目標服務類型。

可選地，作為本發明另一實施例，確定模組520用於，根據URL確定是否存在URL路徑對應的服務，以用於訪問請求身份驗證通過時，根據參數資訊確定訪問請求的目的服務類型。

可選地，作為本發明另一實施例，接收模組510還用於，接收結果資訊；處理模組還用於，對所述結果資訊進行加工處理；發送模組540還用於，向客戶端發送加工處理後的結果資訊，以用於客戶端根據加工處理後的結果進行相應的操作。

其中，加工處理包括資料修改、壓縮、脫敏中的任一 種或者多種。

可選地，作為本發明另一實施例，該裝置還包括查詢模組，用於根據目標服務類型，查詢容錯組件中記錄的目標服務類型對應的伺服器端。

基於本發明實施例提供的裝置，通過根據接收的訪問請求，確定訪問請求的目標服務類型，將訪問請求解析為目標服務類型相對應的資料結構，並提供給相應的伺服器端，實現了大資料平臺環境下的多網路統一請求介面的功能，解耦了系統之間的依賴性，提高了系統對各模組的管理機制功能。

需要說明的是，在本發明實施例中，根據圖5提供的裝置中的各個模組的上述和其它操作和/或功能可以通過圖3中的裝置的各個模組來實現，可以分別實現圖2和圖4中的各個方法的相應流程，為了簡潔，在此不再贅述。

專業人員應該還可以進一步意識到，結合本文中所公開的實施例描述的各示例的單元及算法步驟，能夠以電子硬體、計算機軟體或者二者的結合來實現，為了清楚地說明硬體和軟體的可互換性，在上述說明中已經按照功能一般性地描述了各示例的組成及步驟。這些功能究竟以硬體還是軟體方式來執行，取決於技術方案的特定應用和設計約束條件。專業技術人員可以對每個特定的應用來使用不同方法來實現所描述的功能，但是這種實現不應認為超出本發明的範圍。

結合本文中所公開的實施例描述的方法或算法的步驟 可以用硬體、處理器執行的軟體模組，或者二者的結合來實施。軟體模組可以置於隨機記憶體(RAM)、記憶體、唯讀儲存器(ROM)、電可編程ROM、電可擦除可編程ROM、暫存器、硬碟、可移動磁碟、CD-ROM、或技術領域內所公知的任意其它形式的儲存媒體中。

以上所述的具體實施方式，對本發明的目的、技術方案和有益效果進行了進一步詳細說明，所應理解的是，以上所述僅為本發明的具體實施方式而已，並不用於限定本發明的保護範圍，凡在本發明的精神和原則之內，所做的任何修改、等同替換、改進等，均應包含在本發明的保護範圍之內。

Claims (16)

1. 一種訪問請求轉換的方法，所述方法包括：接收客戶端發送的訪問請求，所述訪問請求包括統一資源定位符URL和參數資訊；根據所述URL和所述參數資訊，確定所述訪問請求的目標服務類型；根據所述目標服務類型轉換所述訪問請求；向所述目標服務類型對應的伺服器端發送根據所述目標服務類型轉換後的訪問請求，以便所述伺服器端根據所述目標服務類型轉換後的訪問請求返回結果資訊。
2. 根據申請專利範圍第1項所述的方法，其中，在所述接收客戶端發送的訪問請求之後，所述方法還包括：對所述訪問請求進行預定義處理，所述預定義處理包括對所述訪問請求進行身份驗證；當身份驗證通過時，根據所述URL和所述參數資訊，確定所述訪問請求的目標服務類型。
3. 根據申請專利範圍第2項所述的方法，其中，所述對所述訪問請求進行身份驗證包括：將所述訪問請求中的身份驗證參數資訊與令牌(Token)中心的令牌資訊進行匹配；當所述身份驗證參數資訊與所述令牌資訊相匹配時，所述訪問請求身份驗證通過。
4. 根據申請專利範圍第1至3項任一項所述的方法，其中，所述根據所述URL和所述參數資訊，確定所 述訪問請求的目標服務類型，包括：根據所述URL確定是否存在URL路徑對應的服務；當存在所述URL路徑對應的服務時，根據所述參數資訊確定所述訪問請求的目標服務類型。
5. 根據申請專利範圍第2項所述的方法，其中，在對所述訪問請求進行預處理之前，所述方法包括：根據所述URL確定是否存在URL路徑對應的服務，以用於所述訪問請求身份驗證通過時，根據所述參數資訊確定所述訪問請求的目的服務類型。
6. 根據申請專利範圍第1至5項任一項所述的方法，其中，所述方法還包括：接收所述結果資訊；對所述結果資訊進行加工處理；向所述客戶端發送加工處理後的結果資訊，以用於所述客戶端根據所述加工後的結果資訊進行相應的操作。
7. 根據申請專利範圍第6項所述的方法，其中，所述加工處理包括資料修改、壓縮、脫敏中的任一種或者多種。
8. 根據申請專利範圍第1項所述的方法，其中，在所述向所述目標服務類型對應的伺服器端發送根據所述目標服務類型轉換後的訪問請求之前，所述方法還包括：根據所述目標服務類型，查詢容錯組件中記錄的所述目標服務類型對應的伺服器端。
9. 一種裝置，所述裝置包括： 接收模組，用於接收客戶端發送的訪問請求，所述訪問請求包括統一資源定位符URL和參數資訊；確定模組，用於根據所述URL和所述參數資訊，確定所述訪問請求的目標服務類型；轉換模組，用於根據所述目標服務類型轉換所述訪問請求；發送模組，用於向所述目標服務類型對應的伺服器端發送根據所述目標服務類型轉換後的訪問請求，以用於所述伺服器端，根據所述目標服務類型轉換後的訪問請求返回結果資訊。
10. 根據申請專利範圍第9項所述的裝置，其中，所述確定模組還用於，對所述訪問請求進行預定義處理，所述預定義處理包括對所述訪問請求進行身份驗證；當身份驗證通過時，根據所述URL和所述參數資訊，確定所述訪問請求的目標服務類型。
11. 根據申請專利範圍第10項所述的裝置，其中，所述確定模組具體用於，將所述訪問請求中的身份驗證參數資訊與令牌中心的令牌資訊進行匹配；當所述身份驗證參數資訊與所述令牌資訊相匹配時，所述訪問請求身份驗證通過。
12. 根據申請專利範圍第9至11項任一項所述的裝置，其中，所述確定模組具體用於， 根據所述URL確定是否存在URL路徑對應的服務；當存在所述URL路徑對應的服務時，根據所述參數資訊確定所述訪問請求的目標服務類型。
13. 根據申請專利範圍第10項所述的裝置，其中，所述確定模組用於，根據所述URL確定是否存在URL路徑對應的服務，以用於所述訪問請求身份驗證通過時，根據所述參數資訊確定所述訪問請求的目的服務類型。
14. 根據申請專利範圍第9至13項任一項所述的裝置，其中，所述接收模組還用於，接收所述結果資訊；所述處理模組還用於，對所述結果資訊進行加工處理；所述發送模組還用於，向所述客戶端發送加工處理後的結果資訊，以用於所述客戶端根據所述加工處理後的結果進行相應的操作。
15. 根據申請專利範圍第14項所述的裝置，其中，所述加工處理包括資料修改、壓縮、脫敏中的任一種或者多種。
16. 根據申請專利範圍第9項所述的裝置，其中，所述裝置還包括查詢模組，用於根據所述目標服務類型，查詢容錯組件中記錄的所述目標服務類型對應的伺服器端。