当前，数字化转型已成各行各业稳发展的“必答题”，对于站在数字化转型潮头浪尖的金融行业来说更是如此。而在技术选择上，因为应用形态与基础设施交替发展，将 IT 基础设施再一次带到十字路口。基础设施经历了虚拟化、云平台，直至容器技术在过去五年普及。另一方面，应用的架构从单体架构，到复杂度提升之后早期主流的三层架构，应用软件变得越来越复杂。

一、容器云成为银行业云原生建设基础

近期《金融电子化》杂志社发布了《银行业私有云建设发展报告》，共有 129 家银行业金融机构参与调研。报告通过汇集行业上百家金融机构科技决策者在云计算建设应用过程中的经验，总结提炼了金融云技术的应用现状、发展趋势以及建设使用中的关注点，对于同行业以及所有的云计算行业从业者来说都非常值得借鉴和参考。

报告中也提到了容器云的应用现状与趋势，有近 1/3 的银行进行了容器云建设。

但是在建设的银行中，已经有 2/3 完成了建设，并且半数银行已经覆盖渠道类和业务类等系统。容器云有利于统一软件交付和运维的模式，从而更好地支撑以互联网业务为代表的敏态业务创新需求。

因此，银行容器云建设比私有云更为积极，32% 的银行选择了本着“能上尽上”的原则。

从应用形态上，新业务尽可能的开始部署在具备容器能力的平台上，同时这些业务也具备了敏捷，快速迭代的特点。

从组织架构上，银行业的 90% 客户都将“容器云”的规划放到规划重点上来，由于云计算平台的规划既要解决业务开发的问题，同时也要解决运维的问题，所以牵头部门无论是开发部还是运维部，都需要一体化的考虑容器能力的建设与方向。

在架构形态上，除了容器化所带来的更加平滑的升级能力、自动化的应用发布以及更为标准化的中间件管理能力之外，“为满足信创要求而必须考虑的“‘一云多芯’能力，支持信创平台建设与应用迁移”能力关注度为 74.5%。关注度最低的“虚拟化能力，容器云平台同时提供虚拟机”项目是 48.9%，部分银行选择了稳态业务使用虚拟化或传统 IT，敏态业务使用容器云，一定程度上规避了这个问题。但根据分析，两个平台始终无法解决企业的云计算路径上的可持续发展问题，该问题的折中解决也能看到这是一个不得已而为之的情况。

而一体化以及云平台与容器云平台的整合能力的关注程度则为整个建设中关注的占比最高的两项，这也侧面说明了容器或者说云原生作为云计算技术中的重要的一站，其面向未来的建设要求与兼顾现有的生产业务要求并存，并能够不断持续提供更为丰富与完整的能力。

二、重新审视容器云的定位与建设目标

容器云经历了技术创新的发展过程，并且现在已经发展到了关键时期，先把技术架构拿出来，在两个架构上分析一下业务发展所能够使用到的能力与考量因素，以及其两者建设目标，并且需要结合整体基础设施的一个情况来看应该如何进行选择。

2.1 稳定的虚拟化基础设施的局限

过去 10 年至 15 年，大部分企业或组织都已经完成了虚拟化平台的建设或者使用云服务商提供的虚拟化算力作为业务的运行载体，并且也留存了一定量的单独的服务器承载业务，而虚拟化平台也在不断随业务与数据的数量线性增长，包括搭配的网络硬件、虚拟化平台资源管理软件、监控软件，商业存储形成了一个稳定的解决方案，这样的架构持续在企业中发挥着支撑核心业务的作用。

在这个过程中，云计算的出现为企业带来了第一次选择，而方案的特点就是虚拟化软件+商业存储（包含集中式与分布式）+硬件交换机（SDN 或非 SDN）+云管理软件成为一个惯性的拼搭式建设方案，而市场也有独立的私有云或者公有云厂商提供一体化的软件，通常以 OpenStack 为技术核心框架，不管这两个方式用哪种，主要提供的能力则都是提供裸金属与虚拟机算力为主，配合多样的存储与硬件或者软件SDN实现基础的基础设施能力，也就是狭义理解上的IaaS基础设施。

