在金融行业数字化转型的驱动下，国有银行、股份制银行和各级商业银行也纷纷步入容器化的过程。
如果以容器云上生产为指标，那么整个容器云平台的设计、建设和优化对于银行来说是一个微小的挑战。如何更好地利用云原生技术，帮忙银行实现麻利、轻量、疾速、高效地进行开发、测试、交付和运维一体化，从而重构业务，推动金融科技的倒退，是个长期课题。
因而，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 疾速、安稳落地上云之路，以翻新科技赋能银行数字化转型。