基于大數(shù)據(jù)分析的Service應(yīng)用的設(shè)備升級方法

孟秀錦　冉九紅　婁新燕

關(guān)鍵詞：Service 應(yīng)用；應(yīng)用升級；服務(wù)器；智能終端設(shè)備；預(yù)置應(yīng)用；大數(shù)據(jù)

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

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

0 引言

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

1 實現(xiàn)原理

1.1 前期準備

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

1）大數(shù)據(jù)分析準備工作

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

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

消息生產(chǎn)者：消息產(chǎn)生的源頭、負責(zé)生成消息并發(fā)送到kafka服務(wù)器上。

消息消費者：是消息的使用方，負責(zé)消費kafka服務(wù)器上的消息。

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

消息分區(qū)：一個主題下會分為多個分區(qū)，消息分區(qū)機制和分區(qū)的數(shù)量與消費者的負載均衡機制有很大的關(guān)系。

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

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

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

2）負載均衡

消費者如何實現(xiàn)負載均衡：設(shè)置PT為指定Topic所有的消息分區(qū)。

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

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

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

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

重新更新ZooKeeper 上消息分區(qū)與消費者Ci 的關(guān)系。

3）日志的配置

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

Config配置

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

典型配置結(jié)構(gòu)如下：

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 ——指向數(shù)據(jù)位置

dataLogDir=/home/hadoop_server/zookeeper/data ?Log ——指向數(shù)據(jù)日志位置

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

1.2 預(yù)置應(yīng)用的升級

預(yù)置應(yīng)用升級的具體步驟如下：

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

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

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

4）服務(wù)器端根據(jù)攜帶的token的信息對智能終端設(shè)備和應(yīng)用進行鑒權(quán)認證。

5）認證通過之后，服務(wù)器根據(jù)終端設(shè)備的設(shè)備類型查詢數(shù)據(jù)庫中對應(yīng)的應(yīng)用升級列表。

6）智能終端設(shè)備根據(jù)獲取到的應(yīng)用列表，將本地的應(yīng)用版本號和系統(tǒng)下發(fā)的應(yīng)用版本號進行對比。

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

8）服務(wù)器收到該請求之后，對比數(shù)據(jù)庫中的信息，根據(jù)數(shù)據(jù)庫中配置的升級策略，通過業(yè)務(wù)服務(wù)器下發(fā)對應(yīng)的目的版本、升級包。

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

該方案具體實現(xiàn)流程為：

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

查詢對應(yīng)的數(shù)據(jù)庫（取出部分關(guān)鍵信息）：

根據(jù)查詢到的數(shù)據(jù)下發(fā)該機型對應(yīng)的升級列表。

對比終端的應(yīng)用版本，相同則不做升級請求的處理，不相同則發(fā)送升級請求。

系統(tǒng)端通過服務(wù)器下發(fā)該升級請求對應(yīng)的升級版本目的版本以及應(yīng)用的下載路徑。

升級完成之后，系統(tǒng)端對升級成功的應(yīng)用進行標識，對于升級成功的設(shè)備從數(shù)據(jù)庫和緩存中進行刪除。

2 總結(jié)

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

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