演讲实录 | 金融行业云原生实践分享

近日，twt社区联合Intel共同主办了主题为“银行高并发交易类场景下，容器云架构如何保障高性能、高可靠性“的线上交流活动，灵雀云首席架构师杜东明受邀进行分享，和来自国内大中小金融机构的技术专家们共同探讨金融行业云原生的实践思考和解决方案，以下为分享内容回顾。
云原生是解决企业数字化转型“敏态IT”问题的唯一途径

今天，以容器为代表的云原生技术，在企业级市场已成主流。据CNCF的报告，2020年中国有68%的企业正在实践着云原生，而全球同期这个数据为92%。回望历史，会发现云原生的到来悄无声息，但是又势不可挡。是什么在推动着云原生的发展？是什么导致了现在的企业，尤其是金融客户，对于云原生有着如此之高的热情？我们在云原生实践的过程中也在不断的探索着答案。
灵雀云在云原生实践的探索过程中发现，云原生背后的推动力量是企业数字化转型的破坏性作用。
所谓数字化转型，是指一个企业实现价值的方式，和数字化的技术、渠道相融合。比如银行原本实现价值的方式是揽储、放贷、提供金融服务，过去选择银行主要看哪家银行的网点离家、离公司更近，但是现在选择银行更看重哪家银行APP做得更好，APP在数字化时代变成了银行实现价值的重要手段。
当一个企业进入到数字化转型，企业的IT部门角色将会发生变化，以前的IT和财务、法务、HR一样都是内部支持部门，但是现在 IT和它开发运维的应用变成了企业获得增长而实现价值在竞争中取胜的重要因素。在这样的一个大背景之下，出现了四种新的现象，正在挑战传统的金融企业IT。
首先，大量新增企业应用的运维。以往运维的应用主要是ERP、财务、OA系统，数字化转型时代，大量新兴数字化业务数量可能带来几何级的增加，比如，灵雀云服务的一些城商行的渠道系统上已经有多达8千+服务，而股份制银行客户更是运营着10万+服务。
第二，不断增长的企业自研应用。以前企业更多通过采购获得新的IT能力，但是现在数字化业务和企业核心业务息息相关，是企业竞争力的来源，结合业务需求不断打磨、自研才是可行途径。Gartner指出，2020年企业有75%的业务来自于自研而非采购。
第三，频繁业务迁移或升级带来的敏捷IT需求。灵雀云南区某金融公司客户，每周二、每周四要针对上千个业务进行升级，这需要非常惊人的敏捷度。
最后，业务复杂度导致业务必须要解耦。传统业务一般是单体系统，但是在数字化的今天，业务系统越来越复杂，单体系统在功能开发、软件交付、测试更新等方面都不能胜任。从单体式架构解耦变成小服务甚至微服务才是良策。
这4个现象我们统称为敏态IT的需求。敏态IT对传统IT意味着强烈的“破坏性”、“颠覆性”。基于过去标准构建的IT运维和运营体系在敏态IT的面前变得疲于应对、捉襟见肘。这就需要一些新的思维方式、新的技术体系来解决敏捷IT问题，这个解决方法就是云原生。
金融行业云原生实践的发展与应用场景

