云原生架构可以高效赋能金融企业加快业务交付、降低运营成本，使金融业务能更从容地接入创新技术、提升渠道的广泛触达能力。因此，云原生技术得到了包括金融业在内的相关行业的高度重视，并成为推动金融业数字化转型的重要利器。

金融企业采用云原生技术，并不是将应用上公有云，而是将金融对安全合规、交易强一致性、单元化扩展、容灾多活、全链路业务风险管理、运维管理等各方面行业要求与云原生技术进行深度融合，发展为一套既符合金融行业标准和要求、又具备云原生技术优势的“金融级云原生架构”。

众所周知，金融行业广泛存在多厂商、多语言、转型成本高、安全要求高、运维难等多种痛点，在进行IT架构的云原生转型过程中，又面临新系统和老系统的双重问题。一方面金融企业希望赶上数字化浪潮的步伐，通过 IT 驱动业务创新并最终占领更多市场分额，然而新技术的应用可能 对金融企业的系统稳定性造成冲击；另一方面，金融行业历来是强监管、高安全性的行业，监管部门对金融 IT 系统的建设和运维有非常 严格的要求。

那么，问题来了——金融企业如何克服多重困难，深度融合云原生技术？

金融企业融合云原生技术必须思考的几个问题

1、如何向非专业技术人员屏蔽容器技术的复杂细节，让他们享受容器价值；

2、如何有效地把微服务、DevOps 与容器技术有机融合，而不是割裂为不同的系统；

3、云原生前沿技术，如 OAM、Dapr 等如何与容器结合；

4、如何在单位内部实现跨子公司、跨部门的软件模块分享、复用；

5、如何被一套包括前述云原生技术以及 DevOps 理念的门户融合，可以在这个目标下各自不同分工、又积极协作，最终把个人的、部门的目标及利益和单位的目标和利益紧密对齐；

6、 如何解决企业多云管理、多云发布能力，不被某一云厂商绑定；

7、如何有效地把相关技术融合一体，成为指导意见所提到的“一站式研发协同平台”；

……

以国内某大型国有银行为例，其在上海、深圳等拥有多个数据中心，但无法进行统一运维和管理，同时开发测试环境上版本无法一键上生产环境，影响业务交付的效率。在金融行业数字化转型的大趋势和金融行业新核心系统建设背景下，该银行期望构建新型金融 IT 基础设施，实现应用的多数据中心高效交付，赋能应用创新。在此之下，行云创新帮助该行建设容器云和云原生技术体系，将包括核心系统在内的近 200 套业务进行云原生改造迁移。经过两年多的建设，行云创新提供的技术和服务已支撑该银行几乎所有业务上云，实现对全国多个地区数据中心应用的统一管理和运维，帮助其大幅度提升开发和运维效率。此外，行云创新帮助该行在 2021 年完成了基于 ARM 服务器和国产操作系统的信创资源池建设，并纳入了已有的多地区、多数据中心、多个异构资源池的统一管理和调度体系。

金融企业深度融合云原生技术应该怎么做？

综合以上问题考量，再结合行云创新多个金融企业云原生项目案例，我们总结出金融企业深度融合云原生技术的关键点：

1. 一站式云原生开发运维协同平台统筹建设

传统的零散式的、工具堆积建设思路已经不能响应数字化转型对于高效创新的诉求，云原生带来的爆发式的新技术和新方法也让传统的以点为主的建设模式捉襟见肘。因此，一站式云原生开发运维协同平台统筹建设就极为必要，在这个背景下，《数字化转型指导意见》也提出了关于平台建设的内容，作为推动科技管理敏捷转型的明确的要求。在平台建设思路上，需要关注核心能力点的同时，兼顾已有的存量系统，如代码库、制品库，甚至是容器云基础设施等。同时，在平台的落地推广上，也应该遵循先找试点项目积累经验，再横向推广到更多项目、形成更大覆盖面的思路。

2. 标准化模块和API构建企业服务市场

分布式架构是技术发展和业务需求下的必然趋势。云原生所倡导的微服务分布式架构是传统SOA体系的一个自然演进，已经成为今天业务架构设计的事实标准。微服务架构一个重要的特点是不同服务模块之间采用松耦合的API接口互联，因此单个服务模块通过开放其标准化接口可以形成极高的复用价值，“避免重复造轮子”这将给研发效率的提升带来根本性变革。而复用性带来的效率高低又和积累的模块的丰富程度相关，所以打造积累标准化模块和API接口的服务市场就尤其重要。通过服务市场，可以把内部各已有系统、在建系统的标准化模块加以积累，同时对内部、外部的API接口进行统一管理和授权。这将成为企业重要的数字化资产沉淀，为新的研发创新将带来巨大的效率性和标准化的价值。

