基于大數據分析的Service應用的設備升級方法

孟秀錦　冉九紅　婁新燕

關鍵詞：Service 應用；應用升級；服務器；智能終端設備；預置應用；大數據

中圖分類號：TP311 文獻標識碼：A

文章編號：1009-3044（2023）10-0078-03

0 引言

隨著智能設備的普及，智能設備中預設的應用也越來越多，但是由于多種多樣的問題，比如：網絡問題、硬件問題、軟件問題等等導致部分應用無法升級到高版本的應用，導致用戶無法正常使用新版本的新功能，特別是涉及用戶支付、用戶賬號由于低版本的應用導致用戶數據不一致、無法支付等問題，對用戶帶來極大的不便利，用戶體驗也較差。目前主流的技術是修改底層的架構并且修改增加新的API（應用程序編程入口）來實現無法升級的應用的升級方式[1]，該做法改動較大，成本高并且涉及物理改動，影響用戶體驗。本方案可以通過大數據分析不同平臺、不同系統方案等導致的系統應用無法升級的預置應用（或者稱為系統應用），在不修改底層邏輯，且已有的Service 應用（后臺運行的應用并且該應用能夠開機自動啟動）上增加兩個請求的方式來實現應用升級的方式，改動小且不會對現有的數據造成破壞，安全性更好[2]。

1 實現原理

1.1 前期準備

本方案采用的是客戶端-服務器模式（人員與它們交互，以將請求發送到計算機服務器），通過將請求轉發到服務器端進行處理，提高網絡的并發性和處理速度，能夠更好地提高用戶體驗。

1）大數據分析準備工作

采用hadoop-zookeeper-kafka大數據分析系統對所有在線機型（連接到互聯網上的活躍的機型）的設備上運行的系統應用（也可以稱為預置應用）的版本升級情況，對于一個升級周期之后（一般是一個月），對于系統應用無法升級的應用對其分析是否存在升級問題，如果存在升級問題無法正常升級的應用，通過配置Service應用升級策略。

使用hadoop 集群具有高可靠性，而zookeeper 是一個開源的分布式應用程序協調服務，可以用來保證數據在集群間事務上的一致性；kafka主要用于實現低延遲發送和收集大量的事件和日志數據——這些數據通常都是活躍數據；主要通過日志的形式記錄下來這些數據信息，然后通過專門的系統來進行日志的收集與統計；kafka中存在消息生產者、消息消費者、主題、消息分區、Broker、消費者分組、Offset（ 偏移量）[3-4]。

消息生產者：消息產生的源頭、負責生成消息并發送到kafka服務器上。

消息消費者：是消息的使用方，負責消費kafka服務器上的消息。

主題：由用戶定義并配置在kafka服務器上，用于建立生產者和消費者之間的訂閱關系，生產者發送消息到指定的主題下，消費者從這個主題下消費消息。

消息分區：一個主題下會分為多個分區，消息分區機制和分區的數量與消費者的負載均衡機制有很大的關系。

Broker：kafka服務器，主要用于存儲消息，在消息中間件中通常被稱為broker。

消費者分組：用于歸組同類消費者，在kafka中，多個消費者可以共同消費一個topic下的消息，每個消費者消費其中的部分消息，這些消費者就組成了一個分組，擁有同一個分組的名稱，通常也稱為消費者集群。

Offset：消息存儲在kafka的broker上，消費者拉取消息數據的過程中需要知道消息在文本中的偏移量。

2）負載均衡

消費者如何實現負載均衡：設置PT為指定Topic所有的消息分區。

設置CG為同一個消費者分組中的所有消費者。

對PT進行排序，使分布在同一個Broker服務器上的分區盡量靠在一起。

對CG進行排序： 設置i為Ci在CG中位置的索引值，同時設置N =size（PT）/size（CG）。

將編號為i × ＼times× N ～ （i + 1） × ＼times× N – 1 的消息分區分配給消費者Ci。

重新更新ZooKeeper 上消息分區與消費者Ci 的關系。

3）日志的配置

獲取升級日志的配置方式：

Config配置

Log_server的config文件可在hitv.conf中配置，安裝后默認存儲在/usr/local/fountain/conf目錄，文件名為logconfig.info。

