本申請涉及數(shù)據(jù)更新技術(shù)領(lǐng)域，更具體地說，涉及一種客戶端更新方法及裝置。

背景技術(shù)：

應(yīng)用軟件在上市之后，應(yīng)用提供商會持續(xù)性的對應(yīng)用軟件進行更新，以新增應(yīng)用功能、修改已有漏洞bug等。

現(xiàn)有技術(shù)中，應(yīng)用提供商在研發(fā)出最新版本客戶端之后，向應(yīng)用的所有注冊用戶開放下載，即所有注冊用戶均可以第一時間下載并體驗最新版本客戶端。但是，本案發(fā)明人研究發(fā)現(xiàn)，現(xiàn)有客戶端更新方式存在如下問題：應(yīng)用提供商研發(fā)的最新版本客戶端有可能會存在重大異常，如新增功能容易導致客戶端崩潰、應(yīng)用業(yè)務(wù)內(nèi)存在bug等問題。尤其針對游戲類應(yīng)用，如果最新版本客戶端在游戲環(huán)境內(nèi)存在bug，極易導致影響游戲公平性。按照現(xiàn)有客戶端更新方式，一旦最新版本客戶端存在問題，則會影響全體用戶的正常使用。

因此，如何提供一種客戶端更新方式，以避免上述存在的問題，成為本領(lǐng)域技術(shù)人員亟待解決的問題。

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

有鑒于此，本申請?zhí)峁┝艘环N客戶端更新方法及裝置，以解決現(xiàn)有采用全體更新方式所存在的，當所更新的客戶端存在問題時，影響全體用戶正常使用的問題。

為了實現(xiàn)上述目的，現(xiàn)提出的方案如下：

一種客戶端更新方法，包括：

獲取客戶端發(fā)送的更新請求，所述更新請求包括所述客戶端當前登錄賬號的賬號信息；

根據(jù)所述賬號信息，確定所述當前登錄賬號所屬的業(yè)務(wù)內(nèi)分組是否處于預配置的灰度名單內(nèi)，所述灰度名單包括配置的允許進行客戶端更新的業(yè)務(wù)內(nèi)分組；

若是，根據(jù)預配置的更新策略對所述客戶端進行更新。

一種客戶端更新裝置，包括：

更新請求獲取單元，用于獲取客戶端發(fā)送的更新請求，所述更新請求包括所述客戶端當前登錄賬號的賬號信息；

灰度名單判斷單元，用于根據(jù)所述賬號信息，確定所述當前登錄賬號所屬的業(yè)務(wù)內(nèi)分組是否處于預配置的灰度名單內(nèi)，所述灰度名單包括配置的允許進行客戶端更新的業(yè)務(wù)內(nèi)分組；

數(shù)據(jù)更新單元，用于在所述灰度名單判斷單元的判斷結(jié)果為是時，根據(jù)預配置的更新策略對所述客戶端進行更新。

本申請實施例提供的客戶端更新方法，獲取客戶端發(fā)送的更新請求，所述更新請求包括所述客戶端當前登錄賬號的賬號信息；根據(jù)所述賬號信息，確定所述當前登錄賬號所屬的業(yè)務(wù)內(nèi)分組是否處于預配置的灰度名單內(nèi)，所述灰度名單包括配置的允許進行客戶端更新的業(yè)務(wù)內(nèi)分組；若是，根據(jù)預配置的更新策略對所述客戶端進行更新。其中，各客戶端的登錄賬號在業(yè)務(wù)內(nèi)劃分為若干不同的分組，以游戲應(yīng)用為例，游戲內(nèi)存在不同的分區(qū)或服，在此基礎(chǔ)上本申請設(shè)置了灰度名單，灰度名單內(nèi)存儲的是配置的允許進行客戶端更新的業(yè)務(wù)內(nèi)分組。因此，本申請可以通過灰度名單設(shè)置部分業(yè)務(wù)內(nèi)分組對應(yīng)的登錄賬號允許進行客戶端更新，且在一段時間內(nèi)更新客戶端的用戶未反饋重大問題時，再設(shè)置全體用戶均可以更新，保證了即使更新后的客戶端存在問題，也僅僅對部分用戶產(chǎn)生影響，不會導致全體用戶均無法正常使用的問題。

