Mock服務系統及Mock服務的處理方法與流程

2023-06-01 22:43:57 2

本申請涉及數據處理領域，具體而言，涉及一種Mock服務系統及Mock服務的處理方法。

背景技術：
隨著軟體系統越來越複雜，大多數企業都採用面向服務的體系架構(Service-OrientedArchitecture，簡稱為SOA)來降低系統間的耦合度，提高服務組件的可重用性。然而，在開發和測試過程中，搭建外部服務系統，與外部服務系統聯調，準備服務的測試數據就可能會成為瓶頸，而且可能需要多個人配合，嚴重浪費人力。其中，SOA是一個組件模型，其將應用程式的不同功能單元(稱為服務)通過這些服務之間定義良好的接口和契約聯繫起來。接口是採用中立的方式進行定義的，它應該獨立於實現服務的硬體平臺、作業系統和程式語言。這使得構建在各種這樣的系統中的服務可以一種統一和通用的方式進行交互。圖1是根據現有技術的Mock服務系統的示意圖。如圖1所示，圖中每個小框都代表一個服務，它們可能部署在同一計算機上，也可能部署在不同的計算機上，對外提供服務，如果「應用1」需要對「客戶端1」，「客戶端2」提供正常的服務，那麼「應用1」依賴的所有服務都必須正常工作，緊密配合，任何一方出了問題，都可能導致客戶端的請求處理失敗。正因為這樣，在開發和測試過程中，為了搭建「應用1」，所依賴的服務才是一個相當麻煩或者困難的事情。在圖1所示的Mock服務系統中，在「應用1」的內部，直接隱藏掉與服務端的通信模塊，改為一個假的通信端，在假的通信端內，不直接通過網絡請求遠程方法調用(RemoteMethodInvocation，簡稱為RMI)服務，而是返回指定的數據給上層模塊。Mock服務是指虛假的服務程序，其同樣接收客戶端的請求，並返回結果，對客戶端程序來說，與真實服務是一樣的。Mock服務與真實服務的唯一差別是：Mock服務不執行具體的業務邏輯，只根據輸入參數不同，返回事先已經準備好的結果數據。在該方案中，服務組1Mock與服務組2Mock等是需要單獨開發的，開發工作量大；其次，如果新的服務需要Mock，則需要針對新的服務進行開發，因而Mock服務組的重用性不高，且每個Mock服務都需要單獨部署，所以整個Mock服務系統搭建工作繁瑣，管理困難，同時，由於服務的返回值基本固定為同一個，修改困難，或者客戶端變化後需要重新準備數據，不能滿足多種測試場景的需要，此外，現有的Mock服務可能比較簡單，不能區分用戶，即，同樣的請求參數，A用戶由於測試需要希望返回成功(即，希望Mock服務的返回值為成功)，B用戶希望返回失敗(即，希望Mock服務的返回值為失敗)，現有的Mock也無法做到。針對現有技術中無法在同一個Mock服務系統中對不同的客戶端提供Mock服務的問題，目前尚未提出有效的解決方案。

