基于互聯網的招投標平臺的構建研究

李娜 王少英

摘? 要：近年來，隨著“互聯網+”招投標的快速發展，人們開始體會到了信息技術所帶來的便利及快捷，同時也出現了一些新問題、新趨勢。文章就目前招投標的現狀進行分析，從系統的整體設計、數據爬取分析、數據存儲、移動端開發、后臺管理等幾個方面進行展開闡述，并對平臺在構建過程中面臨的風險進行了探究。

關鍵詞：互聯網;招投標平臺;構建

Abstract： In recent years， with the rapid development of Internet plus bidding， people begin to realize the convenience and speed brought by information technology， and also have some new problems and new trends. This paper analyzes the current situation of bidding， from the overall design of the system， data crawling analysis， data storage， mobile development， background management and other aspects， and explores the risks faced by the platform in the construction process.

1 概述

隨著互聯網技術、大數據技術的快速發展，招標采購業也有了創新性的發展，借助網絡平臺實現的新型招投標方式逐漸得到了應用。日本是世界上最早實現電子招投標的國家，隨后美國、德國、加拿大等國家都推行了電子招投標的方式。我國從90年代中期開始，地方政府開始依托相關部門開設互聯網門戶網站。2017年，國家發改委等六部委發布《“互聯網+”招標采購行動方案（2017-2019）》，并明確指出要實現互聯網與招投標的深度融合。

基于新一代信息技術，實現互聯網和傳統招投標行業的融合，能夠精準推送企業關注的招投標信息，使企業有的放矢，增加企業中標的幾率。但在實際的運行過程中，目前的招投標系統逐漸顯露出功能不完善、管理制度不健全等缺陷，這與我國的信息化設施建設、招投標的管理制度等有著很大的關系。

2 招投標存在的問題

2.1 文檔歸整方式不足

當前的招投標在文檔歸整方面有的是采用電子招投標平臺，而有的還是采用傳統的紙質方式進行。紙質的歸檔方式，勢必要投入大量的人力、物力，極易造成資源上的浪費，不利于招投標行業的快速發展。在互聯網時代，企業要轉變觀念，規范文檔的管理要求，實現無紙化的招投標方式。[1]

2.2 系統功能不完善

受傳統觀念的影響，某些地區仍然采用傳統的招投標模式，對電子招投標系統的應用還不夠重視，導致招投標系統的功能不夠完善。在互聯網技術快速發展的今天，招投標系統的功能將嚴重阻礙招標采購業的快速發展。因此，應該根據時代的要求，加強招投標系統的建設，并不斷完善系統的功能。[1]

2.3 沒有健全的管理制度

當前的招投標在實施過程中，大多是委托第三方代理機構來進行的。某些代理機構的內部管理比較混亂，相應的管理制度不夠健全，操作時缺乏相應的公平、公正、公開等原則。而且，在招投標代理機構中，某些工作人員的綜合素質水平相對較低，也不能充分勝任招投標的代理工作，嚴重影響了招投標工作的正常開展。[2]

2.4 資源缺乏共享

在當前的招投標行業中，信息之間缺乏對接，尤其是不同地區的平臺之間缺乏統一的數據標準接口以及資源共享。使得信息之間在傳遞時造成阻礙，企業可能因無法及時、準確的獲取招投標信息而喪失良機，而招標單位也可能由于信息的傳遞問題失去優秀的合作企業。因此，在系統建設過程中，應該加強數據標準接口的統一性，實現數據資源的共享。[3]

3 平臺構建原則

隨著大數據技術的快速發展，產生了大量的數據。如何應對爆炸式的數據增長，對于企業及個人來說都是一項挑戰。基于互聯網平臺實現招投標的應用，不僅能夠順應時代的潮流發展，而且能夠提高企業的工作效率。

3.1 平臺監管規范化

