在刚刚结束的 KubeCon2019 上，灵雀云售前工程师邢佳发表了“某大型股份制银行的容器化探索之路”的主题演讲，结合某大型股份制商业银行落地容器 PaaS 的客户案例，分享了目前容器云在金融行业的落地实践。以下为演讲实录。
银行数字化转型两大驱动因素
银行数字化转型主要有两方面驱动因素，一是本身业务模型的驱动，二是技术转型的驱动。什么是业务模型的驱动呢？大家现在都很少去银行柜台网点，很多生活和工作中的需求都可以通过线上应用去满足，比如微信、支付宝，或者通过一些快捷的方式完成临时授信，这些金融服务已经深入到我们生活中的方方面面。
技术转型的动力来自基于柜台的金融业务在随着客群的变化而发生业态的改变，这些金融服务的使用场景和行为在发生变化。此外，各大银行也有意愿将自身的一些金融服务打包成科技产品或者技术服务的手段，深入到生活的场景之中，这带来了创新业务的激烈竞争。
银行业务模式转变带来了对 IT 系统更高的要求，技术转型势在必行。比如，小额信贷以前是银行很不看好的业务，因为产生的收入都不够 cover 内部审批管理流程耗费的成本，现在基于敏捷交付、持续集成以及 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 应该从需求导入开始，要能够管理到这个需求最终落地到什么样的开发项目，什么样的开发计划，由哪个开发团队去承担；项目经理要从 DevOps 平台上能看到每一个需求的迭代情况、交付情况以及交付效率。
所以，就有了双模流水线这张图。从需求导入开始，会有项目管理平台，主要做需求的梳理以及排期，制定开发任务，做流水线定义；接下来，会有一个设计平台系统，具体去分配需求应该交给哪个开发团队，相应要到这个设计平台上制定它的开发计划，整个开发或者交付过程中需要涉及多少环境，开发中使用什么开发工具；之后代码才会被在代码仓库里开出一个属于这个项目的代码存放的空间，主要存放代码、初始化的 SQL 脚本等等；在配置中心，需要把应用在不同环境的配置信息、元素进行存储，从而可以知道应用运行在什么样的环境时应该加载什么样不同的配置，去生成这些配置；持续集成主要是产出配置文件、代码构建；之后采用镜像同步，把制品同步到生产环境，同样也是调用自动化平台对容器平台进行部署的任务发送和执行。
容器 PaaS 平台价值与规划
灵雀云容器化平台投产之后，一个最直接的效果就是帮助银行提升容量规划的水平，统一资源配给管理，提高新系统部署速度，缩短了新业务上线时间。
后边这张图是中间件标准化、平台化以及知识管理。其实我们接触的银行客户在中间件方面，种类并不是很多，但是由于长年的积累，不同的开发团队，不同的技术能力、系统和技术栈选型，带来的问题更多表现在同一个中间件版本非常多，这其实给应用运维和软件开发工程化的标准管理带来了许多不必要的麻烦，很多中间件和技术能力也无法在不同的项目中被继承和复用。
我们服务的该大型股份制银行，在做完容器后，其架构办和平台处统一制定了中间件的规范和标准，并把它做成容器应用市场的模板。一些应用在开发过程中，直接使用架构处和平台处提供的标准化模板来一键生成中间件，开发人员可以专注在业务层面进行开发，而中间件、支撑类环境标准的制定就交给技术管理部门统一管理，作为一种标准的、规范的配置能力输出，极大地简化了行里对中间件版本管理的难度。对于应用运维来说，它面向的环境会更加标准和统一，大幅度的减少了知识和技能的建设和传递成本。
最后，灵雀云的愿景是成为数字化转型引领者，我们希望通过最先进的技术、最专业的服务、最可靠的合作，成为传统企业数字化转型中最可信赖的云原生技术合作伙伴。