本發(fā)明涉及基于微服務的灰度發(fā)布方法。

背景技術：

目前，許多企業(yè)都有服務器集群，服務器集群由大量業(yè)務服務器組成，為用戶提供服務。但很多服務器集群的架構還是基于傳統(tǒng)的MVC層級關系，一個服務一般包含了許多個業(yè)務模塊，產生了較多的業(yè)務耦合，因而在部署方面也存在一定的耦合風險。例如，需要更新某個服務中的A模塊的業(yè)務，但由于A模塊在該服務中無法分離，難以避免的會部署全部服務，導致為了更新小功能不得不更新其所在服務的全部功能，易造成部署風險。此外，部署服務的過程，盡管已經有了灰度發(fā)布(灰度發(fā)布是指在黑與白之間、能夠平滑過渡的一種發(fā)布方式。例如AB測試就是一種灰度發(fā)布，讓一部分用戶繼續(xù)用A，一部分用戶開始用B，如果用戶對B沒有什么反對意見，那么逐步擴大范圍，把所有用戶都遷移到B上面來?；叶劝l(fā)布可以保證整體系統(tǒng)的穩(wěn)定，在發(fā)布開始的時候就可以發(fā)現(xiàn)、調整問題，問題的影響范圍有限。)，但現(xiàn)有的灰度發(fā)布方法在發(fā)布后的回滾和監(jiān)控方面存在缺陷，無法非常細力度、多維度的部署需要更新的服務，也無法快速得知部署后的實際運行情況。

在說明書“背景技術”部分公開的內容，有助于本領域技術人員理解本發(fā)明的技術方案，但不應據此認為這些內容一定屬于現(xiàn)有技術或公知常識。

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

為了克服“背景技術”部分所反映的缺陷，本發(fā)明提供基于微服務的灰度發(fā)布方法。

基于微服務的灰度發(fā)布方法，包括：

反向代理服務器獲取原始發(fā)布請求中的維度參數；

反向代理服務器調用存儲了灰度發(fā)布策略的存儲器，將維度參數和灰度發(fā)布策略匹配，確定原始發(fā)布請求對應的微服務業(yè)務服務器；

反向代理服務器向對應的微服務業(yè)務服務器發(fā)布原始發(fā)布請求；

灰度發(fā)布過程中進行實時數據分析，根據分析結果采取后續(xù)策略。

進一步的，維度參數包括渠道號、客戶端版本、請求網關的業(yè)務方法、客戶端業(yè)務來源。

進一步的，不同的微服務相互獨立、互不干擾。

進一步的，微服務能夠進行負載均衡的集群部署。

進一步的，后續(xù)策略包括回滾或者進一步擴大發(fā)布范圍。

更進一步的，如果后續(xù)策略為回滾，則對灰度發(fā)布過程中產生的數據進行數據遷移。

更進一步的，如果灰度發(fā)布過程中產生的數據存在數據變更，則單獨保存歷史數據。

本發(fā)明技術方案中，“包括”、“用于”等詞語應按照開放式表達方式理解。本領域技術人員通過閱讀本說明書并結合現(xiàn)有技術或公知常識能夠獲知的內容，本說明書中不再贅述。

本發(fā)明提供的基于微服務的灰度發(fā)布方法，在基于微服務思想的服務器架構設計下，采取小流量更新的部署方式，并根據實時數據分析結果決定后續(xù)采取的策略。該方法有效降低了發(fā)布風險，可以把發(fā)布中產生的問題限制在可控范圍內。

附圖說明

圖1為具體實施方式中實現(xiàn)基于微服務的灰度發(fā)布方法的部件架構的簡化示意圖。

圖2為具體實施方式中基于微服務的灰度發(fā)布方法的流程圖。

具體實施方式

下面對本發(fā)明的實施方式進行進一步的具體說明。但應注意，本發(fā)明的范圍并不局限于所描述的具體技術方案。任何對所描述的具體技術方案中的技術要素進行相同或等同替換獲得的技術方案或本領域技術人員在所描述的具體技術方案的基礎上不經過創(chuàng)造性勞動就可以獲得的技術方案，都應當視為落入本發(fā)明的保護范圍。

實現(xiàn)本發(fā)明技術方案，首先需要進行基礎工作，對現(xiàn)有業(yè)務的業(yè)務層次和模塊進行分析，將其中相對獨立的業(yè)務部分和非常重要的業(yè)務部分拆分出來，把這些業(yè)務部分劃分成一個個的子服務，此即為微服務。微服務的特點是不同的微服務相互獨立、互不干擾。將現(xiàn)有業(yè)務拆分為微服務，實質上是通過比較細力度的業(yè)務分析，把傳統(tǒng)的服務器架構轉變?yōu)樗神詈系奈⒎占軜嫞瑥亩鴮崿F(xiàn)業(yè)務的解耦。

