选自《证券基金行业信息技术应用创新前沿》第一期

国信证券OA系统及质量保障体系信创建设

文|刘芳 陆文博 陈福雄

国信证券股份有限公司

刘芳 liufang1@guosen.com.cn

陆文博 luwenbo@guosen.com.cn

陈福雄 chenfuxiong@guosen.com.cn

信息技术应用创新(简称“信创”)是国家重点战略,其目标是建立我国自主可控的IT底层架构和标准。国信证券作为证券行业第一批试点单位于2020年6月启动办公系统(以下简称OA系统)信创适配项目,经过17个月的迭代、升级、技术攻关,系统性能与稳定性得到持续提升,于2021年12月初实现OA系统单轨运行,顺利通过验收。本文主要分享国信证券OA系统的信创适配技术方案、成果、以及过程中的技术攻关与系统质量保障体系建设经验。

概述

信息技术应用创新(简称“信创”)是国家重点战略,其目标是建立我国自主可控的IT底层架构和标准。包括基础硬件(芯片、服务器整机、安全设备)、基础软件(操作系统、数据库、中间件),应用软件(办公软件、通用软件、行业软件)。

国信证券办公系统(以下简称OA系统)信创适配项目是一个全方面、多层次的系统级适配和改造工程。在集成信创服务器、操作系统、数据库、中间件、应用软件过程中,在各个层面经历和克服了一系列问题和难关。

OA系统信创适配改造过程中,为高效定位、诊断、解决问题,项目团队不断探索方法 、总结经验,开发和投产了整套质量保障工具,为大幅提升系统性能与稳定性发挥了关键作用,切实保障系统安全稳定运行。

OA系统信创适配

软硬件环境

国信证券OA系统运行在全信创环境,具体配置见表1-1:

表1-1 OA系统软硬件配置

部署架构

系统部署架构详见图1-1。系统支持信创电脑+信创浏览器、非信创电脑、手机端、平板端多端使用。

图1-1 OA系统部署架构

技术攻关记录

国信证券OA系统在信创适配过程中,遇到了包括服务器、操作系统、数据库、中间件、应用软件在内的一系列问题,进行了诸多配置优化和系统升级,最终实现系统稳定运行。详细的异常现象及原因、优化方案及优化效果见表格1-2。

问题层面

异常现象

异常原因

优化方案

优化效果

操作系统

麒麟v10

OA文件下载请求大量出现响应过慢

文件服务器故障;

内存以及交换分区被打满,使用率超95%,应用程序频繁出现oom,内核态进程iommu_iova占用了230G内存

1.关闭服务器BIOS的SMMU使能,启动后检查硬件设备iommu组绑定已消失;

2.修改grub文件,添加iommu_passthrough=1参数,重启服务器;

3.增加定时监测iommu_iova进程任务,后续继续观察系统运行状态

异常消除

OpenJDK

1.8.0.131

1、CPU在若干线程飙升至100%且不下降,系统响应缓慢

2、应用程序用户会话在并发登录场景下出现被他人覆盖现象

3、并发场景下出现JSP标签解析报错现象

OpenJDK

1.8.0.131

并发bug导致

替换为华为毕昇jdk1.8.0.272

异常消除,

CPU消耗降至3%

1、压测发现CPU线程消耗大户为C2 Compiler

2、CodeCache 使用率达95%

CodeCache默认128MB,明显不足,JVM编译线程忙于将字节码翻译为机器码,无法复用前期缓存

CodeCache=512MB

CPU消耗

下降50%

web中间件

东方通7041

1、大量JSP标签报500错误、系统无法正常使用

蓝凌JSP版本与东方通7041版本

默认的servlet版本不兼容

替换东方通提供的补丁包tongweb.jar

异常消除

当并发线程达到30左右,全系统无响应(所有东方通的端口无响应),观察TCP连接状态发现大量CLOSE_WAIT

东方通默认设置触发快照的条件(cpu、内存、线程并发数等阈值),该条件在生产环境非常容易触发快照生成。snapshot的生成过程还进行了内存dump操作,系统暂停了处理业务请求。

取消东方通快照生产时的内存dump选项,并将生成快照的条件调整为更严格

异常消除

1、运行系统多日后老年代内存持续上涨未见回收(数据迁移量足够大、用户访问足够多才凸显该问题)