我们认为中国金融行业云原生发展的起点在2015年。在2013年 Docker发布后，2015年陆续有一些金融机构开始启动实验性、创新性的项目，希望通过这些项目研究如何通过容器提升开发和运维的效率。当时云原生的主题词是容器即服务，更多关注的是容器的管理调度和编排。
到2018年，云原生领域出现了一个大的技术方向变化，就是Kubernetes战胜了Mesos，战胜了Swarm，变成了云原生平台的实施标准。这一标准的确立，极大的推动了云原生在企业级的落地。灵雀云的很多客户也是在那个阶段和我们构建起合作关系的，像光大银行、中信银行、浦发银行、平安银行、华夏银行、农业银行、招商银行、华夏证券等等。
在那个时期，云原生的主题词是PaaS，关注的是应用的全生命周期管理，包括从需求设计、编码构建、打包测试、上线配置监控等等一体化的管理。
到了2020年，云原生这个领域又出现了新方向，我们称之为“平台化趋势”和“下沉趋势”。
第一个趋势：“平台化趋势”
在2015、2016年，很多客户把K8s放到虚拟机上，当成一个应用去运维，K8s的网络相当于应用的网络。但是到了今天，有大量的应用放到K8s上，比如某股份制银行，最初我们平台上只放了两三个应用，到今天已经有280多个应用，还有部分a+类超核心的应用都在我们的平台上运行。客户也逐渐的意识到K8s就是一个平台，有了更多的功能上的诉求，比如需要支持DevOps，需要支持微服务，需要支持数据服务等。
第二个趋势：“下沉趋势”
随着K8s平台逐渐变大，客户意识到在虚拟机上构建K8s的平台，貌似没有额外的收益，还增加了管理和运维成本。所以有些客户开始尝试把K8s放到物理机上，我们现在大量的新客户默认采用物理机支持容器平台。
横向的平台化的趋势实际上是对于功能的更多诉求，纵向的下沉趋势，实际上要把容器平台变成基础设施。这两个趋势叠加在一起，就是今天的全栈云的诉求，所以我们看到现在业内有不少全栈云相关的项目产生。
灵雀云在金融行业的实践中，总结了9个场景，主要分为以下3类：

第一类，自2016年、2017年至今，客户就比较认可的场景：

敏捷IT，主要指的是DevOps、CICD。
云原生应用，指的是微服务治理、微服务平台。
应用现代化，指的是对传统的单体式架构，分布式架构的应用进行容器化改造或者自动化运维的能力。

第二类，最近的一两年内，客户比较认可的场景：

云原生基础设施，这是把云原生平台部署在物理机上，然后向上提供全栈云的能力。
机器学习、人工智能和大数据，主要是GPU虚拟化的需求。
国产化，是最近一两年特别热的话题，我们也有幸参与到一些银行的国产化项目中。

第三类，我们认为未来比较有趋势的场景：

云原生数据服务，主要是用我们的平台来提供数据库、中间件的服务。
边缘计算，现在一些银行也开始尝试着使用边缘的方案管理网点的这些自动化设备。
超融合一体机，主要针对的是中小型的银行，用极低的成本构建云原生平台。

金融行业云原生实践的难点与原则

一、容器管理领域

面临的难点：

首先是在容器管理领域多个K8s所带来的多版本、多场地、多CPU架构的问题。现在在银行业有两地三中心的数据中心，有开发、测试、准生产、生产4个环境，X86和arm的CPU架构要同时支持，导致有很多个K8s平台要去部署和管理，如何有机的管理它们就是一个挑战。
第二是云原生平台化软件定义一切的理念和银行IT条线式管理的冲突。云原生希望通过一个yaml文件描述应用，所有的部署工艺、应用的计算、存储、网络应该能够自动化生成，但是银行专门的网络部门会定义比较严格的网络规范，它们之间实际上会存在着一定的矛盾。
第三是难以支撑金融行业的一些政策性要求，比如ipv4/ipv6的双栈、两地三中心。

建议原则：采用先进的K8s管理架构。

虽然K8s是开源并且是标准的，但是各个厂商的K8s管理架构却不一样，有单一K8s管理、多K8s管理，甚至可能会有一云多芯的K8s管理， K8s对存储、计算、网络的对接也存在着不同深度的支持。
二、DevOps领域

面临的难点：

首先是客户高度定制流水线的需求，与相对标准化的产品功能之间的矛盾。
第二是开源流水线和闭源工具链之间的矛盾，DevOps一定会有一些历史的沉淀，这些沉淀可能更多是基于开源来做的，而当今我们采用商用的产品是闭源的。
第三就是DevOps项目希望能够兼顾容器和虚拟机应用的矛盾。虽然从云原生的理念上来说，DevOps就应该基于容器去做，但是很多DevOps立项时，还是希望把容器和虚拟机来一起打包支持，这之间也存在着一定的矛盾。

建议原则：采用更加开放的DevOps体系。

第一，对于工具链的开放，我们应该以开源工具链为标准。
第二，对于流水线制定的这种开放，我们能够通过一定的手段制定出来客户所需要的一切的流水线。
第三，对于CD目标的开放，我们应该能够同时支持容器以及虚拟机。
三、微服务领域

面临的难点：

