文 / 招商银行信息技术部总经理 周天虹
招商银行信息技术部 谭斌 熊爱国 张锞斌
(资料图)
过去20年，随着互联网发展浪潮的推进，作为互联网IT技术主体支持的x86开放系统得到跨越式发展，而银行业广泛使用的IBM主机系统的生态则由于封闭而日趋衰落，开放系统替代主机系统成为一个必然的技术趋势。但传统开放平台由于集群规模过小导致资源池割裂，进而产生IT运维和开发的竖井，这让银行业开放系统替代主机的过程充满挑战。在技术演进过程中，云计算技术应运而生，成为重塑整个信息产业业务模式的革命性技术，极大促进了全社会的数字化转型，同时也推动了软件开发的规模和复杂性迅速上升。与此同时，近年来银行业科技应用日渐深入，IT应用开发模式也由多年前的小团队独立开发为主更多转变为大团队协作开发，开发团队迫切需要一个弹性敏捷、扁平开放、支持协作分享的基础设施，这进一步强化了云平台作为未来银行业数字化转型基石的地位。
在云的发展过程中，我们观察到一个重要的现象：技术发展由原来的头部厂商推动转变为开源社区推动。这就意味着我们获取关键技术的方式发生了根本性变化，银行IT不能再完全依赖头部厂商实现关键基础技术的进步，而需要建立自主的力量。在云平台的长期构建过程中，我们获得了一些有价值的经验和认识。
招商银行信息技术部 总经理 周天虹
云计算是新的IT变革中的决定性力量，招行需要一个先进的私有云来重构科技体系，实现科技的扁平、开放、共享和敏捷，并支撑全行业务更加融合互通以及快速发展。原生云的概念由来已久，它要求云在技术架构、组织、流程和工具等各方面均应具备先进的特性，以AWS为首的领先公有云正是原生云的最佳实践。在技术架构上，招行私有云应该具备云的弹性、灵活性、开放特征和大集群管理能力，本身可持续发展并能够支持应用的云原生架构演进。招行从云建设伊始就明确要紧追领先公有云，走原生云之路（招行原生云简称ACS，Advanced Cloud Service）。基于此定位，招行在能力框架、建设方向和原则、总体架构以及实施路线等方面开展了顶层规划设计。
1.企业级云能力框架。云的基本能力方面，基于私有云是企业IT基础设施的定位以及公有云领先实践的状况，我们的策略是私有云建设需全面对标领先公有云。与一般公有云能力表述不同，考虑到私有云的企业属性，提供云的通用能力的同时也应该更好地支持企业自身需求的内嵌场景。特别是IT管理能力部分，由于招行需要实现基础设施领域包括组织、流程和架构等方面的企业级规范管理，因此私有云必须实现相应的管理能力场景，此部分功能对云上架构持续进化具有长远意义。在支持云服务使用者方面，由于拥有对用户使用方式的强管理权限，云服务功能须包含特定技术性要求，同时应针对用户场景提供企业范围内的开发工具支持。在私有云管理功能方面，围绕管理IaaS层各类资源、管理云服务、管理应用和管理用户，拆分为云运营和云运维能力，让云的前后台在流程层面解耦，有助于各自独立发展并持续提升用户体验。结合云的技术特点及应用价值，招行面向用户（云管理者和使用者）提出了云目标能力（见下表）。
表 招商银行原生云云能力框架概要
2.保证云发挥使能作用的建设原则。基于私有云应该具备的能力和需要提供的价值，我们定义了指导私有云建设的基本原则：私有云是承载企业级IT发展的基础设施，是支持、驱动甚至引领组织、流程和文化持续发展变革的IT平台，科技领域的组织、流程和文化要匹配云的建设和应用；在面向用户场景方面，构建以满足技术人员云原生应用开发、云服务开发、应用和服务部署以及业务人员使用云场景的全栈功能云，而非实现局部IaaS云或PaaS云；统一标准化、自动化管理平面，而非拼凑式对接传统运维体系甚至主要靠人工实现云管理；在核心服务模式对齐领先公有云的基础上，构建满足招行特色需求的私有云；在管理工具上形成闭环，支持实施云采用框架（Cloud Adoption Framework，简称CAF，AWS提出的云实施最佳实践框架）。
3.锚定业务场景规划总体架构。架构设计方面，云作为实现IT能力交付的平台，“云即业务”，并且是对传统IT交付模式进行颠覆性变革的业务平台，传统IT的组织、角色、流程在云模式下都有较大的变化，云业务体系的定位对新模式下需求和功能的实现至关重要，是技术体系的出发点。云业务体系中对业务的目标架构和架构变迁路线的明确，有助于理清云服务的主次关系和建设路径，并推动在云转型的干系方如组织和流程等方面作出匹配调整，避免技术架构变成空中楼阁。技术体系方面，IaaS层主要采纳已有厂商产品形成的标准化API管理接口，PaaS层基于开放的K8s及自研云服务，之上以自研云管平台为管理核心，根据招行场景编排需求和组织云服务。同时，针对私有云的应用上云场景，需提供应用参考架构，以及支持其落地的云服务和工具。
4.在探索中交付，在发展中完善。2015年招行启动私有云建设时，以我们预期达成的云能力和规模体量，业界尚无成功案例可借鉴，更缺少具体的实施经验。“道阻且长，行则将至”，招行整体私有云建设在探索中逐渐成熟和规范，具体过程可总结为：凝聚共识、架构引领、规划统筹、协同交付、迭代演进。首先形成科技组织范围内“CloudFirst”的共识，制定业务架构和技术架构，通过总体规划统领落地实施，以云工程项目群管理的方式开放式推进各团队协同交付，从MVP起步，先小范围试点，再逐步推广演进，最终达成目标。
原生云总体架构确定后，具体的业务和技术方案就成为左右云平台成败的关键环节。我们通过共同关注点来聚焦和组织相关业务和技术解决方案。在实施层面，将原生云建设划分为一级实施领域及二级专题，将共同关注点映射到对应专题，并相应组织一系列项目展开具体建设，从而实现方案以高内聚、松耦合的方式落地。截至目前，已经完成二级专题超过600个。某种程度上，一个私有云整体解决方案实际上就是若干个关注点和其解决方案的集合。我们基于业务导向和技术导向，将共同关注点分为两类。业务导向的关注点主要包括：云原生架构转型、自服务、云运营和云运维等；技术导向的关注点主要包括：云基础设施、可用性、容量性能、可维护性和开放性等。
1.精细把握自服务模式。在提升用户使用基础设施资源的效率方面，公有云开创了自服务模式。银行IT历来都是保姆式服务，如果私有云提供自服务模式，虽然可以解决传统IT模式中服务提供者和用户之间的服务链割裂问题，但在管理权责、流程接续和安全等方面必然面临一系列挑战和问题。自服务模式涉及对运维和开发人员的角色和活动的重新定义，涉及组织层次上的调整，同时需要以技术手段保证技术管理域和业务管理域的对应，从而确保安全、性能和个性化服务的要求被落实。我们首先通过责任分担模型，重新定义开发、测试和运维等不同场景下云服务提供者和使用者的权责，制定云服务接入规范和准入标准。结合自研云管平台，把各个云服务都包装成标准Resource Provider以供调用。在云服务规范和标准统一的基础上，优化自服务的流程衔接。为了解决自服务的安全问题，我们采用VPC/SEG等技术手段，实现多租户和数据权限隔离，总分行开发和业务人员能够灵活主动获取资源的同时，也符合银行对安全运维的要求。上述方案实施后，实现了公有云自服务模式在原生云的落地，并在实践中得到了验证和强化。
2.云运营和云运维分而治之。银行IT原来没有运营和运维的区别。上云后，尤其是自助式服务之后，可用性、资源治理、安全管控等问题变得突出。在调研国内几家头部云厂商的后台团队后，招行组建了独立的云运维和云运营团队。云运维面向云服务，关注站点可用性、容量、自动化、SLO/SLI/SLA和资源利用率等；云运营面向用户，关注用户旅程、体验度量优化、权限配额、计量计费和资源治理等。云支持模式从原来运维为主兼顾运营，转变为云运维和云运营并重，用户需求与云平台技术互相促进、良性互动。调整一年后，2022年原生云整体可用性首次突破99.995%，变更自动化率提升到90%，云服务资源交付成功率提升到97%，安全和权限管理失控的状况明显改善。
3.灵活弹性的云基础设施。原生云借鉴公有云的多区域RG（Region）、多可用区AZ（Availability Zone）的云基础设施设计方案，但在具体的部署架构上与公有云有差异。结合金融行业重要信息系统的保障要求，我们规划和建设了分布于深圳和上海的3个区域（RG）共计11个可用区（AZ），每个区域（RG）至少含3个可用区（AZ），每个可用区含多个云资源池MU（Management Unit），投入物理服务器2万余台。在具体设计和实施时，我们根据原生云SDN和SDS的特性和能力，综合评估成本、用户功能、管理、可用性、容量性能和可维护性等要求，灵活设置基础设施的管理域、故障域、安全域、性能域和功能域。例如我们可以把开发、测试和生产环境在同一个可用区（AZ）内用不同的云资源池（MU）隔离，但在可用区（AZ）层面又是统一管理，从而达到管理清晰、成本最优、安全隔离的目的。
4.解耦的可用性才是可管理的可用性。基于国内外领先公有云建设经验，为了建设高可用的金融私有云，我们对基础设施设计了更精细的纵向分层和横向解耦方案。在IaaS层面，借鉴公有云行之有效的RG、AZ高可用架构，根据招行自身架构特点，在AZ级以下设置了MU（Management Unit）、FD（Fault Domain）、CL（Cluster）、机柜和服务器PM（Physical Machine）等可用性级别，有效压缩故障的爆炸半径，为快速故障定界和隔离自愈提供条件。在PaaS层面，根据各类云服务特点设计对应的可用性方案。例如在容器平台方面，有别于公有云上普遍采用的单集群跨多AZ，我们使用多集群跨多AZ架构，通过自研的容器云管和云应用管理平台落地应用流水线部署，通过流量调度平台实现应用在多AZ之间调度流量。这套方案可以规避AZ及以下级别的故障。在2022年触发的近百次故障隔离或自愈事件中，最小可以做到应用服务单元颗粒度级别的故障隔离。通过自动化的一键措施，隔离和切换的应急时效能达到分钟级。在应用层面，除了应用本身的高可用设计，在部署架构方面，原生云提供可用性集AS（Availability Set）等特性，实现应用实例的亲和/反亲和部署。通过发布云原生应用部署参考架构，指导应用按规范部署并实现和底层组件的高可用联动。当前，原生云的整体可用性已经达到99.995%，满足了金融领域绝大多数场景的可用性要求。
5.多管齐下提升容量性能。随着全行大规模的应用上云，早期隐藏的容量性能问题逐步暴露，包括资源供给不足和资源浪费并存，应用部署新旧架构转换导致资源占用双份，SDN性能不理想导致部分场景丢包和延时，基于DNS域名的流量分发不均，大数据应用上云后对存储计算分离模式的巨大冲击等。为此，我们从技术、流程和资源等方面采取措施，大力推进云平台建设过程的标准化和自动化，确保2周就可以供给一个新资源池；建立管理集群，计算集群和存储集群的灰度升级能力；对SDN组件持续升级、调优和扩容；建设云平台元数据收集系统，对容量性能统一监控和分析；建设原生云流量调度平台，确保精准流量调度；对普通资源池，提高超分比和利旧比，提高资源利用率；云运营团队加大资源治理力度。采取这些措施后，原生云容量性能问题得到逐步缓解。目前，容量增长速度下降到高峰时的一半，SDN丢包和延时下降99%，各资源池平均CPU使用率突破20%，标准资源池CPU利用率达到30%以上，已超越公有云的集群CPU利用率水平，2022年资源治理收益折合超过7000台物理服务器。当前，我们正在探索离在线容器混部和动态调度，争取达到40%以上的CPU利用率。
6.灰度升级保证服务不中断。可维护性是云平台成熟度的重要指标。原生云3年来经历了2次跨大版本的升级，每次升级都伴随着可用性和可维护性的全面提升。由于采用计算和存储分离的架构，我们通过优化策略、动态调度等措施，在云平台灰度升级的过程中可以保持服务在线，结合原生云可用性集AS特性，可以不破坏云平台服务的高可用架构，让用户基本无感。在实施中，维护域/容错域/故障域（Fault Domain）的划分确保了每次维护的影响范围/爆炸半径可控，避免变更失误造成重大事故。我们基于云运维平台做了大量的运维数字化增强工作，使变更自动化率提升到90%以上，每2小时可以完成一次全平台的自动化巡检，96%事件能当天处置完毕，IaaS层可不间断持续实施计算和存储的灰度升级。
7.开放才能有未来。开放生态推动了云计算技术发展，构建私有云同样需要开放性来保证其持续发展。私有云开放性关注点落地是比较复杂的工作，我们的做法是以自研云管平台为抓手，利用云管平台的统一调用和编排云服务，在扩大调用范围的过程中逐步落地云服务接口标准化和云服务模块化。云管平台让用户场景和具体实现技术解耦，最底层的计算、存储和网络的云基础模块也实现了异构产品兼容，避免了私有云发展过程中被厂商或技术栈锁定。配套建设混合部署工具、云运维平台等，支持开放技术栈的应用发布和系统运维接口，保证底层异构模块对上层使用的透明。信创政策出台后，招行引入某信创云产品，与原有国外产品形成双技术栈架构。基于上述开放性策略，在信创云建设中，不到一年即实现了两个技术栈的统一纳管和混部调度，云基础能力全面打通，实现一云双栈（通用/信创），支持一云多芯（x86/c86/ARM），支持上层应用在两个技术栈上实现无感平滑迁移（见下图）。
图 原生云的一云双栈和一云多芯示意图
8.推动云原生应用架构转型。云原生指以完全适配云架构的方式在云上开发、设计、部署和运行应用的方法论和技术体系。我行进行云建设和应用上云的同时，也同步开展了云原生的转型工作。相对于传统应用架构，云原生是一套全新的架构体系，在应用架构、代码工程、流程交付和部署架构等方面都需要进行适配。
一是云原生应用开发范式赋能应用设计。应用架构方面，我们通过云原生开发范式对项目开发进行赋能。招行业务应用的上云过程，是一个伴随着云应用架构转型的过程，目前容器应用的比例超过了90%，支持云原生应用的快速部署和灰度发布，应用整体转向云原生架构。在转型过程中，服务的拆分是一个难点。云应用架构设计方面目前没有通用的解决方案，大量依赖于开发团队的能力和经验。我们将业界先进的微服务设计方法论，如领域驱动设计、事件风暴等，结合招行业务的特点，形成可操作的开发范式和流程规范，通过种子教练赋能的方式，提升开发团队在业务应用微服务拆分方面的设计能力。
二是开发框架和代码工程模版赋能开发效能提升。应用开发方面，我们通过开发框架和代码工程模板降低开发门槛。云原生应用为了使用云平台的能力，不可避免地要在业务代码中加入大量的平台相关的技术代码，一方面增加了应用代码和底层平台的耦合性，另外也拉高了业务开发人员的技术门槛。在实践过程中，我们逐步总结了一条结合了开发框架、开发插件和代码工程模板的综合治理之路。开发框架在代码层面实现平台相关技术代码和应用代码的解耦，让业务开发人员聚焦业务逻辑的开发；IDE下自研开发插件可以有效提高开发效率，作为代码规范的落地工具，提升代码的规范性和安全性；代码工程模板解决了设计模式落地的痛点，统一代码语言，提升了代码可维护性和可靠性。
三是开放应用模型（OAM）标准化应用交付。应用交付流程和部署架构方面，我们结合DevOps和OAM提升应用的交付效率。招行很早就将DevOps流水线作为一项重要的软件工程能力进行建设，目前DevOps成熟度是通过信通院成熟度5级认证的两家单位之一，已经覆盖了所有自研系统的交付，并实现了应用的持续交付。OAM是一个基础设施即代码（IaC）的标准开源规范，实现系统级别的不可变基础设施和声明式部署。通过标准的OAM描述语言，描述一个简单业务由哪些微服务组成，这些微服务如何运行，相互之间是怎样的依赖关系，微服务对外暴露服务能力的方式，以及如何运维，如何排障等特性。招行的云原生应用管理平台，基于OAM模型，为应用提供可视化的一站式交付能力。通过简单的可视化配置，可以快速实现多个关联应用服务单元，以及相关云服务的整体发布和部署。
招行原生云自2015年启动建设至今，克服了平台定位把握、技术路线选择、技术难点攻关、性能安全成本三方平衡等困难。期间也犯了不少错误，踩过大量的技术坑，应对紧急情况通宵奋战的场景至今记忆犹新。先后经历了PaaS平台、全栈云和双栈云三个发展阶段，原生云逐步演进为业界最先进的私有云平台之一，并已全面投产应用。面向未来，确保关键业务的长期稳定运行，充分释放云的潜能，我们还有较长的一段路要走。
1.云平台赋能总分行业务发展。当前原生云平台投产的物理服务器算力合计超过130万核，多种分布式云存储总可用容量超40PB，提供70余种云服务，服务总行、分行和多家子公司开放系统全面上云，应用上云过程中同步推进云原生改造和传统中间件的可控平替。原生云上的应用90%以上都是容器应用及云服务。原生云平台及云模式的转变，让总分行和子公司的研发效率得到提升，业务更加敏捷。云上承载的应用每日业务请求量超过300亿次，峰值处理能力超过100万TPS，CPU平均利用率超越公有云水平。
2.紧追前沿技术，分享技术红利。不同于传统银行IT在基础设施方面只使用成熟技术的惯例，招行原生云建设的指导思想是紧追前沿技术，在云建设中引入和应用了大量前沿技术，一方面我们本身享受到技术尝鲜者的收益，另外对于管理前沿技术的风险敞口也积累了有益的经验。
我们在原生云的IaaS层采用了大量新技术，例如25G/100G CLOS网络、存储计算分离架构、软件定义网络SDN、软件定义存储SDS、IPv6+IPv4双网络栈、RDMA、SRIOV和智能网卡、ACS流量调度平台、异构双平面DNS等。稳步推进新技术应用，从实验到可控到推广，实现了IaaS层的技术迭代更新。
在PaaS层，CMB-K8s是我们在原生云信创技术栈上推出的容器平台服务，采用基于Cilium自研组网模式，较通用容器集群网络性能提升30%以上，基于eBPF实现了更好的容器网络可观测性。
自主可控的云管理平台和云运维平台，可以支持应用在多个技术栈之间进行无缝迁移。有利于吸纳和引进最先进的技术，取各家之长，并避免厂商锁定，保证云底座的先进性。
声明式的应用交付模式，基于OAM，实现真正的IaC交付模式。云平台提供的标准化资源和服务供给，为IaC提供了基础能力。将一个通用的应用模型贯穿到整个业务应用研发的用户旅程中，每一个环节的输出都以可执行代码的形式记录，最终通过自动化引擎，实现声明式的部署。
在原生云平台建设中，我们不仅使用开源软件，也在开源社区做出贡献，OAM作为云原生应用交付的重要标准，KubeVela是OAM的主流开源实现，招行已成为国际KubeVela开源社区的最高一级贡献者，能够参与社区的技术规划和决策。
3.发挥云的牵引作用，从上云走向全面适配云。招商银行已经走过“上云”的起步期，进入可持续发展的双栈云阶段，具备有利条件支持云技术在行内的持续发展。为全面获取云的红利，下一步需要推进科技体系全面适配云。为此，我们要加快推进云开发范式落地，通过加强架构设计，提升应用开发的敏捷性，应对业务的快速变化；我们要构建全面适配云的工程管理体系，并从DevOps走向BizDevOps，高质高效地进行产品价值交付；参考云技术的发展轨迹，我们将持续探索科技组织内部的开源生态和开源能力共享；与云带来的开放、创新、分享的文化相匹配，我们更要用云原生重塑IT工作文化，让招行科技体系更快地从“OnCloud”走向“InCloud”，全面释放云生产力，支持“数字招行”建设进一步提速。
（栏目编辑：郑岩）