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

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

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

中圖分類號：TP393.08 文獻(xiàn)標(biāo)識碼：A 文章編號：1004-7344（2018）17-0327-02

1 背 景

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

2 測試前期準(zhǔn)備預(yù)計(jì)應(yīng)用場景

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

3 測試場景設(shè)計(jì)基礎(chǔ)

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

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

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

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

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

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

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

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

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

（4）測試代碼

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

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

4.1 測試方式

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

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

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

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

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

5 測試總結(jié)

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

6 其它考慮因素

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

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

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

參考文獻(xiàn)

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

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

收稿日期：2018-5-11

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