文 / 光大银行金融科技部 张智峰 郑皓广 谢书华

为满足业务系统日益增长的可靠性与性能需求，银行IT系统正朝着分布式架构转型。在转型过程中，我们面临着分布式系统云化部署、自主研发软硬件适配等诸多挑战。本文以光大银行一次大型业务系统性能调优为例，分享分布式系统调优过程中的一些实践经验。

环境介绍

该系统除进行分布式架构改造外，还同步实现了自主研发软硬件适配和云化部署，具体架构和使用的技术产品如下所示。

(相关资料图)

1.基础设施层部署模型介绍

该系统在光大银行最新一代云计算平台——全栈云部署，从底层硬件到操作系统、中间件及数据库均选择自主研发软硬件解决方案。平台主要分为：分布式云原生应用、分布式数据库和缓存数据库三部分。其中云原生应用和缓存数据库分别以容器和虚拟机的形式部署，分布式数据库则部署在裸金属服务器上并搭配了NVMe本地存储，操作系统全部使用自主研发Linux系统。

图1 某大型分布式业务系统架构图

2.业务模型

为了验证分布式架构对高并发场景下的支撑能力，本次调优特意选取了对高并发要求较高的联机交易类系统。

如图2所示，GW（网关）服务、DP（存款）服务、IA（内部账）服务、UNISN（全局序列号）服务、SEATA开源分布式事务等均采用微服务架构运行在容器集群中。微服务会持续对服务注册中心进行心跳检测，同时定期获取微服务清单和配置信息，以实现配置更新及服务发现。

业务请求经GW服务调用DP服务接口识别业务类型，并根据业务逻辑在各微服务和数据库间流转。该系统需要在内部高频远程过程调用的情况下，保证联机交易低时延高并发的需求。

图2 某大型分布式业务系统业务模型图

对比传统架构，我们不难发现系统在进行微服务改造后整体架构较为复杂，各微服务间存在大量远程过程调用，导致了更多的网络交互开销，而这部分时间开销在云计算SDN网络下被进一步放大。

通用调优

整体调优工作分为两个阶段。第一阶段旨在梳理业务模型，确立调优思路，并分别对云网、数据库及系统环境进行普适性调优。我行各技术领域专家均参与到调优过程中，通过网络模型优化、数据库对象及环境优化等手段，使基础组件及设施更适合分布式架构，充分发挥分布式架构的优势。

1.云网篇

全栈云使用基础网络架构（三层SDN网络模型），节点间多采用Vxlan通信，负责Vxlan隧道解封装的隧道端点VTEP，广泛分布在算力资源、SDN网元、裸金属网关等节点，导致各节点间互访的流量路径较为复杂。考虑到分布式架构下的高频远程过程调用使网络开销较大，为追求最佳性能，需要针对分布式架构单独设计网络部署模型。我们将虚拟机及容器全部部署到相同VPC下的同一子网内，使虚拟机与容器的网络通信收束在Leaf交换机以下，规避了SDN层的频繁转发。在网络部署模型优化后，网络的整体性能有了大幅提升，通过最直观的ping测试数据，平均时延被控制在250微秒以内，较优化前350微秒的平均时延有了近30%的提升，整体性能提升了20%以上。

图3 全栈云网络物理部署图

2.数据库篇

从传统集中式数据库迁移至分布式数据库面临很大的困难挑战，需要充分发挥分布式数据库海量数据、高并发的性能优势，同时也要避免架构由集中式转变为分布式带来的缺点与不足，为此我们进行了如下的优化措施。

■ 减少自增列使用：典型的存算分离架构的分布式数据库为了保证带有自增列值在全分片内保持唯一且递增，需要一个统一服务来生成这种递增序号，即GTM组件。分布式数据库自增列的写入效率并不及集中式数据库，在高并发写入场景下会成为性能瓶颈。因此我们去掉了全局自增属性，规避了生成全局递增序号导致的性能瓶颈。

■ 批量优化：为充分发挥分布式数据库高并发的性能优势，我们对业务表以账号进行了哈希水平分片，并在每个分片也以账号做了哈希分区。应用程序可以利用多线程以及数据库STORAGEDB语法特性将SQL透传至对应分片，通过多分片多分区并行执行的方式极大缩短了结息批量的执行时间。随着后续建设中分片数量增加，批量执行时间也会随着并行度增加而进一步缩短，甚至能够超过传统架构使用的集中式数据库。

同时，我们参考同业实践经验以及我行实际情况对数据库服务器内存管理、磁盘数据管理策略做了调整。

■ 定时清理buff/cache：数据库面对高并发读写场景时，服务器buff/cache的高占用容易成为性能瓶颈。我们引入定时清理策略进行，以减少因服务器缓存释放不及时造成TPS和时延的不稳定。

■ 条带化：分布式数据库DN节点属于I/O密集型服务，尽量降低NVMe本地盘的读写延迟是需要考虑的方向。通过条带化配置，数据读取和写入可以获得最大程度的I/O并行能力，从而降低SQL语句执行以及事务提交的时间开销。

针对性能瓶颈的专项调优

在普适性调优之后，系统的整体性能有了显著提升，但离预期仍有一定距离。我们发现各个计算节点的CPU、内存使用率等指标均处于较低的水平，这说明性能瓶颈仍然存在，因此我们将目标转向提升各组件在压力测试下的资源利用率，并利用云上overlay流量观测，underlay网络探针和应用日志埋点等手段分析隐藏的性能瓶颈点，利用工具精准锚定瓶颈点，提升“短板性能”。