2、某个业务高峰期出现内存不足

东方通默认缓存JSP标签且不释放,存在内存泄露问题

bin/external.vmoptions中添加

-Dcom.tongweb.jasper.runtime.JspFactoryImpl.USE_POOL=false(取消缓存JSP标签)

异常消除

内存回收

效果明显

数据库

达梦8

1、3台web服务器连接数瞬间激增,但内存消耗正常,cpu正常

2、数据库连接数激增,cpu使用率99%

3、整个系统失去响应,捕获到相应慢sql,加索引,问题依旧没解决

达梦数据库统计信息未同步更新,SQL走全表扫描,应用层面有若干表数据激增,而相关请求正好来自首页,并发量高,对数据库压力大。

1、配置每周日晚8点自动更新全库统计信息

2、优化操作系统IO调度策略,由fair改为deadline(提升整体IO吞吐量)

异常消除,

性能提升300%

1、3台web服务器连接数瞬间激增,

但内存消耗正常,cpu正常

2、数据库连接数激增,cpu使用率90%,iowait 30%,内存严重不足,swap区使用9GB,数据库日志爆出内存溢出错误

3、整个系统失去响应

1:应用层查询数据量过大、SQL未进行全面优化,引发大量慢查询耗尽数据库资源

2:达梦数据库未对会话内存限制导致系统内存溢出。

1、启动慢查询日志逐条优化出现频率较高、中间结果集较大的慢sql

2、达梦配置调优:

【disql】

sp_set_para_value(1,"MAX_SESSION_MEMORY",2048);--限制单session最大内存为2GB;

【dm.ini】

FAST_POOL_PAGES 99999 --增加快速缓存区页数,提升IO性能;

ENABLE_FREQROOTS 1 -- 动态调整FAST_POOL内容,提升缓存命中率;

异常消除

数据库

服务器

访问高峰期磁盘IO的平均等待时间上升至20ms,util%指标持续100%,

IOPS > 1500,

API平均响应时间上升3倍,用户端感受严重阻塞,持续5分钟左右后恢复。

SAS盘已经无法胜任IOPS高于1500的随机IO

1、磁盘升级为SSD盘

2、将数据文件与日志文件分别放在不同磁盘,分流IO

异常消除

稳定性提升

表1-2 OA信创适配技术攻关记录

关键性能表现

国信OA系统包含流程管理、公文通知、新闻管理、任务管理等50+模块,注册账号1.5万+,日均待办2万+。经过持续监控和优化,各系统性能指标见表1-3和表1-4。

相比项目初期,平均响应时间由极其不稳定的500ms降至稳定的50ms,响应速度提升9倍。单机并发50提升至400+,提升7倍。WEB服务器CPU在若干线程飙升至100%的异常完全消除,总CPU消耗全天维持在3%内;内存回收状况良好,全天动态平衡在预定容量的50%,峰值不超80%。

WEB服务器

基本指标

同时段活跃人数峰值

4100

全系统QPS峰值

997

HTTP平均响应时间峰值

60ms(工作时段)

HTTP平均响应时间

50ms (工作时段)

基础资源

CPU消耗全天峰值

< 3% ( 96核 )

总内存占用

< 30GB / 64GB

GC

吞吐量

99.849%

平均GC时间

50.7ms

最长GC时间

3.19s

表1-3 OA系统WEB服务器性能指标

数据库服务器

基础资源

CPU消耗全天峰值

< 3% ( 96核 )

内存占用

< 50GB / 128GB

IOPS峰值

2551

平均IO等待时间

< 4ms

表1-4 OA系统数据库服务器性能指标

质量保障体系工具建设

概述

与常用的非信创软硬件比,信创基础软硬件商用时间短、商用范围小,应用系统进行信创适配面临的问题多样。在国信OA系统的信创适配改造中,项目组逐步形成了一套闭环的质量保障流程(见图2-1)。为提升各流程节点工作效率,团队通过自研工具覆盖各流程节点需求。

版本回归:基于自研的HTTP流量回放工具,通过捕捉运行时异常及新老版本响应内容差异实现版本回归测试,代替低效的手工测试。

性能压测:基于自研的HTTP流量回放工具,通过设计请求重编排算法可获得高于生产环境数倍压力,具有接口覆盖面广、生产模拟程度高、无需人工编写测试脚本等优点。

