4同行回答
对于一般业务系统，交易量和交易频率都相较于 OA 办公类系统有一个较大提升，一般业务系统对于性能有一定要求。对这类系统做信创改造也可按传统集中式和容器分布式两种策略去完成。
建议选择一些与其他系统交互不太频繁相对独立的一般业务系统做信创改造，如信息采集类系统，数据湖等，这样系统间交互的问题会少很多。
如果选择传统集中式信创 IT 路线，按传统 IT 技术架构照搬对应做国产化替代即可（比如 X86 换 ARM ， RHEL 换统信， Weblogic 换东方通， Oracle 换达梦等等），但一定要做充分的测试，尤其是性能测试，在确保性能的前提下再推广上线。
如果选择容器分布式信创路线，则需对整个云平台做一个规划，是纯 PAAS 云还是 IAAS PAAS 结合的混合云，上云的路线是否提前规划好，云上只有信创应用还是其他应用也要上云。
再就是选择容器分布式信创路线也需要对现有应用产品做一个较大的应用改造去适应云环境，这样才能发挥云环境弹性扩展的优势。
金融信息技术创新项目工程建设客户都在分步进行，先进行试点，技术成熟后进行全面替代。
试点规模方面，按项目建设投资规模计，金融核心业务系统建设 当前信息技术创新 需占比10%+，至2025年达到50%+；金融一般业务系统建设 当前信息技术创新 需占比30%+，至2025年达到80%+。
信息技术创新技术栈
需自底向上从CPU，服务器/存储，操作系统，数据库，中间件，流版软件，桌面客户机及外设等来看：
- CPU厂商：龙芯、兆芯、鲲鹏、飞腾、海光等。其中鲲鹏、飞腾属ARM系列。海光属AMD上一代，完全兼容X86，性能上大约能达到中低端X86 CPU水平。还有一家合芯科技基于OpenPower生产的纯国产ChinaPower CPU，具有与上一代Power一样的良好性能，目前也在进行金融信创云适配
- 服务器/存储厂商：浪潮，曙光，华为，长城等，浪潮生产供应飞腾、海光等主流XC服务器和存储，纯国产ChinaPower服务器，也是国内第一的国产K1 Power高端服务器和国产X86服务器供应商
- 操作系统：主要是麒麟和统信UOS，他们基本适配了所有国产与XC服务器
- 数据库有：达梦、人大金仓、南大通用、优炫、瀚高、海量数据、神州通用等。各家数据库近年都发展迅猛，在替'0'去'O'路上披荆斩棘，与Oracle开发（语法兼容性）和运维（工具、使用习惯）实现了很好的兼容，虽然功能和性能方面与Oracle相比还有一定差距，但产品功能和方案也日渐完备，正在通往从可用到好用的途中。目前国产数据库处于百花齐放状态，在产品生态方面日趋完整，服务交付能力也在不断成熟和改善。作为替'0'去'O'的基础软件，在打磨积累过程中出现bug是难以避免的。某种程度上讲，用户可以接受一定的可用性降级，但在关键的数据安全、可用性上面，仍需要严格保障。与之相对比，去O之后的方案同样需要规避上述可能的风险。
- 中间件有：东方通、宝兰德、金蝶、中创、晋元等。各家中间件都可以依托集群部署模式，实现高可用和性能扩展
- 流版软件，桌面客户机及外设：主要是办公系统软硬件范围，这里不赘述
替代方案原则
目前客户在推进金融信息技术创新项目过程中都按照"先边缘、后核心, 先局部、后整体"的原则，尤其在进行关键数据库的XC改造时，充分考虑可能面临的风险，选择适合自己的方案，进行XC改造与替代，以真正做到风险可控。
- 目前已进行XC改造的客户，大多数还是选择相对独立的单体应用系统进行改造，比如:办公类的综合办公、内部科技管理开发平台；一般业务系统类的运维管理平台；核心业务系统类中相对独立的信贷系统、历史业务查询系统等；也有客户在进行核心业务系统的交易、核算类系统的XC改造。
- 但基本都是先按照双轨模式建设，即原核心业务平台数据库系统仍然继续运行，原核心数据库与新建XC平台XC数据库系统间借助数据库迁移和同步软件/工具完成实时/准实时数据同步，在XC改造项目初期，让新建XC平台XC数据库系统承接部分允许异步数据的查询和统计类业务，等XC数据库系统经过验证成熟后再逐步上线更多业务。
- 考虑到金融核心业务平台中用户规模庞大、交易高并发、系统风险等级高和整体复杂度高，且涉及用户信息和财产资金安全，为进一步降低风险，建议先将原核心数据库做各数据库规模和交易并发要求进行分库改造，比如:按N百万用户 或 峰值N千并发交易量拆分原核心数据库，则数千万或上亿的用户规模 或 数万总体并发交易量可以拆分成4个、8个、16个分库，然后新建XC数据库系统与各个拆分库一一对应，这样可以大大降低单个数据库因意外导致服务降级带来的影响范围和风险。
替代选型要素
从技术架构来说，选型是在选定业务系统应用开发商（或自研），参考其应用技术架构特点及其优选软硬件适配平台，选择合适的服务器/存储硬件平台，操作系统、数据库和中间件基础软件厂商和产品，从开发与运维角度来讲，就是选择厂商的产品可用性、功能和性能、案例丰富度、服务能力，在XC数据库选择方面，上述达梦、人大金仓、南大通用、优炫、瀚高等在XC名录里的国产集中式数据库，无疑是比较好的选择，从架构特点和运维方式上是接近传统Oracle/DB2数据库的，他们也都具备数据强一致性，诚然在Active-Active集群技术方面，它们与Oracle RAC、DB2 PureScale还有差距，但用主流的主/备[一主一备或一主多备]模式在故障情况下也能做到秒级或几十秒内切换，甚至比传统HA方案切换更快，也能基本满足客户的高可用性要求。
现在也有一些基本满足金融级数据一致性的国产分布式数据库产品（如腾讯TDSQL、PingCAP TiDB等）可供选择。但这些分布式数据库产品主要还是原生兼容MySQL，在兼容Oracle方面目前稍逊一筹。可是分布式数据库用在金融的一般业务或者核心业务里头，因其集群都是动辄十来台、甚至几十/几百台的规模。对于金融客户来说，都有上百套甚至数百套系统，这些业务系统的应用部分都可以做分布式集群改造，但后端数据库都上分布式数据库是不现实的，大部分业务系统的数据库从数据规模和并发要求来考量都可以用国产XC列表集中式数据库承载，初期建议与原有传统数据库系统并行运行，确保将风险降到最低。
当前大多数金融客户，无论是核心业务系统和一般业务系统，后台数据库大部分还是运行在Power服务器上，其中又以Power+Oracle RAC或Power+ DB2方案居多。浪潮高端K1 Power服务器一直是以承载客户关键数据业务系统见长，K1 Power服务器与上述各个XC数据库和分布式数据库都有深度适配，很多还有丰富的案例。在进行金融业务系统XC改造创新的时候，您仍可以放心的用K1 Power服务器承载新的XC数据库系统，K1 Power一方面可以以其一贯的高可靠性、高安全性和高性能特点，为金融XC关键数据库方案的高可用性提供更好的保障和补充，降低业务风险，另一方面也能为客户在Power服务器上的投资得以延续，降低迁移、改造过程的成本。