本申請涉及應用灰度管理
技術領域：
，更具體地，是應用灰度發布方法及相關設備、應用訪問方法及相關設備。
背景技術：
：通常地，應用開發者對應用進行測試時，可以將已發布的應用作為主版本的應用，并發布測試版本的應用。不同版本的應用發布在不同的物理服務器上。管理員在配置數據庫中配置應用灰度策略(可簡稱為應用灰度)，灰度策略用于對用戶的訪問請求進行分流，即將大部分用戶的訪問請求轉發至主版本，并將一部分用戶的訪問請求分流至測試版本。從而，可以監測測試版本的運行情況，以作為對主版本改進及完善的依據。以上應用灰度策略的發布系統，應用灰度的發布效率較低，且較為耗費資源。技術實現要素：有鑒于此，本申請提供了一種應用灰度的發布系統，用以提高應用灰度發布的效率，并節省應用灰度發布系統所使用的資源。為實現所述目的，本申請提供的技術方案如下：一種應用灰度發布系統，包括：Redis存儲系統、分流服務器、容器構建服務器及Docker應用容器；其中：所述Redis存儲系統，用于以鍵值對形式存儲灰度策略；所述容器構建服務器，用于監測所述Redis存儲系統，若監測到所述Redis存儲系統的灰度策略中新增某版本的應用，則在物理服務器上構建Docker應用容器；還用于向所述分流服務器發送觸發指令；以及，還用于修改分流服務器中所述新增某版本的應用對應的分流參數，分流參數用于指示所述Docker應用容器的地址；所述Docker應用容器，用于發布所述某版本的應用；所述分流服務器，用于接收到觸發指令后，從Redis存儲系統中讀取灰度策略；其中，所述分流參數及所述灰度策略用于將用戶請求分流至所述Docker應用容器。在一個可能的設計中，在監測所述Redis存儲系統的方面，所述容器構建服務器具體用于：以周期性輪詢方式監測所述Redis存儲系統。在一個可能的設計中，所述鍵值對中的鍵表示用戶信息，所述鍵值對中的值表示應用版本信息，其中，所述用戶信息包括位置信息、注冊時間、登錄時間或訪問數據量。另一方面，本申請還提供了一種應用灰度發布方法，包括：所述容器構建服務器監測Redis存儲系統，以監測Redis存儲系統存儲的灰度策略是否發生變化，其中，所述灰度策略存儲為鍵值對形式；所述容器構建服務器若監測到所述Redis存儲系統的灰度策略中新增某版本的應用，則在物理服務器上構建Docker應用容器，并修改分流服務器中所述新增某版本的應用對應的分流參數，分流參數用于指示所述Docker應用容器的地址；所述Docker應用容器發布所述某版本的應用；所述分流服務器從Redis存儲系統中讀取灰度策略；其中，所述分流參數及所述灰度策略用于將用戶請求分流至所述Docker應用容器。在一個可能的設計中，所述容器構建服務器監測Redis存儲系統，包括：所述以周期性輪詢方式監測所述Redis存儲系統。在一個可能的設計中，應用灰度發布方法還包括：所述容器構建服務器向分流服務器發送觸發指令；所述分流服務器從Redis存儲系統中讀取灰度策略，包括：所述分流服務器接收到所述觸發指令后，從Redis存儲系統中讀取灰度策略。在一個可能的設計中，應用灰度發布方法還包括：若容器構建服務器并未成功修改分流服務器中該灰度策略對應的分流參數，則注銷所構建的Docker應用容器。在一個可能的設計中，所述鍵值對中的鍵表示用戶信息，所述鍵值對中的值表示應用版本信息，其中，所述用戶信息包括位置信息、注冊時間、登錄時間或訪問數據量。又一方面，本申請還提供了一種應用訪問方法，包括：接收到用戶請求后，從所述用戶請求中提取用戶信息；根據灰度策略，確定所述用戶信息所對應的目標版本應用；其中，所述灰度策略為鍵值對形式；根據分流參數，查找所述目標版本應用的地址，該地址表示目標版本應用發布在哪個Docker應用容器上；將所述用戶請求轉發到目標版本應用的地址指示的Docker應用容器上，以使所述用戶請求訪問所述目標版本應用。又一方面，本申請還提供了一種分流服務器，包括：處理器和存儲器，所述處理器通過運行存儲在所述存儲器內的軟件程序、調用存儲在所述存儲器內的數據，至少執行上述應用訪問方法。與現有的應用灰度發布系統相比，本申請提供的應用灰度發布系統中，使用了Redis存儲系統替代原有的配置數據庫，將灰度策略保存為鍵值對形式，灰度策略發布更加快速，且基于該種形式灰度策略的分流流程更加高效。另外，本申請采用Docker技術來作為多版本的應用容器引擎，構建的Docker應用容器代替物理服務器，更加節省資源。當然，實施本申請的任一產品并不一定需要同時達到以上所述的所有優點。附圖說明為了更清楚地說明本申請實施例或現有技術中的技術方案，下面將對實施例或現有技術描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本申請的實施例，對于本領域普通技術人員來講，在不付出創造性勞動的前提下，還可以根據提供的附圖獲得其他的附圖。圖1為現有的應用灰度發布系統的結構圖；圖2為本申請提供的應用灰度發布系統的結構圖；圖3為本申請提供的應用灰度發布方法的流程圖；圖4為本申請提供的基于灰度策略的應用訪問方法的一個流程圖；圖5為本申請提供的基于灰度策略的應用訪問方法的另一示例圖。具體實施方式下面將結合本申請實施例中的附圖，對本申請實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本申請一部分實施例，而不是全部的實施例。基于本申請中的實施例，本領域普通技術人員在沒有做出創造性勞動前提下所獲得的所有其他實施例，都屬于本申請保護的范圍。為了便于理解本申請，首先對應用灰度發布等概念及使用的相關技術進行說明。通常地，應用開發者會發布同一應用的多個版本，并測試用戶對各個版本的使用情況，以完善應用功能及提升應用性能，并降低應用升級所影響的用戶范圍。灰度發布一般包括以下幾個步驟。(1)選取灰度策略，比如用戶規模、應用發布頻率、功能覆蓋度、回滾策略、運營策略、新舊系統部署策略等；(2)篩選用戶，比如用戶的特征、用戶數量、用戶常用功能、用戶范圍等；(3)部署系統，比如部署新系統、行為分析、意見征集、產品功能改進等；(4)應用改進以及完整發布。如圖1所示，現有的灰度發布是基于分流服務器+新老版本服務器集群來實施的。具體地，假設目前應用發布有兩個版本，相應地，服務器集群中設置有兩個服務器，分別為服務器1及服務器2，其中，服務器1上發布的是老版本，服務器2上發布的是新版本。策略發布管理員通過策略配置庫，在分流服務器上部署灰度策略。從而，不同的用戶訪問應用時，分流服務器根據灰度策略，將不同用戶的訪問請求發送至不同的服務器上，以訪問不同版本的應用。雖然圖1中僅僅示出了兩個用戶，兩個用戶僅僅是示例說明，在實施中，訪問應用的用戶是大量的，灰度策略可以將一部分用戶分流到某版本應用的服務器上，以收集此部分用戶對該版本應用的使用情況，進而根據使用情況對應用進行改進及完善。當然，以上對應用測試僅僅是灰度發布的一種應用場景，但在實際應用中，灰度發布的應用場景并不局限于此，只要是使用灰度策略對用戶訪問請求分流的情況均在本申請的保護范圍內。現有的灰度發布方式中，使用物理服務器存儲不同版本的應用，若應用版本數量較多，則需要部署相應數量的物理服務器，耗費資源較多。另外，策略配置庫中的灰度策略以數據表的形式進行存儲，分流服務器需要讀取配置策略庫中的數據表以實現分流，分流效率較低。為了解決以上問題，本申請提供了以下應用灰度發布系統，該系統具體結構見圖2。如圖2所示，應用灰度發布系統可以包括：Redis存儲系統、分流服務器、容器構建服務器及Docker應用容器。Redis存儲系統，代替現有的策略配置數據庫，用于以鍵值對的形式存儲灰度策略。其中，鍵用于表示用戶信息，值用于表示應用版本信息。Redis是一個鍵-值對(key-value)存儲系統。Redis存儲系統上的灰度策略可以是多種形式，例如，一種形式是以位置作為灰度策略中的“鍵”。該種形式中，灰度策略的鍵-值對中的“鍵”為位置信息，“值”為應用版本信息。舉例說明如下：比如，使用某應用的用戶所在的位置包括北京的海淀區、北京的朝陽區、河北的保定市、河北的石家莊、天津的濱海新區等。用戶發送的應用訪問請求可以包含相應的位置信息，如應用訪問請求中的IP地址表示位置信息。該應用的主版本為Version_Quanguo，若想要在主版本的基礎上發布一個測試版本Version_Haidian，該測試版本主要給北京海淀區的用戶使用。待北京海淀區的用戶使用成熟后，可以再發布新版本為Version_Beijing，給所有北京地區的用戶使用，以此類推實現某國家或地區的全部用戶使用。基于上述情況，應用首次發布的兩個版本為：主版本Version_Quanguo及測試版本Version_Haidian，北京海淀區的用戶訪問測試版本Version_Haidian，其他地區的用戶訪問主版本Version_Quanguo。從而，Redis存儲的灰度策略可以如下表1所示。表1Key(地理位置)Value(某版本的應用)HAIDIANVersion_HaidianOTHERVersion_Quanguo以上以用戶的位置信息作為鍵值對中的“鍵”僅僅是一種示例，根據實際應用需求，“鍵”的內容還可以是其他用戶信息，如用戶的注冊時間、用戶的訪問時間或用戶的訪問數據量等。容器構建服務器，用于周期性輪詢Redis存儲系統，以監測灰度策略是否發生變化，若監測到灰度策略發生變化，則在物理服務器上構建Docker應用容器。Docker應用容器，用于發布某版本的應用。以表1所示的應用版本為例，容器構建服務器在Redis存儲系統查詢到在主版本Version_Quanguo的基礎上，新增測試版本Version_Haidian，則在Docker應用容器1的基礎上，新增Docker應用容器2。其中，Docker應用容器1上發布的是主版本Version_Quanguo，Docker應用容器2上發布的是測試版本Version_Haidian。兩個Docker應用容器均部署在物理服務器上，也就是說，是在物理服務器上構建Docker應用容器，以虛擬服務器代替現有的物理服務器。Docker應用容器的配置策略從Redis存儲系統及容器構建服務器上獲取。Docker應用容器構建完成后，容器構建服務器還可以用于修改Redis存儲系統的內部參數及分流服務器的分流參數，并開放對新構建的Docker應用容器的訪問。進一步地，容器構建服務器還可以用于，觸發分流服務器讀取Redis存儲系統中的灰度策略。Docker是一個開源的應用容器引擎，讓開發者可以打包應用以及依賴包到一個可移植的容器中，然后發布到任何流行的Linux機器上，也可以實現虛擬化。分流服務器，用于根據容器構建服務器的觸發，從Redis存儲系統中讀取灰度策略。另外，分流服務器設置有分流參數，分流參數用于指示灰度策略中各個版本的應用所在的Docker應用容器的地址。仍以上述表1及圖2為例，主版本Version_Quanguo發布在Docker應用容器1上，則主版本Version_Quanguo對應的分流參數1表示Docker應用容器1的地址；測試版本Version_Haidian發布在Docker應用容器2上，則測試版本Version_Haidian對應的分流參數2表示Docker應用容器2的地址。Docker應用容器是容器構建服務器構建的，容器構建服務器可以記錄Docker應用容器的地址，因此，分流服務器上的分流參數可以是容器構建服務器修改的。可見，分流服務器依據灰度策略及分流參數實現對用戶訪問請求的分流。具體地分流流程可以參見下文的基于灰度策略的應用訪問方法。與現有的應用灰度發布系統相比，本申請提供的應用灰度發布系統中，使用了Redis存儲系統替代原有的配置數據庫，將灰度策略保存為鍵值對形式，灰度發布更加快速，且基于該種形式灰度策略的分流流程更加高效。另外，本申請采用Docker技術來作為多版本的應用容器引擎，構建的Docker應用容器代替物理服務器，更加節省資源。另外，基于以上應用灰度發布系統，本申請還提供了一種應用灰度發布方法。見圖3，其示出了該應用灰度發布方法的流程，具體包括以下步驟。S31：容器構建服務器輪詢Redis存儲系統，以監測灰度策略是否發生變化。其中，若應用發布新的版本，則策略管理員可以為該版本的應用配置相應的用戶。例如，主版本Version_Quanguo為原有版本的應用，在主版本的基礎上，若新增測試版本Version_Haidian，則策略管理員為測試版本Version_Haidian配置的是北京海淀區的用戶，為主版本Version_Quanguo配置的是除海淀區之外的其他位置的用戶。以上配置信息以鍵值對形式保存在Redis存儲系統中，該鍵值對可以稱為灰度策略。S32：若監測到灰度策略中新增某版本的應用，則容器構建服務器在物理服務器上構建Docker應用容器。S33：Docker應用容器發布該某版本的應用。S34：容器構建服務器向分流服務器發送觸發指令。S35：分流服務器接收到觸發指令后，從Redis存儲系統中讀取灰度策略。S36：容器構建服務器修改分流服務器中該灰度策略對應的分流參數，分流參數指示的是該Docker應用容器的地址。其中，若容器構建服務器并未成功修改分流服務器中該灰度策略對應的分流參數，則注銷所構建的Docker應用容器。以上流程的其他說明可以參見關應用灰度發布系統的說明。應用灰度發布后，分流服務器可以根據分流參數及灰度策略，對用戶發送的訪問請求進行分流。參見圖4，基于灰度策略的應用訪問方法的流程包括以下步驟。S41：分流服務器接收到用戶請求后，從用戶請求中提取用戶信息。其中，提取的用戶信息是根據灰度策略中的“鍵”內容來決定的。例如，鍵內容為用戶的位置信息，則可以提取用戶請求中的IP地址，根據IP地址確定用戶的位置信息。S42：分流服務器根據灰度策略，確定用戶信息所對應的目標版本應用。其中，灰度策略表示為鍵值的對應關系，從各個鍵中，查找表示所述用戶信息的鍵，進而確定該鍵對應的值，將該值表示的某版本的應用確定為目標版本應用。S43：分流服務器根據分流參數，查找目標版本應用的地址，該地址表示目標版本應用發布在哪個Docker應用容器上。S44：分流服務器將用戶請求轉發到目標版本應用的地址指示的Docker應用容器上，以使該用戶請求訪問該目標版本應用。假設分流服務器讀取到的灰度策略如上述表1所示，北京海淀區的用戶訪問測試版本Version_Haidian，其他地區的用戶訪問主版本Version_Quanguo。并且，主版本Version_Quanguo發布在Docker應用容器1上，測試版本Version_Haidian發布在Docker應用容器2上。如圖5所示，分流服務器接收到用戶A的請求后，判斷用戶A的位置信息為OTHER，即海淀區以外，則分流服務器將用戶A的請求轉發至Docker應用容器1；若分流服務器接收到用戶B的請求后，判斷用戶B的位置信息為HAIDIAN，則分流服務器將用戶B的請求轉發至Docker應用容器2。本申請還提供了一種分流服務器，包括處理器和存儲器，所述處理器通過運行存儲在所述存儲器內的軟件程序、調用存儲在所述存儲器內的數據，至少執行圖4中的S41-S44部分。需要說明的是，本說明書中的各個實施例均采用遞進的方式描述，每個實施例重點說明的都是與其他實施例的不同之處，各個實施例之間相同相似的部分互相參見即可。還需要說明的是，在本文中，諸如第一和第二等之類的關系術語僅僅用來將一個實體或者操作與另一個實體或操作區分開來，而不一定要求或者暗示這些實體或操作之間存在任何這種實際的關系或者順序。而且，術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括上述要素的過程、方法、物品或者設備中還存在另外的相同要素。對所公開的實施例的上述說明，使本領域專業技術人員能夠實現或使用本申請。對這些實施例的多種修改對本領域的專業技術人員來說將是顯而易見的，本文中所定義的一般原理可以在不脫離本申請的精神或范圍的情況下，在其它實施例中實現。因此，本申請將不會被限制于本文所示的這些實施例，而是要符合與本文所公開的原理和新穎特點相一致的最寬的范圍。當前第1頁1 2 3