附圖說明

為了更清楚地說明本申請實施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對實施例或現(xiàn)有技術(shù)描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本申請的實施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)提供的附圖獲得其他的附圖。

圖1為本申請實施例公開的一種客戶端更新方法信令交互圖；

圖2為本申請實施例公開的另一種客戶端更新方法信令交互圖；

圖3為本申請實施例公開的一種游戲客戶端更新方法信令交互圖；

圖4為本申請實施例公開的又一種客戶端更新方法信令交互圖；

圖5為本申請實施例公開的一種客戶端登錄方法流程圖；

圖6為本申請實施例公開的一種客戶端更新裝置結(jié)構(gòu)示意圖；

圖7為本申請實施例提供的一種服務(wù)端硬件結(jié)構(gòu)示意圖。

具體實施方式

下面將結(jié)合本申請實施例中的附圖，對本申請實施例中的技術(shù)方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本申請一部分實施例，而不是全部的實施例?；诒旧暾堉械膶嵤├?，本領(lǐng)域普通技術(shù)人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本申請保護的范圍。

本申請實施例公開了一種客戶端更新方案，由客戶端和服務(wù)端配合完成更新過程。其中，客戶端用于運行應(yīng)用業(yè)務(wù)，應(yīng)用業(yè)務(wù)可以是多種類型，如多媒體類型、游戲類型等。本申請方案適用于各客戶端的登錄賬號在業(yè)務(wù)內(nèi)劃分為若干不同分組的場景，如游戲類應(yīng)用業(yè)務(wù)，其中存在多個不同的分區(qū)或者服，用戶可以在任意一個分區(qū)或服中注冊登錄賬號，并通過對應(yīng)的分區(qū)或服進入游戲內(nèi)。不同分區(qū)或服之間玩家數(shù)據(jù)是相互獨立的。

參見圖1，圖1為本申請實施例公開的一種客戶端更新方法信令交互圖。如圖1所示，該方法包括：

S10、客戶端向服務(wù)端發(fā)送更新請求，更新請求包括客戶端當前登錄賬號的賬號信息；

具體地，客戶端可以按照設(shè)定策略向服務(wù)端發(fā)送更新請求。如客戶端在登錄服務(wù)端之前，向服務(wù)端發(fā)送更新請求；或者，客戶端登錄服務(wù)端之后，向服務(wù)端發(fā)送更新請求，再或者，客戶端在收到服務(wù)端廣播的更新指令時，向服務(wù)端發(fā)送更新請求。其中，服務(wù)端在確定獲取到最新版本的客戶端時向各個客戶端廣播更新指令。

客戶端向服務(wù)端發(fā)送的更新請求中，包含了客戶端當前登錄賬號的賬號信息。賬號信息可以包括具體登錄賬號、登錄賬號在業(yè)務(wù)內(nèi)的關(guān)聯(lián)信息，如登錄賬號所屬業(yè)務(wù)內(nèi)分組等。

步驟S11、服務(wù)端根據(jù)所述賬號信息，確定所述當前登錄賬號所屬的業(yè)務(wù)內(nèi)分組是否處于預配置的灰度名單內(nèi)；若是，執(zhí)行步驟S12，若否，執(zhí)行步驟S13；

其中，所述灰度名單包括配置的允許進行客戶端更新的業(yè)務(wù)內(nèi)分組。本申請業(yè)務(wù)提供商可以配置允許進行客戶端更新的業(yè)務(wù)內(nèi)分組，并將配置的業(yè)務(wù)內(nèi)分組存儲在灰度名單中。只有處于灰度名單內(nèi)的業(yè)務(wù)內(nèi)分組對應(yīng)的登錄賬號才可以進行客戶端更新，其余登錄賬號是不被允許進行客戶端更新的。

以游戲業(yè)務(wù)為例進行說明：

目標游戲客戶端共存在10個分區(qū)，用戶可以通過任意一個分區(qū)進行登錄賬號的注冊，并且注冊后能夠通過對應(yīng)的分區(qū)及登錄賬號登錄游戲。

游戲開發(fā)商開發(fā)得到一個新版本的客戶端之后，選擇將分區(qū)1寫入灰度名單內(nèi)，即只有分區(qū)1內(nèi)的登錄賬號才能夠更新該新版本的客戶端。

