在金融行业数字化转型的驱动下，国有银行、股份制银行和各级商业银行也纷纷步入容器化的进程。
如果以容器云上生产为目标，那么整个容器云平台的设计、建设和优化对于银行来说是一个巨大的挑战。如何更好地利用云原生技术，帮助银行实现敏捷、轻量、快速、高效地进行开发、测试、交付和运维一体化，从而重构业务，推动金融科技的发展，是个长期课题。
因此，twt社区主办了主题为“银行高并发交易类场景下，容器云架构如何保障高性能、高可靠性“的线上交流活动，吸引了众多来自银行一线的技术大咖参与交流。我们将干货整理出来，以“金融云原生漫谈”系列文章的形式陆续呈现。
企业数字化转型的道路上，一些大型全国性股份制银行已经走在全行业的最前沿。在构建云原生技术平台的过程中，不仅投入大量的人力和技术资源，还会与专业的第三方技术厂商合作，用先进的技术、解决方案和方法论，以及完善的咨询服务武装自己，保障云原生技术的落地。当然，这样大刀阔斧的改革，也意味着不断试错，和预算、人力、资源的巨大消耗。
对于资源相对有限，技术能力相对薄弱，但数字化需求和要求同样高标准的中小银行来说，数字化转型路上面临的挑战会更加复杂。
云原生的架构改造，是否存在“万能模板”？
云原生架构下应用转型有无相关规范可以参考？
中小银行也需要百人规模的技术团队吗？
飞快的技术更迭下，中小银行如何做稳健的技术选型？
……
本期“云原生漫谈”，我们就将和大家聊一聊，中小银行如何找到适合自己的云原生构建思路，快速抓住科技变革机遇，快速、平稳、高效数字化转型破局。
中小银行在采用云原生架构时，“万能模板”是什么
在云原生技术实践联盟（CNBPA）2021年初的调研中显示，国内 72.7%的企业已经采用Kubernetes作为容器编排技术，占据了绝对的优势地位。这也与CNCF最新发布的中国区云原生调查报告中，72%的受访者已经在生产环境当中使用Kubernetes的数据保持相当高的一致性，同期全球调查报告的数字是78%。
中小城商行在云计算建设和技术引入时，建议考虑基于以Kubernetes为核心的云原生平台来做，Kubernetes作为云的操作系统，可以屏蔽下面各种各样不同的云环境、云基础设施，它自身是一个可移植层，这样在做混合云和多云管理时，对应用迁移以及其他工作负载非常有好处，可以做到跨环境的兼容。由于Kubernetes的可扩展性，本身平台之平台的属性，导致它天生适合用来作为整个混合云的控制面板，用它去编排不同类型的云环境以及云基础设施和各类云服务。
在建设路线上应该以应用为中心，覆盖应用全生命周期为目标进行云计算的建设方向。充分考虑平台融合基础设施、微服务框架、数据服务、DevOps工具等模块作为平台组件，以建设具备全栈能力的云平台为发展方向。
云原生架构下应用转型有无相关规范可以参考？
在应用架构转型的语境里和组织自我进化的角度，建议可以参考以下15个要素，这些要素几乎涵盖了云原生架构下应用转型的各个方面。
要素1：基准代码（Codebase）——一份基准代码，多份部署。
要素2：依赖（Dependencies）——显式地声明依赖关系。
要素3：配置（Config）——在环境中存储配置。
要素4：后端服务（Backing Services）——把后端服务当作附加资源。
要素5：构建、发布、运行（Build、Release、Run）——严格分离构建、发布、运行。
要素6：进程（Processes）——以一个或多个无状态进程运行应用。
要素7：端口绑定（Port Binding）——通过端口绑定提供服务。
要素8：并发（Concurrency）——通过进程模型进行扩展。
要素9：易处理（Disposability）——快速启动和优雅终止可最大化健壮性。
要素10：开发环境与线上环境等价（Dev and Prod Parity）——尽可能保持开发、预发布、线上环境相同。
要素11：日志（Logs）——将日志当作事件流。
要素12：管理进程（Admin Processes）——将后台管理任务作为一次性进程运行。
要素13：优先考虑API设计（API First）。
要素14：通过遥测感知系统状态（Telemetry）。
要素15：认证和授权（Authentication and Authorization）
另外，今年年初，信通院牵头进行了云原生成熟度标准体系的讨论和标准制定，在这个体系里面包括一个云原生业务应用成熟度的评估标准，根据基础设施域、应用研发域、服务治理域以及组织管理域成熟度综合计算，共分为五级，五个级别有明确的定义，比如在初始级，技术架构局部范围开始尝试云原生化改造，并取得初步效果，而卓越级，技术架构已完成全面云原生化改造，且这个技术模块功能已相当完善，能够很好地支撑上层应用。目前这个标准的细则还在酝酿中。
中小银行也需要百人规模的技术团队吗？
首先，我们从什么是云原生架构的角度来理解技术团队职责划分，再去决定技术团队规模会容易一些。简单来说就是把原来开发部门需要开发业务功能的工作下沉到基础设施，把运维部门对于基础设施（例如云计算）的一些原生能力赋能上层业务应用，所以在云原生架构之下，原来开发部门和运维部门的工作职责就出现了冲突，那么中小银行如何在人力、资金、资源相对紧缺的情况下，有效规避这些冲突，目前在金融行业普遍的做法有以下三种：
第一种做法：可以考虑专门成立一个容器管理部门，这个部门介于开发部门和运维部门之间，这个部门不用关心基础设施硬件的建设，它不仅是容器平台建设的计算、存储、网络资源的使用者，同时它也是支撑业务应用开发的开发环境、开发工具、容器应用日志监控等能力支持的提供者。
第二种做法：从现有开发部门或者运维部门拆分成一个虚拟团队，这个虚拟团队可以专门负责容器平台的日常运维管理事宜，一般建议从运维部门拆分出一个这样的虚拟团队，这样可以提升容器平台日常运维管理的沟通和协调效率。
第三种做法：通过引入针对各个部门不同使用场景的多视图和权限的云原生平台来细化工作职责的划分也是一个不错的选择，国内灵雀云等厂商都有类似成熟的云原生平台使用案例。
飞快的技术更迭下，中小银行如何稳健选型
相较于大型股份制银行，中小银行可能面临着IT人员相对匮乏、技术能力相对薄弱、IT系统至今沿用传统架构等问题，那么在实施云原生架构改造过程中应如何进行选型，如何分批次将现有架构纳入改造，传统核心类应用是否适合进行容器化改造，也是现阶段中小银行重点关注的问题。
针对这些问题，灵雀云首席架构师杜东明表示，中小城商行在容器化选型时，应该尽量选择具备丰富落地及咨询经验的企业和成熟的产品，实施步骤上建议初期以容器基础设施建设结合DevOps工具链建设，让中小城商行能快速享受云原生带来的收益。同时选择在容器及基础设施、微服务、DevOps三大领域都具备支持能力的产品和公司，能够有效减少后期由于兼容性问题带来的运维成本，这一点对于技术人员相对较少的中小城商行尤为重要。
在实施容器云架构改造过程中，可以优先选择结构简单的轻量型单体应用，例如一些典型的Java应用和自开发单体应用。另外适合优先改造的还有微服务架构的应用，例如Spring Cloud 等微服务架构应用，这样能够快速平滑地把现有应用资源向容器化环境迁移，让中小银行能够快速体验云原生带来的好处。
相对于大银行，中小银行在数字化转型时，应该更理性地规划转型步骤和资源配置策略，选择更适合自己的云原生构建方案。从业务增长的角度来说，云原生PaaS平台虽然是未来企业业务的核心竞争力的底层支撑，但非核心竞争力本身所在。企业应该将更多的精力投入到与业务相关的研发上，采购相对标准化的第三方底层平台，可有效减少转型过程中的盲目之举和资源浪费。
如今，面对激烈的市场竞争和飞快的技术迭代，中小银行也开始全面拥抱云计算。基础设施、应用架构等层面的云原生化改造，能够让更多业务应用从诞生之初就生长在云端，从技术理念、核心架构等多个方面，帮助中小银行IT快速、平稳落地上云之路，以创新科技赋能银行数字化转型。