分段时延获取、

瓶颈点定位与针对性调优

图4 单交易分段时延获取与分析

链路监测通过捕获应用服务和数据库的日志关键字的方式获取链路分段时延。虽然日志输出会牺牲系统性能，但能够有效帮助我们分析各环节调用次数与时延并找到隐藏的性能瓶颈。

分析发现，单笔交易的时间开销主要来自于应用内部的数据处理、数据库的事务处理和微服务间RPC。为此，我们进行了针对性调优。

1.在业务层，主要进行了缓存优化、批量优化和通讯优化

缓存优化：

（1）对于需要高频访问且日常改动较少的参数类库表，考虑通过采用缓存数据来优化访问效率。

（2）一般情况，应用在每次调用数据库前会对SQL进行预编译，对于SQL比较多的场景，预编译的时间将被放大，通过对SQL预编译的结果进行缓存，可以减少耗费在SQL预编译上的时间。

（3）对注册中心可用性进行了优化，通过本地服务列表内存缓存、本地服务列表文件缓存的多级缓存策略，在注册中心整体宕机时尽量减少了对业务系统的影响。

批量优化：充分发挥分布式架构的优势，在资源允许的范围内进一步提高任务处理的并发度，将批量任务化整为零，通过合理的任务分片全面提升批处理效率。同时尽量避免大事务的产生，通过减小单个事务的规模，有效规避业务处理的潜在锁冲突。

底层通讯优化：在内部服务高频交互的场景下，将服务间的通讯协议由http协议改成了基于socket长连接的bolt协议，减少了通讯的损耗。

2.在数据库方向，主要从事务和裸金属网络两个方面进行了优化

事务优化：在确保相关的表和数据行不会涉及分布式事务并发读写的情况下，我们针对性地通过hint的方式降低了部分事务会话级的隔离级别，减少了不必要的查询活跃事务列表、select for update时间开销。

裸金属网络优化：由于分布式数据库涉及多节点间的通信协调，在网络链路上的开销远高于集中式数据库，为此我行全栈云专家也针对分布式数据库内部网络进行了专项调优。

图5 裸金属网络调优前ping测试数据

我们为每一台裸金属节点新增了一个私网地址，专门用于裸金属节点之间的互通，并对数据库内部网络的流量模型和通信矩阵进行调整，使得裸金属内部通信可以通过Leaf交换机直接转发的方式实现路径最简的高速网络，平均ping延时由130us下降到了80us，性能大幅提升。

图6 裸金属网络调优后ping测试数据

overlay层数据包分析

云上环境很难利用传统的underlay探针预埋手段获取全量网络流量信息，在此我们利用网络可视化工具，在云化资源上部署agent观察overlay层网络。

通过云网可视化工具进行网络抓包，我们发现通信包内多次出现了重传和零窗现象，如图7所示。

图7 利用云网可视化工具定位网络问题

考虑到自主研发ARM服务器与我们熟知的IntelX86服务器除指令集外，其多核架构也是一大不同点，沿用X86相关参数配置服务器的方式需要进行调整。

经过业务分析发现，其中零窗和重传集中于BMS007->BMS011与BMS008->BMS011两条裸金属服务器通信线路中，因此怀疑此部分网络链路存在性能瓶颈。在升级业务逻辑并针对服务器进行了网卡缓冲区扩展、关闭网卡中断聚合、调整网卡中断队列与绑核后，重传及零窗现象有了大幅优化，重传率降低至0.1%以下。

在第二阶段的调优中，联合调优小组通过多个云上系统观测工具进行了瓶颈点分析并实施了多个针对性调优，使得整体系统性能较调优前有了80%以上提升，但是距离项目整体预期的性能仍有部分差距。在调优实施中，有所收获的同时，我们也深刻意识到了不足。面对“分布式+云化+自主研发适配”这种复合架构改造场景，我们还存在诸如云上工具建设不足、微服务改造不彻底、自主研发软硬件适配仍处于探索阶段等问题。

回顾与总结

自主研发软硬件适配正处于经验积累阶段，在实际使用方面距离“开箱即用”还有一定距离。追求高稳定性和极致性能的重要应用系统在建设过程中都需要完成相对复杂的性能调优适配工作，以找到每个系统需要的“最优解”。后续光大银行也将加强与相关厂商的合作，针对性满足应用系统“经济型”“均衡型”“稳定性”和“性能型”等不同方向的需求，形成运维资源交付与应用程序结合的最佳实践。

在当前技术趋势下，应用系统建设同时面临基础设施云化、架构分布式改造、系统软件自主可控适配、应用容器化等一系列挑战，这都给系统性能的调优造成了一系列不确定变量，将原本相对体系规范的性能调优工作难度成倍增加。由于涉及从基础设施到应用程序的多层面配合协调，这就需要基础设施建设人员、云平台建设者、系统软硬件工程师、应用程序开发者“多向奔赴”，合作共赢，共同实现系统性能的极致化。

面对复杂的工作任务，多层面的人员协调，更需要体系化、系统化的工作方法进行情况分析、目标设定、人员协调和任务统筹。在本次性能调优过程中，无论是分段获取数据的标准测试方法论，还是引入的应用日志、网络流量和智能运维等工具完成性能情况的获取都值得在后续工作中积累推广。光大银行也将积极推进相关工作方法、工具以及流程的积累，尽快形成一套标准高效的性能调优方法论，进一步提升敏捷交付的效率。

责任编辑：

标签：