整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
隨著5G的全面商用，移動行業應用在銀行業獲得了蓬勃的發展。廣西北部灣銀行為了滿足用戶多樣化的信息通信需求，盡可能發揮其綜合業務優勢，推動自身業務的高效發展，將建設一個統一高效的移動信息通用服務平臺。
移動信息通用服務平臺除了實現現有廣西北部灣銀行辦公自動化系統、信貸系統、績效考核系統的移動化功能外，還將同步配合廣西北部灣銀行發展新的銀行無線應用，推動廣西北部灣銀行向新型“信息化”銀行大步邁進。
移動信息通用服務平臺是根據現有銀行移動化信息建設中所碰到的問題設計的一個在不改變原業務系統應用邏輯的基礎上，快速構建應用移動化的支撐平臺，其主要建設目標如下：
建設可統一集中管理的移動信息通用服務平臺。
1. 平臺擁有開放的數據交互訪問接口，支持各類應用的接入。平臺上的應用能夠隨身定制，隨需而變。平臺具備多樣化的接入方式，靈活方便的操作體驗，相對標準的接口模式，豐富全面的功能特點 。
2. 平臺具備整合各類移動增值服務的能力。平臺能夠整合SMS、MMS、LBS、手機拍照等移動增值服務，可實現多種平臺訪問方式，其中包括PC、手機客戶端、WAP、SMS等，使得用戶無論在何時、何地、何種場合均可非常便捷的訪問自身的系統應用。
3. 平臺提供支持各種移動終端。平臺對手機應用的支持包括IPhone、GPhone、Symbian、J2ME和Windows Mobile等手機的支持，通過定制手機應用，實現PC和手機的雙終端使用。
廣西北部灣銀行的移動信息通用服務平臺應具備如下的特點和功能。
可在不改變原業務系統應用邏輯的基礎上，快速實現與廣西北部灣銀行各類業務系統的無縫連接。與廣西北部灣銀行業務系統的連接應具備三種方式：仿業務系統客戶端方式、直接訪問業務系統數據庫方式、接口方式，對于前兩種方式，廣西北部灣銀行業務系統無需做任何開發。
支持中國移動、中國聯通、中國電信等多家運營商無線網絡及多種網絡應用的接入，如短彩信、LBS定位、GPRS、CDMA、eFAX等。
支持CDMA1X，CDMA2000，TD-SCDMA，WCDMA，GSM，GPRS，EDGE，WiMAX，LTE，等無線網絡環境，既支持Http協議，也支持Socket協議。
可控制調用終端資源，如攝像頭、錄音、掃描槍、密鑰、通訊錄、通話話記錄、短信、彩信等，可以實現數據的終端本地存儲。
只需要在服務器端通過編輯描述業務界面及流程的腳本，即可快速實現業務客戶端功能。
提供良好的系統內權限分級管理，按角色劃分操作人員的操作權限，能體現在操作過程中操作人員的不同權限，并提供與身份認證等網絡安全措施的融合。
系統應能對所有的操作進行追蹤調查、記錄并進行分類，具有日志記錄和日志管理功能。
支持多種終端，包括但不限于以下平臺的終端：WindowsMobile、WinCE、Brew、Symbian、UIQ、Linux、J2ME、Blackberry、iPhone等。
要求可以將用戶的用戶名，密碼，設備號碼（IMEI）及SIM卡識別號(IMSI或ESN)進行綁定。當用戶進行鑒權時，必須多項數據完全符合時，才能繼續使用業務。可以保證專人專卡專用終端使用業務。
當用戶的終端丟失時，要求系統可以向終端發送一條特殊的信息，將終端上的所有和業務相關的信息全部銷毀的功能。
移動信息通用服務平臺作為一個新型的銀行移動業務支撐平臺，其建立的最終目標是：提供完善、安全、便捷的銀行應用移動化服務。
為實現上述總體目標，本方案將采用移動化服務器做為個整個系統的開發框架，建設一個適合銀行各種信息化應用移動化的系統，承擔移動辦公、信貸系統、績效考核等各種企業信息管理移動化需求。
平臺需具備業務無關性，即可以通過某種方式將客戶化系統展現在客戶手機上并正常完成業務交互，而無需關心客戶業務的具體形態和流程。系統需以平臺化的方式建設，具備未來良好的擴展能力。
平臺對接系統的接入手段和方案需具備典型的業務無關特性，可以通過達到快速批量化系統接入交付的效果。主流業務系統將接入時間需保證在2周到1月之內。
本系統的建設應當充分考慮對當前移動化接入平臺新技術的采用，以及產品供應商在其專業領域內的研發能力，以保證所建系統是一個不但能夠滿足當前需求、技術先進的系統，而且可以在未來合理的系統使用期限內能夠兼容并添加新技術，以最大限度的延長系統生存周期。
平臺應有一定的備份措施，保證系統的不間斷運行，系統應具有軟件故障在線恢復的能力。為保證平臺的高可靠性，數據硬盤（存貯用戶數據和用戶位置信息）應采用磁盤陣列或鏡像設置，主處理機雙備份等措施，并提供在線數據備份的手段。本平臺應要求高可靠率，保證系統（軟件）在99%的時間內都能夠正常運作。
平臺應提供開放標準的接口，企業應用移動化的業務應用系統能非常方便地通過這些接口進行連接而不用受限于某一廠家的硬件設備，使系統具有更大的擴充性和靈活性。同時接口有高效的處理能力，以應付突發大呼叫量的壓力。
平臺所采用的產品應該具有良好的開放性和兼容性，支持國際標準的協議和接口類型，提供多種開放的應用開發接口，能夠和業界主流的產品實現互連互通并具有豐富的應用實例。
系統數據訪問方式具有開放式結構，具有良好的擴展性及與其它系統的互通性。在增加新業務時不需要更改系統的軟件結構和網絡結構；具有易于維護的特點，除具有標準的開放式技術接口外，還能夠完成與現有業務系統、辦公系統等具有標準接口的系統完全對接。
為了確保平臺內部數據的完整性和可靠性，平臺必須提供有效的安全保密措施，確保整個系統的安全運行，應具備網絡安全、加密等措施，具有防入侵、防攻擊、防病毒等能力。并且需要具備與本省主流CA機構結合并提供基于PKI體系安全的能力，以滿足政府等高安全部門的需求。
在硬件方面，設備支持對系統進行靈活地配置和組合，相關軟件能方便地升級和更新，系統容量可保證滿足用戶量的增加；軟件方面，提供二次開發功能，適應不斷增強的支撐功能和不斷拓展的業務空間。
平臺總體框架結構符合廣西北部灣銀行對系統建設的統一規劃，方案有合理的層次結構，體現分層、模塊化、低內聚、高耦合的原則。應用系統要有較大的擴展能力，并且能夠隨著業務量的增長進行升級。
接入平臺長期高效平穩運行的關鍵在于系統能提供一個高效、多級、友好的管理系統。通過管理系統，廣西北部灣銀行的管理員可根據業務需求對平臺的各種軟、硬件資源做出及時有效的規劃調整；產品開發人員能夠迅速有效發布新應用；平臺管理員能夠有效地對業務量進行監控并提供各種報表。
平臺應將運營商所具備的移動增值服務，充分與行業應用相整合，從而最大限度地滿足行業移動化需求。
移動信息通用服務平臺由如下三個模塊組成：
運行模塊上承載著通過“接入”或“搭建”方式部署好的企業應用，方便企業通過手機客戶端程序，手機WAP，手機短信等方式使用自己的移動行業應用，同時運行模塊還提供了企業行業應用的WEB門戶，用戶可以通過瀏覽器使用自己的行業應用。
運行模塊中擁有平臺標準的行業應用接口，可以將原有企業的行業應用系統接入到平臺中來，在平臺中稱之為“接入”，接入成功后，企業用戶就可以通過手機使用到原有的行業應用了。平臺的接入方式有“B/S適配”和“OpenApi”。
B/S適配主要針對B/S架構的原企業應用，B/S適配支持HTML，ASP頁面，JSP頁面，PHP頁面等所有基于瀏覽器訪問的頁面。在協議上支持HTTP，HTTPS協議，并且支持AJAX。開發時可不需要原應用系統的廠商配合。
OpenApi適用于B/S和C/S架構的原企業應用，和B/S適配不同，采用OpenApi接入時需要和原企業應用開發廠商共同完成接口才可使用。
配置模塊是開發廠商專用的模塊，可為那些本身沒有移動行業應用的企業提供“搭建”服務，開發人員通過一系列的配置構建出一個運行在運行模塊的企業行業應用。
配置工作以可視化的拖拽方式完成，和原來編碼方式相比，大大簡化了配置難度，縮短了配置時間。B/S適配也是在這個配置模塊中完成的。
管理模塊為使用移動行業應用的企業管理員提供有效的管理界面，管理員通過這些管理界面，可以分配企業用戶，設置角色，指定權限，設置短/彩信模板，監控系統操作日志等。
移動信息通用服務平臺部署在銀行側可由如下服務器組組成：
單點登錄服務器組的作用如下：
1. 部署了可按運營商要求定制的登錄界面的應用包。
2. 當企業用戶登錄時，如果登錄信息合法，則單點登錄服務器將跳轉到該用戶要使用的應用所在的應用服務器，這樣做可完成應用集群。
單點登錄服務器組有主-備兩臺機器組成。
移動化應用服務器組部署了移動行業應用平臺的核心應用包。所有的接入，搭建，運行，管理都在此服務器中完成，針對每個企業，應用都是獨立的，互不影響。
移動化應用服務器組開始可只有主-備兩臺機器組成，當后期業務越來越多時只需要增加相應的移動化應用服務器就可實現應用集群，分擔服務器的壓力，讓應用平衡的炮制每臺機器上。
數據庫服務器組為整個平臺提供數據存儲，由2臺數據庫服務器和一個磁盤陣列組成。數據的雙機熱備，日備，周備和月備等備份策略都由它們完成。
網關接口服務器用來和運營商的移動化資源進行接入，例如短信，在信，彩信網關的接入，GPS或LBS定位接口；還用來和運營商內部的管理系統進行接入，例如銀賬系統，網絡管理系統等。
網關接口服務器組有主-備2臺機器組成，由于運營商接口的限制，目前采用手工切換的方式完成故障切換。
運維服務器用來獲取整個平臺的維護信息并產生一系列直觀的報表，可用來監控所有企業應用的狀態，短信發送量，并可實現企業開戶，功能開通等功能。
運維機不影響整個系統的運作，只提供管理數據的查詢，所以為單機。
移動信息通用服務平臺采用多會員運營支撐技術。移動化服務器是部署在銀行側的，用戶在登錄時，需要同時驗證平臺的應用ID和自身的用戶名和密碼。平臺針對每個銀行應用都會提供一個單獨的數據庫區，保證應用的安全性和獨立性。
在大多數手機客戶端應用中，手機客戶端程序和PC服務端綁定過緊，造成每次PC服務端程序修改、升級等，手機客戶端程序就需要重現開發和調整，眾所周知，目前市面的手機型號繁多，每款手機都需要特定的開發適合其手機的客戶端程序，這個工作量是巨大的。由于服務端的變更，經常需要升級才能繼續使用，對用戶來說，這個也是非常麻煩的。
在移動信息通用服務平臺中，平臺采用了應用配置化的方式，在應用更新時，不需要對手機客戶端做任何變更，手機端會自動檢查是否有配置變更，對變更的配置進行下載。這樣既解決了手機開發中的變更問題，也解決了用戶頻繁下載，產生流量的問題。
在手機終端的使用過程中，不可避免的會碰到附件下載和瀏覽的問題。很多時候，在用戶打開文檔時，才會知道這篇文檔是不是自己想要的。如果采用直接下載然后打開的方式，這樣會造成流量過大，打開文件占用大量手機內存，耗時長等等的問題。因此，在移動信息通用服務平臺中，采用了文檔解析技術，能將用戶的文檔進行拆分，分頁轉換成圖片的格式，傳到手機端，用戶可以通過預覽來判斷是否需要對文檔進行下載。
移動信息通用服務平臺采用配置的方式來定制手機客戶端、WAP、短信的展現格式，在適配過程中可以做到以系統配置而不是代碼編程來實現業務流程與功能，這樣就使移動信息通用服務平臺的移動化服務能夠以非常快的速度被實施。并且，這些應用可以被快速地重新配置、重新部署，以反映特定客戶業務需求的變化，這將大大降低適配的開發成本和響應速度。
移動信息通用服務平臺采用了網絡優化技術，在適配過程中，對企業應用的數據采用了定點采集的方式，只針對客戶需要的數據進行采集，減少了數據的冗余，并且在對所有的客戶端數據傳輸都采用了數據壓縮的技術。相對于PC訪問的網絡流量，考慮到數據在原頁面所占的比重，一般的壓縮率在4%-15%左右不等，大大縮減了對網絡帶寬的要求。使用戶流量也有了很大程度的減少。
在GSM環境下,首次采用客戶端登陸需要5秒左右，后續登陸平均接入時間在3秒左右。在WCDMA環境下，首次采用客戶端登陸需要3秒左右，后續登陸平均接入時間不到2秒。
移動信息通用服務平臺采用了應用推送技術，以實現平臺內消息，事件的提醒功能以及消息炸彈功能，平臺采用2種方式進行消息推送。
平臺可以通過WAP Push的方式將新公文，新郵件，新代辦等系統消息推送至手機，用戶可以通過WAP的方式對這些內容進行處理。
在手機客戶端程序在運行過程中，平臺可以通過手機IP地址直接將消息直接推送至手機，并彈出提醒。
行業應用接入模塊主要包括了針對B/S和C/S兩種軟件模式的應用適配。負責將用戶的應用數據抽取到平臺中，最終提供給手機終端進行訪問。
平臺對B/S應用的適配采用B/S適配插件的方式，進行B/S頁面的適配。
B/S適配支持HTML，ASP頁面，JSP頁面，PHP頁面等所有基于瀏覽器訪問的頁面。在協議上支持HTTP，HTTPS協議，并且支持AJAX。
B/S適配插件的作用是使手機終端能直接訪問B/S結構的系統，實現對原系統的移動化。對于這類辦公系統，B/S適配插件作為客戶端，與應用系統側服務器端進行正常的交互操作。
B/S適配插件接到移動信息通用服務平臺轉發的手機端發出的請求，進行必要的處理，發送給原系統；并接收從原系統返回的響應數據，對數據進行過濾和整合，再經移動信息通用服務平臺轉發給手機端。
B/S適配插件可根據業務需要設置對應用頁面內容的過濾規則，將頁面中不需要在終端上展現的數據進行過濾處理。過濾的對象可以是頁面中的任意一部分內容。
B/S適配插件將經過過濾抽取出來的數據按照需求進行重新組織，形成適合終端顯示的頁面。支持在頁面中嵌入其他的信息或頁面內容，以及根據需要進行頁面分拆，變成多個頁面進行操作和交換。
C/S應用適配主要是針對與那些無法采用瀏覽器方式進行訪問的應用。
C/S應用的適配采用API接口的方式進行應用的適配。平臺提供二次開發的API開發包，由企業和適配人員進行配合開發。
API接口開發包包括java、C#，C++等開發語言的版本。用戶在做二次開發時需要根據其需求實現包括登錄，簽退，數據查詢，數據處理，流程處理，增值業務處理等多個功能。
API接口開發包接收移動信息通用服務平臺轉發的手機終端請求，直接獲取對應的業務數據，再經平臺組織后轉發給手機端。
應用定制門戶主要負責應用的開發定制，針對用戶終端的界面，可以采用拖拽的方式來對終端的展現進行定制。企業用戶可以根據自己不同的需求，來設定自己界面的布局方式，也可以針對一家企業中的不同類型用戶來定制不同的界面布局。應用定制門戶可以定制企業應用的菜單，列表，表單，日歷，報表等等展現。定制的結果最終可以在PC，手機終端，WAP，短信交互中得到體現。
主控模塊主要負責平臺的正常運行，包括數據處理，流程處理，業務處理。平臺根據適配人員在定制門戶中配置的定制數據流程，業務流程等信息，對數據和流程進行處理。并對用戶的每一步操作記錄日志。
主控模塊在接到終端接入模塊轉發的請求之后，先記錄操作日志。根據配置門戶中定義的界面信息和流程信息，對請求進行分類。主控模塊根據請求的不同，將請求內容進行組織和處理后向企業交互模塊發出請求，獲取企業自身系統的業務數據。當企業交互模塊返回響應數據后，主控模塊將數據進行重組，再將響應數據返回給終端接入模塊。
請求內容主要包括以下幾類：
1. 登錄
使用戶同時登錄到移動信息通用服務平臺和自身應用的系統之中。平臺中不保留用戶的帳號密碼信息，完全采用企業自身的鑒權功能來實現用戶的登錄。
2. 簽退
將用戶從應用系統和移動信息通用服務平臺中同時注銷。
3. 菜單請求
將用戶菜單返回給客戶，菜單在配置門戶進行定義，平臺直接從配置數據中獲取菜單返回給終端。
4. 數據查詢
數據查詢包括表單查詢和列表查詢，主控模塊根據配置門戶中定義的表單頁面布局和列表頁面布局，來組織查詢內容進行查詢，并將結果重組后返回。
5. 數據處理
數據處理包括數據的增刪改等等。平臺會將處理內容轉發給企業交互模塊，并根據配置門戶中定義的成功失敗操作進行處理和返回。
6. 流程處理
流程處理包括了流程的創建，審批，轉發，打回，中止，查詢等等流程動作，平臺本身不承載任何對流程的處理功能，只是將流程的請求轉給企業應用系統，由企業應用系統來執行對流程的流轉。
7. 附件處理
附件處理主要包含了附件的列表，上傳和下載。基于手機終端的屏幕大小，內存大小，流量等因素，平臺提供了一系列附加功能，包括附件的預覽，格式轉換等等。
8. 其他
主控模塊還負責一系列增值服務的操作，例如定位服務，短信發送服務，彩信發送服務等等。
當手機終端第一次請求應用程序時，應用程序首先會建立一個安全的通道，保證之后的數據傳輸在此安全通道內進行，防止數據被他人竊取和竄改。
手機終端和應用服務器之間通過“手機客戶端交互模塊”進行通信，“手機客戶端交互模塊”能夠對數據進行壓縮和解壓縮。例如，應用服務器在接受到手機終端的請求時，“手機客戶端交互模塊”首先對請求數據進行解壓，然后再把請求發送給應用服務器；而在應用服務器把響應結果返回給手機終端時之前，“手機客戶端交互模塊”也會先對響應的結果進行壓縮再發送給客戶。通過“手機客戶端交互模塊”的壓縮/解壓處理，有效地降低了網絡流量，從而減少了延遲時間，加快了手機終端和應用服務器之間的通信效率。
另外，“手機客戶端交互模塊”能夠對數據進行加密/解密處理。例如，應用服務器在接受到手機終端的請求時，“手機客戶端交互模塊”首先對請求數據進行解密，然后再把請求發送給應用服務器；而在應用服務器把響應結果返回給手機終端之前，“手機客戶端交互模塊”也會先對響應的結果進行加密，然后再發送給手機終端。通過“手機客戶端交互模塊”的加密/解密處理，有效地提高了數據傳輸的安全性，降低了關鍵信息被截取或阻斷的可能性。
WAP（無線應用通訊協議,Wireless Application Protocol）是一種向移動終端提供互聯網內容和先進增值服務的全球統一的開放式協議標準，是簡化了的無線 Internet協議。WAP將 Internet和移動電話技術結合起來，使隨時隨地訪問豐富的互聯網絡資源成為現實。
WAP訪問模塊主要作用是將平臺數據采用固定的模板轉化成WML或者XHTML語言，以提供給手機端WAP訪問。
只需要一部具有WAP功能的手機，就可以隨時隨地的登陸系統，獲取實時的商務及辦公信息。
SMS（Short Messaging Service）是最早的短消息業務，也是現在普及率最高的一種短消息業務，通過它，移動電話之間可以互相收發短信，內容以文本、數字或二進制非文本數據為主，目前，這種短消息的長度被限定在140字節之內。SMS以簡單方便的使用功能受到大眾的歡迎，卻始終是屬于第一代的無線數據服務，在內容和應用方面存在技術標準的限制。
如今，短信業務已是運營商主要業務之一，針對此種業務特點本系統在用戶注冊、創建新用戶等操作過程中實現SMS接口的調用。
短信交互模塊主要采用短信的方式和手機終端進行交互。用戶將固定格式的短信發送到移動信息通用服務平臺，平臺采用特定的模板，根據數據的內容，來重組數據，以短信的方式回復到手機。
MMS(Multimedia Messaging Service)為多媒體短信服務，它最大的特色就是支持多媒體功能。多媒體信息使具有功能全面的內容和信息得以傳遞，這些信息包括圖像、音頻信息、視頻信息、數據以及文本等多媒體信息，可以支持語音、因特網瀏覽、電子郵件、會議電視等多種高速數據業務，在GPRS網絡的支持下，以WAP無線應用協議為載體傳送視頻片段、圖片、聲音和文字。多媒體信息業務可實現即時的手機端到端、手機終端到互聯網或互聯網到手機終端的多媒體信息傳送。
移動信息通用服務平臺中，平臺支持彩信收發的功能。
在用戶終端丟失的情況下，移動信息通用服務平臺可實現遠程清除終端內信息。用戶在終端丟失后，可以和銀行聯系，由銀行系統管理員進行操作，進行信息清除。
信息清除可以清除用戶終端的使用信息以及手機中的其他信息，用戶可以對清除規則進行設置，可以清除用戶客戶端的使用信息包括用戶的登錄名、密碼、緩存信息等等，也可以對手機中的其他信息進行清除，包括手機通訊錄，日歷，消息等。
平臺采用兩種方式對信息清除進行處理：
1. 采用特殊短信的方式進行通知，手機客戶端在特定端口偵聽，接受到短信后，客戶端會根據短信傳遞的參數，將對應數據進行清除。
2. 在客戶端登錄時進行清除，當用戶手機丟失后，系統管理員在平臺中進行配置，將信息清除標志打開。用戶使用手機客戶端進行登錄時，發現該標志為打開狀態，則返回清除數據的命令。客戶端根據命令參數將對應數據進行清除。
各行業都有自身的特點和使用習慣，平臺及手機客戶端程序擁有集成使用特殊設備的支撐能力。舉例如下：
平臺應用可外連很多行業設備，POS就是其中之一。平臺擁有可解析標準8583報文的前置附件，部署好此附件后，便可使用金融POS作為企業數據的采集終端，將交易或其他信息通過POS傳遞到平臺應用。
平臺可接入任何可提供GPS/LBS定位服務的系統，進行含有GPS/LBS功能的行業應用開發，GPS衛星定位精準性高于LBS，但是受到建筑物等的影響在某些區域不可用，LBS基站定位精準度稍差，但不受環境限制只看是否部署了該種設備。有了GPS/LBS就可進行例如保險行業的移動定損業務，車務通系統的搭建。
平臺通過采集使用移動行業應用的手機終端的位置信息，可在WEB應用界面中提供實時的地圖監控界面，界面還可根據實際的業務進行行業定制。如下圖：
手機客戶端程序可外接藍牙的二代身份證掃描器，結合行業應用進行身份證信息的采集。掃描按鈕可任意配置在需要出現的地方。例如下圖的信用卡辦卡系統中就使用了身份證掃描來加快數據的采集速度，加強數據采集的準確度。
手機客戶端程序可外接藍牙打印機，結合行業應用出單。例如在信用卡辦卡系統中使用藍牙打印機將客戶信息打出和申明條款一同由辦卡人齊縫簽字方有效。
條形碼掃描是特定機器的可擴展外接設備，裝上條碼掃描背夾后的手機可在移動信息通用服務平臺的應用中進行條形碼的采集，結合后端應用，可搭建出很多應用，可直接使用手機掃描貨品，連接到平臺應用查詢相關的產品信息。
應用系統管理員門戶是管理員對系統用戶和其使用情況進行查詢和管理的門戶。
門戶提供了以下幾點功能：
1. 系統用戶使用情況查詢
2. 短信和彩信的黑白名單設置
3. 用戶操作日志稽核
4. 用戶訪問方式開關(WAP,手機客戶端,短信交互)
5. 企業部分信息修改
6. 消息推送設置
手機客戶端和移動信息通用服務平臺之間采用HTTPS方式進行連接，在交互過程中采用了數據壓縮和數據加密的技術。在保證數據的安全性的同時也對流量有所控制。
移動信息通用服務平臺和企業側應用的接口根據企業應用的不同類型采用了B/S應用適配或C/S應用適配兩種方式進行實現。
1. B/S應用適配主要通過適配人員在應用定制門戶中對企業應用移動化的展現進行配置，以及對企業應用界面的XML描述文件進行定義相結合的方式來實現。
2. C/S應用適配主要通過對API接口進行二次開發的方式來實現。平臺提供API開發包給企業，與企業配合實現應用接口的開發。
3. 移動信息通用服務平臺提供了企業應用側調用增值能力的接口。接口包括以下兩種：
4. 短信發送接口。企業可以通過該接口來調用平臺的短信能力。進行短信的發送、查詢、消息報告、WAP Push等功能
5. 彩信發送接口。企業可以通過該接口來調用平臺的彩信能力。進行彩信的發送、查詢、消息報告等功能。
6. 事件提醒接口（推送）。企業可以通過該接口來實現對用戶的事件通知和消息通知。
平臺提供短信的收發功能，支持運營商在信網關的接入（符合SGIP協議的接口規范）。
平臺采用專用SGIP方式與SMG之間進行通信，端口8801，平臺和SMG之間的通信由平臺向網關服務器端發起連接。連接建立以后，由平臺向服務器端發送命令。平臺和網關互為服務器端。
平臺支持彩信的收發功能。支持運營商MMS接入。
接口符合《數字蜂窩移動通信網多媒體消息業務（MMS）CP/SP業務開發規范》。
平臺支持彩信的發送，彩信消息報告，彩信的接收和彩信的群發功能。平臺采用SMIL格式傳輸消息。
對于規模較大、并且要求提供良好服務的移動信息通用服務平臺，要進行大量的數據交互處理，因此其中的數據庫服務往往是最繁忙的，實際上，數據庫服務往往也是其中最為關鍵的服務，因此在進行數據庫設計的時候，必須充分考慮為其提供良好的軟件環境，以滿足移動信息通用服務平臺對數據庫的需求，保證數據安全、快速的傳輸。
1. 具有較高的安全可靠性和數據恢復能力，采取有效的措施防止數據存儲介質的損壞和數據的丟失；
2. 數據庫支持標準的開放數據庫接口（ODBC），具有良好的開放性和可擴展性，支持多服務器、多客戶機結構；
3. 對數據進行分級管理，對不同級別的數據設置不同的訪問權限，只有合法的授權用戶才被允許訪問數據；數據庫系統設有軟件或硬件防火墻，以阻止計算機病毒、操作失誤或人為破壞數據系統；
4. 提供的數據庫具有足夠的開放性并易于維護，提供足夠詳細的資料，使用戶能夠容易掌握對數據庫的維護和應用；
5. 數據庫管理系統支持關系模型，支持分布式的大型通用數據庫管理系統；
6. 數據庫支持Unix 、Linux或Windows 2003 以上操作系統；
7. 支持系統級、客戶級、表級的權限管理；
8. 支持事務處理，具有開放式的客戶機編程接口和開放型數據庫互連接口，使數據庫之間的互聯成為可能；
9. 為保證系統的安全性和可靠性，使用兩臺數據庫服務器通過軟件構成雙機/多機高可用性結構。支持雙機熱備份方式和負荷分擔方式；
10. 支持本地數據庫和遠程數據庫；
11. MTBF 值必須大于10000 小時，MTBF/（MTBF+MTTR）值必須大于99.9%，必須雙機或多機熱備份配置。
12. Oracle是目前應用最廣泛的數據庫系統。一個完整的數據庫系統包括系統硬件、操作系統、網絡層、DBMS（數據庫管理系統）、應用程序與數據，各部分之間是互相依賴的，對每個部分都必須進行合理的配置、設計和優化才能實現高性能的數據庫系統。應用數據庫系統包含應用數據庫和應用兩方面的內容，應用數據庫就是生產數據庫，與系統數據庫相對。
針對大型數據庫ORACLE 10G對移動信息通用服務平臺數據庫規劃進行如下建議：
1. 建立獨立的ORACLE數據庫服務器，與應用系統分離
將數據庫與應用系統分離有利于對數據庫的獨立監控與維護，減少應用系統與數據庫系統之間的影響，避免由于應用系統的問題導致數據庫性能下降或者出現異常；有利于對問題進行定位，不容易造成混淆。
2. 數據庫用戶空間劃分
在ORACLE服務器中建立多個表空間，這樣一個會員對應一個表空間，每個表空間對應一個用戶，每個表空間對應一個邏輯數據庫。從安全角度分析，對每個表空間建立獨立的用戶，數據庫之間的訪問具有用戶權限的限制，避免一個用戶跨多個數據庫訪問造成數據庫安全隱患。
對于異地數據服務平臺不保留用戶數據，也就是移動信息通用服務平臺我們是不保留用戶數據的，只會產生一些用戶配置信息以及日志數據。
平臺每天晚上會將系統配置數據、流量數據、會員信息等數據在運維服務器上進行備份，并保留一年的歷史數據。
使用了以下三項安全措施：
1. 手機號碼綁定：
甄別合法手機終端的安全措施，移動化平臺記錄已被授權的手機終端的手機號碼，作為判斷是否是合法用戶的條件之一，禁止未授權的手機用戶連接移動化平臺，輔助登錄名和登錄密碼驗證，提高安全性，保證業務信息發送者身份的正確性。
2. IMEI手機序列號綁定：
甄別合法手機終端的安全措施，IMEI (International Mobile Equipment Identity) 是國際移動設備身份碼的縮寫，每個手機的IMEI碼是全球唯一的，移動化平臺記錄授權手機的IMEI碼，作為判斷是否是合法用戶的條件之一，禁止未授權的手機設備連接移動化平臺，輔助登錄名和登錄密碼驗證，提高安全性，保證業務信息發送者身份的正確性。
3. 服務器IP認證：
甄別正確企業應用服務器的安全措施，移動化平臺記錄企業應用服務器的主機IP，拒絕未知IP地址主機的連接請求，同時確保移動化平臺連接到正確的企業應用服務器，在一定程序上防止維護人員的誤操作，保證業務信息接收者身份的正確性。
平臺的業務安全采用以下四種安全措施：
1. 用戶名密碼認證：
甄別合法用戶的安全措施，作為最基礎的安全措施，阻止未授權用戶登錄移動化平臺系統。平臺的用戶名密碼認證采用的是企業端的用戶名密碼認證。
2. 帳號權限管理：
平臺對企業用戶的權限進行分級管理，對不同的權限有不同的策略。
3. 操作日志稽核：
記錄用戶的各項操作，使歷史操作內容有據可查。
4. VPDN接入
手機客戶端可以采用VPDN的方式進行接入，平臺從運營商服務器獲得ECID和OA-USER后，會對企業ID和用戶做認證。
平臺針對網絡安全采用以下四種安全措施：
1. 主機防火墻安全：
網絡的安全問題主要是由網絡的開放性、無邊界性、自由性造成的，所以我們網絡安全首先應該考慮把被保護的網絡由開放的、無邊界的網絡環境中獨立出來，成為可管理、可控制的安全的內部網絡。也只有做到這一點，實現信息網絡的安全才有可能，而最基本的分隔手段就是防火墻。利用防火墻，可以實現內部網（信任網絡）與外部不可信任網絡（如因特網）之間或是內部網不同網絡安全域的隔離與訪問控制，保證網絡系統及網絡服務的可用性。
網絡層的安全防護主要是通過防火墻設備，以保障整個移動化平臺系統的網絡層安全。防火墻保護是網絡安全性設計中重要的一環，網絡邊界采用防火墻系統進行防護，可以有效地降低網絡安全風險。
在本方案的網絡設計中，業務服務器所在網域與其他所有相關鏈路的網域之間都部署了企業級防火墻設備，從而建立成安全級別較高的DMZ區，起到隔離的作用，提高網絡的可靠性和安全性，在防火墻上配置相應策略，只允許合法數據信息通過，達到保護內部網絡，限制外部對系統的非授權訪問的目的。
在網絡安全問題日益突出的今天，防火墻技術發展迅速，目前一些領先防火墻不但具有信息過慮的功能還具有VPN功能、流量管理與控制功能、監控功能、NAT功能、防病毒功能和防御網絡攻擊等功能。
2. 專線接入：
移動化平臺服務器可以使用專線與企業應用服務器進行連接，確保信息數據傳輸的安全性。
3. 手機CA證書認證：
CA，全稱Certificate Authority，即證書授權中心，是數字證書的簽發機構,它是PKI的核心。CA是負責簽發證書、認證證書、管理已頒發證書的機關。它要制定政策和具體步驟來驗證、識別用戶身份，并對用戶證書進行簽名，以確保證書持有者的身份和公鑰的擁有權。CA 也擁有一個證書（內含公鑰）和私鑰。網上的公眾用戶通過驗證 CA 的簽字從而信任 CA ，任何人都可以得到 CA 的證書（含公鑰），用以驗證它所簽發的證書。
由于，移動化平臺可以采用給手機終端頒發CA證書和驗證CA證書的方式，不僅可以對手機終端進行身份確認，而且也確保手機終端發送到移動化平臺的信息數據傳輸過程中不會被他人篡改。
4. 基于CA的服務器證書：
對于非專線接入的企業應用，移動信息通用服務平臺可以給企業應用服務器頒發CA證書和驗證其CA證書，確保移動化平臺與企業應用服務器之間的數據傳輸的安全可靠。
1. 集群部署與負載均衡
為確保業務服務的穩定性、高效性和高可用性，對主要的業務服務器采用集群部署方式，以達到負載均衡作用，降低單個業務服務器的運行壓力。
負載均衡（Load Balance）提供了一種廉價、有效、透明的方法，來擴展網絡設備和服務器的帶寬、增加吞吐量、加強網絡數據處理能力、提高網絡的靈活性和可用性。
它主要完成以下任務：解決網絡擁塞問題，服務就近提供，實現地理位置無關性 ；為用戶提供更好的訪問質量；提高服務器響應速度；提高服務器及其他資源的利用效率；避免了網絡關鍵部位出現單點失效。
負載均衡有兩方面的含義：首先，大量的并發訪問或數據流量分擔到多臺節點設備上分別處理，減少用戶等待響應的時間；其次，單個重負載的運算分擔到多臺節點設備上做并行處理，每個節點設備處理結束后，將結果匯總，返回給用戶，系統處理能力得到大幅度提高。
負載均衡是由多臺服務器以對稱的方式組成一個服務器集合，每臺服務器都具有等價的地位，都可以單獨對外提供服務而無須其他服務器的輔助。通過某種負載分擔技術，將外部發送來的請求均勻分配到對稱結構中的某一臺服務器上，而接收到請求的服務器獨立地回應客戶的請求。
提供服務的一組服務器組成了一個應用服務器集群(cluster)，并對外提供一個統一的地址。當一個服務請求被發至該集群時，根據一定規則選擇一臺服務器，并將服務轉定向給該服務器承擔，即將負載進行均衡分攤。
通過應用負載均衡技術，使應用服務超過了一臺服務器只能為有限用戶提供服務的限制，可以利用多臺服務器同時為大量用戶提供服務。當某臺服務器出現故障時，負載均衡服務器會自動進行檢測并停止將服務請求分發至該服務器，而由其他工作正常的服務器繼續提供服務，從而保證了服務的可靠性。
2. 冗余備份
在備份方面，Oracle自身就提供了強大的備份與恢復工具，足以滿足現實需求。
簡單的按照備份進行的方式，可將Oracle備份分為邏輯備份和物理備份，其中物理備份又分為冷備份（脫機備份）和熱備份（聯機備份）。按照備份的工具，可以分為EXP/IMP（EXPDP/IMPDP）導出/導入備份、OS文件拷貝備份和RMAN備份與恢復管理器。
這里我們推薦使用磁盤陣列柜，作為備份數據冗余存儲的設備。
磁盤陣列可以很好支持集群和存儲共享，磁盤冗余具有易于部署、配置和管理的高級數據保護特性。此外，磁盤冗余確保提高可擴展性，提供未來擴展的硬件投資。智能磁盤陣列架構為從低配置向高配置遷移提供了一個快速、便捷的途徑，從而提高了可擴展性。磁盤冗余具有極高的密度、熱插拔驅動器、多單元的擴展性、可以使用的圖形用戶界面，可提供良好的數據保護。
當然，也可以使用磁盤陣列柜存儲近期備份數據，使用磁帶機存儲長期備份數據。
平臺遵循SNMP網管接口，能做到系統的實時監控與報警。
計算機系統可靠性設計是為了在設計過程中挖掘和確定隱患薄弱環節，并采取設計預防和設計改進措施有效地消除隱患和薄弱環節，因為系統的可靠性在很大程度上取決于設計的正確性。
可靠性預計是可靠性設計的一個重要內容，它是一種預報方法，即在設計階段，從以前的系統所得到的失效率數據，預報新系統可能達到的可靠度，以及在規定的條件下和規定的時間內完成規定功能的概率。要重視可靠性預計的作用，在設計的初期，及時完成可靠性預計工作，可以充分了解系統中各部分之間可靠性的相互關系，找出提高整個系統可靠性的有效途徑。
現代質量觀認為，產品質量的基本目標是性能、可靠性、維修性、保障性、安全性和經濟性等，所以，可靠性是產品基本質量目標之一，是產品質量的重要組成部分。
可靠性管理的目的，是以最少的資源，實現產品規定的可靠性指標要求，達到“一次成功”，降低全壽命周期費用。
可靠性管理是一個系統工程問題，它貫穿于產品研制、生產和使用的整個壽命周期，也稱全面可靠性管理。
可靠性管理和質量管理的根本目標是一致的，都是為了提高產品的質量和可靠性，所以，可靠性管理是全過程質量管理活動的一個重要組成部分，也是質量保證體系的重要組成部分，兩者不能決然分開。可靠性管理離不開質量管理，質量管理同樣也離不開可靠性管理。現在普遍主張可靠性管理和質量管理并舉，而且以可靠性為重點（中心）進行質量管理。可靠性管理和質量管理均是企業管理的重要組成部分，與企業其他管理活動密切相關，應和其他管理活動結合起來進行。
但是，由于可靠性技術的特點，可靠性管理有許多不同于一般質量管理的特點。第一，可靠性管理不僅涉及生產過程中的質量控制，而且側重于產品形成的各階段的可靠性指標的管理；第二，可靠性管理不是一種單純的管理科學，而是一種組織進行可靠性設計和實施可靠性工程的活動；第三，可靠性管理不是單純的“驗收把關”，而是通過可靠性論證、分析、試驗等工作將問題盡量消除在早期。從發展歷史階段和學術上看，可靠性管理和質量管理是有區別的，而且有很大的區別。狹義的質量管理所要管的主要是產品的成品率或不良品率，而可靠性管理所要管的主要是產品的效率和平均無故障時間（MTBF ），前者與時間無關后者是時間的函數。
因此，對于有可靠性要求的產品，除進行質量管理外，還必須進行可靠性管理，這是因為可靠性有其專門領域和專門技術，是質量管理無法代替的。同時，由于可靠性涉及產品的全壽命周期，其管理工作就占據重要地位。
可靠性設計準則是進行可靠性定性設計的重要依據，是設計人員在可靠性設計中必須遵循的原則，貫徹設計準則可以有效避免一些不該發生的故障，提高系統的可靠性。
可靠性設計準則的內容主要有：
1. 降額設計
降額設計就是使設備工作時承受的工作應力適當低于設備規定的額值，從而達到降低故障率、提高使用可靠性的目的。電子產品都應做適當的降額設計，因電子產品的可靠性對其電應力和溫度應力敏感，故而降額設計技術對電子產品則顯得尤為重要，成為可靠性設計中必不可少的組成部分。當然，過度降額并無益處。
2. 簡化設計
簡化設計就是在保證產品性能要求的前提下，盡可能使產品設計簡單化。簡化設計可以提高產品的固有可靠性和基本可靠性。為了實現簡化設計，可采取以下措施：
1) 盡可能減少各組成部分的數量及其相互間的聯接。
2) 盡可能實現元件的標準化、系列化與通用化，控制非標準元件的比率，爭取用較少的元件實現多種功能；
3) 盡可能采用經過考驗的可靠性有保證的元件；
4) 盡可能采用模塊化設計。
3. 非容錯設計
非容錯設計是指事先消除使系統不可靠的因素以提高系統可靠性的設計方法，也就是在允許的成本范圍內，選擇最可靠的元件，使用成熟、可靠的連接裝配技術，采取有效的措施屏蔽可能的外界干擾等。非容錯法設計要結合可靠性預計，在確定初步方案后，利用可靠性預計來評估系統的可靠性，根據評估結果，對設計進行合理調整，從而提高設計的正確性和可靠性。
4. 容錯設計
容錯設計是指針對系統運算過程中出現的故障或者低可靠性元件所采取的系統性可靠措施。運行故障有三種類型：永久性失效、瞬間失效和外界干擾。根據故障失效的持續時間、影響范圍和出現頻率，選用不同的防護性冗余就是容錯法的設計內容。容錯設計是建筑在非容錯設計基礎上的，而不損傷整個系統。
冗余技術是系統或設備獲得高可靠性、高安全性和高生存能力的設計方法之一。特別是當元件質量與可靠性水平比較低、采用一般設計已經無法滿足設備的可靠性要求時，冗余技術就具有重要的應用價值。計算機系統冗余就是在系統中配置作貯備用的元件，當原元件出現故障時，貯備件能夠立即替換上去。計算機冗余包括靜態和動態硬件冗余、軟件冗余以及時間冗余。
1) 靜態硬件冗余：又稱屏蔽冗余，它是通過附加元件的辦法來屏蔽故障，使系統的功能不受影響。常見的靜態硬件冗余比如雙工，即使完成同一職能的一批元件同時（并行）工作，并且當其中的某個或部分元件失效時，其余的設備仍能保證系統的正常工作。
2) 動態硬件冗余：這種冗余包括二個階段，首先發現故障，其后消除故障而“復常”。在計算機系統中采用動態硬件冗余時，要求系統具有模塊結構和檢測故障的能力，例如設有自校驗碼，部件狀態標志等。復常的措施可選用糾錯裝置（如海明校驗）、部件切換以及系統適度降級重新組織好元件等技術。為了保證復常成功，還要求系統有一個高可靠性的硬核。硬核范圍內的元件發生故障，將不能復常。
3) 軟件冗余：用附加軟設備的方法來達到容錯的目的。與硬件冗余相比，其優點是能在硬件設計完成之后增加系統的容錯功能。常用的軟件冗余比如關鍵程序或者數據多處存儲、程序和微程序上附加測試手段，以及增設程序入口和出口點等。
4) 時間冗余：簡稱“復執”。在時間允許的條件下，通過重復執行以消除瞬時的偶然性故障是時間冗余提高可靠性的原理。復執允許在微動作、指令、程序段或者整個作業等各種級別上進行。選取復執方案取決于復執的再啟動點、實現復執可付的代價（包括時間、硬件和軟件），以及復執成功率等因素。
無論是硬件冗余、軟件冗余，還是時間冗余，相互之間并不排斥，大多數的計算機系統具備多種冗余的特色──混合冗余。
但是冗余使系統的復雜性、重量和體積增加，使系統的基本可靠性降低。系統或設備是否采用冗余技術，需從可靠性、安全性指標要求的高低、元件的可靠性水平、非冗余和冗余方案的技術可行性、研制周期和費用、使用及維護和保障條件、質量及體積和功耗的限制等方面進行權衡分析后確定。同時需注意，采用某些冗余技術時會增加若干故障檢測和冗余通道切換裝置，它們的不可靠度應保證低于受控部分的50%，否則采用冗余布局所獲得的可靠性增長將會被它們的故障所抵消。此外，冗余技術也不能用來解決設備超負荷之類的問題。
軟件可靠性設計在某種意義上講比硬件可靠性設計更重要。這是因為：第一，系統中配置的硬件幾乎都是商品化的貨架產品，可靠性有保障；第二，隨著系統自動化程度的不斷提高，功能的不斷增強，系統運行的應用軟件越來越龐大，軟件發生故障的概率呈上升趨勢。為此，軟件可靠性設計更為重要。
提高軟件可靠性的技術可以分為兩類，一類是避開錯誤（fault-avoidance）技術，即在開發過程中不讓差錯潛入軟件的技術；另一類是容錯（fault-tolerance）技術，即對某些無法避開的差錯，使其影響減至最小的技術。
避開錯誤技術是軟件開發的質量管理體系的技術基礎，靠嚴格的質量管理過程實現。但是，無論使用多么高明的避開錯誤技術，也無法做到完美無缺（zero-defect）和絕無錯誤（error-free），這就需要采用容錯技術以使錯誤發生時不影響系統的特性，或使錯誤發生時對用戶的影響限制在特定的允許范圍之內。
運營商移動信息通用服務平臺應用軟件在整個設計與研發過程中采用了如下避開錯誤技術與容錯技術，保證了整個平臺軟件的高可靠性要求。
移動化服務器支持應用級的負載均衡，通過單點登錄服務器，把訪問壓力均勻分配在移動化服務器集群，充分利用服務器資源。
并且在某一臺移動化服務器出現故障時，系統會迅速將請求轉發到其它正常移動化服務器進行處理，以避免業務的停頓。
平臺通過人工指定的方式來對企業會員進行服務器的分配，通常情況下，會員通過指定的服務器進行登錄，但如果一臺服務器中的會員連接數過大，單點登錄服務器會將后續登錄的企業用戶轉向另一臺連接數較小的服務器。當一臺服務器發生了故障時，單點登錄服務器會將用戶分配到其他服務器中，如果所有服務器連接數均達到上限，則拒絕該請求，并給用戶提示。
如果要做自動分配，建議配置專門的負載均衡設備（例如：F5），本期由于接入企業數不多，暫不做推薦。
考慮到運營商移動信息通用服務平臺安全的特殊性以及社會影響力，采取系統定時容災備份，確保當運營商移動信息通用服務平臺發生災難或故障，可以利用容災備份來保證應用系統的安全，在移動信息通用服務平臺發生災難時，可以通過容災備份恢復生產,保證業務的連續性。
博云打印外賣店鋪授權及不出單問題的處理方法
購買佳博云打印，想用在外賣平臺接單，
在使用過程中可能會遇到這些問題。
不知道怎么綁定外賣店鋪？
外賣店鋪綁好了，店鋪列表看不到？
店鋪設置完了，出現丟單或者一直不出單？
......
小編匯總了一些外賣店鋪常見問題及處理方法，
請接著往下看吧~
問題一：購買了佳博云打印機，怎么綁定美團外賣？
答：請按照使用說明文檔步驟執行。
美團外賣教程：
http://help.poscom.cn:8181/blog-14.html
餓了么教程：
http://help.poscom.cn:8181/blog-15.html
餓百零售教程：
http://help.poscom.cn:8181/blog-16.html
京東到家教程：
http://help.poscom.cn:8181/blog-31.html
問題二：蘋果手機選擇打印機設置時選不上？
答：嘗試上下滑動后在點擊確定。
問題三：店鋪提示綁定成功，但是在店鋪列表看不到？
答：
1）先確認綁定的是否同一個云平臺賬號；
2）檢查是否在其他地方授權，如是，請嘗試重新綁定操作；
3）以上操作還不能解決，聯系佳博云打印技術客服，電話：0756-3965611/3965100
問題四：美團店鋪綁定后，出現漏單或者一直不出單是怎么回事？
答：針對美團的個別訂單出現了漏單的問題，經技術人員排查后的主要原因及解決方法如下：
1）導致漏單的原因：用戶在電腦的美團外賣商家版客戶端「開啟了自動接單」；
2）解決漏單的方法：請自行登錄電腦的美團外賣商家版客戶端檢查是否「開啟了自動接單」；如有請自行關閉，即可避免漏單的問題；
3）確認店鋪沒有在其他地方授權：如飛*云、易*云、其他三方軟件等；
4）確認其他終端不能開啟自動接單功能，如：手機、電腦和pos收銀機等；
問題五：外賣店鋪綁定成功后，出現丟單，如何處理？
答：
1）如是打印標簽，請確認菜品是否在佳博云平臺上選擇；
2）收集佳博云平臺賬號、終端編號、餓了么賬號、美團訂單號、出現故障的大概時間、打印機現象等提供給到云平臺技術排查。
問題六：外賣店鋪已綁定了，一直不出單是怎么回事？
答：
1）先確認店鋪是否授權成功，在云平臺對應的應用店鋪列表內查看是否能看到店鋪，如果沒有請嘗試重新授權綁定店鋪；
2）檢查店鋪是否設置了打印機，點擊對應的外賣店鋪，進入店鋪列表查看是否設置對了打印機。
3）檢查打印機是不是離線了？在云平臺首頁，點擊「終端列表」查看打印機狀態是否正常。
更多云打印問題，可直接聯系售后技術
電話：0756-3965060
TML 5雖然只是一個技術標準，但是眼下更多承載著顛覆蘋果與谷歌移動生態的理想。我并不想單純從技術角度談論HTML5的現實處境，因為技術從來不會成為發展的絕對瓶頸，尤其是HTML 5本身就不存在任何重大的技術難題。反而“商業”成了HTML 5發展無法逾越的鴻溝。只可惜“商業”從來都摻雜大量的投機成分，當然也有商業政治的成分。
HTML5所謂的“標準定稿”在我看來只是一場公眾秀。HTML 5標準自始至終就不是W3C組織一家的自留地，更不是唯一的代言人。原本W3C組織對外宣傳“要到2022年才會完成HTML 5正式標準的頒布”，現在為何又如此匆忙的定稿？這種定稿真的會對移動開發產生多大影響？
最糾結的10%
真正一直關心HTML 5的人會記得2012年7月的一個重大新聞，HTML5的兩個標準組織W3C和WHATWG因為“理念不合”決定分道揚鑣，這被看成一場IT界的商業政治事件。二者的根本理念差異是WHATWG認為HTML 5應該成為一個動態的標準既Living Standard，而W3C則認為應該形成一個固定的標準。導致這場事件升級的真正原因并不是“理念”這么簡單，而是二者各自代表的利益集團背后的推手。WHATWG向W3C叫板的底氣，正是來自Mozilla、蘋果和Opera的支持。W3C則選擇了微軟。
HTML5標準本身涉及的技術并無任何障礙，但是之前遲遲無法定案的原因則是錯綜復雜，緩慢的進度除了再一次證明這些組織是超級低效機構之外，所謂的利益和政治博弈才是直接導致了進度緩慢的真正原因。實際上截止2013年90%以上的HTML 5的標準早已完成，剩下的部分恰恰是各大利益集團博弈的重點，此次W3C代為發聲，明顯生米煮成熟飯的意味，這真的會奏效么？答案是完全否定的！因為各大金主不會因為一場PR活動就放棄自己的利益。
那么對開發者和技術用戶而言，W3C所謂的標準定案到底意味著什么？是否可以從中獲益？到底該如何看待這一“進步”？
這一切還要從W3C與WHATWG的分歧開始，動態標準還是固定的標準更適合開發者？我想，答案或許是WHATWG的Living Standard！因為沒有動態的標準，就不會有HTML 5的未來。未來HTML5想得到真正的發展，核心問題并不是標準哪天定稿亦或是瀏覽器性能不足，關鍵在于兩點，一是持續改進，二是生態。
龜速迭代
如果沒有一個持續改進的標準和為此而不斷努力的組織，HTML 5就只能把顛覆App生態當成一句口號，永遠充當配角。因為生態革新速度要遠大于開發者的行動速度。
IT world已經完全不是10年前的樣子，Cloud/Client“云與端”快速蠶食著傳統B/S架構（瀏覽器到服務器）的空間。端不特指“手機端”而是更廣泛的包含“pad端”“PC端”甚至“手表端”“汽車端”“家電端”等等。而相比PC時代，更多端的出現，代表著更多的硬件組合以及更多業務場景和功能。我們一直詬病W3C等標準組織行動緩慢，這次標準的公布很明顯沒有解決任何“云與端”復雜性的解決方案。我們設想一下：
場景A：以iphone的touchID為代筆的生物識別功能在各種端上興起，繼而產生了大量新的API，甚至可能今后帶有硬解的虹膜識別、聲紋識別等終端能力，在一個固定的HTML5標準下如何解決？HTML5附帶的device API甚至只涵蓋了feature phone時代的基礎通訊錄、攝像頭等功能，今天出現的touchID均無法有效調動，更何況2、3年后我們無法認知的新功能的標準配套實現。這種情況下不發展的HTML 5標準代表著“弱功能”
場景B：智能硬件的發展對藍牙和wifi使用以及驅動的需求迅猛增長，而HTML 5配套的對藍牙3.0驅動的支持標準何在？可以遵照標準的HTML 5亦或是配套的標準以及協議在瀏覽器內連接大部分的智能硬件么？答案當然也是全然否定的。這種未來最常見的常見之一都無法實現，那些大談HTML 5將會取代APP的人恐怕又會說“這些不是HTML 5擅長的，這種舉例毫無疑義”。那請問HTML 5擅長的只是排版布局和閱讀類亦或者一些低價游戲的APP么？更不要說對于NFC等很快可能成為終端標配的系統新能力，所以定稿后不發展的HTML 5標準代表著“弱擴展”
其實，這一切基于HTML 5的論點并非沒有明確的解決方案，簡單來說所謂的HTML 5定稿只是鬧劇和PR，如果真正期盼HTML 5挑戰App生態，一定要出現一個不停發展的動態標準，才能夠具備上場參賽的基礎。只是這倚重的是標準背后的“推手”和“金主”，那些想打造自己生態王國的大玩家。作為WHATWG的重要支柱，蘋果公司一直在低調中快速發展著自身的Web App技術，到今天為止，在iOS中已經有比Android和其他操作系統更成熟和完美的圍繞HTML 5和Web App的支持，只是遺憾的是蘋果公司只是把HTML 5當成技術，而沒有為打造HTML 5的生態做出任何其他的努力。
推不動的生態
2013年是HTML 5最低調的一年，因為在此前一年，眾多打擊接踵而至，除了用戶對HTML 5普遍負面的反饋之外，最嚴重的一次事件就是Facebook的徹底反水！
扎克伯格：我們過去最大的錯誤就是在HTML 5上面賭太大！
曾幾何時，面對HTML5扎克伯格野心勃勃的推動著“復制Facebook在PC端生態和霸權計劃”。眾所周知，蘋果的生態系統是相當封閉的，Android雖然開放但是也全面復制著蘋果的玩法iOS－>Developer－>APP－>Appstore－>User。所以Facebook全面推進HTML 5，妄圖跳開移動操作系統的掌控，擁抱HTML5和www的開放流量體系。
但是即便是Facebook如此重量級的玩家，最后也認栽了。無獨有偶，Linkedin作為又一風向標，在2013年也同樣放棄了HTML 5重新擁抱APP。到今天，難道短短的一年多，世界就發生了徹底的改變，HTML 5又重新具備了王者的氣質？當然是不可能的，世界上各個IT王國都沒有改變，改變的只是時間。
根據Flurry的報告，相比去年，2014年用戶在移動端的使用APP的份額進一步上升突破80%，而手機網站的使用情況進一步被擠壓。這說明用戶市場沒有將APP升級和下載當成多大的困難（至少沒你想像的那么困難），并且隨著App store更加人性和智能化的幫助用戶在wifi環境下自動升級等機制的普及，APP在使用上對用戶來說門檻越來越低，反而基于HTML5的Web App的使用和獲取倒是成了用戶的障礙。手機瀏覽器的用戶留存和使用情況越來越不樂觀，這個最重要的HTML 5的載體正在失去活力，反而大家寄望于超級APP，微信在中國眼下成了一根救命稻草。
當然想基于超級APP的形式打造自身閉環生態的廠商不止Facebook一家，反觀國內試水的大公司也很多，但均以鳴金收兵結尾。從UC的web app商店到百度的輕應用，構建基于移動web流量的生態系統無一成功。目前造成這種局面原因眾多，例如瀏覽器性能不足、HTML 5標準未定稿、無有效的web app發行渠道等等，但是正如我3年前說的，最核心的問題是移動開放流量體系和原生生態系統的對抗。
目前用戶從App store去搜索和下載app，在桌面存留app入口點擊使用，這已經成了iOS與Android生態系統下的固定模式。反而讓用戶進入超級APP，再通過搜索或連接的方式進入一個第三方web app，無論是從操作流程還是用戶最終體驗都無法和操作系統層級的體驗抗衡。而HTML 5標準定稿沒有為這種生態的困難帶來任何一點的改變，所以說HTML 5在W3C操縱下的所謂標準定稿，只是一場PR的鬧劇，雖然攪動了市場，但是也刺激了一批從業者充當炮灰。
期待新玩家
打造移動開放平臺和生態系統，微信是佼佼者，并且成功將部分App的流量轉化成了Web app的流量。微信也一路創新了導流手段，沒有選擇用戶網址輸入、也沒有選擇用戶搜索進入web app，而是把賬號變成網址并且直接收藏的方式，形成了一個特殊的“web app瀏覽器”。在打通了流量后又恰當的加入了支付手段，不但盤活了流量也讓流量變得更加有價值。
這給HTML 5開發者帶來了希望，不過很快又很失望，因為開發者發現微信對流量的管控超乎預期。這讓我想到了SNS時代開放平臺玩死眾多social game廠商的過去。中國有大的互聯網開放平臺，曾經的騰訊、人人甚至淘寶。但是總結規則無一不是“貔貅原則”流量只進不出，所謂的盤活流量只是為自身生態服務，雖然這樣無可厚非，只是對于開發者來說把自己的夢想嫁接在“中國版的開放平臺上”無異于“與虎謀皮”。因此HTML 5生態的建立或許可以借助開放平臺，但是真正可以對抗原生生態的HTML 5需要的是類似于WebOS這種更徹底的變革。
開發者對于HTML5的定稿，心態大可保持平和，短期內不會帶來任何的實質性改變。瀏覽器特別是操作系統廠商也不會因為W3C標準的定稿而放棄一直維護的自身利益，該支持的早已經支持，不該支持的也不會遵照標準去支持。只是HTML 5作為進步的一代標準，拋開利益和政治的博弈，還是會給開發者帶來更多的價值。只要不盲從，以學習的心態積極對待，仍會從中獲益。
HTML 5和配套的web開發技術具有跨平臺、低門檻的特性，目前大量的APP中廣泛使用了HTML5配合native development原生開發，極大的降低了APP整體的開發成本，更有一些移動應用引擎使用Javascript和HTML 5開發跨平臺native app，在不觸碰iOS與Android生態利益的前提下，發揮實用的價值。因此只要回歸到技術本身，把HTML 5技術應用到可以使用的場景中充分發揮價值，就可以逐步迎接更光明的未來。
2年前，移動開發領域掀起過一次行業大辯論“web app和native app誰死誰活”的問題。今天這個問題依然是一個有價值的問題。所以下一篇是，HTML 5盛宴（二）：再論Web app和Native app的未來。
本文作者劉鑫，移動云服務APICloud創始人兼CEO，從SP夢網時代就開始持續關注移動Web開發，個人郵箱hi.seanliu@yahoo.com
除非注明，本站文章均為原創或編譯，轉載請注明： 文章來自 36氪
36氪官方iOS應用正式上線，支持『一鍵下載36氪報道的移動App』和『離線閱讀』立即下載！
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
