基于云架構(gòu)的設備數(shù)據(jù)接口的效率研究與測試

摘 要：智能制造系統(tǒng)的實現(xiàn)需要依靠底層的基于產(chǎn)品生產(chǎn)過程和設備運行過程的數(shù)據(jù)采集，為提高系統(tǒng)復用性和降低部署的成本和難度，都會采用標準化的B/S模式的數(shù)據(jù)采集，當時間單位內(nèi)的采集數(shù)據(jù)量達到一定規(guī)模后，系統(tǒng)架構(gòu)的瓶頸就會凸顯，現(xiàn)在數(shù)據(jù)采集的方式和實現(xiàn)方法較多，我們希望通過一定的測試，得到適合需求是數(shù)據(jù)采集接口的實現(xiàn)方式。

關(guān)鍵詞：數(shù)據(jù)采集；C#；WebService；Restful Api；WebAPI；JSON

中圖分類號：TP393.08 文獻標識碼：A 文章編號：1004-7344（2018）17-0327-02

1 背 景

按集團公司和公司自身產(chǎn)品發(fā)展的要求，公司準備搭建基于云架構(gòu)的MES系統(tǒng)，需要將原來部署在各企業(yè)的MES系統(tǒng)的逐步遷移上云，系統(tǒng)運行時所需要的各類數(shù)據(jù)也需要逐步提交到云上。因最初MES系統(tǒng)設計和部署時，是作為企業(yè)的獨立應用存在，數(shù)據(jù)采集接口在設計時考慮因素較少，數(shù)據(jù)處理環(huán)節(jié)也較簡單，所以接口采用基于SOAP的WebService方式設計，而眾所周知的SOAP的處理方式效率較低、數(shù)據(jù)冗余量大，所以現(xiàn)有接口不適合繼續(xù)沿用，我們必須要重新構(gòu)建基于云服務的數(shù)據(jù)采集接口，而現(xiàn)在流行的接口實現(xiàn)方式較多，為解決接口問題并獲取最高效的接口，我們對相關(guān)接口技術(shù)進行了一定測試，希望可以幫助獲取有效數(shù)據(jù)和依據(jù)。

2 測試前期準備預計應用場景

為沿用系統(tǒng)構(gòu)架和降低成本，數(shù)據(jù)采集接口先期仍采用C#語言編寫，后期在需要進行平臺調(diào)整或架構(gòu)調(diào)整時，再對比.NetCore和Java進行重構(gòu)；因現(xiàn)在微軟.Net FrameWork可提供的基于HTTP方式的的Web訪問接口的實現(xiàn)方式較多，常見的有WebService、基于IIS Hander的Ashx頁面和基于Razor引擎的MVC的WebApi方式接口，我們將同時測試對比這三種接口的訪問和執(zhí)行效率。

3 測試場景設計基礎(chǔ)

3.1 數(shù)據(jù)采集情況

按系統(tǒng)設計，我公司的MES系統(tǒng)遷移后，前3年大約需連接數(shù)據(jù)采集設備1000～2000臺，而每臺設備通過物聯(lián)網(wǎng)及中間設備不定時的將與采集設備關(guān)聯(lián)的在運行中的設備、器具的各類數(shù)據(jù)匯總、封包后傳輸?shù)降皆破脚_的采集接口上，數(shù)據(jù)采集設備輪詢時間為1s，在獲取數(shù)據(jù)后及時傳輸?shù)綌?shù)據(jù)采集接口，根據(jù)采集設備運轉(zhuǎn)情況不同，單個采集設備每秒提交的數(shù)據(jù)峰值將不會超過100條數(shù)據(jù)。

3.2 數(shù)據(jù)格式說明

用于測試的數(shù)據(jù)按以下格式設計，主要考慮為盡量簡化數(shù)據(jù)類型，減小網(wǎng)絡傳輸帶寬。

3.3 測試數(shù)據(jù)提交方式的選擇