可選的，服務(wù)端可以在本地存儲灰度名單，或者是在服務(wù)端所能夠訪問到的其它設(shè)備中存儲該灰度名單。

步驟S12、服務(wù)端根據(jù)預配置的更新策略對所述客戶端進行更新；

具體地，在上一步驟中確定所述當前登錄賬號所屬的業(yè)務(wù)內(nèi)分組處于灰度名單內(nèi)時，表示當前登錄賬號允許進行客戶端更新，因此，服務(wù)端根據(jù)預配置的更新策略，對當前登錄賬號所對應(yīng)的客戶端進行更新。

步驟S13、服務(wù)端拒絕對所述客戶端進行更新。

具體地，在上一步驟中確定所述當前登錄賬號所屬的業(yè)務(wù)內(nèi)分組未處于灰度名單內(nèi)時，表示當前登錄賬號不被允許進行客戶端更新，因此服務(wù)端拒絕對當前登錄賬號所對應(yīng)的客戶端進行更新。

本申請可以通過灰度名單設(shè)置部分業(yè)務(wù)內(nèi)分組對應(yīng)的登錄賬號允許進行客戶端更新，且在一段時間內(nèi)更新客戶端的用戶未反饋重大問題時，再設(shè)置全體用戶均可以更新，保證了即使更新后的客戶端存在問題，也僅僅對部分用戶產(chǎn)生影響，不會導致全體用戶均無法正常使用的問題。

參見圖2，圖2為本申請實施例公開的另一種客戶端更新方法信令交互圖。如圖2所示，該方法包括：

S20、客戶端向服務(wù)端發(fā)送更新請求，更新請求包括客戶端當前登錄賬號的賬號信息以及客戶端的版本信息；

相比于上一實施例，本實施例中客戶端向服務(wù)端發(fā)送的更新請求中進一步增加了客戶端的版本信息。

步驟S21、服務(wù)端根據(jù)所述賬號信息，確定所述當前登錄賬號所屬的業(yè)務(wù)內(nèi)分組是否處于預配置的灰度名單內(nèi)；若是，執(zhí)行步驟S22；

步驟S22、服務(wù)端根據(jù)所述版本信息確定所述客戶端是否為最新版本；若否，執(zhí)行步驟S23，若是，執(zhí)行步驟S24；

具體地，服務(wù)端在確定當前登錄賬號所屬的業(yè)務(wù)內(nèi)分組處于預配置的灰度名單內(nèi)時，進一步判斷所述客戶端是否為最新版本。

步驟S23、服務(wù)端將最新版本的客戶端更新數(shù)據(jù)發(fā)送給所述客戶端；

具體地，如果服務(wù)端判斷所述客戶端不是最新版本，則服務(wù)端將最新版本的客戶端更新數(shù)據(jù)發(fā)送給客戶端，以使得所述客戶端利用所述最新版本的客戶端更新數(shù)據(jù)進行更新。

可選的，該最新版本的客戶端更新數(shù)據(jù)可以是最新版本的客戶端文件，也即，服務(wù)端直接將最新版本的客戶端文件發(fā)送給客戶端。

除此之外，如果最新版本的客戶端文件未存儲在服務(wù)端本地，而是存儲在其它設(shè)備。則本步驟中服務(wù)端發(fā)送的最新版本的客戶端更新數(shù)據(jù)可以是最新版本的客戶端文件的下載鏈接地址。進而，客戶端在收到下載鏈接地址之后可以訪問該下載鏈接地址，進而下載對應(yīng)的最新版本的客戶端文件。

步驟S24、服務(wù)端確定是否存在配置的升級數(shù)據(jù)文件；若是，執(zhí)行步驟S25；

具體地，如果服務(wù)端判斷所述客戶端是最新版本，則確定不需要更新客戶端。在此基礎(chǔ)上，服務(wù)端可以進一步判斷本地是否存在配置的升級數(shù)據(jù)文件。升級數(shù)據(jù)文件為對客戶端已有的某些數(shù)據(jù)文件進行升級所需的數(shù)據(jù)文件，其不涉及客戶端整體的更新。

步驟S25、將配置的升級數(shù)據(jù)文件的下載鏈接地址發(fā)送給所述客戶端。

