王志刚：加速推进芯片与服务器创新实践
随着“中国芯”的崛起，光大银行从2019年开始试点和推广国芯服务器，并将其作为加强基础技术领域产品多样化的重点工作领域来推进。在工作机制方面，以总体目标为导向，从试点系统的月度工作计划入手，促进任务实施，跟踪任务进展，推进各试点系统的工作进度。
在办公管理系统上，适配国芯服务器的OA和邮件系统的上线后稳定运行。其中，OA系统为全行集中部署，邮件系统为总、分行分布式部署。使用国芯服务器超过100台，部署数据库、中间件，成为全栈一体化的国芯方案。目前正在持续开展总行个人邮箱系统和分行OA系统新增功能的适配和测试工作；在一般业务场景系统上，中间业务云平台等系统在国芯服务器投产上线，率先支持完成公安部经侦网络查控等功能；在关键业务场景系统上，选取人民币跨境支付等系统的作为国芯服务器的推广目标。目前，国芯服务器数量占服务器总量比例已超过10%，形成了一定的国芯服务器应用和运维能力。
中国光大银行信息科技部 王志刚
技术适配
对于应用者来说，一种新型设备能否推广开来，除了其本身的性能、稳定性之外，软件适配才是最重要的环节。
首先，从操作系统的适配上看，国芯服务器已经与国产操作系统深度融合，对JDK的支持、C/C++编译器也比较完善，基本保持了与X86服务器一致的编译和运行环境，但仍存在一些具体需要注意的地方。
光大银行以JAVA开发栈为主，JDK的选择就对程序开发有至关重要的影响。国芯服务器及操作系统上提供的JDK大部分是基于Open JDK的再发行版本。而Open JDK是商业版本JDK的开源实现，与我们传统使用的Oracle JDK功能基本一致，但是细节功能仍有所区别，在开发设计中需要额外注意。在我们的应用程序移植过程中，就曾经出现过Open JDK报警机制导致的迁移问题，即：某些特定的异常在Oracle JDK中仅作为警告级别出现，而在Open JDK中却作为错误抛出，影响程序运行。同时，我们发现最新的GC（垃圾收集）选项只在Oracle JDK上可用，Open JDK提供GC选项则相对滞后。此外，传统Oracle JDK提供的长期技术支持(LTS)服务，在Open JDK中则需要由适配国芯的操作系统厂商来提供，其对JDK的技术支持能力尚需进一步的实践检验。
在C/C++应用程序的开发过程中，国芯（ARM64 CPU）与X86-64CPU相比有较大变化。在移植、改造、重编译、程序优化的过程中，需要了解其体系结构、指令集、编译器的变化。由于其生态圈也尚在建设和发展中，ARM版本缺乏部分软件包，会给移植造成了额外的困难。此外，还需关注不兼容指令、依赖包和第三方软件重编译的ARM64版本差异、不支持32位应用、数据类型差异、变量地址按变量长度对齐、体系结构差异带来的性能变化。例如：ARM架构的CPU的cacheline通常是128B，而X86架构通常是64B；ARM架构下的CPU指令并行优化采用的是weak memory order，故内存barriers的实现和优化策略将需要与X86架构区分处理。同时，应用也应根据实际情况，对国产CPU专有指令进行专门适配优化。例如：ARM架构下的CRC32指令，可大幅提升针对日志和数据表空间文件的CRC32校验计算效率；ARM架构下的STADD指令，可大幅提升数值原子累加操作的实现效率；ARM架构下CPU提供的CAS指令效率高于TAS指令，所以部分原子性操作可基于CAS的实现替代TAS指令实现以提高性能。
在数据库领域，新兴的分布式数据库，如：OceanBase、GoldenDB、TiDB已发布了国芯版本。传统国产数据库品牌，如武汉达梦等都已经适配了国芯，在光大银行OA、人民币跨境支付等系统中也得到了具体的应用，在性能上满足了相关应用程序的需求，功能上与X86版本也基本没有差异。目前，光大银行内部使用较多的仍是基于MySQL8.0源代码自行编译的ARM版本。而在编译过程中，我们也发现，针对部分平台无关（platform-independent）代码模块,相对于面向X86环境，是可以提供ARM版本的优化的。例如：ARM架构下数据内存存储采用的是小端模式，可以针对性地进行存取优化，避免针对额外的转换开销。而my_convert，面向X86的优化同样可以用于ARM平台。
在中间件领域，光大银行在国芯服务器上主要使用Web中间件BES和光大银自有的EverTP交易中间件。和传统中间件的使用方式类似，目前运行也比较稳定。
由上述可见，在操作系统、编译器、数据库、中间件等信息系统的核心技术组件，在国芯服务器上都已经有了相应的适配产品，并且主要功能与X86平台区别不大，只在部分技术细节上需要额外注意，并加以优化改造。
现存问题
在实际使用过程中，对比传统平台，我们发现数据库、中间件之外的那些“边缘”技术组件，往往成为困扰我们应用国芯服务器推广的难题。例如：高可用切换软件、备份软件、存储多链路软件等。
在传统架构中，高可用切换软件用于保障服务器、操作系统、数据库、中间件、共享存储、浮动IP等组件的存活侦测、资源管理、故障切换。传统的商业高可用切换软件包括：PowerHA、Veritas Cluster Server等。目前，国内成熟的高可用切换软件较少，尤其在国芯服务器平台上，更是缺少经过实践检验的产品。
在备份软件方面，国内已经有了较多厂商进入该领域，也形成了一定的技术积累，但在全栈国产化的产品集成方面仍存在较多问题。例如：我们使用的某国产备份产品与国产数据库之前有互相兼容的认证。然而，在实际使用中却发生了当数据库升级了补丁之后，备份就无法执行的问题。经过分析，发现原因是数据库软件更新了备份软件调用的API。可见，尽管国产化软件之间有了的相互兼容的认证，但双方却缺少真正有效沟通和协作机制，使兼容认证仅停留在纸面上。而与之相对应的是，国产备份软件对国外商业数据库、开源数据库的兼容性却更好，或许这就是市场的影响力所决定的。
在存储方面，作为集中式SAN存储必不可少的多链路高可用软件，目前在国芯服务器上仍缺少成熟产品，这个问题应该由存储厂商解决，还是由操作系统来提供，目前还没有定论。
由此可见，由于市场影响力等原因，国芯服务器上的操作系统、数据库、中间件等核心组件处于高光之中，目前发展态势较好。相对而言，一些支撑系统运行类的保障类软件却发展较慢。
国芯上云
如何破解目前的难题呢？我们认为，除了推动相关厂商持续投入研发、加强协作之外，实际上，当我们重新审视这些目前发展较为缓慢的技术组件时，就会发现：除了备份软件之外，上述的大部分技术组件都是传统架构下的产物。而在云计算普及和分布式、微服务架构推广的趋势下，上述软件的重要程度就不是那么突出了，无怪乎市场有限了。
因此，向云端转型，推进应用上云的同时，进行微服务和容器化改造，在云平台中将国芯服务器抽象成一种算力而非传统集中式运行环境，这样就能最大限度地降低国芯与传统X86平台在技术与生态领域的差异，推进国芯服务器的应用。
在这方面，光大银行以云平台3.0为核心做出了部分探索。
云平台3.0是光大银行云计算的“十四五”规划，全栈云是云平台3.0的技术核心和落地实体。全栈云以全行算力基础提供统一的资源供给和算力编排，提供IaaS和PaaS的技术赋能，构建“操作系统+容器+K8S”的云原生不可变基础设施。其中，基于ARM架构的国芯算力与传统x86算力都是作为计算资源向用户提供。而软件定义存储、软件定义网络等基础技术栈及云原生PaaS的全栈架构，也是同样基于国芯服务器和传统X86服务器实现，对用户来说，与传统X86算力并没有太多区别。
目前，光大银行已有对公主动负债管理系统、公司业务管理系统、门户网站系统、冠字号信息查询系统、现金管理系统等16个应用系统进行了相关改造。在改造过程中，一方面，业务系统要从X86的CPU架构向ARM架构进行转变，用ARM指令集对源代码进行重新必不可少编译。而另一方面，由于业务系统向云原生的系统架构进行了改造，从计算、网络、存储等多个领域，由传统的集中式架构向新型的分布式架构进行了转变。对高可用软件、集中式存储等传统技术生态的依赖最大限度的降低了。上述高可用需求，由基于云原生架构的软件定义存储、分布式数据库、分布式中间件自身的高可用能力来保证。这样，就大大降低了技术壁垒，为推动应用在国芯架构落地实践，承载更多金融业务服务提供有力的技术支撑。
（栏目编辑：韩维蜜）
推荐阅读
（点击图片查看精彩内容）
精彩内容回顾
（点击查看精彩内容）
■ 案例 | AR/VR 技术在商业银行贵金属营销中的应用——以中国银行某一线城市分行为例
《金融电子化》新媒体部：主任 / 邝源 编辑 / 傅甜甜 潘婧