（1）系統(tǒng)每次隨機按上表格式產(chǎn)生50～100條數(shù)據(jù)，并將數(shù)據(jù)轉(zhuǎn)換為Json格式的字符串進行保存。

（2）通過Web工具分別向三個接口提交保存的字符串數(shù)據(jù)，并逐次記錄訪問接口所需的時間、成功率、1min內(nèi)完成的請求數(shù)。

（3）提交數(shù)據(jù)格式的確定

客戶端在通過WebService格式或WebApi提交數(shù)據(jù)時，根據(jù)接口接受參數(shù)類型的不同，系統(tǒng)會做一些自動處理，如可以把包含json數(shù)組的字符串直接轉(zhuǎn)換為接口設置的List對象，而在方法體內(nèi)，我們也可以編程實現(xiàn)數(shù)據(jù)轉(zhuǎn)換，在WebApi接口中使用字符串或同轉(zhuǎn)換方式的效率有需要通過測試確定，經(jīng)過測試，直接提交字符串的效率比使用特定格式的效率稍高，且考慮到實際使用時，為降低采集設備的使用帶寬，也不會采用提交json數(shù)據(jù)，所以測試還是以提交字符串為主。

（4）測試代碼

因測試主要是為測試三種接口方式的執(zhí)行效率。所以測試代碼皆盡量簡化：因研究的主要目的是為了測試三種不同的接口方式的執(zhí)行效率。所以作為測試數(shù)據(jù)的產(chǎn)生都按系統(tǒng)隨機產(chǎn)生50條數(shù)據(jù)，按上表格式組裝為json數(shù)組。

4 接口執(zhí)行效率測試

4.1 測試方式

用WestWindWebSurge程序，通過10線程提交包含200條信息的采集數(shù)據(jù)，持續(xù)1min，共執(zhí)行10次，取最后各項的平均值進行比較。

4.2 接口調(diào)用執(zhí)行效率

執(zhí)行此測試時，接口的方法體內(nèi)不做數(shù)據(jù)處理，直接返回0，主要測試IIS和.NetFrameWork在處理不同接口上的差異，測試結(jié)果如表3。

4.3 增加數(shù)據(jù)處理后接口執(zhí)行效率

執(zhí)行此測試時，接口的方法體需要將提交的字符串轉(zhuǎn)換為List對象，并返回對象長度，主要測試接口總體的執(zhí)行效率差異，測試結(jié)果如表4。

5 測試總結(jié)

經(jīng)過測試，大致結(jié)果與我們預期一致，Ashx接口因為沒有經(jīng)過.Net和IIS的相關(guān)引擎的處理，所以執(zhí)行效率最高，且由于Ashx方式可以方便的操作Http上下文，更利于接口功能擴展和處理，所以應是選擇實現(xiàn)接口的最優(yōu)方式。

6 其它考慮因素

（1）本次測試沒有測試接口的數(shù)據(jù)庫操作，因根據(jù)檢索以往的文檔，已可確定在.NetFrameWork系統(tǒng)中，ADO.NET是最快的數(shù)據(jù)庫訪問方式[2]；

（2）在客戶端或底層設備向云端的接口提交數(shù)據(jù)時，應想法盡量降低提交的數(shù)據(jù)量，減少帶寬，提高效率，生硬的規(guī)定使用XML格式或Json格式都不是好選擇；

（3）增加IIS進程數(shù)、采用數(shù)據(jù)緩存、集群服務器等技術(shù)都可以提高接口的數(shù)據(jù)處理效率，可在需要的時候采用。

參考文獻

[1]淡泊明智：SOAP webserivce和RESTful webservice對比及區(qū)別.

[2]Radenko Zec：8 ways to improve ASP.NET Web API performance.

收稿日期：2018-5-11

作者簡介：柏富強（1969-），男，助理工程師，大專，主要從事IT技術(shù)服務工作。