通過將下載鏈接地址發(fā)送給客戶端，便于客戶端訪問該下載鏈接地址，進而下載對應(yīng)的升級數(shù)據(jù)文件。

可選的，在確定服務(wù)端存在配置的升級數(shù)據(jù)文件時，除了按照步驟S25的實施方式之外，還可以將配置的升級數(shù)據(jù)文件直接發(fā)送給所述客戶端。

可選的，上述步驟S22，服務(wù)端根據(jù)所述版本信息確定所述客戶端是否為最新版本的過程，具體實現(xiàn)過程可以包括：

服務(wù)端判斷所述版本信息所包含的版本號是否小于配置的最新版本的客戶端的版本號；

若否，確定所述客戶端為最新版本，否則，確定所述客戶端不是最新版本。

也即，版本信息可以包括版本號?？蛻舳穗S著迭代更新，其版本號一般是遞增的。也即，新版本的客戶端的版本號要大于舊版本的客戶端的版本號。因此，本實施例中，可以通過判斷所述版本信息所包含的版本號是否小于配置的最小版本的客戶端的版本號，來判斷所述客戶端是否為最新版本。

可選的，上述賬號信息可以包括當前登錄賬號所屬的業(yè)務(wù)內(nèi)分組標識。在此基礎(chǔ)上，上述步驟S11，根據(jù)所述賬號信息，確定所述當前登錄賬號所屬的業(yè)務(wù)內(nèi)分組是否處于預配置的灰度名單內(nèi)的過程，具體可以包括：

確定所述當前登錄賬號所屬的業(yè)務(wù)內(nèi)分組標識，是否存在于預配置的灰度名單內(nèi)。其中，所述預配置的灰度名單包括配置的允許進行客戶端更新的業(yè)務(wù)內(nèi)分組的標識。

業(yè)務(wù)內(nèi)分組的標識可以是數(shù)字、字符的形式，也可以是二者的結(jié)合。以游戲業(yè)務(wù)為例進行說明：

游戲內(nèi)分區(qū)/分服表示為zoneid，zoneid＝3001表示分區(qū)標識為3001的游戲分區(qū)。

在本申請的一個實施例中，以游戲客戶端的更新過程為例，對本申請方案進行介紹。如圖3所示，該方法包括：

S30、游戲客戶端向游戲服務(wù)端發(fā)送更新請求，更新請求包括游戲客戶端當前登錄賬號所屬的游戲內(nèi)分區(qū)標識以及游戲客戶端的版本號；

其中，游戲內(nèi)分區(qū)標識可以表示為zoneid，版本號可以表示為curVersion。

步驟S31、游戲服務(wù)端確定所述當前登錄賬號所屬的游戲內(nèi)分區(qū)標識是否處于預配置的灰度名單內(nèi)；若是，執(zhí)行步驟S32；

步驟S32、游戲服務(wù)端判斷所述游戲客戶端的版本號是否小于配置的最新版本的客戶端的版本號；若是，執(zhí)行步驟S33，若否，執(zhí)行步驟S34；

具體地，配置的最新版本的客戶端的版本號可以表示為clientVersion。因此，本步驟中可以判斷curVersion是否小于clientVersion。

步驟S33、游戲服務(wù)端將最新版本的客戶端更新數(shù)據(jù)發(fā)送給所述游戲客戶端；

可選的，該最新版本的游戲客戶端更新數(shù)據(jù)可以是最新版本的游戲客戶端文件，也即，服務(wù)端直接將最新版本的游戲客戶端文件發(fā)送給游戲客戶端。

除此之外，如果最新版本的游戲客戶端文件未存儲在游戲服務(wù)端本地，而是存儲在其它設(shè)備。則本步驟中游戲服務(wù)端發(fā)送的最新版本的游戲客戶端更新數(shù)據(jù)可以是最新版本的游戲客戶端文件的下載鏈接地址。進而，游戲客戶端在收到下載鏈接地址之后可以訪問該下載鏈接地址，進而下載對應(yīng)的最新版本的游戲客戶端文件。

步驟S34、游戲服務(wù)端確定是否存在配置的升級數(shù)據(jù)文件；若是，執(zhí)行步驟S35；