首先是Spring Cloud和Service Mesh双栈的技术路线之争，虽然现在的应用90%是Spring Cloud，但是有大量的客户也承认在未来的三五年内肯定会拥抱Service Mesh,这之间可能会存在着一定的矛盾。
第二是容器化、微服务转型周期长，困难多、历史包袱重。
第三是微服务平台运维管理界面不清晰，增加运维难度。

建议原则：采用双栈路线，All in容器。

所谓双栈路线是指我们没有必要在Service Mesh和Spring Cloud之间2选1，应该双栈去支持，并且应该制定一个Spring Cloud到Service Mesh的过渡路线。
第二就是All in容器，我们建议客户应该把所有的微服务全都放在容器里，在容器里实现自动化运维的基础之上，进行有机迭代。
四、数据管理领域

面临的难点：

第一是微服务会导致数据库、中间件多实例管理诉求。我们的微服务最佳实践是每一个服务下面都会有一个数据库，那么这样会面对着很多数据库实例，如何有机管理这些数据库是一个问题。
第二是中间件运维的难度高，用户侧实用性低。现在很多客户在尝试用容器来运维MySQL、Redis、Kafka这些中间件时，发现运维难度相对较高，客户要求的场景和部署模式各种各样。
第三就是开源中间件无法获得安全性、可用性的支持服务。虽然有不少容器平台产品都会在helm chart里给出数据库的部署图标，点击一下也能部署起来，但是这个仅限于demo和POC，真正到客户的现实环境中是不敢去使用的。

建议原则：使用产品化数据服务。

我们应该使用能够提供技术咨询、技术兜底、调优和培训等一系列服务的真正的产品。
灵雀云在金融行业的云原生实践

在金融行业云原生的实践探索中，灵雀云基于上述原则采用了创新金融全栈云架构，先构建云原生全栈云，进而把DevOps和微服务延展到虚拟机甚至物理机的场景。
一、先进云原生架构

Kubernetes支撑一切

我们的产品分成两层，第一层我们称之为管理集群。一些管理功能都放在管理集群中，比如集群管理、租户管理、用户管理、权限管理、统一日志、统一监控、高级API以及我们所访问的外部页面。
管理集群一般不承载业务，业务会放在标准的K8s业务集群中。通常我们所使用的容器、数据服务、微服务的应用都会放在业务集群中，可以接入纳管OpenShift、EKS等标准的开源的API。

管理和业务分离

当管理失效、或者管理和业务的网络出现问题时，不会影响业务持续使用，下层的 K8s还能继续工作。

业务集群拥有独立性

它们之间的配置可以完全不同。比如a集群可以采用and类的网络，那么b集群可以采用over类的网络；a集群可以部署在上海，b集群可以部署在北京；另外两个集群之间还可以进行联邦化，变成联邦集群。

支持一云多芯

两个业务集群可以采用不同的CPU架构，比如a集群采用x86架构， b集群采用arm架构，这样在信创环境中，就可以更好地兼容x86和arm，进行统一管理。
二、开放的DevOps体系

我们的体系中包含三层，第一层是工具集成，所谓工具集成是指把外部和内部的工具链整合到平台中。值得一提的是，对于大部分开源工具，灵雀云都提供技术支持，它是我们产品的一部分。
第二层是流程定义，对于集成到平台的工具，可以进一步把它们映射给某一个项目，我们称之为绑定。每一个工具可以绑定给不同的项目，进而在项目工具的基础上创建流水线。
流水线创建方式有三种图形模板和脚本，对应三种不同的用户类型。对于初级用户可以用图形化方式来创建，所见即所得；对于流水线数量极多的客户可以用模板式方法创建，迅速画出来大量流水线；对于高端客户可以使用脚本的方式来创建。
第三层进行数据展示，统一收集整个流水线过程中所涉及的所有工具生成的数据，并生成报告，让管理人员能够进行更好地量化管理，提升DevOps的效率。
三、双栈微服务架构