例如，現(xiàn)有的業(yè)務中存在發(fā)送短信的模塊，則可以將該業(yè)務拆分為注冊業(yè)務微服務和短信發(fā)送微服務，兩個微服務部署在不同的業(yè)務服務器，形成注冊業(yè)務微服務的業(yè)務服務器集群和短信發(fā)送微服務的業(yè)務服務器集群。同時設置消息隊列集群，利用消息中間件(例如KAFKA，一種高吞吐量的開源分布式發(fā)布訂閱消息系統(tǒng)。)在不同的微服務集群之間推送消息。來自客戶端的原始請求首先由注冊業(yè)務微服務進行處理，注冊業(yè)務微服務發(fā)現(xiàn)原始請求中包括向指定用戶發(fā)送短信的請求時，通過消息中間件推送消息到短信發(fā)送微服務，短信發(fā)送微服務收到消息后，發(fā)送短信到指定的用戶，如果出現(xiàn)發(fā)送失敗，可以通過重試等策略在短信發(fā)送微服務的內部進行調整。這樣注冊業(yè)務微服務和短信發(fā)送微服務就實現(xiàn)了解耦，兩個微服務相互獨立，互不干擾。

如上所述，將現(xiàn)有業(yè)務拆分為微服務后，每個微服務都要部署到多個業(yè)務服務器上，形成微服務業(yè)務服務器集群。為了保證微服務的穩(wěn)定性和可擴展性，要求微服務能夠進行負載均衡的集群部署。反向代理服務器NGINX能夠實現(xiàn)負載均衡配置。而將負載均衡配置自動化部署到相應的業(yè)務服務器上，可以利用開源的自動化持續(xù)集成工具jenkins和相應的shell腳本實現(xiàn)，業(yè)務服務器可以根據其IP地址進行識別。

本發(fā)明技術方案“基于微服務的灰度發(fā)布方法”的實現(xiàn)需要基于一定的部件架構，圖1為部件架構的簡化示意圖。一般客戶端處于因特網(internet)，而業(yè)務服務器處于內部的局域網，因此客戶端和業(yè)務服務器之間需要通過反向代理服務器通信。多個部署了微服務的業(yè)務服務器組成微服務業(yè)務服務器集群。為了簡化顯示，圖1中的客戶端、反向代理服務器和存儲器只畫了一個，而實際中它們的數量往往非常多。圖1中的微服務業(yè)務服務器集群只畫了兩個，每個微服務業(yè)務服務器集群中只有兩個業(yè)務服務器，實際中微服務業(yè)務服務器集群和每個集群中業(yè)務服務器的數量也遠遠多于此。圖1中的連線代表通信關系。

基于微服務的灰度發(fā)布方法，其流程如圖2所示，包括：

S201：反向代理服務器獲取原始發(fā)布請求中的維度參數。

具體的，本步驟中，客戶端向反向代理服務器發(fā)送原始發(fā)布請求，原始發(fā)布請求中包括了維度參數。維度參數用于標記客戶端的多樣性，使得客戶端和服務器端有更多溝通上的區(qū)分度。常見的維度參數包括渠道號、客戶端版本、請求網關的業(yè)務方法、客戶端業(yè)務來源。渠道號(CHANNEL)反映了客戶端所處的市場渠道。客戶端版本(VERSION)反映了客戶端軟件的版本號信息。請求網關的業(yè)務方法(METHOD)為請求的接口方法名稱，例如登錄(login)、注冊(register)等。客戶端業(yè)務來源(REQUEST_SOURCE_INDEX)為約定的標記值，用于區(qū)分每個業(yè)務的來源。此外，維度參數還可以包括客戶端的IP地址、客戶端的UA(用戶代理，User-Agent)等。渠道號、客戶端版本、請求網關的業(yè)務方法、客戶端業(yè)務來源等維度參數可以設置在客戶端原始發(fā)布請求的代碼中，作為原始發(fā)布請求的規(guī)定參數。

原始發(fā)布請求中的維度參數能夠被反向代理服務器以get/post方式(get用來從服務器上獲得數據，post用來向服務器上傳遞數據)獲取。反向代理服務器可以選用NGINX，NGINX是一款高性能、輕量級的反向代理服務器，LUA語言(一個小巧的腳本語言)能夠嵌入到NGINX的配置中，形成功能強大的NGINX-LUA模塊。

S202：反向代理服務器調用存儲了灰度發(fā)布策略的存儲器，將維度參數和灰度發(fā)布策略匹配，確定原始發(fā)布請求對應的微服務業(yè)務服務器。