步驟S35、將配置的升級數(shù)據(jù)文件的下載鏈接地址發(fā)送給所述游戲客戶端。

本實施例介紹的游戲客戶端更新方式，在進行游戲客戶端更新時，通過設(shè)置灰度名單，僅對部分分區(qū)的登錄賬號進行游戲客戶端更新，在一段時間內(nèi)未收到用戶反饋的重大問題時，可以進一步對全體玩家開放下載。

可以理解的是，上述介紹的灰度名單可以包括兩份，一份是針對單個分區(qū)設(shè)置的第一灰度名單，也即第一灰度名單內(nèi)包括允許進行客戶端更新的單一游戲分區(qū)，另一份是針對全部分區(qū)設(shè)置的第二灰度名單，也即第二灰度名單包括允許進行客戶端更新的全部游戲分區(qū)。則上述判斷所述當前登錄賬號所屬的游戲內(nèi)分區(qū)標識是否處于預配置的灰度名單內(nèi)的過程，具體包括：

判斷所述當前登錄賬號所屬的游戲內(nèi)分區(qū)標識是否處于第一灰度名單內(nèi)，如果是，執(zhí)行上述步驟S32，如果否，進一步判斷所述當前登錄賬號所屬的游戲內(nèi)分區(qū)標識是否處于第二灰度名單內(nèi)，如果是，執(zhí)行上述步驟S32。

參見圖4，圖4為本申請實施例公開的又一種客戶端更新方法信令交互圖。如圖4所示，該方法包括：

S40、客戶端向服務(wù)端發(fā)送更新請求，更新請求包括客戶端當前登錄賬號的賬號信息；

S41、判斷預置的白名單功能是否處于開啟狀態(tài)，若是，執(zhí)行步驟S42，若否，執(zhí)行步驟S43；

具體地，本申請預先設(shè)置有白名單功能，白名單功能即為啟動白名單判斷機制，只有處于白名單內(nèi)的登錄賬號才可以執(zhí)行后續(xù)操作。其中，所述白名單包括配置的允許進行客戶端內(nèi)測的登錄賬號。

這里，為了保證客戶端對外的下載質(zhì)量，在開放下載之前，允許讓部分內(nèi)測人員先行下載更新后的客戶端，對更新的可行性進行體驗。

步驟S42、判斷所述當前登錄賬號是否處于預配置的白名單內(nèi)；若是，執(zhí)行步驟S43，若否，退出；

步驟S43、服務(wù)端根據(jù)所述賬號信息，確定所述當前登錄賬號所屬的業(yè)務(wù)內(nèi)分組是否處于預配置的灰度名單內(nèi)；若是，執(zhí)行步驟S44，若否，執(zhí)行步驟S45；

步驟S44、服務(wù)端根據(jù)預配置的更新策略對所述客戶端進行更新；

步驟S45、服務(wù)端拒絕對所述客戶端進行更新。

相比于上述各實施例，本實施例中進一步增加了白名單判斷策略，即只有當前登錄賬號處于配置的白名單內(nèi)，才進行后續(xù)灰度名單的判斷策略。通過設(shè)置白名單，在客戶端對外開放下載之前，為了保證下載質(zhì)量，先讓部分內(nèi)測人員下載更新后的客戶端，以驗證客戶端更新的可行性。

在上述實施例的基礎(chǔ)上，本實施例進一步介紹了一種客戶端登錄方式，從服務(wù)端角度對該登錄過程進行介紹，參見圖5所示，該過程可以包括：

步驟S500、獲取所述客戶端發(fā)送的登錄請求，所述登錄請求包括所述客戶端的版本號；

具體地，如果客戶端在登錄之前進行了更新，且更新成功的話，則本步驟中登錄請求所包含的客戶端的版本號即為最新版本號，否則，為更新之前客戶端的版本號。

步驟S510、判斷所述客戶端的版本號是否大于設(shè)置的版本號閾值；若是，執(zhí)行步驟S520，若否，執(zhí)行步驟S530；

具體地，由于在客戶端迭代更新過程，會存在修復原有的漏洞、增加新功能等，因此，工作人員可以設(shè)置版本號閾值，用戶只有使用版本號大于該版本號閾值的客戶端才被允許登錄服務(wù)端，否則，拒絕用戶的登錄請求。