在微服务领域，灵雀云提供双栈微服务治理平台，部分客户还是基于Spring Cloud构建应用的，但是大部分金融客户也都坦言未来一定是Service Mesh的天下。现在的难点在于如何实现Spring Cloud向Service Mesh的迈进。我们建议应该采用双栈的思想构建微服务架构，让微服务同时支持Spring Cloud向Service Mesh。这样一来，新兴应用可以考虑在Service Mesh上去治理，传统的Spring Cloud应用可以在一定的历史阶段内，逐渐地迁移到 Service Mesh，这种迁移的过程有可能长达3~5年。
所以在基础设施层面，我们会给客户提供双栈服务之间的相互调用的能力，Service Mesh可以调用传统的Spring Cloud服务，Spring Cloud也可以调用Service Mesh服务，两者之间的调用关系依然会存在，这种调用是不可避免的。
目前我们的产品两者都可以支持，并且也可以支持相互的调用，给客户一个足够长的周期，逐渐实现Spring Cloud 向Service Mesh的演变。
四、产品化的数据服务

在数据库和中间件领域，灵雀云提供产品化的数据服务能力，灵雀云的数据服务产品是基于 Kubernetes构建的，我们使用了Kubernetes的Operator技术，提供了6种中间件的部署运维和管理，包括MySQL、Redis、Kafka、PostgreSQL、rabbitmq、mongodb，用户可以使用operator对这6个中间件进行深度管理。
对于普通用户，我们可以叠加运维和运营管理模块，提供中间件自助服务的门户，用户可以很方便地在自助服务门户上创建实例，对实例进行生命周期管理，进行配置管理、备份和恢复等等。
那么这样一来就产生了两种管理形式，一种是高端用户可以通过operator直接进行高级的管理操作；一般用户则可以用自助门户的方式，像公有云一样去操作中间件。
灵雀云携手Intel创新方案助力金融客户

云原生平台相比传统虚拟化平台，应用离硬件更近，硬件的创新也更能够发挥作用。不像虚拟化隔离了应用和硬件，容器可以直接运行在服务器上，直接借助硬件的创新特性，而硬件的创新特性对应用有非常大的优化和加速作用。
因此，灵雀云一直以来得到了英特尔的大力支持，通过一些基于英特尔软硬件优化能力的联合测试，提升灵雀云云原生方案的性能，将英特尔的硬件价值发挥到最大，共同助力金融行业数字化转型。
基于灵雀云企业级云原生平台的英特尔精选开源云解决方案

该解决方案搭载了灵雀云企业级云原生平台ACP，还提供了针对特定容器云应用负载进行测试验证和性能优化的硬件配置建议。在这套方案中明确了管理集群和生产集群，分别使用了第二代英特尔至强可扩展处理器、英特尔傲腾持久内存、英特尔傲腾固态盘、英特尔数据中心级固态盘、英特尔以太网融合网络适配器等，我们双向认证了这套解决方案，并且进行了严格的实验室测试，确保方案的稳定性、可靠性和性能。用户能够以此为基础，快速搭建轻量化、松耦合、灵活敏捷的云原生平台，助力数字化转型战略的实施。
基于傲腾持久内存的云原生平台存储

在灵雀云ACP产品中，也集成了一套稳定的Ceph产品，可以实现存算一体和存算分离两种架构。值得一提的是，灵雀云基于英特尔傲腾非易失性内存设备和Rook以及Open CAS缓存加速方案，采用模拟真实生产环境对Ceph的块存储服务和对象存储服务性能进行评估，发现不同的工作负载模式下，最高吞吐量提升可以达到原来的2.96倍，延迟也可以缩减到原来的34.2%。数据表明，这一组合能够实现对于分布式存储系统Rook-Ceph及上层业务的加速。
基于Kube-OVN的合作

在2019年我们自主开发并且开源了Kube-OVN解决方案，这也是业界目前最热的容器网络解决方案之一。
我们和Intel在Kube-OVN上也有多种合作，在多网卡实现上，我们使用了Intel的Multus CNI Plugin技术，可以实现一个容器有多张网卡，不同的网卡可以采用不同的网络，甚至可以一个网卡基于overlay网络，另一个网卡基于underlay网络，还有一个网卡基于多播的网络。
第二我们可以使用Kube-OVN来统一纳管K8s和 OpenStack的网络。这样的优势在于，虚拟机和容器可以共处于同一个网络，二者可以互相直接调用。
基于性能优化的服务
Intel常年耕耘于数据中心，对于性能优化有着非常深入的研究，也积累了很好的工具。未来，灵雀云也将继续深化和英特尔的合作，共同为客户提供更好的性能诊断、性能调优服务。