具體的，本步驟中，存儲器中事先存儲了灰度發(fā)布的發(fā)布策略，發(fā)布策略中包括了維度參數和相對應的微服務業(yè)務服務器的IP地址。這樣，反向代理服務器調用存儲器，將獲取到的原始發(fā)布請求中的維度參數和灰度發(fā)布策略相匹配，就可以知道原始發(fā)布請求對應的是哪一個或哪些微服務業(yè)務服務器。

儲存器可以選用REDIS緩存。REDIS緩存是一個開源的使用ANSIC語言編寫、支持網絡、可基于內存亦可持久化的日志型、Key-Value數據庫，并提供多種語言的API。REDIS緩存支持Master-Slave方式的數據備份。

下面通過一個簡單的理想化示例進一步說明步驟S202的工作原理?？蛻舳说脑及l(fā)布請求中包括CHANNEL和VERSION兩個維度參數。REDIS緩存中存儲了如下灰度發(fā)布策略：如果VERSION是1.0-BETA版本且CHANNEL是inner-test(內部測試)，則向IP地址為192.168.0.1:8080的業(yè)務服務器發(fā)布，否則向IP地址為192.168.0.2:8080的業(yè)務服務器發(fā)布。NGINX獲取到原始發(fā)布請求中的CHANNEL和VERSION參數后，調用REDIS緩存，將CHANNEL和VERSION參數與REDIS緩存中的灰度發(fā)布策略進行匹配，就可以知道如果VERSION是1.0-BETA且CHANNEL是inner-test，則將原始發(fā)布請求向IP地址為192.168.0.1:8080的業(yè)務服務器發(fā)布，如果VERSION不是1.0-BETA或者CHANNEL不是inner-test，則原始發(fā)布請求向IP地址為192.168.0.2:8080的業(yè)務服務器發(fā)布。

S203：反向代理服務器向對應的微服務業(yè)務服務器發(fā)布原始發(fā)布請求。

具體的，本步驟中，反向代理服務器根據步驟S202中獲知的微服務業(yè)務服務器IP地址等信息，將原始發(fā)布請求發(fā)布到相對應的一個或多個微服務業(yè)務服務器上。

S204：灰度發(fā)布過程中進行實時數據分析，根據分析結果采取后續(xù)策略。

具體的，步驟S203完成，就意味著灰度發(fā)布過程已經開始。本步驟中，實時數據分析模塊(可以采用KAFKA+SPARK，SPARK由美國加州大學伯克利分校的AMP實驗室開發(fā)，是進行大數據快速處理的通用引擎。)在灰度發(fā)布過程中對發(fā)布產生的日志數據進行實時分析并入庫，這樣負責管理灰度發(fā)布的專業(yè)人員可以實時監(jiān)控日志和報表數據的變化，根據數據分析結果決定采取何種后續(xù)策略。常見的后續(xù)策略包括回滾或者進一步擴大發(fā)布范圍。

回滾一般意味著發(fā)布失敗，已經發(fā)布了原始發(fā)布請求的業(yè)務服務器退回發(fā)布前的狀態(tài)。如果后續(xù)策略為回滾，則對灰度發(fā)布過程中產生的數據進行數據遷移，在指定的設備上保存而不是丟棄相關數據。此外，如果灰度發(fā)布過程中產生的數據存在數據變更，則單獨保存變更前的歷史數據。由于灰度發(fā)布過程中產生的數據可能是業(yè)務服務器的用戶所需要的，這樣可以確保這些數據不會有任何損失或破壞，用戶不僅可以在需要時恢復數據，還可以恢復歷史數據。

進一步擴大發(fā)布范圍一般意味著初步發(fā)布成功，最終在所有相關的微服務業(yè)務服務器上發(fā)布了原始發(fā)布請求后，灰度發(fā)布過程結束。

本發(fā)明技術方案，將微服務松耦合、易擴展的優(yōu)勢與灰度發(fā)布低風險的優(yōu)勢進行了有效結合，進一步降低了灰度發(fā)布的風險。同時，在灰度發(fā)布過程中對日志等數據進行實時分析，根據分析結果采取后續(xù)策略，實現(xiàn)了后續(xù)策略的科學決策。即使發(fā)布失敗需要回滾，由于不同的微服務之間相互獨立、互不干擾，回滾只在特定的微服務業(yè)務服務器上進行，不涉及其他業(yè)務服務器，對整體業(yè)務服務器集群的影響非常小，把灰度發(fā)布中產生的問題限制在了可控范圍內。

本領域技術人員在以上所描述的具體技術方案的基礎上，完全可以構造出其他方案。例如，反向代理服務器采用NGINX之外的其他反向代理服務器。在此不一一列舉。