步驟S520、允許所述客戶端登錄；

步驟S530、拒絕所述客戶端登錄。

本申請通過設(shè)置版本號閾值，避免用戶長時間不更新客戶端，使用過時的客戶端登錄服務(wù)端，從而利用舊版本客戶端所存在的漏洞進行攻擊。以游戲業(yè)務(wù)為例，如果舊版本客戶端存在bug，則玩家容易通過該bug來破壞游戲公平性，而本實施例通過增加判斷客戶端的版本號是否大于設(shè)置的版本號閾值的過程，可以有效杜絕此類事件的發(fā)生，保證游戲公平性。

下面對本申請實施例提供的客戶端更新裝置進行描述，下文描述的客戶端更新裝置與上文描述的客戶端更新方法可相互對應(yīng)參照。

參見圖6，圖6為本申請實施例公開的一種客戶端更新裝置結(jié)構(gòu)示意圖，如圖6所示，該裝置包括：

更新請求獲取單元11，用于獲取客戶端發(fā)送的更新請求，所述更新請求包括所述客戶端當前登錄賬號的賬號信息；

灰度名單判斷單元12，用于根據(jù)所述賬號信息，確定所述當前登錄賬號所屬的業(yè)務(wù)內(nèi)分組是否處于預配置的灰度名單內(nèi)，所述灰度名單包括配置的允許進行客戶端更新的業(yè)務(wù)內(nèi)分組；

數(shù)據(jù)更新單元13，用于在所述灰度名單判斷單元12的判斷結(jié)果為是時，根據(jù)預配置的更新策略對所述客戶端進行更新。

本申請可以通過灰度名單設(shè)置部分業(yè)務(wù)內(nèi)分組對應(yīng)的登錄賬號允許進行客戶端更新，且在一段時間內(nèi)更新客戶端的用戶未反饋重大問題時，再設(shè)置全體用戶均可以更新，保證了即使更新后的客戶端存在問題，也僅僅對部分用戶產(chǎn)生影響，不會導致全體用戶均無法正常使用的問題。

可選的，所述更新請求還可以包括：所述客戶端的版本信息?；诖?，所述數(shù)據(jù)更新單元可以包括：

版本判斷單元，用于根據(jù)所述版本信息確定所述客戶端是否為最新版本；

客戶端更新數(shù)據(jù)發(fā)送單元，用于在所述版本判斷單元的判斷結(jié)果為否時，將最新版本的客戶端更新數(shù)據(jù)發(fā)送給所述客戶端，以使得所述客戶端利用所述最新版本的客戶端更新數(shù)據(jù)進行更新。

可選的，所述客戶端更新數(shù)據(jù)發(fā)送單元可以包括：

第一客戶端更新數(shù)據(jù)發(fā)送子單元，用于在所述版本判斷單元的判斷結(jié)果為否時，將最新版本的客戶端文件的下載鏈接地址發(fā)送給所述客戶端，以使得所述客戶端訪問所述下載鏈接地址并下載所述最新版本的客戶端文件；

或者，

第二客戶端更新數(shù)據(jù)發(fā)送子單元，用于在所述版本判斷單元的判斷結(jié)果為否時，將最新版本的客戶端文件發(fā)送給所述客戶端。

可選的，所述數(shù)據(jù)更新單元還可以包括：

升級數(shù)據(jù)文件判斷單元，用于在所述版本判斷單元的判斷結(jié)果為是時，確定是否存在配置的升級數(shù)據(jù)文件；

升級數(shù)據(jù)文件發(fā)送單元，用于在所述升級數(shù)據(jù)文件判斷單元的判斷結(jié)果為是時，將配置的升級數(shù)據(jù)文件發(fā)送給所述客戶端，或者，將配置的升級數(shù)據(jù)文件的下載鏈接地址發(fā)送給所述客戶端。

可選的，所述版本判斷單元可以包括：

版本號比較單元，用于判斷所述版本信息所包含的版本號是否小于配置的最新版本的客戶端的版本號；若否，確定所述客戶端為最新版本，否則，確定所述客戶端不是最新版本。

可選的，所述賬號信息可以包括當前登錄賬號所屬的業(yè)務(wù)內(nèi)分組標識。在此基礎(chǔ)上，所述灰度名單判斷單元可以包括：

