（中國移動通信集團(tuán)福建有限公司泉州分公司，泉州 362000）

企業(yè)IT架構(gòu)移動化遷移方案的研究

王瑞斌

（中國移動通信集團(tuán)福建有限公司泉州分公司，泉州 362000）

企業(yè)的IT系統(tǒng)從傳統(tǒng)Web架構(gòu)向移動App架構(gòu)遷移是近幾年的一個重要的趨勢。在實際的遷移過程中，需要結(jié)合現(xiàn)有的網(wǎng)絡(luò)拓?fù)洵h(huán)境以及IT系統(tǒng)的相關(guān)情況，去構(gòu)思一個能夠承上啟下，穩(wěn)中求變的新IT架構(gòu)。同時又要兼顧安全、性能、可擴(kuò)展、運維等方面的需求。新的IT架構(gòu)結(jié)合移動App特點從用戶通行證、WebAPI統(tǒng)一門戶、App生命周期管3個維度出發(fā)，形成了用戶池、App應(yīng)用池、接口能力池、分析數(shù)據(jù)池四大資源池，從而實現(xiàn)了用戶數(shù)據(jù)，生產(chǎn)數(shù)據(jù)，分析數(shù)據(jù)和日志數(shù)據(jù)的各自分流，降低了移動App開發(fā)和運維成本，提升了開發(fā)效率。

IT架構(gòu)；API管理；移動化；App

企業(yè)的IT系統(tǒng)從傳統(tǒng)Web架構(gòu)向移動App架構(gòu)遷移是近幾年企業(yè)IT支撐方面一個重要的趨勢。企業(yè)IT系統(tǒng)移動App化為企業(yè)用戶帶來便利和競爭力的同時，也為企業(yè)的IT架構(gòu)帶來了新的挑戰(zhàn)。由于移動App的開發(fā)比例急劇增加，且移動App完全不同的開發(fā)和使用特性，使得舊有的IT架構(gòu)和運維體系都顯得捉襟見肘。因此，必須結(jié)合企業(yè)自身的網(wǎng)絡(luò)拓?fù)洵h(huán)境以及已有的IT系統(tǒng)的相關(guān)情況，去構(gòu)思一個能夠承上啟下，穩(wěn)中求變的新IT架構(gòu)。同時這個IT架構(gòu)必須兼顧安全、性能、可擴(kuò)展、運維等幾方面的需求。本研究提出的移動應(yīng)用開發(fā)支撐平臺有效地解決了這一難題。

1 歷史制約與遷移的思路

新IT架構(gòu)的遷移方案必須從網(wǎng)絡(luò)結(jié)構(gòu)及其安全要求，以及企業(yè)內(nèi)網(wǎng)IT系統(tǒng)的平滑銜接這兩個主要的歷史制約因素為出發(fā)點進(jìn)行考慮。

以往的IT系統(tǒng)相對比較分散，網(wǎng)絡(luò)結(jié)構(gòu)也比較多樣，可能有開放到公網(wǎng)中，也可能皆是內(nèi)網(wǎng)應(yīng)用。而移動App的引入，需要打破這種相互的隔絕，同時需要兼顧整體系統(tǒng)的安全性，尤其是對接公網(wǎng)部分的安全性。因此，平臺引入了類似Layer 7和APIgee的企業(yè)WebAPI管理機(jī)制。移動App只能訪問部署在DMZ區(qū)的WebAPI統(tǒng)一門戶的虛擬WebAPI，WebAPI管理平臺經(jīng)過各層安全檢驗后，將訪問請求轉(zhuǎn)發(fā)給對應(yīng)的獨立業(yè)務(wù)系統(tǒng)的真實數(shù)據(jù)接口，從而使各業(yè)務(wù)系統(tǒng)保持了平滑擴(kuò)展的獨立性，同時也保證了權(quán)限和安全的可控性。

在解決歷史問題的同時，新的IT架構(gòu)從移動App特點出發(fā)對內(nèi)在的元素進(jìn)行重新組合，形成了用戶池、App應(yīng)用池、接口能力池、分析數(shù)據(jù)池等四大資源池。如圖1所示，從而實現(xiàn)了用戶數(shù)據(jù)、生產(chǎn)數(shù)據(jù)、分析數(shù)據(jù)和日志數(shù)據(jù)的各自分流。