一個完善、健全的管理制度，能夠促進規范化交易平臺的建立。在平臺構建過程中，要遵循專業化、市場化的原則，從社會需求出發，編制相關的規范性文件，并不斷完善相關規定和細則。搭建規范化的監管平臺，加大監管力度，實現一個公平、公正的交易環境，以促進招投標行業的健康發展。

3.2 信息資源公開化

借助互聯網技術構建招投標平臺，能夠實現對信息資源的快速處理，并進行及時發布，確保了信息資源的時效性。利用網絡平臺對招投標信息的處理，提高了對信息處理的質量和效率，縮短了招投標的周期。同時，通過平臺發布的招投標信息，能夠實現信息資源的共享，促進了此項工作的公平、公正、公開性，杜絕了腐敗行為的滋生，提高了政府工作的公信度。

3.3 減少成本

以較低的成本實現利益的最大化是所有工作的出發點，通過構建的招投標平臺能夠對信息進行較好的統計以及分析，并且便于保存，避免了傳統紙質材料的失誤、遺漏以及資源浪費，能夠提高工作的效率。同時，借助網絡平臺實現的招投標，能夠確保流程的正常運行，也降低了相應的投資成本及運行成本。[2]

4 招投標平臺的構建過程

4.1 系統整體介紹

招投標平臺是互聯網思維和傳統招投標業務融合的產物，基于新一代信息技術，圍繞招投標過程提供信息聚合服務、信息推送服務，面向招標單位和投標單位提供招投標過程的增值服務，能夠解決企業招投標過程中遇到的各種問題。

招投標平臺主要分為面向終端應用的APP和后臺管理支撐系統，APP應用能夠提供招投標信息的查詢、訂閱和推送服務，面向注冊用戶主要提供招標信息之外的增值服務，如招標信息分析、招投標價格分析以及同類項目中標價格分析等附加功能，為投標企業和招標企業在制定招投標業務時提供參考。后臺管理系統面向后臺管理人員提供爬蟲信息的配置、運行監控等功能，后臺管理系統主要基于Hadoop平臺，實現對爬取的海量數據的存儲，基于開源Elasticsearch組件實現對海量數據的快速檢索功能。此外，后臺管理系統還提供算法中心功能，能夠對招標信息和中標信息進行分析，為前端用戶提供分析結果的輸出。

4.2 數據爬取及數據解析

從海量的招投標網站抓取網站上發布的招標信息、中標信息等，不同的招標網站由不同的網站開發商建設，在技術上存在很大的差異。因此，在數據的爬取上，系統設計上需要考慮通用型和個性化定制的需求，對于通用的網站，可以通過配置URL地址和簡單的規則實現網站信息的抓取;對于一些相對復雜的網站，系統需要提供自定義代碼的方式實現對數據信息的抓取。

在對抓取網站的數據解析上，需要結合通過正則表達式提取項目的基本信息，進行數據的存儲和展示，滿足投標人訂閱的需要。網站信息在爬取過程中，需要對網站的一些附件進行保存，同時保留原網頁完整的URL信息。

4.3 數據標簽定義

在大數據時代，數據呈現出海量化、多樣化和價值化等特點，如何從海量的數據中獲取并篩選出有價值的信息，是信息化的一大挑戰。通過構建招投標數據的標簽體系，能夠支撐精準招投標信息服務。

從短期來看，能夠對參與招投標的單位可能關注區域、招標類型（貨物、工程、服務）、采購單位等一些事實標簽進行定義，以實現招標項目名稱的定制化查詢。從中長期來看，單一的事實標簽已經無法滿足業務的發展，需要對招投標單位的屬性及行為等抽象和聚類，通過剖析招投標的基礎數據為招投標的項目和參與的人員貼上相應的總結概括性標簽及指數，以實現更精確的匹配。同時結合招標文件的內容，提煉關鍵字形成個性化的標簽，以滿足用戶更深層次數據應用的需求。

