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

[[87961]]

優化移動中間件設計

理想的移動中間件架構應當擁有服務器元素，并以此為基礎實現邏輯應用交付。這些應用程序既可以代表數據的消費方、也可以代表對應外部服務或數據訪問的應用程序接口（簡稱API），也就是中間件層的后端。位于服務器前端的API或者接口作為信息及體驗的交付平臺。綜合起來，這就是傳統四層式結構，即用戶-服務器-應用程序-資源。

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

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

移動中間件應用框架的一大核心問題在于API的使用方式。如果大家希望支持瀏覽器訪問（基本上這也是必備要素之一），那么基礎應用必須提供RESTful前端。此外，大部分移動設備應用同樣需要使用RESTful API。需要強調的是，如果需要使用RESTful API，大家必須根據表述性狀態轉移為前提設計應用程序。這意味著我們不能假定應用程序會保持狀態。總之，對于應用程序到資源連接機制來說，這一點非常重要。

性能改進之路

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

移動中間件能夠顯著縮短開發時間。

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

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

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

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

當通過移動中間件移動大量數據時，請注意可能由虛擬化或者云計算引發的性能問題。根據虛擬機管理程序的使用方式以及數據通道的優化效果，網絡流量很可能無法被高效傳輸至虛擬機端。如果移動應用需要在同一臺主機內的多套虛擬機系統之間進行數據傳輸，那么網絡連接的橋接效率會變得相當低下，從而導致嚴重的性能問題。這時需要向虛擬機管理程序或者云軟件供應商尋求幫助，看看有沒有合適的數據優化途徑——這一點在交付移動視頻時尤其重要。

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