基于高并发融合技术提升电子采购标书解密效率

李生龙

北京京能招标集采中心有限责任公司 北京 102300

引言

在电子招标采购过程中，在投标环节，电子投标，给投标人带来极大的便利，减少了纸质标书打印和人为线下投递的痛点，降低了投标成本。同时在电子采购标书解密过程中，如果标书文件过大，可能会出现因解密速度慢导致系统无法快速处理的情况。本文阐述高并发融合技术，解决标书文件过大、解密速度慢的问题，给用户带来更舒适的体验。

1 高并发融合技术目标和定位

高并发是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指通过设计保证系统能够同时并行处理很多请求。在用户使用、投标开标等环节会使用。使用高并发融合技术，能将各种分布式、缓存、云计算、集群、队列综合起来，结合实际开标业务场景，解决开标解密文件大、时间要求短的痛点。

2 传统高并发的缺点

传统高并发技术基于电脑配置及线程池技术CDN加速，数据库优化，效率低下，扩展困难。使用集群是网站解决高并发、海量数据问题的常用手段。当一台服务器的处理能力、存储空间不足时，企图去更换更强大的服务器，对大型网站而言，不管多么强大的服务器，都满足不了网站持续增长的业务需求。

3 设计思路

微服务架构基于高内聚低耦合、高度自治、以业务为中心、弹性设计、日志与监控及自动化六大原则进行设计，在采用SpringCloud分布式服务框架和“松耦合”设计，支持微服务架构服务治理和容量线性扩展，可以在没有任何风险的条件下保证业务的成长[1]。使用集群是网站解决高并发、海量数据问题的常用手段。

这种情况下，更恰当的做法是：①增加多台服务器分担原有服务器的访问及存储压力。②将原有的计算复杂度进行分布式拆分。③Kubernetes进行容器编排进行动态扩展节点。④使用Redis和rocketMq集群队列解决排队并发压力问题。⑤使用高性能硬盘在数据、文件计算处提高性能， 这也是最关键的。

在分布式开发过程中，分布式事务是必须面临的问题。因为分布式系统中，存在多个服务之间的调用。服务与服务之间存在事务问题，可能在某个服务调用链过程中某个服务发生异常导致数据不一致问题。使用seata进行集群，保证系统的高可用。对网站架构而言，只要能通过增加一台服务器的方式改善负载压力，就可以以同样的方式持续增加服务器不断改善系统性能，从而实现系统的可伸缩性。应用服务器实现集群是网站可伸缩集群架构设计中较为简单成熟的一种。

4 实施方案

整体实施方案包含电子采购标书解密技术架构和业务架构，以及研究方案，技术架构及业务架构。

4.1 技术架构

技术架构是将应用架构中定义的各种应用组件映射为相应的技术组件，这些技术组件代表了各种可以从市场或组织内部获得的软件和硬件组件。由于技术架构定义了架构解决方案的物理实现，因而它与实施和迁移规划有着很强的关联。技术架构是一个或一套基础结构，用来开发大范围的不同架构，包括前端展示层、访问控制层、数据服务层、存储技术层、支撑服务层、运行资源层及DevOps。

4.2 业务架构

业务架构是用来将其后架构工作的业务价值阐述给相关干系人所必不可少的，并且针对信息的收集和分析也应该依据架构工作的范围而采用那些能够促成明智决策的信息。针对电子采购标书的解密，解密分为服务端解密和客户端解密两种摸索，客户端解密是由用户自行保管key、自行解密，集中解密是统一根据时间戳和授权一起集中解密，分为一次开标和两次开标。

4.3 研究方案

4.3.1 总体思路。采用了基于Java的前后端分离开发模式，前端采用了VUE + Element Ui，后端采用了阿里巴巴开源的SpringCloud Alibaba一套微服务解决方案。数据库使用的是mysql集群模式，扩展性、可靠性、安全性上给系统提供技术保障。扩展性通过分布式、集群资源充分利用、动态扩展等方案解决。可靠性及分布式事务通过seata解决。安全性通过oauth权限管理体系，防止越权，授权管理。缓存使用的是redis及rocketMq队列进行管控。

4.3.2 分布式解决方案。本方案分布式架构设计规划，主要包括整体架构设计、业务领域抽象、建模、服务规划与层次划分、数据库设计与划分、服务内流程、数据、接口定义和技术选型。

微服务架构基于高内聚低耦合、高度自治、以业务为中心、弹性设计、日志与监控以及自动化6大原则进行设计。解密分布式微服务计算优化方案，且开发代码必须严格按照以下约定及规则执行。

