【2013年10月23日 51CTO外電頭條】移動(dòng)中間件，這一術(shù)語(yǔ)對(duì)于任何一位曾經(jīng)創(chuàng)建移動(dòng)應(yīng)用、為員工提供移動(dòng)設(shè)備支持或者實(shí)施客戶(hù)體驗(yàn)戰(zhàn)略的朋友來(lái)說(shuō)都不會(huì)陌生。正確地選擇并使用移動(dòng)中間件能夠從根本層面縮短開(kāi)發(fā)時(shí)間、提升用戶(hù)體驗(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)化而帶來(lái)了一系列變數(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ù)訪(fǎng)問(wèn)的應(yīng)用程序接口（簡(jiǎn)稱(chēng)API），也就是中間件層的后端。位于服務(wù)器前端的API或者接口作為信息及體驗(yàn)的交付平臺(tái)。綜合起來(lái)，這就是傳統(tǒng)四層式結(jié)構(gòu)，即用戶(hù)-服務(wù)器-應(yīng)用程序-資源。

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

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

移動(dòng)中間件應(yīng)用框架的一大核心問(wèn)題在于API的使用方式。如果大家希望支持瀏覽器訪(fǎng)問(wèn)（基本上這也是必備要素之一），那么基礎(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ī)制來(lái)說(shuō)，這一點(diǎn)非常重要。

性能改進(jìn)之路

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

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

在多數(shù)情況下，我們有必要為每一個(gè)API提供受支持的不同前端。與其將應(yīng)用程序邏輯直接針對(duì)每種用戶(hù)界面進(jìn)行復(fù)制，大家不妨考慮創(chuàng)建一套多前端方案、從而使使調(diào)度同一套應(yīng)用后端。這樣一來(lái)，大家就可以為全部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)行去耦處理也能帶來(lái)實(shí)際幫助。我們針對(duì)API定義的通用數(shù)據(jù)模式從訪(fǎng)問(wèn)角度看只能算是基準(zhǔn)方案，數(shù)據(jù)模式中包含了所有必要的資源因素。只要向數(shù)據(jù)模式中而非向用戶(hù)提供應(yīng)用需要使用的元素，我們就能夠?qū)崿F(xiàn)有效的資源優(yōu)先模式。接下來(lái)，大家可以利用后端（實(shí)際上屬于面向后端的前端接口）與任何資源實(shí)現(xiàn)對(duì)接。

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

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

當(dāng)通過(guò)移動(dòng)中間件移動(dòng)大量數(shù)據(jù)時(shí)，請(qǐng)注意可能由虛擬化或者云計(jì)算引發(fā)的性能問(wèn)題。根據(jù)虛擬機(jī)管理程序的使用方式以及數(shù)據(jù)通道的優(yōu)化效果，網(wǎng)絡(luò)流量很可能無(wú)法被高效傳輸至虛擬機(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)重的性能問(wèn)題。這時(shí)需要向虛擬機(jī)管理程序或者云軟件供應(yīng)商尋求幫助，看看有沒(méi)有合適的數(shù)據(jù)優(yōu)化途徑——這一點(diǎn)在交付移動(dòng)視頻時(shí)尤其重要。

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