性能监控:基于Zabbix平台调用自定义监控脚本获取监控数据,结合Grafana实现可视化。

实时告警:基于Zabbix平台的实时告警功能,推送至企业微信。

问题定位:JVM诊断平台支持多人在线协同诊断。

图2-1 OA系统质量保障体系

流量回放平台

1、基于流量回放的性能压测方案

为全面预估系统性能,定位系统瓶颈、明确优化方向,国信OA信创项目组自研了基于HTTP日志回放的自动化压测系统。系统部署架构详见图2-2。生产环境、回放环境之间实现了数据、附件文件、日志文件的定期同步。为便于观察压测性能,回放环境搭建了ES-APM监控平台。

图2-2 OA流量回放部署架构

流量回放的基本原理为:生产环境NGINX负责记录HTTP请求日志,回放环境通过解析该日志并重新构造HTTP请求进行重放。

与其他应用相比,OA系统基于流量回放进行压测面临两个主要难题:

1)日志回放过程中产生的对象ID为随机数,后续日志请求参数无法与之关联。

2)对于请求严格有序的业务场景,压测并发量的增加会影响业务的正确性。

为了解决难题1,项目组经过对比分析,选择基于阿里开源的JVM-Sandbox①沙箱技术。生产环境作为录制端,NGINX日志不仅记录HTTP请求信息,且包含每次请求生命周期内数据库新增的所有主键ID(WEB应用端已存在UUID的通用接口且作为数据库表主键,录制工具负责拦截该接口并记录服务器生成的UUID)以及每个请求的RequestId(录制工具负责生成);回放环境解析NGINX日志,构造与生产环境一致的HTTP请求向受压WEB服务器发送。受压WEB服务器同样基于JVM-Sandbox接口增强技术,解析HTTP请求并将录制端的主键ID传入相应接口,保证数据库中各表勾稽关系的合法性,从而实现高质量的请求回放。

对于难题2,项目组自行设计了请求重编排算法。利用录制端请求日志的主键ID(通常是UUID)识别度高的特点(结构化、易识别、重复出现必有关联),可大概率判断请求间的依赖关系。如:请求A中记录了新增ID为K0、K1,后续请求B中任意参数出现K0或K1,则认为请求B依赖请求A,重放时必须保证先放A后放B,且依赖关系满足传递性。实现上首先解析给定行数的日志量(分批次进行回放),将存在依赖关系的请求构造成有向无环图。同时采用自定义容量的线程池(容量即压测并发度),各线程以高效的方式抢占满足发送条件的请求进行重放。从国信OA的实践看,该方法成功覆盖OA系统超85%的全流程场景,95%的接口,且最高达到生产10倍压力。

2、基于流量回放的回归测试方案

基于流量回放平台进行回归测试的步骤如下:

1) 备份基准数据库D0、基准代码C0、基准日志L0。

2) 对D0,C0,L0 启动流量回放,将每个请求的RequestId与返回值记录到ES中。

3) 对于新版本C1,以D0、L0启动流量回放。

4) 在版本C1的回放过程中,从ES中取出相同RequestId的响应结果进行比对。

5) 按受影响的用户数对异常结果排序并以xls输出。

6) 选择稳定性较好的代码版本,重新定义D0,C0,L0

3、应用成果

与基于Jmeter进行压测和回归测试相比,国信自研的流量回放平台在OA系统测试中具备以下优点:

1) 测试覆盖面更广:已覆盖OA系统超85%的全流程场景,95%的接口。

2) Jmeter难以完成OA系统全流程压测(以上提到的2个难点无法解决)。

3) 资源消耗更低,内存、CPU消耗远低于受压机器(约1个数量级),支持并发上限更高。

4) 自动适应新接口,无需手动编程。

基于回放环境可不定期研究系统在极限压力下的性能表现,提升应急状况响应能力,当生产环境发生类似问题时可迅速应对。通过实施流量回放压测,发现了JVM的CodeCache不足引发额外cpu消耗、SAS磁盘IO瓶颈、数据库内存消耗较大等问题,以上问题均在生产环境未出现故障前提前做了优化,有效提升系统性能与稳定性。

性能监控平台

1、平台方案

