基于高并發(fā)融合技術(shù)提升電子采購(gòu)標(biāo)書解密效率

李生龍

北京京能招標(biāo)集采中心有限責(zé)任公司 北京 102300

引言

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

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

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

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

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

3 設(shè)計(jì)思路

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

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

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

4 實(shí)施方案

整體實(shí)施方案包含電子采購(gòu)標(biāo)書解密技術(shù)架構(gòu)和業(yè)務(wù)架構(gòu)，以及研究方案，技術(shù)架構(gòu)及業(yè)務(wù)架構(gòu)。

4.1 技術(shù)架構(gòu)

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

4.2 業(yè)務(wù)架構(gòu)

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

4.3 研究方案

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

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

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

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

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

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

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

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

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

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

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

通過(guò)Seata技術(shù)組建，使用數(shù)據(jù)庫(kù)存儲(chǔ)seata緩存數(shù)據(jù)的摸索，同時(shí)利于seata集群技術(shù)，可以有效解決標(biāo)書解密因?yàn)榉植际绞聞?wù)導(dǎo)致的問(wèn)題。

4.3.5 運(yùn)行效果指標(biāo)。模擬2萬(wàn)家次同時(shí)遠(yuǎn)程開(kāi)標(biāo)，投標(biāo)文件大小50～100M不等，通過(guò)上述方案。商務(wù)標(biāo)解密緊使用了35min左右，經(jīng)濟(jì)標(biāo)約10min左右。服務(wù)器詳細(xì)性能如下：

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

（1）NAS性能吞吐量（秒級(jí)）。優(yōu)化后的NAS每秒性能吞吐讀寫：每秒達(dá)到1.65G/S，云服務(wù)器已經(jīng)對(duì)該賬號(hào)的所有NAS進(jìn)行了實(shí)時(shí)性能配置。后期無(wú)限擴(kuò)張NAS可隨著NAS增大而實(shí)時(shí)增加性能。

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

（3）遠(yuǎn)程開(kāi)標(biāo)RDS數(shù)據(jù)指標(biāo)。解密過(guò)程中數(shù)據(jù)庫(kù)CPU使用率都在5%以內(nèi)，沒(méi)有服務(wù)器壓力。

（4）上傳遠(yuǎn)程開(kāi)標(biāo)結(jié)果RDS數(shù)據(jù)庫(kù)壓力指標(biāo)。目前使用16核64G數(shù)據(jù)庫(kù)，CPU和內(nèi)存使用率都在5%以內(nèi)，沒(méi)有服務(wù)器壓力。

（5）Redis緩存指標(biāo)。Redis最多時(shí)存放了20萬(wàn)條KEY，釋放時(shí)間30分鐘。Redis使用率都在5%以內(nèi)，沒(méi)有服務(wù)器壓力。

5 應(yīng)用效果

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

6 結(jié)束語(yǔ)

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