金融机构的“数字化、智慧化”战略落地，多数金融机构启用了全新的容器云平台，并花了大量时间和精力对关键业务进行了微服务改造，以适配云平台。通过对金融企业架构和热点主流技术的研究和探索，浅谈一些个人观点。
一、技术选择
新应用系统需要更加灵活快速上线，以客户体验为主要考量指标。私有云IaaS云平台，能够灵活提供虚拟机、容器服务。而基于虚拟机或物理机的紧耦合架构，软件版本的细微更新就会造成牵一发而动全身的后果，一个新版本往往需要数月，甚至更长时间，这无法满足业务快速迭代的需求。
容器技术是细粒度的虚拟化技术，比传统虚拟化技术的资源利用率要高很多。容器技术的轻量化能给基础架构带来的另一好处，就是具备了灵活的扩展能力，具备了真正意义上的资源弹性，实现了快速自动的扩展和回收。也正是因为其轻量化的特征，让业务具备了云内、云间的按需流动。
图1：虚拟化与容器对比
二、容器需要存储
微服务改造中，目标业务系统需要首先实现无状态改造，将有状态的数据分离到存储系统。让业务真正实现了无状态的全自动伸缩，而有状态的数据将由分布式数据库来承载。
金融级的容器平台需要提供一致性能力、弹性伸缩能力、灰度发布能力，和DevOps开发运维一体化以及微服务架构集成，以实现持续集成、监控、改进的优化循环。
容器平台除了常规所需的计算、内存、网络资源外，存储资源也是不可缺失的关键能力之一。存储作为容器平台基础资源，保证容器云数据安全和持久存储。同时，容器对存储服务种类除了标准的NFS挂载外，还需要对象存储服务，主要用于容器镜像存储。当然块存储也常见用于容器的持久化存储，如应用程序的日志读写。
而基础平台除了能够提供NFS、对象存储服务外，还需要具备和云协同服务的存储能力，随着容器的发放、运行、终止、回收进行生命周期的管理。为了保证数据的安全性和可用性，存储平台除了前面提到的和云配套的能力之外，还需要具备金融级的安全性和可靠性，从而能够完全满足监管机构对业务连续性要求。
图2：容器应用场景
在业务连续性方面，微服务架构通常的做法是通过应用层面来提供容灾能力，但当前主流的分布式数据库采用的MySQL和类MySQL数据库系统，它的本地、同城、异地容灾能力往往是我们规划的一个难题。比如，本地的一主多备模式保障本地的可用性，同城部署第三副本，以binlog复制方式保障RPO。若考虑强一致性的业务场景，这种方式下的RPO不能满足业务需求。
另外，微服务改造后的容灾架构往往也存在不合理的地方。业务拆分得非常复杂，某些业务和其他业务的关联关系耦合度还很高，这就造成了一些高容灾需求的业务系统依赖于低容灾需求的业务系统，这种不合理的现象在分布式改造项目中是一个通病。这需要一个严格的统一的业务连续性规划来规避这种潜在风险。
图3：容器存储使用场景
图4：微服务架构应用容灾
基于以上考虑，个人认为可以通过引入企业级集中式存储来解决一些问题。利用集中式存储的低时延、高可靠性解决容器应用的高性能场景，利用集中式存储的双活方案解决业务连续性的痛点。
三、实施效果
我行在云计算、微服务等技术方面进行了探索、试验及落地，经过多年的技术探索，积累了一些经验。诸如渠道类业务系统、办公类系统、信贷类系统等利用容器技术实现了落地。为未来的其他重要业务系统的容器化部署打下了坚实的基础，积累了丰富的实施经验。
如智能柜面实现微服务改造，145个服务实现容器化部署。渠道业务层提供基于Docker的容器化服务，通过在容器中运行接口服务对接ESB以及其他业务系统和模块。单中心使用资源约为1400C，3600G。经实际运行，目前单中心交易TPS约为1900左右，响应时间在50ms以下。整体运行稳定，满足业务要求。
四、总结
微服务改造、容器云是当前热点，我们紧跟时代技术发展脉搏，通过新技术的使用来解决当前的一些挑战，也希望通过新技术来驱动金融服务的创新，从而完成数据来源于业务、数据驱动业务创新的闭环，实现真正意义上的企业数字化转型，让金融机构更加智慧化、智能化。
刘艳春 某金融公司架构师：
绝大多数容器生产业务，需要数据持久化，需要有状态的容器服务，需要稳定、全方位支撑的数据存储平台才能保证业务安全稳定运行。
数据成为继土地、劳动力、资本之后一种新的生产要素，成为提高生产效率，降低成本，增强企业发展韧性的关键，数据安全可靠、稳定运行在核心基础设施之中才能产生价值， 因此数据存储也正成为加速数字化转型的坚实底座。
自2020年年初以来，一场突如其来的疫情，席卷了全球，改变着人类生活和工作模式。企业级存储的IT基础设施也随之改变，如何满足数据对存储各种场景的需求，涌现出了很多存储解决方案，如软件定义分布式存储、全闪存储、云存储、容器云存储、大数据存储、AI存储、区块链存储、边缘存储、量子存储等等。当前越来越多的企业正发挥以容器云为代表的数字技术的巨大潜力，优化运营能力，加速数字创新进程。容器平台是以Kubernetes和Docker为技术基础，为容器化应用提供从应用的创建、发布、运行、扩容、迭代、销毁的全生命周期的管理能力，集成适应云场景下的网络服务、存储服务、镜像服务等特性。绝大多数容器生产业务，需要数据持久化，需要有状态的容器服务，需有稳定、全方位支撑的数据存储平台，才能保证业务安全稳定运行。本文将简述容器云环境下如何设计存储架构。
一、容器云平台的存储需求
1. 数量大-大量存储卷
容器用户需要建立更多的存储卷来支持存储的虚拟化和池化。由于容器技术可以实现在单个主机上运行数百个容器，但这些容器加起来需要的存储卷可能超过操作系统的限制，需有灵活应对突发需求，敏捷响应业务变化、动态分配以及多容器应用的并行访问的存储卷的存储。
2. 活性-动态存储调度
由于容器会不断的创建，销毁，并且在Node之间迁移。因此需有动态灵活调度，软硬件解耦，易于扩展并且可以紧密地集成到容器编排框架中的存储。在容器层可实现卷的动态创建，裸卷映射、快照、克隆、卷扩展等。
3. 差异化-持久化卷支持适应不同场景
不同的容器有状态应用需求不同的数据存储方式，块存储(RBD，iSCSI)、文件存储(NFS)、对象存储(S3)。当节点异常时，Pod会被调度到其他节点，如果使用本地卷，新的Pod启动后无法访问原有数据，需要有支持持久化卷(Persistent Volume)，Pod被调度后，依然可以访问到之前的数据的存储。同时也需要多应用同时访问数据，多协议的支持，多容器类型的支持存储平台。
二、容器云平台的存储架构设计
1. 容器存储卷主要有如下方式
1) 服务器本地存储：固定在容器正在运行的主机上的存储。
2) 传统存储设备：由其他供应商提供的容器存储驱动程序配置的SAN、NAS或超融合系统平台。
3) 分布式文件系统：由多个服务器提供的统一命名空间的共享文件系统。
4) 容器原生存储：一种软件定义的容器化存储系统，专门为容器化应用程序提供数据管理。
5) 云块存储服务：IaaS平台的块存储服务。
6) 云文件存储服务：IaaS平台的文件存储服务。
2. 有状态数据存储要求
1) 存储卷生命周期单独管理。存储卷的生命周期和容器分开，可以创建存储卷，然后再绑定到容器，容器删除不会自动删除存储卷。
2) 提供对接文件存储，多个容器可以共享同一个存储卷用于存储数据。
3) 提供存储快照和恢复能力。能够对存储卷做快照，或者通过快照恢复存储卷数据。4) 提供对接本地存储，可将本地文件路径挂载到容器内部。
5) 支持插件扩展不同第三方存储方案。可以通过插件的方式对接不同的底层存储方案。
3. 容器云存储架构
软件定义存储能够支持适用于容器的可动态创建的持久化存储，可同时支持不同类型应用的存储访问需求。通过软件将通用服务器整合为统一存储资源池，以软件定义的方式提供块、文件、对象等不同数据存储形态。在企业存储管理上，大多数据中心存储承载敏态稳态混合架构数据服务，需有一个统一存储平台管控。统一存储平台不但可以提供基于商用硬件的分布式存储系统以及高性能高可靠性存储，而且可以通过基于控制平面的软件应用存储控制器，同一套存储系统为上层应用同时提供块、文件和对象三种数据服务，满足业务对结构化、半结构化、非结构化数据的存放需求。实现对虚拟化环境中不同异构存储的统一管理交付，将底层异构存储资源抽象化，数据中心管理员可依据前端业务团队所要求的特性以需求创建存储服务，并将其自动配置给所需的应用程序服务器。容器云平台存储按容器云架构分为五层架构，各层功能特性如下表：
表 1：容器云存储功能架构
容器云存储常用CSI (Container StorageInterface) 插件对外开放的存储接口来实现存储服务。解耦了Kubernetes系统的计算层和存储层。
统一性：无论是块存储还是文件存储，都可以通过CSI的方式去使用。
稳定性：CSI方案将存储和计算两种资源完全解耦，实现了资源的隔离，同时CSI插件以容器化部署， 因此稳定性更进一步得到保障。
兼容性：CSI插件以容器化部署，不会受操作系统版本和存储集群的限制，消除环境差异所带来的不确定性以及其他约束。
易运维：不需要复杂的集群配置修改和准备工作，只需填好CSI容器配置，拉取镜像，一键可达。
无缝升级：如果之前使用的RBD，iSCSI，NFS对接，存储也提供完善可靠的无缝升级到CSI接口。
丰富的特性：不仅仅满足客户存储的基本需求，在实际使用中，存储提供的存储插件有很多非常重要和倍受青睐的高级特性，支持动态扩容，根据实际需求动态地扩容和缩容。除此之外，还会有Snapshots快照以及QoS管理等其他的特性，进一步完善容器生态。
高晓峰 无锡农商行 科技管理部系统管理团队长：
对于中大型银行是不可能凭借一种存储技术解决大部分平台容器需求，因此各种类型存储资源池成为了设计主角，需要根据其业务特性选择合适的存储架构落地方案。
一、业务与容器云、与存储的关系
引用《以业务为核心的云原生体系建设》对架构划分，总的来说银行IT架构包含以下几个方面：业务架构、技术架构、数据架构、研发流程和组织架构。
就业务架构而言，目前大部分银行核心系统多是外采的(合作开发)，或者由于业务稳定性等诸多因素考虑，处于单体架构的阶段。部分非核心业务，采用了服务化的架构，构建了中台体系。而互联网化业务因为要应对高并发流量，以及应对市场的快速变化，已经将服务拆分得更加细，实现了微服务架构。
就技术架构而言，最初银行多会使用采购物理机的方式运行业务代码，因为资源使用效率和灵活度的问题，很多银行采用了虚拟化平台。从虚拟化平台到云平台的变化不在于技术，而在于使用模式，主要是三点，统一接口，抽象概念，租户自助，说白了就是让业务方不需要特别专业的底层技术能力，就能实现应用的部署，同时将运维人员从应对越来越多的业务方的噩梦中解放出来。容器进一步让应用从代码到运行无缝的连接起来，并且可以实现跨云的迁移。ServiceMesh将微服务的治理放到统一的平台上来做，进一步解放业务方。
就数据架构而言，在业务运行的过程中，会积累很多的数据。最初银行的系统大多只做数据记录的作用，并没有发挥太多的价值，数据是散落在各个系统的数据库之中的。如果想进行分析，查看当前业务的运行情况，需要分析师将数据导出来，做成表格和报告，给领导看，这样时效性就会很差。后来很多银行开始做数据的梳理，建设数据仓库(数据仓库或者数据湖)，并且建设BI大屏，领导驾驶舱，支撑战略决策。当然这种方式没有办法和业务直接结合，后期考虑数据运营驱动业务创新(或IT引领业务)，也就是在电商和社交APP上的千人千面，智能推荐等功能。
容器云是一种技术手段，与虚拟化或物理机相比能更好的节能增效，并且与现阶段微服务化应用更紧密结合。以Kubernetes为例，其对底层基础架构进行抽象，池化了底层资源，将资源交付的时效性降低至分钟级别。系统资源维护从原来的虚拟机(物理机)交付，变成了资源扩容(Quota分配)，减轻运维的工作量;同时，开发应用通用镜像技术打包发布，避免了环境变量不一致带来的应用部署麻烦，将应用部署从天级缩减至小时级，甚至于分钟级。
存储既是技术架构的组成部分，也是支撑数据架构的重要基石，对于容器云来说，存储提供了存储资源池的功能，业务根据各自的需求按需申请存储资源，存放数据信息。
二、业务需求与存储需求
根据《*金融行业标准—金融数据安全数据安全分级指南》对金融行业的分类规则提供的参考表，其分为了四大类：客户、业务、管理、监管。而这四大类数据又可以抽象为两大类数据即结构化数据与非结构化数据。其中结构化数据主要表现形式为数据库数据，数据记录小以及随机查询的需要，读写硬盘的块大小(Block size)一般都很小，这种小数据块的读写，对于总带宽要求不会很大，因此通常评定这类数据的性能指标为IOP;而非结构化的数据一般是比较大的文件为主，读写块大小会设置得比较大(64KB以上，甚至512KB或者1MB)，而且单个文件内部可以认为是连续读写的，因此对于这类数据的读写，更多以带宽为其性能指标。因此对银行应用数据来说，存储既需要提供满足于高IOPS的需求，也需要满足高带宽的需求。
目前主流的容器云平台都是基于Kubernetes，Kubernetes存储数据主要有三类：
镜像文件
配置信息
应用数据
而数据库一般不运行于容器云平台中，因此对容器云来说，存储需要提供高带宽、高IOPS的服务。
三、容器云存储架构设计
Kubernetes作为一个主流的开源容器平台，有很多主流的存储是默认支持的，例如本地盘，Ceph，以及主流公有云平台的块存储等。支持这些存储的代码逻辑都是在Kubernetes代码中运行的，我们称为In-Tree方式。但是Kubernetes作为私有云平台进行部署，会有一些商业化的NAS、SAN以及对象存储需要进行对接，这就要用到CSI接口。CSI全称Container Storage Interface，主要目标是将任意存储系统都可以通过标准的接口暴露给容器化的应用。
对于多数银行业的企业，都有丰富的SAN和NAS的存储管理及运维经验，结合应用的存储需求、平台镜像方案的设计，以及银行业的应用系统普遍有多中心部署的监管需求，我认为比较合适采用NFS类型的存储用于支持容器数据持久化以及镜像服务的相关存储需求来应对容器平台在小型银行企业的落地。
当然对于中大型银行是不可能凭借一种存储技术解决大部分平台容器需求的，因此各种类型存储资源池成为了设计主角，需要根据其业务特性选择合适的存储架构落地方案。
结束语
综上所述，对于容器云来说，存储提供了存储资源池的功能。金融企业不可能凭借一种存储资源解决所有的容器需求，需要根据其业务特点选择适合的存储架构落地方案。