【2013年10月23日 51CTO外電頭條】移動(dòng)中間件，這一術(shù)語對(duì)于任何一位曾經(jīng)創(chuàng)建移動(dòng)應(yīng)用、為員工提供移動(dòng)設(shè)備支持或者實(shí)施客戶體驗(yàn)戰(zhàn)略的朋友來說都不會(huì)陌生。正確地選擇并使用移動(dòng)中間件能夠從根本層面縮短開發(fā)時(shí)間、提升用戶體驗(yàn)、促進(jìn)安全性并推動(dòng)合規(guī)性治理工作。雖然一般的移動(dòng)中間件模式具備標(biāo)準(zhǔn)化方案，但在數(shù)據(jù)管理、映射以及全局應(yīng)用程序設(shè)計(jì)等領(lǐng)域，中間件由于需要針對(duì)應(yīng)用及政策做出優(yōu)化而帶來了一系列變數(shù)。

[[87961]]

優(yōu)化移動(dòng)中間件設(shè)計(jì)

理想的移動(dòng)中間件架構(gòu)應(yīng)當(dāng)擁有服務(wù)器元素，并以此為基礎(chǔ)實(shí)現(xiàn)邏輯應(yīng)用交付。這些應(yīng)用程序既可以代表數(shù)據(jù)的消費(fèi)方、也可以代表對(duì)應(yīng)外部服務(wù)或數(shù)據(jù)訪問的應(yīng)用程序接口（簡(jiǎn)稱API），也就是中間件層的后端。位于服務(wù)器前端的API或者接口作為信息及體驗(yàn)的交付平臺(tái)。綜合起來，這就是傳統(tǒng)四層式結(jié)構(gòu)，即用戶-服務(wù)器-應(yīng)用程序-資源。

這種簡(jiǎn)單的結(jié)構(gòu)為我們帶來兩個(gè)設(shè)計(jì)工作中需要面臨的早期問題，即：應(yīng)用程序是什么？資源又是什么？舉例來說，Web API就可以被看作應(yīng)用程序；這一定義意味著它有能力直接由用戶實(shí)施訪問。允許用戶直接訪問Web API的問題在于，這類訪問會(huì)繞過登錄、安全以及管理等一系列可能由中間件所提供的流程——可以算是純粹的用戶到資源連接。在某些情況下，例如以性能為主要訴求的視頻數(shù)據(jù)交付流程，這類針對(duì)資源的直連機(jī)制無疑是大家需要盡量避免的。

由此帶來的必然結(jié)果是，我們必須從應(yīng)用程序創(chuàng)建的初期就融入良好的設(shè)計(jì)實(shí)踐方案。從框架入手，大家需要為框架結(jié)構(gòu)提供出色的安全性與合規(guī)性支持、活動(dòng)登錄以及其它多種因素，從而確保全部實(shí)踐切實(shí)貫徹到位。

移動(dòng)中間件應(yīng)用框架的一大核心問題在于API的使用方式。如果大家希望支持瀏覽器訪問（基本上這也是必備要素之一），那么基礎(chǔ)應(yīng)用必須提供RESTful前端。此外，大部分移動(dòng)設(shè)備應(yīng)用同樣需要使用RESTful API。需要強(qiáng)調(diào)的是，如果需要使用RESTful API，大家必須根據(jù)表述性狀態(tài)轉(zhuǎn)移為前提設(shè)計(jì)應(yīng)用程序。這意味著我們不能假定應(yīng)用程序會(huì)保持狀態(tài)?？傊瑢?duì)于應(yīng)用程序到資源連接機(jī)制來說，這一點(diǎn)非常重要。

性能改進(jìn)之路

如果應(yīng)用程序會(huì)利用Web服務(wù)直接訪問我們的中間件，那么大家需要審查BYOD政策（也就是針對(duì)為員工提供的移動(dòng)設(shè)備建立起的實(shí)踐機(jī)制）中每款平臺(tái)對(duì)于API的支持效果。制作一份圖表，其中列舉所有受到每一款平臺(tái)支持的API，以此為基礎(chǔ)即可輕松找到適合自身需求的最低API使用數(shù)量。