于此同时，其实应用的架构也没有停止发展，很多企业在虚拟化作为算力的环境中已经运行了多种的容器或者容器编排软件，而容器编排软件，如果过去是虚拟化+云管平台的路径，则一般会寻找市面上独立容器平台厂商，通常这些厂商会把自己的平台称为“容器云”或者“PaaS 平台”，而一体化的云厂商则提供了集成度更高的容器服务，在虚拟机上帮助用户来构建 Kubernetes 平台，随着这个状态持续向前，容器化/云原生化的应用占比越来越高，应用对于计算、存储、网络的功能与性能需求以及管理运维复杂度的持续提升，新形态的应用需要物理机为基础的云原生化基础设施（传统意义上理解为物理机容器云）。这时，虚拟化基础设施的局限出现了，企业很难抉择裸金属/物理机运行容器的方案，要么选择开源与自研路线，要么咨询厂商沟通是否有解决方案。

2.2 堆叠式构建的好处与弊端

诚然，IT 基础设施都有一个建设过程，而主流的堆叠式建设方案也是顺理成章的，其技术架构分层清晰，可以简单的分成两层，基础设施层提供虚拟机，容器编排软件提供容器管理能力，其他如微服务、DevOps、容器安全在不同层级或独立部署均可，而大部分企业或组织也将应用/开发部门与基础设施部门在虚拟机这个层面分开。

这个方案的弊端也存在，首先会浪费虚拟机的资源，但同时需要维护虚拟机的运行状态，应用对于真正承载容器应用的 GuestOS 也有要求，在算力问题解决后，问题来到了存储与网络方案上，由于所有的应用运行在虚拟机中，那么自然需要 overlay 的网络与透传进虚拟机 namespace 的存储能力，这无形中增加了整个业务的 IO 与网络传输路径，在私有云中，这是当前的现状，而在公有云中，云服务厂商提供了更多样的服务选择给客户，并不是多个独立的平台，而是独立并彼此相关的服务。随着业务发展，持续与客户的沟通可以看到，需要更优更长久的解决方案。

2.3 一个平台还是两个平台

以上探讨的都是在基础设施中容器与虚拟化的架构关联，当问题变成云计算平台建设时，就会面对到底是用一个虚拟化平台叠加容器云，还是一个虚拟化平台旁边再建设一个运行容器的平台，或者是否有容器平台能够兼顾虚拟化、裸金属的能力，虽然在技术上云原生有类似 kubevirt、metal3 的虚拟机或裸金属解决方案，但较比发展这么多年的虚拟机管理软件而言，并不能很好的解决企业应用的运行与管理问题。

从基础设施负责人的角度，也不希望企业有多个基础架构平台，两个或者更多都带来了更多的运维、管理、升级、安全等维度的问题，那么如何用一个平台既解决容器化/微服务化应用的运行，提供更好的性能与稳定性支持，同时又能够兼顾虚拟机与裸金属的稳定成熟的功能称为核心是需要考虑的问题。

2.4 容器云在云计算中的位置

综上所述，“容器云”本身定位过窄了，容器运行需要依赖的编排工具，存储、网络、管理、权限、监控、运维以及底层的操作系统需要一体化考虑，更希望称之为具备容器运行时支撑能力的云计算平台，以能够更好的支持云原生架构应用的运行为目标。

三、持续不断的技术创新与云计算的可进化

在分析完技术发展，建设方案选择，业内行业客户调研结果之后，能够隐约感觉到了云原生架构应用的持续发展拉动了基础设施的变革，IT基础设施又又又又一次站在了一个十字路口，而云计算技术或者企业的云计算平台建设也同样需要考虑以上这些问题，容器也好、狭义云原生中相关的技术也好，都是云计算的一小部分，而云计算本身的形态就不是传统软件，其需要持续面对不断的技术创新，并且保持可向前演进的能力。企业的能力、组织与文化的不断升级，才能持续依赖于数字化的可进化的云计算基础设施有条不紊的完成业务创新。