在刚刚结束的KubeCon2019上，灵雀云售前工程师邢佳发表了《容器化探索之路》的主题演讲某大型股份制银行》，结合某大型股份制商业银行实施容器PaaS的客户案例，分享了目前容器云在金融行业的实施实践。以下为演讲实录。银行数字化转型的两大驱动力银行数字化转型的主要驱动力有两个。一个是自身商业模式驱动，一个是技术改造驱动。商业模式的驱动因素是什么？现在人们很少去银行柜台，生活和工作中的很多需求都可以通过微信、支付宝等在线应用来满足，或者通过一些快捷的方式完成临时授信。这些金融服务已经深入到我们的生活中。各个方面。技术变革的动力来自柜台金融业务随着客户群的变化而发生业务业态的变化，这些金融服务的使用场景和行为也在发生变化。此外，各大银行也愿意将自身的部分金融服务包装成科技产品或科技服务手段，深入到生活场景中，这为创新业务带来了激烈的竞争。银行业务模式转型对IT系统提出更高要求，技术改造势在必行。例如，小额信贷曾经是银行不看好的业务，因为产生的收入不足以覆盖内部审批管理流程的成本。现在，基于敏捷交付、持续集成和DevOps的能力，银行可以快速完成应用的上线和更新。并且迭代地，银行将能够开展小额信贷等业务。对银行来说，开发模式已经从瀑布式开发转变为敏捷开发，一些快速发展的银行已经转向DevOps和云原生；在应用架构方面，银行已经从之前单一的架构转变为大中大平台战略。在大中型平台建设中，后端稳定服务模块化、组件化、能力化。前端保持一定的灵活性和敏捷性，后端原子化业务接口灵活组装，快速适应不同场景和业务需求变化。.这还需要对银行基础设施进行转型，使其更加敏捷和有弹性。银行曾经是小型机和物理计算机。前期完成了虚拟化和IaaS改造，帮助银行摆脱了一些历史包袱，解决了应用运行环境与硬件的紧耦合关系。容器化应用进一步解放了应用与运行环境之间的耦合关系。某大型股份制商业银行容器PaaS云平台概述以下是灵雀云在某大型股份制商业银行实施的容器PaaS云平台总体框架。底层将物理环境、虚拟化环境、托管专有云环境打包成一个资源池，运行编排集群，即Kubernetes。银行的运行环境分为开发、测试、准生产、生产四个环境。需要遵守一定的安全管理规范，根据不同的安全级别划分不同的业务区域，每个业务区域有一个独立的Kubernetes集群。对于银行而言，如何集中管理各个安全区域的Kubernetes集群成为了亟待解决的问题。我们在大型商业银行提供的平台可以跨地域管理多个Kubernetes集群。基于这个平台，我们构建了三个能力：第一，容器化生产能力，包括应用发布、日志收集、应用监控。DevOps除了拓展DevOps和微服务场景之外，主要解决如何将容器技术与开发过程对接起来。在本次大型商业银行项目中，容器化技术的应用主要分为两步：第一步验证容器化技术能否承载生产环境中的银行金融业务；第二步是将开发过程与DevOps工具链连接起来。应用基于容器底层技术进行开发、测试、上线，达到容器化、云原生开发的效果。其次是设计微服务应用和业务架构的能力。容器化应用程序采用微服务框架。这些微服务专为弹性或模块化应用程序而设计。平台需要提供对微服务的集中管理功能。基于上述云原生“金三角”，灵雀云还提供了企业级的IT治理能力。从一个平台上的不同Kubernetes集群统一管理这些权限和角色。对于银行来说，一个应用可能就是一个项目，这个应用可能跨越开发、测试、准生产、生产等不同的环境。那么平台需要具备在开发、测试、准产、生产中对应用进行统一规划的能力。将生产环境所需的资源划分为整个容器云平台的多个租户。灵雀云平台在这个大型商业银行客户的不同环境部署了多套，可以同时管理多个Kubernetes集群。例如，开发侧平台管理开发、测试、准生产集群，生产侧平台管理不同安全管理区域的多个集群。但金融行业要求开发、测试、预生产、生产包括容灾环境严格分离、分开建设。一些交易业务需要两个地点和三个中心的多活动能力。承载这些业务的管理平台，管理平台本身必须具备相应的能力，才能让银行客户的业务在容器平台上进行生产。.Kube-OVN：适合金融行业特点的网络解决方案。银行客户本身就有很强的技术能力。对容器厂商的要求不是技术说教，而是解决具体问题。然而，银行真正关心的可能不是技术问题，而是如何应用这些技术来满足银行的安全管理规定。只有回答完这里所有的问题，才能真正了解银行客户对容器技术落地的真正担忧。比如容器网络可以分为Underlay、Overlay、Routing、Routing+Overlay等模型，而这些网络容器模型都得到了Kubernetes的支持。银行关心的是集群能不能跨VLAN，集群节点之间、容器之间的传输性能，哪种模式有什么指标。这里我重点介绍网络解决方案Kube-OVN。我们调研了很多开源社区和国内一些大公司推出的网络解决方案，但是没有找到特别适合金融行业特点的网络解决方案，所以灵雀云选择了自研。基于IaaS中相对成熟的OVN虚拟网络底层，推出了Kube-OVN开源项目。Kube-OVN提供了大量Kubernetes目前没有的网络功能，并在原有基础上进行了增强。通过将OpenStack领域成熟的网络功能转化为Kubernetes，可以应对更复杂的基础环境和应用合规需求。对于金融行业来说，除了限制业务带宽外，更高阶的要求是某些业务有更高的优先级。如果网络不通，需要先释放这些服务的流量。这种控制也是金融行业的特性要求。还有内置负载均衡或分布式网关，以及基于NameSpace的网关，更适合金融行业。“双模”流水线，打造DevOps敏捷流程之前的DevOps思路是专注于工具链的建设，从代码存储、代码构建、镜像构建、推送到产品仓库和Kubernetes进行生产。我们关心的是工程水平。关联。但实际上，在为银行客户服务DevOps平台的设计和实施时，会发现客户对DevOps的理解超越了工程层面，偏向于项目管理层面。什么样的开发项目，最终实施什么样的开发计划，由哪个开发团队来承担；项目经理必须能够从DevOps平台上看到每个需求的迭代状态、交付状态和交付效率。于是就有了双模流水线的图。从需求导入开始，会有一个项目管理平台，主要是梳理和调度需求，制定开发任务，定义流水线；接下来会有一个设计平台系统，具体把需求分配给哪个开发团队，并相应地在这个设计平台上制定它的开发计划，整个开发或者交付过程需要涉及多少环境，有哪些开发工具用于开发；之后代码会在代码仓库中开辟一个属于本项目的代码存储空间，主要存放代码，初始化SQL脚本等；在配置中心，需要存放应用在不同环境下的配置信息和元素，这样你就可以知道应用运行在什么环境下应该加载哪些不同的配置，去Generatetheseconfigurations；持续集成主要是输出配置文件和代码构建；之后通过镜像同步将产品同步到生产环境，这也是调用自动化平台部署执行容器平台的任务。容器PaaS平台价值及规划灵雀云容器化平台投产后，最直接的作用之一就是帮助银行提高容量规划水平，统一资源分配管理，提高新系统部署速度，缩短时间新业务上线。背后的图景是中间件标准化、平台化和知识管理。其实我们接触的银行客户中间件的种类并不多，但是由于多年的积累，不同的开发团队，不同的技术能力，不同的系统和技术栈选择，带来的问题更多的表现在相同的有很多中间件版本多，实际上给应用运维和软件开发工程的规范管理带来了很多不必要的麻烦，很多中间件和技术能力在不同的项目中无法继承和复用。我们服务的大型股份制银行，在做完容器后，其架构室和平台部统一制定了中间件的规范和标准，做成了容器应用市场的模板。一些应用在开发过程中，直接使用架构部门和平台部门提供的标准化模板，一键生成中间件。开发人员可以专注于业务层面的开发，而中间件和配套环境标准的制定则留给技术管理。部门统一管理，作为标准、标准化的配置能力输出，大大简化了业界中间件版本管理的难度。对于应用运维而言，其所面临的环境将更加标准化、统一化，大大降低知识技能的构建和传递成本。最后，灵雀云的愿景是成为数字化转型的领导者。我们希望通过最先进的技术、最专业的服务、最可靠的合作，成为传统企业数字化转型中最值得信赖的云原生技术合作伙伴。
