一、背景

主流金融机构如银行、证券商等,都在逐渐将核心应用及其数据库部署到容器或Kubernetes中,来提高系统的弹性和敏捷性、处理能力、高可用性。 笔者最新有幸参与某股份制大行新柜面系统信创改造， 本项目最主要亮点是云原生和信创结合，应用服务部署、基础组件部署在云原生上（容器云平台），基于鲲鹏 arm/ 海光 X86 混合架构，采用国产麒麟操作系统，数据库 TXSQL （基于 mysql 作为底层引擎进行分布式改造），本着信创（信创即信息技术应用创新）在于创新思维，云原生内在就具备协同创新的基因。 70% 节点基于通用 x86 架构， 30% 节点基于纯国产的 ARM 架构混合架构，双活部署。 本次信创改造重点是对信创 CPU 芯片（鲲鹏、海光等多种采用不同指令集架构的 CPU ）的支持和信创操作系统、信创数据库、以及信创中间件等的支持。

系统大体拓扑架构

客户痛点与需求

在信创架构选型中有芯片服务器、操作系统、数据库、中间件等众多产品可供选择，但云平台、虚拟化等可复用、有共性的底座型技术决定了企业未来信创技术线路的选择，需要对其关键点在于架构的兼容性、可靠性及可持续性验证。

实施亮点

1）验证柜面系统一般营业日峰值处理能力；特殊时点峰值处理能力及稳定性，RTO/RPO等
2）验证旧柜面系统迁移到科创平台，双活，一云多芯的背景，整体 弹性、高可用性、容错性 。
对双活实时同步，准实时同步吞吐能力进行验证

微服务方面及业务代码实现优化及潜在风险隐患排查

1）链路梳理优化包括减少数据库高频流水表连接次数，连环调用，公共模块重复查询。这块主要做法从各中心打印火焰图分析调用栈来进行分析。
2）发出异步请求报文后，用嵌套循环去轮询返回的异步结果，修改为异步框架，将future改为complepableFuture避免轮询线程结果，极大降低节点cpu使用率。提升微服务之间的通信和数据传输性能和吞吐量。
3）每次数据库保存前获取序列存在同步锁问题，修改获取序列号机制
4）批量执行的话，JDBC连接URL字符串中需要新增一个参数：rewriteBatchedStatements=true ，解决应用pod节点负载不均衡问题。
5）网络波动下数据准实时同步rocketmq跨集群出现数据重复，流水表设置唯一性主健，业务端强制去重，保证双数据中心消息对等。
6）在压测过程发现从下游获取文件下载耗时长，采用固态硬盘存储提升性能，从通用性、性能角度来选择存储以支持容器非持久化场景下高效运行。
7） 云原生的 K8S 平台（Ingress、node、pod等资源）的故障恢复机制，检查通过 POD 重启、漂移等方式快速规避故障，将故障对业务系统的影响降低到最小。提升组件的弹性、高可用性、容错性
8）及时发现空指针异常、类型转换异常等，增加代码健壮性。
9）异步调用采取通讯日志线程池和业务trade使用的线程池分开。

配置参数优化及 潜在风险隐患排查

1）调整超时配置，满足漏斗原则；避免如调用下游节点存在爆炸节点导致全链路上游节点网关超时问题。
2）稳定性测试数据同步rocketmq提示broker busy超时异常remotingtimeoutException，根据节点cpu资源，扩容rocketmq队列
3）文件句柄参数配置不足，导致too many open files in system异常。 合理操作系统内核参数配置。
4）调整内存分配器，从默认 ptmalloc 改为 jiemalloc ，使用jemalloc作为内存分配器时，可以更高效地管理内存，减少内存碎片和内存泄漏的问题，从而提高数据库的整体性能和稳定性。jemalloc具有多线程支持，能够有效地分配和释放内存，提高数据库的并发处理能力。同时，jemalloc还提供了一些高级特性，如内存统计和调试功能，方便开发人员进行性能分析和调优。

云原生层面优化及潜在风险隐患排查

1）及时发现底层硬件arm cpu 指令级和麒麟操作系统适配发现调用文件上传下载存在线程堵塞问题，兼容性问题
2）newworkplioy策略设置不合理导致k8s,出现同一namespace,出现service访问网络不通
3）主进程启动失败导致循环重启，pod状态一直是CrashLoopBackOff

PASS集群层面问题PASS集群层面问题

1）rocketmq 队列和序列化的步长数配置过低导致接口调用超时。