分組標識判斷單元，用于確定所述當前登錄賬號所屬的業(yè)務(wù)內(nèi)分組標識，是否存在于預配置的灰度名單內(nèi)，所述預配置的灰度名單包括配置的允許進行客戶端更新的業(yè)務(wù)內(nèi)分組的標識。

其中可選的，所述當前登錄賬號所屬的業(yè)務(wù)內(nèi)分組標識可以為：游戲業(yè)務(wù)內(nèi)，當前登錄賬號所屬的游戲分區(qū)或分服。

可選的，本申請裝置還可以包括：

登錄請求獲取單元，用于獲取所述客戶端發(fā)送的登錄請求，所述登錄請求包括所述客戶端的版本號；

版本號閾值判斷單元，用于判斷所述客戶端的版本號是否大于設(shè)置的版本號閾值；若是，允許所述客戶端登錄，否則，拒絕所述客戶端登錄。

可選的，本申請的裝置還可以包括：

白名單判斷單元，用于若確定預置的白名單功能處于開啟狀態(tài)，則判斷所述當前登錄賬號是否處于預配置的白名單內(nèi)，所述白名單包括配置的允許進行客戶端內(nèi)測的登錄賬號，若是，則執(zhí)行所述灰度名單判斷單元，若否，退出。

本申請的客戶端更新裝置可以應(yīng)用于服務(wù)端，如游戲服務(wù)器等。接下來的實施例中，對實現(xiàn)本申請的客戶端更新裝置的服務(wù)端的硬件結(jié)構(gòu)進行介紹，參見圖7，圖7為本申請實施例提供的一種服務(wù)端硬件結(jié)構(gòu)示意圖。

如圖7所示，服務(wù)端可以包括：

處理器1，通信接口2，存儲器3，通信總線4，和顯示屏5；

其中處理器1、通信接口2、存儲器3和顯示屏5通過通信總線4完成相互間的通信；

可選的，通信接口2可以為通信模塊的接口，如GSM模塊的接口；

處理器1，用于執(zhí)行程序；

存儲器3，用于存放程序；

程序可以包括程序代碼，所述程序代碼包括處理器的操作指令。

處理器1可能是一個中央處理器CPU，或者是特定集成電路ASIC(Application Specific Integrated Circuit)，或者是被配置成實施本申請實施例的一個或多個集成電路。

存儲器3可能包含高速RAM存儲器，也可能還包括非易失性存儲器(non-volatile memory)，例如至少一個磁盤存儲器。

其中，程序具體用于：

獲取客戶端發(fā)送的更新請求，所述更新請求包括所述客戶端當前登錄賬號的賬號信息；

根據(jù)所述賬號信息，確定所述當前登錄賬號所屬的業(yè)務(wù)內(nèi)分組是否處于預配置的灰度名單內(nèi)，所述灰度名單包括配置的允許進行客戶端更新的業(yè)務(wù)內(nèi)分組；

若是，根據(jù)預配置的更新策略對所述客戶端進行更新。

最后，還需要說明的是，在本文中，諸如第一和第二等之類的關(guān)系術(shù)語僅僅用來將一個實體或者操作與另一個實體或操作區(qū)分開來，而不一定要求或者暗示這些實體或操作之間存在任何這種實際的關(guān)系或者順序。而且，術(shù)語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者設(shè)備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者設(shè)備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括所述要素的過程、方法、物品或者設(shè)備中還存在另外的相同要素。

本說明書中各個實施例采用遞進的方式描述，每個實施例重點說明的都是與其他實施例的不同之處，各個實施例之間相同相似部分互相參見即可。

對所公開的實施例的上述說明，使本領(lǐng)域?qū)I(yè)技術(shù)人員能夠?qū)崿F(xiàn)或使用本申請。對這些實施例的多種修改對本領(lǐng)域的專業(yè)技術(shù)人員來說將是顯而易見的，本文中所定義的一般原理可以在不脫離本申請的精神或范圍的情況下，在其它實施例中實現(xiàn)。因此，本申請將不會被限制于本文所示的這些實施例，而是要符合與本文所公開的原理和新穎特點相一致的最寬的范圍。