基于高并發(fā)融合技術提升電子采購標書解密效率

李生龍

北京京能招標集采中心有限責任公司 北京 102300

引言

在電子招標采購過程中，在投標環(huán)節(jié)，電子投標，給投標人帶來極大的便利，減少了紙質標書打印和人為線下投遞的痛點，降低了投標成本。同時在電子采購標書解密過程中，如果標書文件過大，可能會出現(xiàn)因解密速度慢導致系統(tǒng)無法快速處理的情況。本文闡述高并發(fā)融合技術，解決標書文件過大、解密速度慢的問題，給用戶帶來更舒適的體驗。

1 高并發(fā)融合技術目標和定位

高并發(fā)是互聯(lián)網分布式系統(tǒng)架構設計中必須考慮的因素之一，它通常是指通過設計保證系統(tǒng)能夠同時并行處理很多請求。在用戶使用、投標開標等環(huán)節(jié)會使用。使用高并發(fā)融合技術，能將各種分布式、緩存、云計算、集群、隊列綜合起來，結合實際開標業(yè)務場景，解決開標解密文件大、時間要求短的痛點。

2 傳統(tǒng)高并發(fā)的缺點

傳統(tǒng)高并發(fā)技術基于電腦配置及線程池技術CDN加速，數(shù)據(jù)庫優(yōu)化，效率低下，擴展困難。使用集群是網站解決高并發(fā)、海量數(shù)據(jù)問題的常用手段。當一臺服務器的處理能力、存儲空間不足時，企圖去更換更強大的服務器，對大型網站而言，不管多么強大的服務器，都滿足不了網站持續(xù)增長的業(yè)務需求。

3 設計思路

微服務架構基于高內聚低耦合、高度自治、以業(yè)務為中心、彈性設計、日志與監(jiān)控及自動化六大原則進行設計，在采用SpringCloud分布式服務框架和“松耦合”設計，支持微服務架構服務治理和容量線性擴展，可以在沒有任何風險的條件下保證業(yè)務的成長[1]。使用集群是網站解決高并發(fā)、海量數(shù)據(jù)問題的常用手段。

這種情況下，更恰當?shù)淖龇ㄊ牵孩僭黾佣嗯_服務器分擔原有服務器的訪問及存儲壓力。②將原有的計算復雜度進行分布式拆分。③Kubernetes進行容器編排進行動態(tài)擴展節(jié)點。④使用Redis和rocketMq集群隊列解決排隊并發(fā)壓力問題。⑤使用高性能硬盤在數(shù)據(jù)、文件計算處提高性能， 這也是最關鍵的。

在分布式開發(fā)過程中，分布式事務是必須面臨的問題。因為分布式系統(tǒng)中，存在多個服務之間的調用。服務與服務之間存在事務問題，可能在某個服務調用鏈過程中某個服務發(fā)生異常導致數(shù)據(jù)不一致問題。使用seata進行集群，保證系統(tǒng)的高可用。對網站架構而言，只要能通過增加一臺服務器的方式改善負載壓力，就可以以同樣的方式持續(xù)增加服務器不斷改善系統(tǒng)性能，從而實現(xiàn)系統(tǒng)的可伸縮性。應用服務器實現(xiàn)集群是網站可伸縮集群架構設計中較為簡單成熟的一種。

4 實施方案

整體實施方案包含電子采購標書解密技術架構和業(yè)務架構，以及研究方案，技術架構及業(yè)務架構。

4.1 技術架構

技術架構是將應用架構中定義的各種應用組件映射為相應的技術組件，這些技術組件代表了各種可以從市場或組織內部獲得的軟件和硬件組件。由于技術架構定義了架構解決方案的物理實現(xiàn)，因而它與實施和遷移規(guī)劃有著很強的關聯(lián)。技術架構是一個或一套基礎結構，用來開發(fā)大范圍的不同架構，包括前端展示層、訪問控制層、數(shù)據(jù)服務層、存儲技術層、支撐服務層、運行資源層及DevOps。

4.2 業(yè)務架構

業(yè)務架構是用來將其后架構工作的業(yè)務價值闡述給相關干系人所必不可少的，并且針對信息的收集和分析也應該依據(jù)架構工作的范圍而采用那些能夠促成明智決策的信息。針對電子采購標書的解密，解密分為服務端解密和客戶端解密兩種摸索，客戶端解密是由用戶自行保管key、自行解密，集中解密是統(tǒng)一根據(jù)時間戳和授權一起集中解密，分為一次開標和兩次開標。

4.3 研究方案