圖1 App數(shù)據(jù)流向圖

2 移動化架構(gòu)的設(shè)計和實現(xiàn)

2.1 從賬號到通行證

由于移動App的私密性以及隨時在線的特點使得移動化IT架構(gòu)的身份認(rèn)證機(jī)制與原有的基于AD域的賬號體系有著較大的不同。基于這種不同，支撐平臺提出了基于硬件特征碼和手機(jī)號碼的移動互聯(lián)網(wǎng)通行證解決方案。其中，移動互聯(lián)網(wǎng)通行證主要特點如下。

（1） 通行證以終端設(shè)備的硬件特征碼（物理身份特征碼）和手機(jī)號碼（邏輯身份特征碼）的組合作為每個運行實例的唯一身份特征碼。由于一般手機(jī)都沒辦法獲取手機(jī)號，故在本體系中只能以IMSI代替。對于一些沒有IMSI卡的設(shè)備，如平板電腦等，則虛擬一個用戶識別號。

（2） 對于無需登錄用戶賬號的低安全要求的App，可通過身份特征碼獲知用戶的身份，同時識別同一用戶手中的不同設(shè)備終端。通過手機(jī)客戶端軟件與服務(wù)器配合，將手機(jī)身份特征碼引入驗證環(huán)節(jié)，解決手機(jī)上網(wǎng)后在IP層面鑒別其身份比較困難的問題。

（3） 對于高安全級別App需要用戶登錄相應(yīng)的賬號，但同一用戶的同一硬件（同一運行實例）下可以實現(xiàn)對同一賬號體系的共享登錄狀態(tài)，同時使用手勢密碼保障共享登錄不被非授權(quán)使用。手勢密碼采用數(shù)字化存儲，存儲方式為AuthToken的反碼和手勢密碼的數(shù)字值進(jìn)行DES加密，再使用SecretKey進(jìn)行再次加密。

（4） 每個App使用短期令牌AccessToken來通過WebAPI管理門戶的身份校驗。AccessToken短期令牌是用來表明每個App的實例對接口的訪問用戶身份標(biāo)識，但僅用于維持單次會話的身份驗證。AccessToken訪問周期開始時需要用長期令牌AuthToken從授權(quán)接口獲得。AuthToken在每個App第一次運行時產(chǎn)生，可以疊加該終端的身份特征碼以及已登陸賬號的相關(guān)權(quán)限，用來表明每個App的實例對接口的訪問用戶身份標(biāo)識。AuthToken無法直接使用，必須通過相應(yīng)的接口獲取相應(yīng)的AccessToken方能使用。

2.2 WebAPI統(tǒng)一門戶

WebAPI統(tǒng)一門戶是整個移動開發(fā)支撐平臺的核心。其以WebAPI訪問請求的代理路由轉(zhuǎn)發(fā)為核心，對安全機(jī)制和運維機(jī)制進(jìn)行深化擴(kuò)展。如圖2所示，WebAPI統(tǒng)一門戶的主要功能和技術(shù)特點如下。

圖2 WebAPI管理平臺運轉(zhuǎn)機(jī)制

（1） 三重驗證機(jī)制保障接口訪問安全：App簽名校驗，每個App均有獨有的ID和密鑰用以生成簽名，確保每個請求均有不同的簽名。數(shù)據(jù)訪問權(quán)限最小化設(shè)定，嚴(yán)格限制App對服務(wù)器的訪問權(quán)限，每個App只能訪問對其授權(quán)的接口，動態(tài)令牌授權(quán)校驗，根據(jù)AppID、用戶名、用戶密碼（MD5加密）到用戶授權(quán)服務(wù)器進(jìn)行驗證，生成包含用戶授權(quán)信息的長期令牌，使用長期令牌避免了客戶端保存賬號密碼，通過長期令牌換取短期令牌進(jìn)行訪問，避免令牌泄漏。