技術實現要素：
為此，本申請的主要目的在於提供一種Mock服務系統及Mock服務的處理方法，以解決現有技術中無法在同一個Mock服務系統中對不同的客戶端提供Mock服務的問題。為了實現上述目的，根據本申請的一個方面，提供了一種Mock服務系統。該Mock服務系統包括：接收模塊，用於接收來自客戶端的請求，其中，客戶端為用於調用MOCK服務的裝置；查找模塊，用於查找與請求對應的Mock服務，其中，在Mock服務系統中存儲有多個Mock服務；以及關聯模塊，用於建立客戶端與查找到的Mock服務的關聯關係以便為客戶端提供Mock服務。進一步地，查找模塊包括：獲取子模塊，用於獲取客戶端的IP位址以及請求的路徑；第一列出子模塊，用於列出與路徑匹配的Mock服務方式列表；第二列出子模塊，用於列出Mock服務方式中的數據提取方式列表；以及匹配子模塊，用於根據客戶端的IP位址與數據提取方式列表中的數據提取方式進行匹配以查找與客戶端的IP位址對應的數據提取方式。進一步地，多個Mock服務包括第一Mock服務，且多個Mock服務中的每個Mock服務均包括服務接口和服務版本，其中，接收模塊還用於接收用戶上傳的第一服務版本，其中，第一服務版本為第一Mock服務的服務版本，Mock服務系統還包括：映射模塊，用於建立第一服務版本和第一服務接口的映射關係，其中，第一服務接口為第一Mock服務的服務接口。進一步地，接收模塊用於通過不同的通信方式接收不同的請求。進一步地，接收模塊用於接收來自多個客戶端的請求；查找模塊用於分別查找與多個客戶端的請求對應的Mock服務；以及關聯模塊用於分別建立多個客戶端與查找到的Mock服務的關聯關係以便為多個客戶端分別提供Mock服務。為了實現上述目的，根據本申請的一個方面，提供了一種Mock服務的處理方法。該Mock服務的處理方法包括：接收來自客戶端的請求，其中，客戶端為用於調用MOCK服務的裝置；查找與請求對應的Mock服務，其中，在Mock服務系統中存儲有多個Mock服務；以及建立客戶端與所查找到的Mock服務的關聯關係以便為客戶端提供Mock服務。進一步地，查找與請求對應的Mock服務包括：獲取客戶端的IP位址以及請求的路徑；列出與路徑匹配的Mock服務方式列表；列出Mock服務方式中的數據提取方式列表；以及根據客戶端的IP位址與數據提取方式列表中的數據提取方式進行匹配以查找與客戶端的IP位址對應的數據提取方式。進一步地，在客戶端的IP位址改變時，方法還包括：修改客戶端的IP位址與數據提取方式的對應關係。進一步地，接收來自客戶端的請求包括：通過不同的通信方式接收不同的請求。進一步地，多個Mock服務包括第一Mock服務，且多個Mock服務中的每個Mock服務均包括服務接口和服務版本，上述方法還包括：接收用戶上傳的第一服務版本，其中，第一服務版本為第一Mock服務的服務版本；以及建立第一服務版本和第一服務接口的映射關係，其中，第一服務接口為第一Mock服務的服務接口。進一步地，一個服務接口中包括一個或多個方法，其中，在Mock服務系統內部，將所有的遠程調用都映射為一個方法的調用。進一步地，接收來自客戶端的請求包括：接收來自多個客戶端的請求，查找與請求對應的Mock服務，其中，在Mock服務系統中存儲有多個Mock服務包括：分別查找與多個客戶端的請求對應的Mock服務，建立客戶端與所查找到的Mock服務的關聯關係以便為客戶端提供Mock服務包括：分別建立多個客戶端與查找到的Mock服務的關聯關係以便為多個客戶端分別提供Mock服務。通過本申請，採用包括以下部分的Mock服務系統：接收模塊，用於接收來自客戶端的請求；查找模塊，用於查找與請求對應的Mock服務，其中，在Mock服務系統中存儲有多個Mock服務；以及關聯模塊，用於建立客戶端與所查找到的Mock服務的關聯關係以便為客戶端提供Mock服務，由於在該Mock服務系統中存儲有多個Mock服務，且該Mock服務系統能夠根據客戶端的請求查找相應的Mock服務以便為客戶端提供Mock服務，因而實現了對Mock服務的統一管理，能夠使得同一個Mock服務系統對不同的客戶端提供Mock服務，解決了現有技術中無法在同一個Mock服務系統中對不同的客戶端提供Mock服務的問題。附圖說明構成本申請的一部分的附圖用來提供對本申請的進一步理解，本申請的示意性實施例及其說明用於解釋本申請，並不構成對本申請的不當限定。在附圖中：圖1是根據現有技術的Mock服務系統的示意圖；圖2是根據本申請實施例的Mock服務系統提供Mock服務的示意圖；圖3是根據本申請第一實施例的Mock服務系統的結構示意圖；圖4是根據本申請第二實施例的Mock服務系統的結構示意圖；圖5是根據本申請實施例的Mock服務系統的核心對象的示意圖；圖6是根據本申請實施例的Mock服務系統的服務註冊流程圖；圖7是根據本申請實施例的Mock服務的處理方法的流程圖；以及圖8是根據本申請實施例的Mock服務系統對請求的處理流程圖。具體實施方式需要說明的是，在不衝突的情況下，本申請中的實施例及實施例中的特徵可以相互組合。下面將參考附圖並結合實施例來詳細說明本申請。圖2是根據本申請實施例的Mock服務系統提供Mock服務的示意圖。如圖2所示，該Mock服務系統包括服務組1、服務組2至服務組n多個Mock服務組。該Mock服務系統中的服務都是Mock的，不再依賴下層的所有基礎服務，當客戶端調用時，直接返回某個給定的結果。本申請所提到的客戶端是相對於服務端來說的，即，客戶端為用於調用MOCK服務的裝置，服務端為用於提供MOCK服務的裝置，在本申請中，Mock服務系統即作為服務端，用於給客戶端提供MOCK服務，比如，A裝置調用B裝置的MOCK服務，B裝置又調用C裝置的MOCK服務，這時，B裝置是A裝置的服務端，A裝置是客戶端，而C裝置又是B裝置的服務端，B裝置是C的客戶端。舉例而言，A裝置需要經過B裝置查詢第三方所提供的天氣服務，而B裝置本身又不想聯繫第三方，則A裝置可以通過調用B裝置的MOCK服務來實現查詢天氣服務的目的，其中，B裝置不再依賴下層所提供的基礎服務，直接根據A裝置的查詢請求返回一個預先存儲的給定結果，即，給A裝置提供MOCK服務。本申請中的服務是指運行在計算機上面的程序，該程序接收客戶端程序通過網絡發送的參數，然後執行業務邏輯，最後又通過網絡將執行結果返回給客戶端程序。該Mock服務系統提供了一個統一的服務Mock平臺，將所有需要Mock的服務都納入這個平臺，方便統一管理。應用只需要依賴這一個Mock服務系統即可，用戶可以在Mock服務系統上一起設置各個服務的返回值，方便管理，同時，也可以設置為代理調用真實服務，即先調用真實服務，然後把數據保存下來，應用下次訪問時，直接返回保存的數據。由於該Mock服務系統是一個統一的Mock服務系統，因而所有需要Mock的服務不再需要開發，只要在Mock服務系統中註冊一個服務，設置服務的提供方式即可(如RMI服務，Webservice服務，Http服務)。其中，Webservice是由企業發布的完成其特定商務需求的在線應用服務，其他公司或應用軟體能夠通過Internet來訪問並使用這項在線服務。Mock服務的返回值也可以自由定義。需要使用Mock服務的用戶，可以添加多組測試數據，並設置相應的參數匹配規則，當客戶端發送的參數滿足用戶設置的規則時，則返回對應的返回值。所有Mock服務的期望數據準備的方式都是統一的，用戶的使用成本降低。不同用戶準備的期望數據是相互獨立的，可以滿足不同的測試人員對不同測試場景的需求。以下對本申請實施例所提供的Mock服務系統20的結構進行介紹。圖3是根據本申請第一實施例的Mock服務系統20的結構示意圖。如圖3所示，該統一的Mock服務系統20包括以下結構：服務Mock單元21，用於提供Mock服務；具體地，該服務Mock單元21在接收到客戶端的請求後，用於對請求進行處理，並返回用戶準備的期望數據。後臺管理單元22，用於對Mock服務進行統一管理。具體地，對Mock服務進行統一管理可以包括：提供Mock服務的註冊，修改，刪除功能，以及期望數據新增，修改，刪除功能。優選地，服務Mock單元21包括以下部分：遠程通信模塊211：這個模塊支持不同的通信方式，比如基於http協議的服務，基於RMI的服務，基於socket的服務等等。這些通信方式是所有服務共享的。數據協議解析模塊212：這個模塊主要負責解析通信數據，將他轉換為服務接口能夠識別的對象。比如Hessian服務，Webservice服務就是基於http協議的，這時就需要提供相應的協議解析模塊對http中的數據流進行解析，反序列化裡面的java對象，然後封裝為一個遠程調用，包括接口，方法名，參數等信息。請求處理模塊213：這個模塊就相當於真實服務的一個代理實現，它的輸入是請求參數，輸出是對應的返回值。在這個模塊中可以執行用戶自定義的代碼，然後調用數據提取模塊215取得這次請求應該返回的結果數據。數據提取模塊215：負責從用戶準備的期望數據集裡找出滿足與參數匹配的返回值。它調用數據匹配模塊214對期望數據進行匹配。數據匹配模塊214：執行用戶準備的期望數據匹配規則，滿足則返回true，否則返回false。當用戶設置所有參數的匹配都滿足時，數據提取模塊215就會返回這組參數對應的返回值。後臺管理單元22包括：Mock服務管理模塊221：用戶可以註冊，修改，刪除Mock服務。期望數據管理模塊222：對期望數據新增，修改，刪除。圖4是根據本申請第二實施例的Mock服務系統20的結構示意圖。如圖4所示，該Mock服務系統20包括：接收模塊2111，用於接收來自客戶端的請求；優選地，接收模塊2111用於通過不同的通信方式接收不同的請求，即，接收模塊2111可以支持不同的通信方式，此時，同一Mock服務系統可以接收不同的請求，實現了能夠同時為多個客戶端或用戶提供服務。查找模塊2112，用於查找與請求對應的Mock服務，其中，在Mock服務系統中存儲有多個Mock服務；該查找模塊2112還可以包括：獲取子模塊2a，用於獲取客戶端的IP位址以及請求的路徑；第一列出子模塊2b，用於列出與路徑匹配的Mock服務方式列表；第二列出子模塊2c，用於列出Mock服務方式中的數據提取方式列表；以及匹配子模塊2d，用於根據客戶端的IP位址與數據提取方式列表中的數據提取方式進行匹配以查找與客戶端的IP位址對應的數據提取方式。關聯模塊2113，用於建立客戶端與Mock服務的關聯關係以便為客戶端提供Mock服務。由於在該Mock服務系統中存儲有多個Mock服務，且該Mock服務系統能夠根據客戶端的請求查找相應的Mock服務以便為客戶端提供Mock服務，因而實現了對Mock服務的統一管理，能夠對不同的客戶端提供Mock服務。優選地，Mock服務系統中存儲的多個Mock服務包括第一Mock服務，且多個Mock服務中的每個Mock服務均包括服務接口和服務版本，其中，接收模塊2111還用於接收用戶上傳的第一服務版本，其中，第一服務版本為第一Mock服務的服務版本，Mock服務系統還包括：映射模塊216，用於建立第一服務版本和第一服務接口的映射關係，其中，第一服務接口為第一Mock服務的服務接口。通過在增加新的版本時，建立新增加版本與服務接口的映射關係，相比於重新部署Mock服務，可以更容易地實現Mock服務的升級處理。優選地，接收模塊2111用於接收來自多個客戶端的請求；查找模塊2112用於分別查找與多個客戶端的請求對應的Mock服務；以及關聯模塊2113用於分別建立多個客戶端與查找到的Mock服務的關聯關係以便為多個客戶端分別提供Mock服務。此時，通過同時接收多個客戶端的請求以及同時為多個客戶端提供Mock服務，提高了Mock服務系統的通用性，使得Mock服務系統能夠適用於不同的應用場景。需要說明的是，上述的接收模塊2111至關聯模塊2113可以是上述實施例中遠程通信模塊211的組成部分。以下對上述實施例中提到的Mock服務系統的核心對象進行介紹：圖5是根據本申請實施例的Mock服務系統的核心對象的示意圖，在該圖中，「1」和「*」表示關係的數量，具體地，「1」對「*」表示1對多的關係。用戶(user)：包括用戶名和角色，本系統是支持多用戶的Mock服務系統，用戶可以包括多個角色，同一角色的期望數據是可以共享的，其中，該圖中的Mock服務以及Mock服務方式等中的創建人屬性以及數據提取方式中的用戶名即對應於用戶對象。Mock服務(MockService)：是對所有遠程服務的抽象，其中，每個服務都有一個服務接口，以及服務的版本，服務接口名與服務的版本組合起來代表一個唯一的服務。一個服務接口中包括一個或多個方法。在本申請實施例的Mock服務系統內部，將所有的遠程調用都映射為一個方法的調用，比如，對於http的get請求，同樣映射到一個接口和一個方法。這樣在請求處理與期望數據準備時，都是針對一個具體的方法，從而，統一了所有的遠程服務到這一個Mock服務系統。期望數據(ExpectData)：是指用戶準備的服務參數匹配規則以及對應的返回值。用戶可以準備任意多組期望數據，當客戶端請求Mock服務時，Mock服務將實際的輸入參數與用戶準備的參數匹配規則進行匹配，如果滿足規則，則返回對應的返回值，否則繼續匹配下一條期望數據，一個Mock服務的每個方法都可以有多組期望數據，期望數據包括方法中每個參數的匹配規則和對應的返回值。當這組期望數據的所有參數匹配規則都與實際參數匹配時，就返回這組期望數據的返回值。參數匹配器(ArgumentMatcher)是一個匹配接口，負責根據用戶設置的匹配規則與調用時的時間參數進行匹配，並返回匹配成功或失敗。Mock服務方式(Exporter)與Mock服務是一對多的關係，即一個Mock服務可以有多種對外提供服務的方式，比如，同一個服務接口可以同時通過Webservice，Hessian和RMI等方式對外提供服務，客戶端可以通過任意一種方式請求Mock服務。遠程通信協議(RPCExporter)負責接收客戶端的請求與響應。一個遠程通信通道上，可以承載多個服務方式，比如，對於http的url:http://Mock.alibaba.com/MockServiceTest，對於A用戶定義Webservice服務，所以通過Webservice客戶端調用該服務；對於B用戶定義它為Hessian服務，所以通過Hessian的客戶端調用該服務，對於C用戶定義它為一個普通的http頁面，所以直接通過httpget請求就可以調用該服務。這也是本申請Mock服務系統特有的解決方案。實現方式是，根據客戶端的IP去匹配到不同的Mock服務方式，然後採用不同的協議解析數據。數據提取方式(UserInvoker)：本申請Mock服務系統的數據提取方式可以包括：方式1，從用戶自己準備的期望數據集裡查找匹配的數據。方式2，訪問真實的服務端，將真實服務的返回結果返回給調用者，同時把返回的結果保存的用戶的期望數據集裡，下次在有相同的請求直接返回給客戶端。在調用真實服務時，也支持協議的轉換，比如客戶端在請求Mock系統時使用的是Hessian協議，而真實服務現在是通過RMI方式提供的服務，這時，Mock系統可以通過RMI方式調用真實服務取回數據，然後把數據通過Hessian協議返回給客戶端。方式3，用戶自己實現數據提取接口，擴展平臺的功能。需要說明的是，本申請Mock服務系統的數據提取方式也可以是以上方式1至方式3的任意組合。總之，不同用戶可以設置不同的數據提取方式，這也體現了本申請Mock服務系統在數據提取方式上的優越性。在上述實施例中通過核心對象對Mock服務進行了介紹，以下對Mock服務的配置進行介紹，具體地，一個Mock服務包括一個服務接口、一個服務版本和多個方法，這些信息均在配置文件中進行定義。圖6是根據本申請實施例的Mock服務系統的服務註冊流程圖。如圖6所示，Mock服務系統的服務註冊流程包括以下步驟：步驟S51，配置Mock服務(MockService)具體地，該步驟S51還可以包括以下步驟：步驟S511，用戶上傳配置文件，在該配置文件中定義服務的接口，版本，以及所有方法名，參數，返回值類型。由於本申請實施例的Mock服務系統定義了一個通用的服務配置文件，通過該服務配置文件，可以實現服務統一配置，註冊。具體格式可以如下所示：服務配置文件：步驟S512，上傳接口依賴的class文件或者jar包。步驟S513，系統自動創建一個classloader，用來加載該Service的相關class文件。實現多個服務之間的隔離，從而在一個平臺上支持多個服務的Mock。步驟S52，配置Mock服務的方式(Exporter)具體地，該步驟S52還可以包括以下步驟：步驟S521，選擇提供服務的方式：即設置服務使用的遠程通信協議，以及數據協議，比如：http，http(webservice)，rmi步驟S522，設置服務的路徑，即，設置服務對應的URL地址或者服務名稱步驟S523，指定服務的埠，即，對提供給客戶端訪問的埠，比如web服務一般是80埠.RMI服務默認是1099埠等等。此外，還可以設置攔截器(Filter)，對請求進行攔截處理。這裡的攔截器是針對當前的Mock服務方式的。只要客戶端調用的是這個服務，都會執行這個攔截器。一個Mock服務可以支持多種方式輸出，比如rmi，webservice。當選擇一種方式後，系統自動生成一個Exporter對象，註冊到相應的RPCExporter中。步驟S53，準備期望數據(ExpectData)，這時本系統實現服務數據靈活配置，支持複雜的服務接口Mock的關鍵。步驟S531，設置方法裡每個參數的匹配器，系統支持多種參數匹配器，比如：斷言腳本：assert(「helloMock」，ARG)；表示當參數是string，且值為helloMock時才匹配成功。ARG代表當前參數。javascript腳本：if(ARG＝＝「helloMock」)returntrue；elsereturnfalse；每個參數都可以設置這樣的匹配規則。步驟S532，設置方法返回值，系統支持多種設置方法：比如：a，java腳本：m＝newMemberDO；m.name＝「Mock」returnm；表示返回一個MemberDO對象，Mock服務系統會執行這句代碼，構造一個MemberDO對象，返回給客戶端。b，json格式的數據：{『name』：』Mock』}，Mock服務系統會根據服務配置文件裡的類型定義，將json串轉換為對應的MemberDO對象，返回給客戶端。Mock服務系統會將這個xml串反序列化為MemberDO對象，返回給客戶端。步驟S533，數據提取模塊215在提取數據時，首先列出用戶準備的期望數據，然後依次將每個實際的參數與設置的匹配規則進行匹配。當發現一組數據的所有參數規則都匹配成功時，則返回對應的返回值。步驟S54，配置數據提取方式(UserInvoker)這時Mock服務系統支持多用戶數據隔離以及「核心對象介紹」中提到的一個遠程通信通道上，可以承載多個服務方式」的關鍵。實現方式是做了兩層映射。第一層，根據客戶端IP找到匹配的UserInvoker，第二層，根據UserInvoker對應的用戶，找到用戶準備的數據以及數據提取方式。及時客戶端IP變了，只要修改第一層的對應關係即可，從而保持了用戶期望數據的穩定性，可重用性。這裡有幾個屬性設置：步驟S541，設置數據提取方式：首先選擇一個Mock服務方式，一個用戶對一個Mock服務方式只能設置一個數據提取方式。數據提取方式有多種見圖5所示的「核心對象介紹」。步驟S542，設置客戶端IP位址規則，當某個客戶端請求Mock服務時，系統會取出客戶端的IP，與所有用戶設置的IP規則進行匹配，如果匹配成功則找到了用戶以及數據提取方式。所以，這裡的IP規則具有排他性，在同一個服務方式下，多個用戶設置的IP規則不能有交叉，系統可以通過校驗來完成。步驟S543，設置攔截器(Filter)，對請求進行攔截處理。這裡的攔截器是針對當前用戶的，只有匹配到當前用戶的執行方式時，才會執行攔截器。需要說明的是，上述的步驟S53和步驟S54可以先後執行，也可以同時執行，不分先後。圖7是根據本申請實施例的Mock服務的處理方法的流程圖。如圖7所示，該方法包括以下步驟：步驟S61，接收來自客戶端的請求；例如，通過遠程通信模塊211接收來自客戶端的請求。優選地，為了能夠同時服務於不同通信類型的用戶，在該步驟中，可以通過不同的通信方式接收不同的請求。優選地，為了能夠同時為多個客戶端提供服務，在該步驟中，可以是同時接收來自多個客戶端的請求。步驟S62，查找與請求對應的Mock服務，其中，在Mock服務系統中存儲有多個Mock服務；例如，通過遠程通信模塊211在Mock服務系統中查找與請求對應的Mock服務。該步驟S62還可以包括：步驟S621，獲取客戶端的IP位址以及請求的路徑；步驟S622，列出與路徑匹配的Mock服務方式列表；步驟S623，列出Mock服務方式中的數據提取方式列表；以及步驟S624，根據客戶端的IP位址與數據提取方式列表中的數據提取方式進行匹配以查找與客戶端的IP位址對應的數據提取方式。相應於步驟S62中可以是同時接收來自多個客戶端的請求，在該步驟中，可以分別查找與多個客戶端的請求對應的Mock服務步驟S63，建立客戶端與所查找到的Mock服務的關聯關係以便為客戶端提供Mock服務。例如，通過遠程通信模塊211建立客戶端與Mock服務的關聯關係以便為客戶端提供Mock服務。相應於步驟S62中可以是同時接收來自多個客戶端的請求，在該步驟中，分別建立多個客戶端與查找到的Mock服務的關聯關係以便為多個客戶端分別提供Mock服務。在該Mock服務的處理方法中，在接收到客戶端的請求後，在Mock服務系統中查找相應的Mock服務，可以看出，在Mock服務系統中實現了對Mock服務的統一管理，各個Mock服務不再是僅僅只能服務於唯一的應用。優選地，在客戶端的IP位址改變時，該Mock服務的處理方法還可以包括：步驟S64，修改客戶端的IP位址與數據提取方式的對應關係。通過步驟S64，在客戶端IP變化時，只要修改IP位址與數據提取方式的對應關係即可，無需修改期望數據，從而保持了用戶期望數據的穩定性，可重用性。Mock服務系統中的多個Mock服務可以包括第一Mock服務，且多個Mock服務中的每個Mock服務均包括服務接口和服務版本，優選地，該Mock服務的處理方法還包括：步驟S65，接收用戶上傳的第一服務版本，其中，第一服務版本為第一Mock服務的服務版本；以及步驟S66，建立第一服務版本和第一服務接口的映射關係，其中，第一服務接口為第一Mock服務的服務接口。通過步驟S65和步驟S66，在增加新的版本，即第一服務版本時，通過建立新增加版本與服務接口的映射關係，相比於重新部署Mock服務，可以更容易地實現Mock服務的升級處理。優選地，一個服務接口中包括一個或多個方法，其中，在Mock服務系統內部，將所有的遠程調用都映射為一個方法的調用。圖8是根據本申請實施例的Mock服務系統對請求的處理流程圖。如圖8所示，Mock服務系統對請求的處理流程如下：步驟S1，客戶端發起請求客戶端調用Mock服務的方式與調用真實服務的方式是一樣的，只需修改服務地址為Mock服務的地址即可。步驟S2，接收請求遠程通信模塊211接收到客戶端的請求，取得客戶端的IP位址與請求服務的地址，比如Http請求的路徑是什麼，RMI請求對應的服務名稱(簡稱路徑)是什麼。步驟S3，查找當前請求對應的服務方式，用戶以及數據提取方式具體地，步驟S3還可以包括以下步驟：步驟S31，遠程通信模塊211取得客戶端的IP位址以及被請求服務的路徑；步驟S32，遠程通信模塊211根據服務請求路徑，列出登記在該遠程通信協議上的與服務路徑匹配的「Mock服務方式」列表；步驟S33，遠程通信模塊211依次列出Mock服務方式中的數據提取方式列表；步驟S34，遠程通信模塊211根據客戶端的IP位址，與數據提取方式中設置的IP匹配規則進行匹配，如果不匹配則繼續匹配，直到找到一個匹配的數據提取方式位置；步驟S35，遠程通信模塊211將匹配到的Mock服務方式，以及對應的數據提取方式，以及對應的用戶即為當前這次客戶端請求所對應的服務與用戶。步驟S4，委託解析數據遠程通信模塊211將請求轉交給協議數據解析模塊212。步驟S5，解析請求的方法與參數數據解析模塊212根據當前Mock服務方式所指定的數據協議，解析數據流，得到這次遠程調用的方法和參數列表。將所有遠程調用都統一起來，即使對Http服務也映射為一個方法調用。步驟S6，委託處理請求遠程通信模塊211將請求的參數封裝，委託給請求處理模塊213處理請求。步驟S7，構造請求處理鏈請求處理模塊213採用責任鏈模式，處理請求，用戶可以設置自己的攔截器(Filter)加入請求到處理鏈中，對請求進行處理，從而擴展平臺的功能。這裡的攔截器也體現了用戶的之間的隔離性，在Mock服務方式與數據提取方式兩個地方配置的攔截器的作用範圍是不一樣的，前者是對該Mock服務方式的所有請求都會攔截，後者是指定的客戶端IP發出的請求才會執行，從而提高系統的可擴展性或靈活性。提高不同用戶對Mock服務的可定製功能。步驟S8，執行請求請求處理模塊213執行請求處理鏈。步驟S9，提取用戶數據處理鏈的最後一步就是提取用戶數據。步驟S10，委託提取數據是根據當前用戶設置的數據提取方式委託給具體的提取測試模塊通過數據提取策略來完成的。步驟S11，獲取期望數據每種策略的功能就是根據請求的方法參數，返回對應的服務結果。策略分類見「數據提取方式(UserInvoker)」。步驟S12，返回數據執行策略將服務的返回值返回給數據提取模塊215。步驟S13，返回數據數據提取模塊215將服務的返回值，返回給請求處理模塊213。步驟S14，返回數據請求處理模塊213將服務的返回值，返回給數據協議模塊。步驟S15，將數據按協議格式封裝數據協議模塊將返回值按照指定的協議對數據進行封裝，就像tcp/ip協議族一樣，每個層次都有相應的數據包裝。步驟S16，返回服務結果數據協議模塊將數據返回給遠程通信模塊211。步驟S17，對數據進行封裝：遠程通信模塊211對數據進行封裝，加上數據包頭。同14的原理步驟S18，返回給客戶端這時Mock服務系統就將用戶的這次請求的期望結果返回給了客戶端。由於Mock服務所使用的協議是與真實服務一樣的，所以對客戶端來說是區分不出來的，做到了對客戶端的完全透明。需要說明的是，在附圖的流程圖示出的步驟可以在諸如一組計算機可執行指令的計算機系統中執行，並且，雖然在流程圖中示出了邏輯順序，但是在某些情況下，可以以不同於此處的順序執行所示出或描述的步驟。顯然，本領域的技術人員應該明白，上述的本申請的各模塊或各步驟可以用通用的計算裝置來實現，它們可以集中在單個的計算裝置上，或者分布在多個計算裝置所組成的網絡上，可選地，它們可以用計算裝置可執行的程序代碼來實現，從而，可以將它們存儲在存儲裝置中由計算裝置來執行，或者將它們分別製作成各個集成電路模塊，或者將它們中的多個模塊或步驟製作成單個集成電路模塊來實現。這樣，本申請不限制於任何特定的硬體和軟體結合。以上所述僅為本申請的優選實施例而已，並不用於限制本申請，對於本領域的技術人員來說，本申請可以有各種更改和變化。凡在本申請的精神和原則之內，所作的任何修改、等同替換、改進等，均應包含在本申請的保護範圍之內。