开发过程中仔细看命名规范表，业务，微服务，实体，数据库，表的归属，必须参考前后端代码规范，设计好接口，缕清业务逻辑，接口只是验证，接口和代码做到单一职能，轻量级，每个微服务对应的业务和数据实体只能在单一微服务，命名规范参考（命名规范）每个微服务对外提供数据库表结果操作的微服务接口及查询接口，每个微服务的查询按照实体相关拆分，service和mapper、dao、vo、dto只能增加，不能删改，如果有需要跨数据库的连表查询，建议使用表冗余存储，针对更新跨数据库必须调用微服务接口[2]。针对独立查询其他微服务，必须去其他微服务调用。没有的话就提供出来，所有更新状态都增加判断非正式条件。正式的不允许改。所有附件在附件微服务调用，解密存储附件的除外。只有相应权限的人才能操作对应的代码，否则需要告知模块负责人，谁需要服务谁去某个微服务里面写并告知，mode引用基础包，api引用基础和mode，微服务引用api、基础、mode包（一般微服务引用api就行，跨微服务可能单独引用mode）、jar包传递，打包从底层开始打。设计遵循类及方法的单一职责、关闭原则；只在有错误情况下才打开，需求只在扩展中实现，原则上产品提供出去的稳定的类和方法不要动。后端是否完成入参的完整性校验，数据库是否都增加索引，都需要监控。并且没有慢sql风险，例如修改、删除所有的风险，数据库关键字段的标准存储模型是否建立，数据库30万条压力测试是否完成，数据库高层次接口及调用其他微服务链条是否完成风险评估，比如数据量大、异常评估，是否存在高并发业务点，及并发操作会造成并发问题，需要用分布式锁解决，数据库每张表及字段的来源及更新是否清晰并描述清楚，是否完成代码走查问题都必须要跟踪直至问题关闭，而且要特别重视。除了增删改查，维护的数据，其他引用的数据都是正式的有效状态数据；很多地方都是没有根据数据类型已经有效状态查询，很容易随机通过get(0)随机出问题，用户ID不能从前台页面传过去，用户登录信息都是在session里面取的，MQ、Redis存储规范，必须按微服务有前缀，前端和其他类似全局变量都按此规范，不能重复，循环里面避免写sql，否则代码效率极低，sql里面多余的关联表和字段，多余的返回值，效率低下。关键数据只有一条的话，这些记录有效状态在某个供应商阶段里面需要做唯一存储限制，数据库层面和代码层面拦截，存储的数据库字段都存对了需要从数据库层面检查。每个微服务正确数据的场景标识出来，在详细设计里面。微服务的简称在这高层次接口里面，涉及定义类型的都需要微服务的简称开头；例如Redis代号，类型代号等不能提供对外传入路径读写本地文件方法。

4.3.3 大数据解决方案。采购标书中大规模数据的解决需要通过数据采集、数据分析、数据处理和分析性能调优和监控、可视化和报表等过程[3]。

基于Flink和Elasticsearch的全栈大数据开发技术体系，可以用来构建一个完整的系统。

数据采集和存储层：使用Apache Kafka作为流处理平台和消息队列，接收并缓存数据，可以使用HDFS或Amazon S3进行长期存储。

流处理层：使用Apache Flink作为流处理引擎，对实时数据进行处理和分析，包括数据清洗、过滤、转换和计算等。

数据存储和查询层：使用Elasticsearch作为实时数据存储和查询引擎，支持全文搜索、聚合查询和可视化展示等功能。

分析和可视化层：使用Kibana作为数据可视化和仪表盘工具，支持创建各种可视化图表和仪表盘，以及实时监控和警报功能。

4.3.4 分布式事务解决方案。微服务架构和传统的单体架构不一样，所以为存在分布式事务。在单体架构中一整套项目只对应一个数据库，也就是之后一个数据库事务，在微服务架构中每个服务对应一个数据库，在它服务与服务之间调用的情况下，例如：A服务调用B服务，在A服务中进行操作了一下DB是成功的，B服务是失败的，这样的情况下程序的数据上就会出现问题，保证要么都成功，要么都失败，这样的情况下就要用到分布式事务来进行解决这个问题。

通过Seata技术组建，使用数据库存储seata缓存数据的摸索，同时利于seata集群技术，可以有效解决标书解密因为分布式事务导致的问题。

4.3.5 运行效果指标。模拟2万家次同时远程开标，投标文件大小50～100M不等，通过上述方案。商务标解密紧使用了35min左右，经济标约10min左右。服务器详细性能如下：

本次测试一共增加35台tomcat服务器。发现性能并未提升反而下降。最终调整至25台服务器。以下服务器CPU/内存使用率都在5%以内，没有服务器压力，各项指标均处于极低状态。

（1）NAS性能吞吐量（秒级）。优化后的NAS每秒性能吞吐读写：每秒达到1.65G/S，云服务器已经对该账号的所有NAS进行了实时性能配置。后期无限扩张NAS可随着NAS增大而实时增加性能。

（2）SLB四层负载指标。使用四层负载，最大可连接数8万。带宽可使用按量计费，最大可设置支持5000M带宽峰值。本次限制带宽峰值200M。使用率都在5%以内，没有服务器压力。

（3）远程开标RDS数据指标。解密过程中数据库CPU使用率都在5%以内，没有服务器压力。

（4）上传远程开标结果RDS数据库压力指标。目前使用16核64G数据库，CPU和内存使用率都在5%以内，没有服务器压力。

（5）Redis缓存指标。Redis最多时存放了20万条KEY，释放时间30分钟。Redis使用率都在5%以内，没有服务器压力。

5 应用效果

通过高并发融合技术方案，能够大幅提高解密速度，通过单微服务能支持25台电脑集群解密，解密速度高达到42.1G/s远高于电子招标投标系统检测技术规范标准要求的1GB/s。

6 结束语

在实现高并发性能、可扩展性、高可用性和灵活性方面都具有很大的优势，通过高并发融合技术方案，使用多项技术融合使用集成，最大程度的提高并发能力及稳定性，满足网站持续增长的业务需求，提高了企业电子采购标书解密效率、经济效益及用户体验。