（2） 靈活的接口動態(tài)路由機(jī)制以及創(chuàng)新的AB鑰匙模式，讓開發(fā)環(huán)境平滑過渡到生產(chǎn)環(huán)境。每個App提供生產(chǎn)環(huán)境和開發(fā)環(huán)境兩套不同的鑰匙，在不同的AppID和密鑰下訪問同一個虛擬WebAPI可以被路由到不同的真實WebAPI，從而實現(xiàn)在同一套App代碼下正式生產(chǎn)環(huán)境和開發(fā)測試環(huán)境的隔離。

（3） 實時訪問監(jiān)測，快速數(shù)據(jù)審計預(yù)警及系統(tǒng)故障告警（日志機(jī)制），記錄API每次的訪問詳情包括時間、請求地址、返回數(shù)據(jù)等，設(shè)置每個App在一段時間對某個API的訪問請求次數(shù)做出限制，設(shè)置每個App在一段時間對某個API的訪問請求對某些參數(shù)出現(xiàn)的頻次進(jìn)行限制（例如短信接口對同一個手機(jī)號碼發(fā)送短信數(shù)量設(shè)限）。

（4） API資源池的共享：接入WebAPI統(tǒng)一門戶的各業(yè)務(wù)系統(tǒng)的API通過接口平臺授權(quán)都可以開放給不同的App使用，通過API共享解決了資源信息孤島問題，實現(xiàn)了松耦合的API的開發(fā)，具有層次清晰、維護(hù)方便的特點，降低了以后對平臺系統(tǒng)升級、改造的影響。

2.3 管理應(yīng)用的生命周期

和傳統(tǒng)Web系統(tǒng)的集中化部署的方式不同，每個App都運行在不同用戶的終端上，因此需要一個合理的機(jī)制對每個App的生命周期進(jìn)行管理和維護(hù)。主要內(nèi)容如下。

（1） 統(tǒng)一的發(fā)布平臺：所有客戶端皆按統(tǒng)一標(biāo)準(zhǔn)在此平臺發(fā)布，支持IOS和Andorid應(yīng)用發(fā)布，方便進(jìn)行客戶端應(yīng)用版本維護(hù)升級。

（2） App訪問密鑰管理：第一次發(fā)布的客戶端會自動創(chuàng)建密鑰，所有客戶端皆有兩對AppID和SecretKey，用于生產(chǎn)和開發(fā)訪問WebAPI統(tǒng)一門戶的訪問簽名。

（3） App的更新機(jī)制：提供版本更新檢測及下載的WebAPI接口和SDK，提供新版本提醒以及強(qiáng)制更新功能，方便客戶端進(jìn)行版本升級，讓用戶享受更加高效、平滑的升級體驗。

（4） App的運營數(shù)據(jù)采集：提供標(biāo)準(zhǔn)化的用戶反饋功能、以及自定義事件采集功能的WebAPI和SDK。通過標(biāo)準(zhǔn)化反饋功能實現(xiàn)和用戶輕松高效溝通，收集用戶建議，了解用戶需求，解決用戶問題，服務(wù)端的反饋管理功能可管理所有用戶的反饋，不錯過任何用戶的聲音。自定義事件采集功能，通過后臺配置能夠適應(yīng)各個App數(shù)據(jù)的采集，采集回來的數(shù)據(jù)方便分析用戶行為，利用數(shù)據(jù)進(jìn)行產(chǎn)品、運營、推廣策略的決策。

3 應(yīng)用實例

目前移動應(yīng)用開發(fā)支撐平臺已成功應(yīng)用于中國移動通信集團(tuán)福建有限公司泉州分公司，該平臺有效地支撐了泉州公司的App開發(fā)，其中不乏精品項目，如泉州移動應(yīng)用匯、無線辦公、營銷助手等。

下面以無線辦公應(yīng)用為例，闡述此架構(gòu)中用戶的授權(quán)流程，流程圖如圖3所示。詳細(xì)步驟解釋如下。

圖3 用戶授權(quán)流程圖

（1） 客戶端發(fā)送AppID（客戶端識別碼）、用戶名、用戶密碼（MD5加密）到用戶授權(quán)服務(wù)器進(jìn)行驗證，服務(wù)器根據(jù)用戶資料（授權(quán)）數(shù)據(jù)庫的內(nèi)容，返還AccessToken（訪問令牌）、Scope（訪問范圍，即用戶授權(quán)可以訪問哪些數(shù)據(jù)接口的哪些內(nèi)容）、ExpirationTime（過期時間，即當(dāng)前令牌的有效時間，視客戶端信任等級而定）。