4.4 數據存儲及檢索實現

在平臺的構建過程中，主要面向互聯網提供應用服務。一方面需要通過互聯網抓取招投標的資訊信息，涉及到大量的結構化數據和非結構化的數據（如：招投標發布的附件信息等）;另一個方面，招投標系統需要面向大量的用戶提供信息檢索服務，需要產生高并發的數據查詢需求。

在結構化數據的存儲上主要采用Mysql數據庫，后續可以根據數據量和訪問量的大小，對數據庫實現水平和垂直切分;水平切分通過分庫實現，垂直切分通過分表實現，通過增加數據庫實例的數量，增加系統的承載能力和運行效率。對于非結構化數據，主要是招投標的文件，建議采用Hadoop的分布式文件系統實現。

4.5 移動端開發實現

移動端應用是面向終端用戶的服務平臺，在平臺層面需要提供較高的安全性和健壯性。同時，還要兼顧用戶體驗、面向當前移動終端的多端要求，需要考慮適配型，即開發一次可以實現面向多端、多種類型的適配。在業務層面，平臺可以為無注冊用戶、注冊用戶提供招標信息的查詢、訂閱、推送等功能，面向未來需要考慮平臺的開放性，隨著業務的發展，可以實現功能的快速擴充。

4.5.1 移動端開發框架

MUI是最接近原生App體驗的前端框架，可以實現一套代碼多個版本的發布。同時基于MUI的標準，增強移動開發使用的各種控件，能夠實現標準化的輸出，提升應用開發的效率。MUI框架配套Hbuilder的開發平臺，采用IDE的方式進行編碼設計，容易上手。自誕生以來，MUI受到了大多數互聯網企業的青睞，當前的版本基本上可以滿足商業應用的需求。

4.5.2 信息查詢

用戶登陸APP，會出現類似百度的搜索框界面，用戶可以通過輸入條件進行模糊查詢。也可以通過系統提供的的引導式搜索功能，按照行業、金額、時間、地區、類型等屬性進行模糊查詢。

系統基于ElasticSearch提供信息查詢功能，ElasticSearch 是一個分布式、高擴展、高實時的搜索與數據分析引擎，它能使大量數據具有搜索、分析和探索的能力。利用ElasticSearch的水平伸縮性，能夠使數據在生產環境變得更有價值。ElasticSearch 的實現原理主要分為以下幾個步驟，首先用戶將數據提交到ElasticSearch 數據庫中;再通過分詞控制器去將對應的語句分詞，將其權重和分詞結果一并存入數據;當用戶搜索數據的時候，再根據權重將結果進行排名、打分;最后將返回結果呈現給用戶。

4.5.3 信息訂閱

信息訂閱功能，是用戶通過對信息的發布時間、地區、關鍵字等進行訂閱設置，系統能夠向用戶自主推送符合訂閱條件的招投標信息，大大節省了用戶的時間以及精力。

在開發實現時，用戶訂閱功能通過采集用戶的訂閱需求，將相應采集到的關鍵字存儲到后臺系統中。系統后臺啟動線程，按照用戶的訂閱需求，定時進行匹配，對于匹配上的項目進行信息推送。信息訂閱功能，主要由前端的H5頁面和后臺的服務系統實現，前端H5頁面實現信息的展示、采集和提交，調用后臺管理系統的服務接口，提供訂閱信息到后臺中。

4.5.4 信息推送

對于完成訂閱的項目，用戶可以設定推送的時間、推送的頻次、推送方式等個性化的方式，從而為用戶提供良好的用戶體驗。

信息推送功能，是根據用戶訂閱信息，將后臺匹配的項目信息及時、準確的推送到用戶的APP中。系統集成Quartz組件，在后臺部署任務調度服務，通過調用ES的API接口，實現信息的高效檢索，從而生成信息的匹配結果。通過推送組件，能夠將匹配信息及時的推送到訂閱者的手機中，讓訂閱者第一時間掌握所關注的項目信息。

