作者 | 褚杏娟
2009 年，“双十一”的大幕首次拉开，2010 年总成交额就翻了 18 倍，到了 2011 年更是翻了近 65 倍。以“双十一”为代表的各类电商大促活动直接带动了银行交易频率和数量的大幅增加，对银行系统的弹性扩缩容等能力提出了更高的要求。
对此，在云计算还在发展初期的 2012 年，工商银行便开始基于服务器虚拟化软件，自主研发和推广第一代基础设施云，并在此后一直紧跟云计算技术的发展：2014 年启动容器技术的预研工作；2015 年在业内首次基于开源的 Docker 容器技术、微服务等，建成应用平台云，运用到生产环境；2016 年完成互联网金融高并发场景的试点，顺利支撑快捷支付“双十一”大促等活动。
2017 年，工商银行组建了“七大创新实验室”，其中在杭州设立云计算实验室，主要负责云计算、分布式、基础软件等领域的前瞻性研究、平台建设和重难点技术课题攻关工作。同年，工商银行建成了基于 Kubernetes 的企业级应用平台云——PaaS 2.0，并顺利完成融 e 联、融 e 行以及 II/III 类电子账户等应用首次上云。
到了 2019 年，工商银行已建成同业规模最大的云计算平台，集基础设施云（IaaS）、应用平台云（PaaS）和金融生态云（SaaS）三位一体，有效支撑全行高并发、大容量业务的开展。2020 年，行内全量核心应用均已上云。2022 年，全行应用节点入云率已经超过 91%。
与此同时，随着云原生技术的发展，工商银行自身的技术架构也在不断演进：一方面由于金融行业的敏感性，监管部门一直在制定和更新行业技术规范，银行业对待新技术的态度相对保守；另一方面，以工商银行为代表的大型国有企业正纷纷加入开源项目共建和社区运营，以崭新的面貌走进开发者们的视野。
在这种约束与开放之间，工商银行需要找到自己的平衡。
自己的“云”
现在，工商银行内部有“五朵云”：研发云、测试云、生产云、分行云和金融生态云，这些云都建立在行内的基础设施之上。
研发云、测试云、生产云主要基于总行的业务应用设立，承载了软件从研发、测试到生产三个阶段。分行云主要用于输出总行云计算建设成果，实现技术组件、服务、解决方案等多层次复用，使分行更加聚焦业务研发。金融生态云则用于为合作方等提供服务。
这五朵云均组建了对应的专业运维团队，并通过云平台灵活、自动化的运维流程，建立了工商银行特色的 DevOps 流程，提供面向开发、测试、生产不同阶段的全流程快速交付能力，并通过行内企业级日志中心、云医平台、全息监控平台等平台，逐步形成自动化、精细化、智能化的云运维体系，实现云上应用运行趋势分析、故障秒级预警及实时诊断。
工商银行的“上云”历程可以说是金融科技行业的重要变革，象征以云计算、分布式等为代表的一系列技术创新也给金融行业带来了新的机遇，推动着银行业的数字化转型。在这一过程中，“构建自主可控技术、支撑全行架构转型”成为了每个银行技术人的坚定信念。
“我们高度重视云计算架构的自主可控能力。”工商银行金融科技研究院云计算实验室高级研究员周晓庆说道。
根据周晓庆介绍，云的自主可控主要体现在以下三个方面：
第一，承载云服务的服务器交换机等硬件设备需要自主可控。
第二，云平台依赖的操作系统需要自主可控。
第三，云平台的上层服务（如容器、中间件和数据库等）也需要符合自主可控的要求。
其中，硬件和操作系统方面一般以厂商提供为主，银行主要负责推动落地并做客户化定制。上云服务则以银行为主，虽然也会与厂商或高校合作，但银行自身要完全掌握设计、开发、运维、调优等关键能力。
工商银行会根据技术研判制定产品引入相关的技术规划，新增系统原则上都要采用自主可控技术路线产品，体量较大的存量系统则实行逐步转型。行内的专职研究团队负责对细化的服务器、操作系统、数据库、中间件、桌面终端等进行研究与适配验证，应用则更加聚焦业务系统转型实践。
上云历程
工商银行对应用入云都有明确的要求，根据适云评估情况“应入尽入”，具体实施过程涉及架构管理、平台、应用开发测试及运维等多部门协作。按照分工，架构管理部门牵头规划和组织，云计算实验室负责技术支撑工作，其中 PaaS 团队聚焦容器领域的建设，主要职责是跟进云计算方向最新的技术趋势，开展新技术前瞻性研究和原型验证工作，同时推进平台能力建设，支持应用上云。目前 PaaS 研发团队有 50 人左右，涉及有状态容器、无状态容器及配套运维监控等技术方向。
不同于 IaaS 层面以厂商产品为主，PaaS 层主要是基于开源产品自主研发。
2015 年，PaaS 团队已经基于开源 Docker 容器技术，建设应用平台云 PaaS 1.0。早期新应用上线，大家都很谨慎，团队全程参与，一对一指导业务改造、测试和跟进后续投产情况。当时，因为业界没有成熟的先例可以借鉴，团队以“自己造轮子”为主，比如自主研发调度引擎等。但随着试点范围的扩大，这种“摸着石头过河”的方式，无法快速满足大规模应用的需求。
到了 2016 年，PaaS 团队开始着手调研业界容器编排产品，包括 Kubernetes（谷歌）、Swarm（Docker）、Openshift（RedHat）等。当时，Docker 虽已成为容器引擎的事实标准，占有较大市场份额，但 Docker 公司缺乏大型集群运维方面的经验，社区也相对封闭，最终团队综合多方面因素选择了 Kubernetes。2017 年 6 月，基于 Kubernetes 的 PaaS 2.0 应用云平台正式上线！
为实现云平台从 1.0 到 2.0 的平稳升级，PaaS 团队也会协助业务应用进行改造，并逐步建成较为完善的上云支持机制，形成“一线运维—属地支持团队—PaaS 团队”三级支持体系，为应用提供及时、专业的上云支持服务。到 2020 年，所有核心应用均已入云。
最初的上云试点主要是从低风险、非敏感的互联网秒杀大促等场景开始，然后逐步扩大到有敏捷迭代需求的互联网属性业务。经过充分的实践验证，应用上云工作逐步推广到全行，主要覆盖的场景包括：
一、以支付类为代表的、具有互联网并发属性的应用，如个人网银、手机银行、快捷支付等。
二、主机下平台应用，如个人结算帐户、个人电子银行业务等。
三、其他对行内提供决策支持或者管理类、办公类应用，如集团信息库、财务管理等。
银行如今的业务跟之前有很大差异。银行不再只提供线下服务，开始面向互联网提供更多的线上服务，因此银行也面临互联网特点（如业务需求变化快、并发高、低延迟等）。同时，金融的业务逻辑比互联网更为复杂，导致银行系统的调用关系、链路等也比较复杂。
为应对上述挑战，PaaS 团队与微服务技术团队协作，一方面通过拆分以服务群组为主体的系统管理模式，基于分布式服务将整体功能拆分到不同服务群组的节点上，加快业务需求响应。另一方面，团队还推进标准化集群和部署流程建设，业务上云策略要按照标准化的指引和相关技术规范进行，因此到了核心应用上云阶段，业务应用通常可以独立完成绝大部分场景下的上云工作，PaaS 团队无需深度介入，主要以配合支持为主。
“面对生产上一些不常见的问题，从业务开发、生产到我们云计算实验室各个技术平台的人，大家在一个群里实时诊断，从不同维度分析问题并解决，最终形成一份经验指导。我当时参与其中，对此印象颇深。”工商银行金融科技研究院云计算实验室资深架构师王建奇说道。
云建设思路
当前，工商银行容器规模早已超过 30 万，全面承载包括核心银行业务系统在内的众多应用，整体规模一直处于同业领先地位，并且经过了双十一等高并发考验。
一、容器存储方面
对接分布式共享文件存储，为应用容器动态供应共享文件存储，落地批量等业务场景；自研 CSI 插件对接分布式存储、盘机、本地盘等，提供大容量、持久化存储，实现存储资源和存储申请的解耦管理；另外提供“临时存储 配额控制”功能，支持 tmpfs，满足高敏应用去存储依赖需求，应对日志输出等场景。
二、流量记录方面
一是通过软负载均衡体系处理。二是基于 Dubbo 框架做服务发现，通过“bridge 网络 多端口”支持，实现容器内外部随机端口映射，构建一张架构简洁、性能优异并且支持跨集群通信、云内外互通的扁平容器网络；基于 Etcd、confd、HAProxy 等开源产品自研了一套负载均衡体系。
如今，团队已经开始尝试结合自身情况研究 Ingress 来解决负载均衡问题。该方案相比社区版本的优势之一就是支持跨集群的负载，对后端 pod 是否在同一 Kubernetes 集群没有要求，可匹配行内大量的跨集群。
三、调度编排方面
早期在使用 Docker 时，PaaS 团队自研发了一套编排系统，引入 Kubernetes 后便基于 Kubernetes 做编排部署。
四、运维方面
自研了一整套以 Ansible 为基础、适配各类集群、覆盖所有常见运维场景的自动化运维工具，通过该工具对集群进行日常运维和升级等工作，同时将该工具与容器云管理平台集成，实现运维工作统一化、可视化。同时，统一的管理视图为运维人员提供面向容器的运维工具，例如一键部署、滚动更新、多节点伸缩、Web 终端等。
五、可观测方面
主要基于 Prometheus 监控体系，采集操作系统、应用中间件、云平台和基于日志精细化配置的应用多层级运行指标，提供云上应用运行趋势分析、故障秒级预警及实时诊断。基于容器监控、日志采集等数据，建立通用、可定制、可扩展的业务分析模型平台，实现云上运维可视化，并对接到手机端，直观展示 PaaS 云整体运行情况、云上应用运行状态、以及报警信息。
鉴于跨集群的自动伸缩和自动故障迁移存在一定的技术挑战，PaaS 团队已在行内环境进行测试，未来将继续推进生产的规模化落地。
思维转变的挑战
上云后，工商银行整体的部署架构、开发模式和问题分析等发生变化，应用研发人员面临的最大问题便是要学会用云化的思维去分析问题。
新的云化架构下，有些问题无法按照原有思路解决，应用开发对 PaaS 底层技术架构并不完全了解，所以会非常依赖于平台提供的辅助分析工具或功能。
对于迭代发布部署方式的变化，PaaS 团队牵头建立了云上 DevOps 工具链，对 Deployment 等资源对象进行抽象，封装成模板、构建包等概念，尽可能屏蔽 Kubernetes 底层技术细节，并与行内 DevOps 体系衔接，支持全链路自动化上线，降低应用上云成本。
传统虚拟机或物理机部署情况下，应用开发团队可仅验证几台服务器，现在面对应用容器细粒度、大规模的部署形式，部署后的验证成为一个艰巨的考验。为帮助应用解决这一痛点，PaaS 团队建立了投产验证平台，可以自动化托管投产业务的验证，比如提供业务侧的日志、业务接口等验证方式。
此外为适应上云模式，PaaS 团队还积极探索中间件领域，已实现涵盖 MySQL、Redis、ElasticSearch、ZooKeeper 等多种有状态应用的容器化部署，其中 MySQL 容器上云率已达到 90% 以上。
“上云不只是将云下架构模式直接搬到云上来部署，还有代码重构。”王建奇表示，应用侧遇到的更多是代码层面的问题。“即便监控平台能够分析出问题在哪，比如哪里 CPU 使用率高了，但到底哪段代码引起的还需要应用侧进一步定位。”
主动加入开源
目前，工商银行仅生产环境就有一百多个集群，且规模还在不断扩大。导致工商银行集群超大规模的原因是多方面的。
首先，工商银行采用“两地三中心”架构，北京、上海共分布三个数据中心，不同中心之间的集群是分开的，每个中心又有不同的网络安全域，安全域之间又要求物理隔离……如此势必会产生较多集群。
其次，一些特殊类型需要用独立的集群支撑，比如无状态通用集群与有状态 MySQL 数据库集群等异构集群需要分开。
最后也是最为重要的，基于故障域的考量，PaaS 团队会去限制单个集群的规模。银行业，甚至整个金融行业对业务连续性要求非常高，特别是核心的业务场景，因此控制基础设施的故障爆炸半径非常重要。也就是说，不能因为某个集群出现问题而导致全行业务受影响。
对此，PaaS 团队自研了管控面用于多集群管理，同时也与华为等共同打造了 karmada 项目，致力于解决遇到的跨集群问题。
开源项目共建
基于拥有的大规模容器云运营经验，PaaS 团队经常会参加外部分享和交流。2020 年下半年，在一次与华为的偶然交流中，双方发现彼此都遇到了多集群管理的问题，如自动扩缩容、故障修复等。
当时的开源产品或多或少还存在一些问题，并没有真正解决双方的痛点。因此，工商银行联合华为、小红书等共同发起了多云容器编排引擎 karmada 项目。
参与共建的几个企业最开始就用了类似开源社区的工作模式。大家先构建一些最基础的模块，然后逐步增加功能，社区提交 issue，再在周会、双周会上认领某些功能的开发。
“大家的侧重点不同，关心的功能也不同，但努力的方向是一样的，就是想把多集群管理做好。”工商银行金融科技研究院云计算实验室资深架构师沈一帆说道。PaaS 团队主要投入了集群生命周期管理和跨集群调度模块的建设。
2021 年 5 月，karmada 正式发布，如今项目已加入 CNCF。PaaS 团队还是一如既往积极参与社区开发，解决规模化应用上的问题。
开放但审慎
周晓庆提到了大家早前对于银行业的一个刻板印象：闭源就意味着闭门造车。但周晓庆表示，闭源并不代表技术一定落后。
“与互联网等行业不同，银行不会单纯追求技术新，最核心的关注点还是信息系统的稳定性和可靠性。实际上，金融行业可能是除了通信行业之外，最早使用计算机技术的行业，但行业特性决定了银行对技术应用会更加稳健一点。”
与其他商业场景类似的是，大家早期都选择基于成熟框架或商用产品去建设信息系统。“这些闭源产品与外界交互较少，我们对外也没有太多的分享。但随着开源的发展，银行的整体架构也在发生变化。”周晓庆说道，“现在银行的迭代升级速度比之前快了很多。”
拥抱开源对银行来说是一个必然选择。如果延续之前的模式，银行自身的技术可能会与开源生态技术不兼容，同时与社区的脱节也意味着后期对商业技术的依赖非常大。
工商银行拥抱开源的一种方式是与互联网企业合作共建。除了 karmada，工商银行还与网易联合发起了云原生日志系统 Loggie 项目，该项目也在今年 3 月份正式开源。
“之所以选择这样的方式，一是互联网企业愿意在社区上投入，并已经拥有了丰富的经验；二是与工商银行一样，这些企业也有较大的规模和体量，双方有相同的需求。”周晓庆解释道。
开源技术虽然极大推动了工商银行内部技术栈的升级，但工商银行对开源技术也非常审慎。现在开源技术和产品普遍面临安全漏洞、代码质量参差不齐等风险，因此使用开源软件一定要安全可控。
工商银行对于开源技术有一套非常严格的引入流程和事后跟进机制。在工商银行金融科技研究院云计算实验室里，新技术团队负责及时跟进业界最新动态，对前沿技术做研判，并做相关原型验证，形成研究报告。研发团队会完成技术方案、落地研发及灰度测试，试点成功后再逐步上线推广。
使用开源产品，对于要保证技术自主可控的云计算实验室来说，也意味着要始终有丰富的技术积累和经验去解决未知的问题。
“但总体看，国内开源现在为追赶阶段，本土开源项目发展和影响力仍需持续提升。主流开源项目当前仍以国际社区为主，一旦停止维护就会出现比较被动的局面。而国内开源项目社区普遍参与贡献没有那么高，建设发力就比较分散。同时相较于国内庞大的开源软件使用规模，市场上缺少与之相匹配的专业技术支持服务提供商，这也对用户的自主掌控能力提出了更高的要求。”周晓庆评价道。
结束语
以云计算和分布式为代表的新技术在帮助银行解决原有问题的同时，也给金融行业带来了很多机遇，周晓庆以数字人民币为例解释道，“如果停留在原来的主机架构模式上，没有云计算、分布式等技术的支持，就不会有数字人民币等业务创新。”
要抓住新机遇，就会对研发团队提出更高的要求。团队只有完成从上到下的提升，才能保证对技术的开放和可控。
“管理者要同时拥有过硬的技术和管理团队的能力，两者都非常重要。”周晓庆强调，一个技术团队管理者的专业技术能力不能丢，要对自己的技术能力进行“保鲜”，持续学习，保证自身技术知识的深度和广度，这样才能更合理地制订团队目标，并对团队成员的技术方案提供指导。
同时，PaaS 团队坚持结果导向，做好关键性决策，不过多去管控团队成员的执行细节，引导其充分发挥自身能力，确保任务计划按时完成，如果有进度风险需要主动汇报和上升，因此团队成员需要有更高的自驱力和执行力。
嘉宾介绍：
周晓庆，工商银行金融科技研究院云计算实验室高级研究员
王建奇，工商银行金融科技研究院云计算实验室资深架构师
沈一帆，工商银行金融科技研究院云计算实验室资深架构师
