[發明專利]服務上線自檢方法、裝置、設備及存儲介質

在審

• 申請號: 202011573351.3
• 申請日: 2020-12-25
• 公開（公告）號: CN112579397A
• 公開（公告）日: 2021-03-30
• 發明（設計）人: 李兵
• 申請（專利權）人: 京東數字科技控股股份有限公司
• 主分類號: G06F11/30
• 分類號: G06F11/30;G06F11/34;G06F11/36
• 代理公司: 北京華夏泰和知識產權代理有限公司 11662
• 代理人: 劉蔓莉;李雪

本申請涉及一種服務上線自檢方法、裝置、設備及存儲介質，所述方法包括：本申請的技術方案首先獲取每個實例中運行的目標服務的運行參數，并確定每個實例的存活狀態，然后判斷每個實例的存活狀態和每個實例中運行的目標服務的運行參數是否滿足預設條件，若滿足，就將實例中當前運行的目標服務對應的服務包存儲到預設文件系統中，若不滿足，就從預設文件系統中獲取前次版本的目標服務對應的目標服務包，以利用目標服務包使每個實例中的目標服務回滾到前次版本。如此，服務上線的整個過程便可以實現自檢，大大減小了對人工的依賴，克服相關技術中存在的人工對服務上線過程進行檢查的效率低下且漏檢幾率較大問題。

技術領域

本申請涉及服務上線技術領域，尤其涉及一種服務上線自檢方法、裝置、設備及存儲介質。

背景技術

現有的微服務架構下，服務上線的過程一般是開發者將服務的底層代碼提交至GitLab，然后Jenkins從GitLab中拉取開發者提交的底層代碼，根據底層代碼對服務進行構建，然后部署到相應的實例中。

為了保證服務部署到實例之后，具有較高的穩定性，相關技術中，負責服務上線的開發人員會手動檢查服務在各個實例中是否正常運行、各實例中運行的服務的版本是否一致，還會在服務上線后，服務的調用量、性能等進行檢查，由于實例的數量較多，這種情況下，由人工對服務上線過程進行檢查的效率低下，延長服務上線的過程所消耗的時間，而且人工漏檢的幾率較大，服務上線后，漏檢可能會對服務運行的穩定性造成影響。

發明內容

為克服相關技術中存在的人工對服務上線過程進行檢查的效率低下且漏檢幾率較大問題，本申請提供一種服務上線自檢方法、裝置、設備及存儲介質。

根據本申請的第一方面，提供一種服務上線自檢方法，包括：

獲取每個實例中運行的目標服務的運行參數，并確定每個所述實例的存活狀態；

判斷每個實例的存活狀態和每個實例中運行的目標服務的運行參數是否滿足預設條件；

若滿足，將所述實例中當前運行的所述目標服務對應的服務包存儲到預設文件系統中；

若不滿足，從所述預設文件系統中獲取前次版本的所述目標服務對應的目標服務包，以利用所述目標服務包使每個實例中的目標服務回滾到所述前次版本。

在一個可選的實施例中，所述確定所述實例的存活狀態，包括

向所述實例發送請求報文并啟動定時器；

若在定時器定時到預設時間段之內，接收到所述實例根據所述請求報文返回的數據，確定所述實例的存活狀態為存活；

若在定時器定時到預設時間段之內，未接收到所述實例根據所述請求報文返回的數據，確定所述實例的存活狀態為非存活。

在一個可選的實施例中，所述運行參數包括所述目標服務的運行日志、所述目標服務的版本號以及所述目標服務的運行狀態參數；

所述判斷每個實例的存活狀態和每個實例中運行的目標服務的運行參數是否滿足預設條件，包括：

判斷每個實例的所述存活狀態和每個實例運行的所述目標服務的所述運行日志是否滿足第一預設子條件，得到第一判斷結果；

判斷每個實例運行的所述目標服務的版本號是否滿足第二預設子條件，得到第二判斷結果；

判斷所述目標服務的運行狀態參數是否滿足第三預設子條件，得到第三判斷結果；

若所述第一判斷結果、所述第二判斷結果和所述第三判斷結果均為滿足，則判斷每個實例的存活狀態和每個實例中運行的目標服務的運行參數滿足預設條件；