系統集成個推的SDK，能夠實現對終端信息的推送功能。個推是國內領先的推送技術服務商，主要提供消息的推送解決方案，能夠幫助企業和開發者快捷高效地建立推送系統。通過高效穩定推送SDK，使APP快速集成云推送功能，免去自行開發成本，上手容易，且免費應用。

4.6 系統開發平臺支撐及服務接口實現

系統采用Java的技術路線，并且面向互聯網提供服務，需要保證應用系統具有較高的可靠性和健壯性，同時面向互聯網海量訪問的需求，在架構層面需要支持應用的橫向擴展。移動APP和后臺管理系統之間通過服務接口調用，需要考慮互聯網環境帶來的運行風險，平臺層面需要做好數據的安全防護和訪問認證。

系統采用Sping cloud框架進行開發，簡化了分布式系統基礎設施的開發，如服務發現注冊、配置中心、消息總線、負載均衡、斷路器、數據監控等。采用分層設計理念（數據訪問層，業務邏輯層，展示層），層次清楚、低耦合，各層必須通過接口才能接入并進行參數校驗（如：在展示層不可直接操作數據庫），保證了數據操作的安全。

系統前后臺服務接口都是采用restful web服務架構方式，使用HTTP作為通訊方式，報文格式為JSON，交易信息存放在http的請求體中。HTTP頭部（header）中Content-Type屬性需設置為application/json;charset=utf-8，accept-type屬性設置為utf-8。

采用get、post提交方式，移動端采用rsa非對稱加密認證形式，先使用系統的公鑰對信息進行加密，然后使用系統設定的私鑰對原始信息進行簽名。后臺管理系統使用私鑰進行解密，解密后使用系統提供的公鑰對傳遞信息進行驗簽。

5 招投標平臺在構建過程中面臨的風險

5.1 爬蟲的技術風險

當前的爬蟲是通過對網站URL和頁面內容進行解析實現的，如果源網站發生改版或者規則進行了調整，會對爬蟲任務的正常進行產生影響。因此，需要在技術層面做好防范工作，做好系統執行任務的隔離，不會因為個別網站爬取任務的失敗而造成整體爬取的失敗。另外，對系統增加詳細的日志功能，做好運行狀態的監控和預警防范，一旦出現異常可以第一時間進行修復。

5.2 數據所有權風險

招投標平臺通過爬蟲的方式，能夠獲取政府和企業招投標網站公示的招投標信息，這些信息的所有權尚未明確。將這些數據通過爬蟲的方式獲取并對外提供服務，會存在一些法律上的模糊地帶，未來可能會存在風險。因此，平臺的運營方可以和政府、企業的招投標單位開展業務合作，通過正規途徑獲取招投標信息。平臺以專業化的優勢，將招投標的信息進行更大范圍的發布，讓更多的人員參與招投標的業務中，更好實現供需雙方的匹配，實現各方的共贏。

6 結束語

隨著信息技術的快速發展，基于互聯網的招投標平臺的構建得到了創新性發展。基于網絡平臺的招投標方式，可以方便人們對招投標信息的精準查找，實現對信息的自由訂閱及消息的個性化推送。縮短了招投標時間，降低了各項資源的消耗成本，從而實現了綠色采購。另外，基于互聯網的招投標平臺，對于時空的約束性也比較低，大大增加了投標方參與競爭的機會，便于實現招投標的良性競爭，保障了招投標的公平性、公正性、公開性。

參考文獻：

[1]黃煒.“互聯網+”時代招標采購業的創新與發展研究[J].全球流通經濟，2018（9）：28-29.

[2]劉忠明.基于互聯網的政府電子采購招投標平臺的構建[J].通訊世界，2017（10）：270-271.

[3]張遠.論電子招標與傳統招標[J].中外企業家，2020（2）：122-123.