3年时间、2亿用户、2200+套系统上云：招商银行ACS原生云怎样练成？
一、云建设的背景和选型
1.1 为什么上云
当年为什么要决策上云？其中一个原因是传统技术架构已成为了进一步创新发展的瓶颈。包括两个方面：传统主机系统和传统的开放系统。
比方传统的主机系统招行用到了IBM z390、IBM AS400，用到了Tandem，就面临一些问题：COBOL语言在现代化的场景下已经不太适应。
面临的诸多挑战：比如难以横向扩展、与主流技术脱节、生态封闭、参与者少等等。传统开放系统也有问题，比如资源割裂、敏捷和弹性差、技术栈繁杂、应用架构散乱等。
因此，招行在上云过程形成两个洞察：
-
我们认为整个技术的发展已经从头部厂商引领转变为开源社区的引领。因为传统的IBM、EMC、Oracle 等，在技术的引领方面已经落后于开源社区。
-
外包外购到自主可控，金融行业转型到云需要做很多的探索和创新，传统的头部厂商不能给更多的引领和帮助。所以很多工作需要我们自主可控、自主创新。
1.2 为什么是全栈云和原生云
为什么是全栈云和原生云？原生云是在云发展过程中提出的一个概念，要求云在技术架构、组织、流程和工具等各方面均要具备先进的特性，以AWS为首的公有云正是原生云的最佳实践，建私有云就必须建原生云，以最先进的公有云为目标导向。
1.3 为什么是多云和混合云
经常看 Gartner 报告的同学会知道“双模（BIModal IT） ”，就是以标准+稳态为主的传统架构和以云原生为主的云架构。
在建设私有云的过程中，招行发现云的理念和架构已经可以接受考验，传统架构达到的可用性，云架构同样可以达到。
所以我们要求传统架构也可以上云：可以上一个稳态的云，这正是招行所理解的多云：稳态云+敏态云。Gartner 报告里面显示85%企业采用 Multicloud 多云架构，多云现在不仅仅是一个策略，而是一个实践。稳态云：金融交易云FTC，还有一个敏态云：ACS，这正是招商银行的多云战略。
混合云：官方定义混合云=公有云+私有云，招行理解是跨多云的统一云平台，具有高可用、安全异构、避免锁定、安全信创等特点。
1.4 招行私有云特征
-
云开两朵：面向金融核心稳定的金融云，面向开源开放敏捷的原生云。 -
一云双栈：招行私有云发展过程中采用两种技术栈，一是使用X86技术栈的通用区，另外是安可信创技术栈的信创区。
-
一云多芯：通用区主要使用 X86 的芯片，在信创区更多使用国产芯片。
-
开放+云原生：招行坚持开放、全面面向云原生的架构，容器化、微服务、DevOps、Serverless 等。这就是招行私有云的特征。
二、云建设的历程和现状
下面简要介绍下 ACS IaaS 平台发展历程：
-
ACS 1.0：2015年做出建设私有云的决策，2017 年招行建设了首个云计算实验室，并且在2018年基于WS2016建设一朵分行云，此时仍处于试点阶段。 -
ACS 2.0：2019年，我们将ACS原生云升级到了2.0，已经具备3AZ云原生架构，无论是规模还是可用性安全性稳定性已经到了一定的水平，为三年上云工程打好了一个基础。 -
ACS 2.1：2022年，招行根据发展情况做出全面上云的决策。全面上云是指所有业务都上云（敏态业务+稳态业务）。
-
ACS 3.0：2022年ACS也升级到了3.0，此时已经实现全行一朵云，建成大规模先进的私有云。在这个全面上云过程中我们也符合国家的信创战略，与腾讯云合作，建设了原生云信创区，正式实现“一云双栈”和“一云多芯”，持续迭代两个技术栈，并实现两个技术栈全面支持IPv6+IPv4。
2.1 ACS PaaS 平台建设历程
当前，ACS PaaS平台在三个方面取得较大进展：
-
ACS PaaS 容器平台已经发展到了3.0 -
基于 ACS 信创技术栈也打造了一个全信创的平台 -
招行开始自研 Kubernetes ，在 2022 年招行推出自研的 CMB K8S，打造完全可控的容器平台。同时在这个过程中逐步扩大规模，最终在2022年全面实现了上云。
2.2 应用上云历程
启动全面上云之后，上云速度显著提高，2020年700+系统上云，2021年1500+系统上云，2022年9月全行所有的系统均实现了上云。
上云不光是一些不重要的系统，招行最核心应用——手机银行、掌上生活等都实现了上云，共计2200+系统完成了上云。
2.3 发展趋势总结
-
稳中求进：是从单技术栈（通用区）发展到了双技术栈（通用区+信创区）。 -
安全合规：从开始的单网络栈 IPv4 到双网络栈（IPv4+IPv6），建设招商银行私有云的过程中主要是通过招行自己的技术在不断的推进，把两个技术栈通用区和信创区都实现了 IPv4+IPv6 的双网打通。招行 IPv4+IPv6 是全路径的，包括从前端负载均衡 → Web服务器 → 应用服务器 → 容器平台都使用了IPv6。 -
有的放矢：容器化和微服务化，我们借助一些第三方的力量来帮助我们做云原生云服务的改造。 -
小步快跑：我们在上云的过程中首先是建立一个云计算实验室小规模的试点，建设一个分行云把分行拿上来试点，当条件具备环境成熟的时候我们就启动全面的上云。
三、问题和风险
3.1 安全的问题
安全方面：DMZ 和 BIZ 安全方面的问题，招行上云要不要把这两个区合并到一起。从云计算技术角度来讲，可以通过 VPC、安全组、虚拟防火墙做到虚拟的隔离，但是要不要做这两个的虚拟隔离。招商银行选择物理隔离，因为银保监会是要求物理隔离的。这不仅仅是一个技术问题，实际上也是一个策略问题。
3.2 网络的问题
网络方面：这方面问题非常的突出，主要就是因为 SDN 引入，招行上云是上一个彻底全栈的云原生的云，所以必须要用软件定义网络。肯定会面临一个和传统的物理交换网络同样存在的问题，就是超时丢包、网络容量和传输瓶颈等等。这些问题都是没有现存解决方案的，都是要在上云的过程中，在建设过程中持续演进，迭代不断优化。
3.3 体验的问题
体验问题：传统上，金融机构IT类似保姆式服务，实际上云之后是自服务的模式，自服务模式就需要去推责任共担模型，责任共担模型在公有云是非常普遍的，私有云推动有很大阻力。
3.4 运营运维的问题
3.5 业务连续性的问题
上云的问题：包括流量调度、灰度发布、混合部署、迁移搬迁，三年上云涉及到了大量应用的迁移搬迁——从传统环境往云上进行搬迁。也需要有相应的工具和条件，搬迁的时候能不能实现灰度搬迁？搬迁过程中IP地址保持不变，或者搬迁过程中能够是流量式分批介入。
还有统一日志、链路追踪，这都是非常重要的。这些问题如果得不到解决，是很难定位和分析问题的。尤其是链路追踪，必须实现全链路的追踪才能够真正实现快速定位和解决问题。还有信创替代等都是在上云过程中需要面对和解决的问题。
四、经验和趋势
4.1 顶层设计在云建设中的关键性
4.2 集中力量打磨云平台的关键组件
通过平台化、服务化屏蔽基础设施的复杂性，持续改进服务质量。
重点提下招行自主研发的几个工具，包括用户侧的云管理平台，运维侧的云运维平台。还有公共能力，CMBAgent、CMDB、监控平台、事件平台等，把这些能力牢牢抓在自己手里才能够脱离厂商的控制和约束。
4.3 发挥云基础设施敏捷弹性的优势
4.4 活着是第一要务，恢复业务是第一优先
我们认为解耦的可用性才是管理的可用性，多管齐下提升容量性能，通过灰度升级保障服务不中断，构建多层次的保障体系，业务活着对我们就是0和1的关系。
4.5 开放才能有未来
招行的私有云一定要坚持一云双栈，一云多芯。通过通用区和信创区的双栈混部架构，满足应用支撑能力（业务需求）、独立自主（监管要求）、成本（可持续性）。
4.6 紧追前沿技术，分享技术红利
刚才强调了招行现在完成了的第一步，从传统架构向 OnCloud 的转型——把应用迁移上云，最后实现从 OnCloud 到 InCloud 转型，那怎么实现这个？
需要持续的飞轮的敏捷迭代才能够实现，比方说就是要实现云开发范式、云原生架构模型、持续演进、全场景覆盖和数字化向智能化这样一个飞轮架构，通过不断的敏捷迭代使飞轮能够旋转起来，这个旋转速度越来越快，最终必将实现一个 InCloud 云的架构。
以上就是今天分享的内容，谢谢。
本文根据演讲者在 GOPS 2023·深圳站演讲整理而成，如有图文不妥，请以视频为准。更多精彩，请关注高效运维公众号。
作者简介：
长按下方二维码，立即领取
世界上第一个SRE是如何诞生的？
被 Kubernetes 报错整懵了？试试这些排障方法
“高效运维”公众号诚邀广大技术人员投稿
发表评论