移動(dòng)中間件能夠顯著縮短開發(fā)時(shí)間。

在多數(shù)情況下，我們有必要為每一個(gè)API提供受支持的不同前端。與其將應(yīng)用程序邏輯直接針對(duì)每種用戶界面進(jìn)行復(fù)制，大家不妨考慮創(chuàng)建一套多前端方案、從而使使調(diào)度同一套應(yīng)用后端。這樣一來，大家就可以為全部API建立起通用數(shù)據(jù)模式并將這套模式提交給特定API（以及HTML）。如果需要根據(jù)設(shè)備操作系統(tǒng)或者移動(dòng)設(shè)備政策對(duì)API進(jìn)行定期調(diào)整，這將簡(jiǎn)化應(yīng)用程序生命周期管理流程。

從中間件的資源角度看，將API從應(yīng)用邏輯中進(jìn)行去耦處理也能帶來實(shí)際幫助。我們針對(duì)API定義的通用數(shù)據(jù)模式從訪問角度看只能算是基準(zhǔn)方案，數(shù)據(jù)模式中包含了所有必要的資源因素。只要向數(shù)據(jù)模式中而非向用戶提供應(yīng)用需要使用的元素，我們就能夠?qū)崿F(xiàn)有效的資源優(yōu)先模式。接下來，大家可以利用后端（實(shí)際上屬于面向后端的前端接口）與任何資源實(shí)現(xiàn)對(duì)接。

這種處理方案的主要挑戰(zhàn)之一在于性能，而多數(shù)情況下這都會(huì)成為移動(dòng)中間件的主要障礙。為了獲取最大程序的靈活性，大家可能希望應(yīng)用程序在資源及用戶角度都能擁有多API松散特性，這要求我們處理更多信息、也因此影響了性能表現(xiàn)。為了優(yōu)化性能，我們往往不得不舍棄一部分靈活性與硬編碼接口、甚至復(fù)制應(yīng)用邏輯，從而緩解給用戶及資源造成的壓力。

另一種值得考量的性能改進(jìn)途徑在于對(duì)中間件的多個(gè)副本進(jìn)行向外擴(kuò)展處理。但這種方式同樣存在局限性，即只有在應(yīng)用程序、中間件以及用戶API在連接方面存在性能障礙時(shí)才有效。舉例來說，如果大家面對(duì)的性能問題源自數(shù)據(jù)庫處理速度，那么復(fù)制中間件副本不會(huì)帶來任何幫助。

當(dāng)通過移動(dòng)中間件移動(dòng)大量數(shù)據(jù)時(shí)，請(qǐng)注意可能由虛擬化或者云計(jì)算引發(fā)的性能問題。根據(jù)虛擬機(jī)管理程序的使用方式以及數(shù)據(jù)通道的優(yōu)化效果，網(wǎng)絡(luò)流量很可能無法被高效傳輸至虛擬機(jī)端。如果移動(dòng)應(yīng)用需要在同一臺(tái)主機(jī)內(nèi)的多套虛擬機(jī)系統(tǒng)之間進(jìn)行數(shù)據(jù)傳輸，那么網(wǎng)絡(luò)連接的橋接效率會(huì)變得相當(dāng)?shù)拖?，從而?dǎo)致嚴(yán)重的性能問題。這時(shí)需要向虛擬機(jī)管理程序或者云軟件供應(yīng)商尋求幫助，看看有沒有合適的數(shù)據(jù)優(yōu)化途徑——這一點(diǎn)在交付移動(dòng)視頻時(shí)尤其重要。

移動(dòng)中間件對(duì)于連接丟失問題非常敏感，特別是在移動(dòng)活動(dòng)涉及某些資源提交或者金融交易時(shí)，情況就更值得關(guān)注。對(duì)于涵蓋全部活動(dòng)類型的從用戶到資源的路徑，我們必須深入進(jìn)行檢查與測(cè)試，從而確保故障不會(huì)在用戶不知情的狀況下保留他們的提交信息或者無人管理的滯留資源。