4.3.1 總體思路。采用了基于Java的前后端分離開發(fā)模式，前端采用了VUE + Element Ui，后端采用了阿里巴巴開源的SpringCloud Alibaba一套微服務解決方案。數(shù)據(jù)庫使用的是mysql集群模式，擴展性、可靠性、安全性上給系統(tǒng)提供技術保障。擴展性通過分布式、集群資源充分利用、動態(tài)擴展等方案解決?？煽啃约胺植际绞聞胀ㄟ^seata解決。安全性通過oauth權限管理體系，防止越權，授權管理。緩存使用的是redis及rocketMq隊列進行管控。

4.3.2 分布式解決方案。本方案分布式架構設計規(guī)劃，主要包括整體架構設計、業(yè)務領域抽象、建模、服務規(guī)劃與層次劃分、數(shù)據(jù)庫設計與劃分、服務內流程、數(shù)據(jù)、接口定義和技術選型。

微服務架構基于高內聚低耦合、高度自治、以業(yè)務為中心、彈性設計、日志與監(jiān)控以及自動化6大原則進行設計。解密分布式微服務計算優(yōu)化方案，且開發(fā)代碼必須嚴格按照以下約定及規(guī)則執(zhí)行。

開發(fā)過程中仔細看命名規(guī)范表，業(yè)務，微服務，實體，數(shù)據(jù)庫，表的歸屬，必須參考前后端代碼規(guī)范，設計好接口，縷清業(yè)務邏輯，接口只是驗證，接口和代碼做到單一職能，輕量級，每個微服務對應的業(yè)務和數(shù)據(jù)實體只能在單一微服務，命名規(guī)范參考（命名規(guī)范）每個微服務對外提供數(shù)據(jù)庫表結果操作的微服務接口及查詢接口，每個微服務的查詢按照實體相關拆分，service和mapper、dao、vo、dto只能增加，不能刪改，如果有需要跨數(shù)據(jù)庫的連表查詢，建議使用表冗余存儲，針對更新跨數(shù)據(jù)庫必須調用微服務接口[2]。針對獨立查詢其他微服務，必須去其他微服務調用。沒有的話就提供出來，所有更新狀態(tài)都增加判斷非正式條件。正式的不允許改。所有附件在附件微服務調用，解密存儲附件的除外。只有相應權限的人才能操作對應的代碼，否則需要告知模塊負責人，誰需要服務誰去某個微服務里面寫并告知，mode引用基礎包，api引用基礎和mode，微服務引用api、基礎、mode包（一般微服務引用api就行，跨微服務可能單獨引用mode）、jar包傳遞，打包從底層開始打。設計遵循類及方法的單一職責、關閉原則；只在有錯誤情況下才打開，需求只在擴展中實現(xiàn)，原則上產品提供出去的穩(wěn)定的類和方法不要動。后端是否完成入參的完整性校驗，數(shù)據(jù)庫是否都增加索引，都需要監(jiān)控。并且沒有慢sql風險，例如修改、刪除所有的風險，數(shù)據(jù)庫關鍵字段的標準存儲模型是否建立，數(shù)據(jù)庫30萬條壓力測試是否完成，數(shù)據(jù)庫高層次接口及調用其他微服務鏈條是否完成風險評估，比如數(shù)據(jù)量大、異常評估，是否存在高并發(fā)業(yè)務點，及并發(fā)操作會造成并發(fā)問題，需要用分布式鎖解決，數(shù)據(jù)庫每張表及字段的來源及更新是否清晰并描述清楚，是否完成代碼走查問題都必須要跟蹤直至問題關閉，而且要特別重視。除了增刪改查，維護的數(shù)據(jù)，其他引用的數(shù)據(jù)都是正式的有效狀態(tài)數(shù)據(jù)；很多地方都是沒有根據(jù)數(shù)據(jù)類型已經有效狀態(tài)查詢，很容易隨機通過get(0)隨機出問題，用戶ID不能從前臺頁面?zhèn)鬟^去，用戶登錄信息都是在session里面取的，MQ、Redis存儲規(guī)范，必須按微服務有前綴，前端和其他類似全局變量都按此規(guī)范，不能重復，循環(huán)里面避免寫sql，否則代碼效率極低，sql里面多余的關聯(lián)表和字段，多余的返回值，效率低下。關鍵數(shù)據(jù)只有一條的話，這些記錄有效狀態(tài)在某個供應商階段里面需要做唯一存儲限制，數(shù)據(jù)庫層面和代碼層面攔截，存儲的數(shù)據(jù)庫字段都存對了需要從數(shù)據(jù)庫層面檢查。每個微服務正確數(shù)據(jù)的場景標識出來，在詳細設計里面。微服務的簡稱在這高層次接口里面，涉及定義類型的都需要微服務的簡稱開頭；例如Redis代號，類型代號等不能提供對外傳入路徑讀寫本地文件方法。

