以下从三个层面对云原生的技术架构、生态和基础设施中的几个关键技术架构进行说明：
单元化及分布式云架构 ：以容器微服务平台为基础，通过跨地域的多Region 多AZ 多活可扩展的分布式云部署模式，构建高可用的异地容灾能力。云化基础设施在业务达到一定规模后，为避免系统性故障导致整体性的业务宕机，需要进行单元化切分，将业务按照某种维度划分为多个业务单元。单元内部包含了业务所需的所有服务，能独立处理完整的业务流程。“单元”作为一个相对独立的整体进行业务开展和保护，比如一个具备 4000 万用户的中型银行，可以按照不同的省份或者卡号范围划分，以 800 万用户为一个处理单元，可切分出多个单元在多个AZ 进行部署。每个单元具备完整的业务系统、应用系统和计算、网络、存储等硬件系统，与其他单元资源完全隔离，互不影响。部署在不同AZ内的业务单元同时运行业务。共同承载 800 万用户的访问。当用户访问时，系统选择匹配的路由，由其中一个单元承担业务处理；处理后的数据复制到其他 AZ，确保本 AZ 故障后，其他业务单元立即可承担业务处理。
开源生态与标准：开源分布式中间件（Kafka/Nginx/Redis 等）和分布式数据库（MySQL/PostgreSQL 等）的成熟，是分布式架构在关键业务领域规模商用的关键推动力。随着云原生技术与开源生态的逐步结合，催生了一批基于 K8S 生态，针对开源中间件、数据库等复杂、有状态工作负载的打包、部署、管理和运维等各阶段的开源项目，涉及制品标准、生命周期管理、自动化部署和配置模型标准化等，使用较为广泛的有：Helm、Operator-Framework、Kappital 、KubeVela 等。
从当前的技术和发展来看，业界和社区的重点在于标准化构建和自动化部署。随着云原生技术更加成熟，云原生进入到“以应用为中心”的 2.0 时代，云原生应用也有了新的变化和挑战：1. 云原生技术深入到各行业中，促使云原生应用的种类越来越多。从最初的 Web 应用、中间件应用，到如今的Serverless应用、大数据 AI 应用等。与此同时，应用还面临公有场景、边缘场景、本地场景等不同环境。开发者面临大量应用开发和构建工作。如何实现应用的高效打包和管理，为企业提供高质量的应用，将是下一阶段的发力点。 2. 应用开发和使用产生了供给关系：以前开发者聚焦于开发和部署应用。如今随着云原生应用越来越多，社区开发者向社区贡献众多开源应用，成为了应用的开发者。而另一部分的开发者从开源社区获取应用，成为了应用的使用者。这种应用供需关系将越来越多，将给应用的双方带来挑战，例如应用的开发者如何描述应用的能力以便向社区推广，使用者如何准确获取符合自身诉求的应用。因此，我们认为云原生应用的未来将进入云原生服务生态中。在这个服务生态链中，应用将以云原生服务的方式呈现，而应用开发者将会成为服务提供者，通过发布云原生服务，向社区提供多种多样的产品能力。使用者将会成为服务使用者，通过社区获取相关服务，缩减开发周期，实现自身业务发展。
云原生服务生态是应用蓬勃发展的必然结果，同时也是促进应用落地的最佳方式。同时我们看到社区中尚未有服务生态的规范和标准，缺少如何构建、发布云原生服务，以及对云原生服务统一管理的载体。“云原生服务规范”应运而生，它指导开发者如何构建、发布和管理云原生服务，并且围绕云原生服务，提供服务的“全生命周期管理”。通过 服务规范和全生命周期管理，帮助用户高效发布和管理云原生服务，打造云原生的服务生态。基于此规范构建出来的云原生应用，能被 kappital 等开源云原生服务平台进行管理，简化企业的运维。
云原生服务规范包含以下 8 个方面：1. 架构准则：镜像支持 OCI 规范，应用支持微服务化。2. 部署方式：包括非托管方式部署（如web 应用），托管方式部署（如 RDS、数据库应用）。 3. 运营管理规范：描述应用的计量、计费等运营策略。4. 运维管理规范：描述应用的监控指标、日志审计及日志管理等相关运维。 5. 多租认证规范：描述应用支持逻辑多租、物理多租的认证方式。 6. 服务 API 接入规范：描述应用的API 接入及暴露规范。7. 公共能力使用规范：描述应用使用第三方服务或者公共能力的规范，例如第三方数据库、缓存服务、消息服务等。8. 安全可信规范：描述应用的安全、韧性和隐私保护。
云原生基础设施： 传统以“资源”为中心的基础设施云服务（IaaS），是基于虚拟化技术将硬件资源池化管理，按需发放特定规格的计算、存储和网络资源。而现代化应用和中间件对资源的发放速度、规格粒度、QoS保障、地理位置、隔离性和使用成本等都提出了极高的要求，这是传统IaaS 服务无法满足的。基于新的数据中心架构、软硬协同和云原生架构技术，以“应用”为中心的云原生基础设施服务应运而生，这改变了基础设施的资源供应模式，能够根据现代化应用的需求特征，提供具备调度、弹性、网络、安全隔离和多云容灾等关键能力的基础设施底座。
中大型银行机构通常按照总行、分行、网点等对基础设施资源和业务进行层次划分，是典型的分布式云架构。跨地域的数据中心（包含异构硬件）资源通过云原生技术平台统一管控，基于内置的调度、云原生网络、服务编排治理和边云协同等技术为不同业务场景提供解决方案，例如：面向高性能稳态业务的裸金属容器方案，面向网点和总行核心协同的云边方案等。
出于不同的性能和成本要求，可以采用虚机节点或裸金属服务器部署业务容器。下图是两种典型的容器组网方案：在虚机节点可以采用 subeni（辅助弹性网卡）为容器提供高密度（256+）具有VPCIP地址和安全组能力的网口，而裸金属节点上可以采用SR-IO VF直通的 ENI（弹性网卡）作为容器网口，支持网络QoS 和零损耗转发能力。统一的扁平网络模型使容器成为 VPC 内的一等公民，具有完全的路由互通和网络 ACL 能力。
对于不同类别的业务负载，比如：微服务、批量计算、边缘计算等，可以采用容器集群、Serverless 容器或边缘容器等不同的部署和运行环境，对容器运行时的资源开销、隔离性和启动性能的要求也有所不同。如下图所示，容器运行时分为High-level(CRI)和Low-Level（OCI）层，在开源社区中也有多种实现方案，通过运行时沙箱（Sandbox API）接口可以对接多种隔离技术的沙箱，比如：MicroVM 类，App Kernel 类、Wasm 类及机密容器类，具有不同的安全隔离、性能开销和硬件支持能力。
面向客户在线交易的微服务类业务具有明显的周期性潮汐效应，比如交易时段和非交易时段，服务的响应性能（Latency）直接影响到客户体验；而批量计算类业务，资源消耗量大，实时性要求不高，不影响外部客户体验。这为云原生基础设施通过统一业务调度、资源供应和 QoS 保障能力提升资源效率，降低服务成本提供了机遇。离线业务“混合部署”技术，通过将节点层 OS 内核的优先级、抢占调度、性能隔离等技术，与集群（联邦）层的统一任务调度和资源协调技术相配合，达到将基础设施资源利用率大幅提升（CPU 平均使用率提升到 40-50%+）的同时，保证业务质量不下降，甚至有提升。
近年来，处理器芯片技术蓬勃发展，国内外芯片厂商提供了越来越多的处理器架构和代际选择，比如：基于ARM 架构的鲲鹏、飞腾，基于 X86 架构的海光等。在银行云数据中心的建设中，出于业务连续性和监管要求的考虑，采用异构服务器的“一云多芯”云数据中心成为常态。多厂商的 ARM、x86 架构处理器在指令集、核心数、生产工艺等方面均有所不同，性能有显著差异，这对业务的统一调度和集群的运维管理带来了很高的复杂度。
算力差别可通过等价算力来刻画，按层次划分为：规格算力、有效算力和业务算力（见下表）。其中，规格算力的通用性最强，有效算力对特定负载类型更具针对性，业务算力更加贴近真实的应用场景，但由于负载和应用的多样性，有效算力、业务算力需要综合实际的上下游组件进行测算，复杂度高而适应性低。实际的业务分类测试体现：绝大多数业务通过等价算力系数即可满足统一调度的要求。领先厂商的云原生基础设施，通过算力抽象、算力转换、算力补偿以及微架构感知和算力统计等一系列技术，屏蔽了异构算力差异，与”混合部署“等降本增效方案兼容并存，为上层业务提供统一高效的异构算力调度能力。