（2） 客戶端根據(jù)需求，使用AccessToken對數(shù)據(jù)接口進(jìn)行訪問，數(shù)據(jù)接口服務(wù)器依據(jù)令牌查詢出相應(yīng)的Scope和ExpirationTime，對其進(jìn)行訪問權(quán)限鑒別，鑒別通過后返回相應(yīng)的數(shù)據(jù)內(nèi)容。

（3） Sign數(shù)字簽名，在無線辦公客戶端采用客戶端+ 數(shù)據(jù)接口（WebAPI）的方式進(jìn)行數(shù)據(jù)交互。其中主要的訪問行為如圖4所示，客戶端向數(shù)據(jù)接口服務(wù)器提出http訪問請求，數(shù)據(jù)接口服務(wù)器驗證訪問請求中的sign數(shù)字簽名進(jìn)行驗證，驗證通過則允許訪問，驗證不通過則拋棄該次訪問。其中sign簽名方法如下。

圖4 Sign驗證流程圖

（1） 對接口調(diào)用URL后，所帶所有參數(shù)和參數(shù)值（不包括sign）所生成字符串經(jīng)過md5加密后轉(zhuǎn)成16進(jìn)制后得到一個32 bit的密文，該密文稱為 first_sign。

（2） first_sign的值（32 bit字符串)+訪問客戶端的SecretKey（本質(zhì)為guid，32 bit字符串），再次進(jìn)行md5加密，加密結(jié)果轉(zhuǎn)成16進(jìn)制后得到一個32 bit的密文，該密文稱為sign，也就是提交給服務(wù)器的sign數(shù)字簽名。

移動應(yīng)用開發(fā)支撐平臺從用戶信息授權(quán)、客戶端訪問鑒權(quán)、傳輸內(nèi)容加密等3個方面對無線辦公客戶端進(jìn)行全方位的安全保障。移動應(yīng)用開發(fā)支撐平臺建成正式上線以來（截至2014年6月20日），共接入App應(yīng)用35個，業(yè)務(wù)系統(tǒng)API接口55個；接口總訪問量4 781 540次，日均訪問量38 252次。API接口的平均復(fù)用率為1.32，個別接口如授權(quán)接口復(fù)用率為29，Android和IOS可復(fù)用組件復(fù)用率為1.19。

4 總結(jié)

移動應(yīng)用開發(fā)支撐平臺可有效地支撐現(xiàn)代企業(yè)的App建設(shè)，為企業(yè)提供一個統(tǒng)一的App管理平臺，所有App開發(fā)皆采用統(tǒng)一接口及規(guī)范，并且提供基于令牌識別的安全認(rèn)證機(jī)制以及安全審計機(jī)制，對API接口和App應(yīng)用實現(xiàn)了有效的支撐和管控。同時，該平臺的大部分通用WebAPI接口可重復(fù)利用，可極大地降低開發(fā)成本及提升開發(fā)效率，平臺自2014年1月上線以來共節(jié)省了約50個接口的開發(fā)及測試，節(jié)省了約100萬元的開發(fā)成本，后期若將該平臺架構(gòu)推廣至全省或集團(tuán)公司，整體經(jīng)濟(jì)效益將更加可觀。

Investigate the scheme of mobile migration for enterprise IT architecture

WANG Rui-bin
(China Mobile Group Fujian Co., Ltd. Quanzhou Branch, Quanzhou 362000, China)

The mobilization for the enterprise IT systems from traditional Web-based architecture is an important trend in recent years. In the actual practice, we also need to concern the existing network environment and old IT system, with thinking a new IT architecture that can transit smoothly. Security, performance, scalability and good maintainability are also the key issues. The new IT architecture combined the perspectives of user passport, WebAPI portal and App lifecycle, to form four resource pool that they are pool of users, pool of Apps, pool of API capabilities and pool of analytical data. With this, we can separate data flows of user authentication, Application data, analytical data and log data, in order to reduce development and maintenance costs of mobile App, improve the eff ciency of development.

IT architecture; API management; mobilization; App

TN915

A

1008-5599（2014）09-0076-04

2014-08-08