4.3.3 大數(shù)據(jù)解決方案。采購標書中大規(guī)模數(shù)據(jù)的解決需要通過數(shù)據(jù)采集、數(shù)據(jù)分析、數(shù)據(jù)處理和分析性能調優(yōu)和監(jiān)控、可視化和報表等過程[3]。

基于Flink和Elasticsearch的全棧大數(shù)據(jù)開發(fā)技術體系，可以用來構建一個完整的系統(tǒng)。

數(shù)據(jù)采集和存儲層：使用Apache Kafka作為流處理平臺和消息隊列，接收并緩存數(shù)據(jù)，可以使用HDFS或Amazon S3進行長期存儲。

流處理層：使用Apache Flink作為流處理引擎，對實時數(shù)據(jù)進行處理和分析，包括數(shù)據(jù)清洗、過濾、轉換和計算等。

數(shù)據(jù)存儲和查詢層：使用Elasticsearch作為實時數(shù)據(jù)存儲和查詢引擎，支持全文搜索、聚合查詢和可視化展示等功能。

分析和可視化層：使用Kibana作為數(shù)據(jù)可視化和儀表盤工具，支持創(chuàng)建各種可視化圖表和儀表盤，以及實時監(jiān)控和警報功能。

4.3.4 分布式事務解決方案。微服務架構和傳統(tǒng)的單體架構不一樣，所以為存在分布式事務。在單體架構中一整套項目只對應一個數(shù)據(jù)庫，也就是之后一個數(shù)據(jù)庫事務，在微服務架構中每個服務對應一個數(shù)據(jù)庫，在它服務與服務之間調用的情況下，例如：A服務調用B服務，在A服務中進行操作了一下DB是成功的，B服務是失敗的，這樣的情況下程序的數(shù)據(jù)上就會出現(xiàn)問題，保證要么都成功，要么都失敗，這樣的情況下就要用到分布式事務來進行解決這個問題。

通過Seata技術組建，使用數(shù)據(jù)庫存儲seata緩存數(shù)據(jù)的摸索，同時利于seata集群技術，可以有效解決標書解密因為分布式事務導致的問題。

4.3.5 運行效果指標。模擬2萬家次同時遠程開標，投標文件大小50～100M不等，通過上述方案。商務標解密緊使用了35min左右，經濟標約10min左右。服務器詳細性能如下：

本次測試一共增加35臺tomcat服務器。發(fā)現(xiàn)性能并未提升反而下降。最終調整至25臺服務器。以下服務器CPU/內存使用率都在5%以內，沒有服務器壓力，各項指標均處于極低狀態(tài)。

（1）NAS性能吞吐量（秒級）。優(yōu)化后的NAS每秒性能吞吐讀寫：每秒達到1.65G/S，云服務器已經對該賬號的所有NAS進行了實時性能配置。后期無限擴張NAS可隨著NAS增大而實時增加性能。

（2）SLB四層負載指標。使用四層負載，最大可連接數(shù)8萬。帶寬可使用按量計費，最大可設置支持5000M帶寬峰值。本次限制帶寬峰值200M。使用率都在5%以內，沒有服務器壓力。

（3）遠程開標RDS數(shù)據(jù)指標。解密過程中數(shù)據(jù)庫CPU使用率都在5%以內，沒有服務器壓力。

（4）上傳遠程開標結果RDS數(shù)據(jù)庫壓力指標。目前使用16核64G數(shù)據(jù)庫，CPU和內存使用率都在5%以內，沒有服務器壓力。

（5）Redis緩存指標。Redis最多時存放了20萬條KEY，釋放時間30分鐘。Redis使用率都在5%以內，沒有服務器壓力。

5 應用效果

通過高并發(fā)融合技術方案，能夠大幅提高解密速度，通過單微服務能支持25臺電腦集群解密，解密速度高達到42.1G/s遠高于電子招標投標系統(tǒng)檢測技術規(guī)范標準要求的1GB/s。

6 結束語

在實現(xiàn)高并發(fā)性能、可擴展性、高可用性和靈活性方面都具有很大的優(yōu)勢，通過高并發(fā)融合技術方案，使用多項技術融合使用集成，最大程度的提高并發(fā)能力及穩(wěn)定性，滿足網站持續(xù)增長的業(yè)務需求，提高了企業(yè)電子采購標書解密效率、經濟效益及用戶體驗。