国信OA系统的监控体系基于Zabbix+Grafana建设。Zabbix调用自定义Sh或Py脚本监控各项指标,以Grafana实现可视化呈现。

国信OA系统自下而上构建了涵盖资源层、网络层、数据库、中间件、应用层、业务层等关键指标的全面监控体系(详见图2-3)。具体包括:

基础资源监控:CPU使用率、内存使用率、磁盘可用率、IOPS、IOWAIT、UTIL 等指标。用于在大方向上对问题定性。

TCP状态监控:TCP连接的各种状态,用于判断系统间TCP连接健康状况、被调用方连接数是否过载等网络层问题。

JVM监控:进程堆相关(用于定位是否存在堆内存持续不释放等问题)、GC相关(用于综合判断JVM参数是否足够优化)、线程相关(用于判断JVM线程数是否过载等)。

数据库监控:单位时间慢查询行数增量监控(用于判断是否出现过多慢查询)、表空间大小(用于及时扩容),当前锁个数,当前阻塞SQL数。

HTTP日志监控:HTTP接口平均响应时间、HTTP请求完成量、活跃用户数、QPS峰值(综合判断全系统监控状况与在线用户数)等。

业务监控:面向OA核心业务功能的监控。

图2-3 OA系统监控指标体系

2、应用效果

通过分层监控体系的实施,实现了对系统性能的准确感知,告警准确率已达99%。系统监控大屏示意图详见图2-4。

图2-4 OA系统数据库服务器监控大屏

JVM问题诊断平台

1、平台方案

为快速定位OA系统JVM问题,项目组基于阿里的Arthas②建设了国信版的JVM问题诊断平台。平台架构详见图2-5,分为4层。底层诊断工具层基于Arthas提供的诊断功能。对接服务层提供隧道服务与调用本地Arthas的安全代理服务。平台化层一是实现用户隔离机制,限制用户仅能操作自己的机器;二是通过整合机制实现来自不同IP诊断数据的归集;三是为上层应用访问底层工具提供认证机制和通信机制。诊断业务层负责实现提升用户诊断效率的各种特性与功能。

图2-5 JVM诊断平台逻辑架构

国信版JVM诊断工具已实现如下功能和特性:

1)将开源的单机工具arthas-tunnel-server分布式化,结合增强的权限隔离机制实现基于单一平台对接所有JVM进程实现在线诊断。

2)改进Arthas工具对JVM进程的attach方式,用户基于单一平台在浏览器端即可随时attach或detach JVM进程,方便快捷。

3)增强用户体验,实现了大内存dump文件高效下载、诊断进程关键字历史记忆、多人在线协同诊断等功能。

4)前后端分离,3行脚本秒级安装对接。

2、应用效果

OA信创项目期间,利用该工具成功定位了OOM、OpenJDK Bug、应用侧接口响应过慢等10+问题。此外,该平台已成功应用于邮件、互学e等其他信创系统,以及资讯系统、投研系统等非信创系统。

如下图2-6,图2-7所示,通过层层钻取调用链,平台实现了对慢方法的定位(红色字体)。同时平台支持一键分享,多人在线协同诊断。

图2-6 JVM诊断平台层层钻取调用链,精准定位慢方法

图2-7 JVM诊断平台邀请诊断功能

总结与展望

国信证券OA系统及质量保障体系信创建设是一个系统工程项目。通过一年半时间的努力,解决了信创适配过程中遇到的操作系统、中间件、数据库、JDK等各类问题;通过自主集成和定制开发的流量回放、性能监控、JVM诊断平台等工具,构建了较为完备的质量保障体系,切实保障了OA系统长时间安全稳定运行。国信证券通过自身实践已形成一套完整成熟的信创适配改造解决方案,该方案可在其他机构复制落地。

虽然信创CPU、操作系统、数据库、中间件等基础软硬件产品与国外成熟产品相比还有一定差距,我们相信,随着信创系统“真试真用”的场景和范围逐步扩大、各类问题的持续暴露和解决,信创软硬件产品将加速完善和进化。各类信创产品和系统将很快实现从能用到好用的蜕变。

声明:本文来自上交所技术服务,版权归作者所有。文章内容仅代表作者独立观点,不代表安全内参立场,转载目的在于传递更多信息。如有侵权,请联系 anquanneican@163.com。