3. 通过标准模块和API以搭积木方式构建业务

通过构建企业服务市场积累了标准化模块和API后，就需要考虑如何便利地把他们像“搭积木”一样架构业务。面对多达数十、上百个服务模块、API的复杂架构，采用配置文件方式编写和管理架构变得完全不再可行。而采用图形化、所见即所得、以组件拖拉拽方式设计企业架构是最直观的解决方式。这种可视化的微服务架构设计器应与前述企业服务市场在一站式开发运维平台上对接融合，在给开发者提供充分赋能、为创新效率保驾护航的同时，也是对《数字化转型指导意见》有关“提高科技架构支撑能力”做出的完美回应。

4. 结合有代码和低代码方式支撑业务快速构建

近年来，云原生体系演进出相关技术，因其方案轻量、业务响应快，受到业界广泛关注。在考虑引入低代码相关方案时，需要重点考虑“低代码”如何与“有代码”的现有模式在统一的开发运维平台上有机融合。做到这一点就可以在统一的分布式微服务架构下，把某些微服务采用“有代码”实现，某些微服务采用“低代码”实现，进而实现对创新效率的再一次跃升。通过一站式云原生开发运维协同平台上同步支持“有代码”和“低代码”两种不同的模式，开发者可以把焦点完全放在业务实现本身上，更保持在不同模式间灵活选择的便利性。

5. 代码、架构图等核心数字化资产的安全管控

传统模式下代码虽然集中存储于代码服务器上，但编码过程还是在开发人员的台式机或是笔记本上完成的，这不但有不及时提交代码导致资产没有归档的风险，更会有因为电脑丢失或是人为因素导致的核心算法泄露的风险。在传统的IDE代码编写工具应对无力的情况下，应运而生。Web IDE完全运行在数据中心，以浏览器Web页面形式对开发者提供服务，开发者像本地传统IDE一样的体验来编写和调试代码。通过在一站式平台的建设中引入Web IDE，可以和平台本身的权限体系拉通，在平台已有的架构图、测试用例等数字化资产安全保护的同时，解决了代码安全保护的最后一块拼图；更可以与一站式平台架构设计、应用发布等其他能力实现融合和对接，达成使用便利性和开发效率性的双重目标。

6. 围绕API接口构建的测试驱动开发模式

API编程接口是分布式架构下不同的组件间沟通的契约。因此，他的重要性不言而喻。如果因为某个组件的升级导致他的API接口不能正常工作，将导致整个组件甚至是整个业务受到影响。另外一个方面，测试驱动开发（TDD）、测试先行的观点已经深入人心。在API时代传统的靠人力通过手动的界面功能测试已经不足以保障软件质量。那么基于API接口在一站式平台上定义测试用例、自动化执行测试用例，不但可以通过保障API接口契约来保障业务的核心质量，更可以通过“Mock Up接口仿真”功能，使得在某模块尚未完成开发时，依赖他的其他模块可以同步开发、不受影响。

7. 分布式应用一键式灵活交付到多活数据中心

《数字化转型指导意见》提出了多活数据中心的建设要求。目前银行等金融企业已经在从传统的两地三中心向多活数据中心转变，这个过程中也在积极探索和实践容器云这一新型虚拟化技术的落地。一站式云原生开发运维协同平台的一个重点建设能力是将采用微服务的分布式应用向企业的多活数据中心实现一键式的灵活交付，充分利用容器、虚拟机等技术，按业务需求实现多活副本的调度，按业务量实现自动扩缩容等策略的执行。只有通过一站式平台解决了上层业务的灵活调度和自动伸缩问题，多活数据中心的基础设施建设才能发挥出最大的价值，才能为银行等企业应对新型互联化业务在诸如“双十一”等高峰场景保驾护航。

8. 分布式应用上线后的问题定位和排查

一站式平台要实现对业务应用生命周期的端到端覆盖，除了高效研发的之外，还需要关注分布式应用上线后的问题定位和排查。分布式架构带来了可以灵活更换、升级有问题业务组件、而不需要触碰其他正常业务组件的便利性，但同时也带来了定位和排查问题困难的新挑战。好在云原生的发展产生了服务网格技术专门应对这种挑战，可以在隐患发生的第一时间、甚至在用户有感知之前就以图形化的方式标识出问题所在，并给出具体的故障接口定位、输入输出参数的具体值以便于问题的排查。通过在一站式云原生开发运维协同平台中有机地融合服务网格技术，形成从应用架构、开发、测试、发布到运维的端到端全覆盖，更好地为金融业数字化转型提供支撑能力。

内容出自《2022云原生技术应用情况调研报告》，点击免费获取，了解更多行业云原生转型现状。