典型配置結構如下：

upgrade

{

msgid 23

filetag adeviewlog ; filename， if RT log，

means RT Queue Name.

max_file_size 10 ;Unit：M

rt 0 ;0：not RT ;1：RT

suffix_processor 0 ; 0： Normal; 1： Fill Cur?rent Time at Msg tail.

main_processor solve_common_log

rt_processor NULL

protocol 1;1：udp;2：tcp

init_processor 1 ; 1： initialize_log_file; 2： initial?ize_exception_log

}

zookeeper下的conf：

～/zookeeper-3.3.3/conf/zoo_sample.cfg

zoo.cfg的配置：

dataDir=/home/hadoop_server/zookeeper/data ——指向數據位置

dataLogDir=/home/hadoop_server/zookeeper/data ?Log ——指向數據日志位置

通過前面三步的配置和日志的分析獲取，可以取得智能終端的預置應用的版本號和所在平臺的相關信息[5]。

1.2 預置應用的升級

預置應用升級的具體步驟如下：

1）通過前述步驟獲取無法升級的智能終端無法升級的預置應用的列表，運營后臺根據設備類型和設備型號配置待升級的應用列表之后存儲到數據庫中；并配置對應應用的升級版本（源版本、目的版本、升級包、升級方式）。

2）智能設備開機之后，首先根據應用的appkey公鑰、appsecret私鑰（客戶端和服務器端事先約定好）、用戶名和密碼，向服務器端獲取認證鑒權所需的to?ken（用于請求的驗證）信息。

3）智能終端攜帶第二步獲取的token信息發送獲取待升級的應用列表請求。

4）服務器端根據攜帶的token的信息對智能終端設備和應用進行鑒權認證。

5）認證通過之后，服務器根據終端設備的設備類型查詢數據庫中對應的應用升級列表。

6）智能終端設備根據獲取到的應用列表，將本地的應用版本號和系統下發的應用版本號進行對比。

7）本地的應用版本號與系統下發的應用版本號是否一致，一致則保持不變，如果低于系統下發的應用版本號，則通過自啟動的Service應用發送升級請求，該HTTP請求中包含應用當前版本的信息（包括當前版本號、appkey公鑰、appsecret私鑰、應用包名等）。

8）服務器收到該請求之后，對比數據庫中的信息，根據數據庫中配置的升級策略，通過業務服務器下發對應的目的版本、升級包。

9）智能終端設備根據獲取升級包執行升級流程，首先獲取升級包在文件服務器中的地址，然后通過后臺下載，下載完成之后，將無法升級的應用包升級到更高版本。

該方案具體實現流程為：

智能設備開機之后通過部署的大數據系統分析集群，上報本地已經安裝的應用列表，服務器通過和數據庫中的設備表進行對比，對獲取到的應用進行分析（與對應機型根據機型的唯一標識進行識別的最高版本）。

查詢對應的數據庫（取出部分關鍵信息）：

根據查詢到的數據下發該機型對應的升級列表。

對比終端的應用版本，相同則不做升級請求的處理，不相同則發送升級請求。

系統端通過服務器下發該升級請求對應的升級版本目的版本以及應用的下載路徑。

升級完成之后，系統端對升級成功的應用進行標識，對于升級成功的設備從數據庫和緩存中進行刪除。

2 總結

通過大數據系統分析預置應用的版本和平臺信息，分析現在運行的應用軟件的信息，通過在服務器端進行對比，能夠檢測出是否升級成功的信息，對于無法正常升級的應用（對于復雜的網絡環境、終端設備兼容性等原因，導致已經預置的系統應用無法更新安裝），業內主要采用修改底層設備和邏輯來實現應用的升級，對于這種方式修改的范圍比較大，成本比較高，出現風險的可能性也比較高，并且用戶的接受度也比較低，通過系統攜帶的Service應用，通過后臺應用更新對于用戶來說是透明的，不需要用戶做任何操作，對用戶來說接受度比較高，而且安全性也有保障，用戶的數據信息不會發生變化和泄露，可以無感對接。

通過該方法可以使無法升級的固有應用能夠正常升級，解決特別是老舊平臺以及歷史遺留的一些問題。