作者jianglj·2021-11-15 15:18

其它·SNB

银行基于云原生架构下的 DevOps 建设实践经验

字数 7303阅读 10872评论 10赞 17

#  一、 前言及需求分析

在银行业金融科技的创新过程中 ， 计算基础架构的根基以及应用开发与运营的方式都已发生了翻天覆地的变化。基础架构、平台软件、分布式应用 、容器和云原生技术架构 ，以及适应快速、迭代式应用开发的文化和流程等——这些快速发展的技术和方式正在迅速整合，形成一种新型的IT管理方法，并为企业发展所依赖的关键传统型IT架构提供有益补充。

全球云计算技术发展历经20年，历经虚拟化时代、传统云计算时代演变为至今的云原生技术时代。 “云”中的资源 可随时获取，按需使用，按使用付费，可无限扩展，这种特性被称为像水电一样使用 IT 基础设施。云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务的技术组件部分进行最大化的剥离，从而让云原生设施接管应用中原有的大量非功能特性（如弹性、安全、可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时具备轻量、敏捷、高度自动化的特点。云原生架构的典型技术代表是容器技术与Kubernetes编排调度技术，在企业的数字化转型过程中 ，两者也成为云原生时代下的新型PaaS平台计算基础架构的根基 。

DevOps（Development和Operations的组合词）起源于 2007 年，是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运维工作必须紧密合作。DevOps优势明显：能够对各种修改需求做出快速的反应、能够实现灵活的安全部署与编排、能够建立完善的协作与沟通渠道、能够快速地识别出代码中的错误或漏洞、开发团队聚焦关键问题，不必过度专注于各项安全功能。

既然云计算和DevOps技术都历经发展了多年，每家金融机构目前所处于的云计算和DevOps建设阶段可能各不相同，如何能全面复盘整个技术的演进历程，不走无谓的弯路和老路，紧跟云原生技术的发展趋势去做云原生化DevOps尤为重要。但在如今开源技术社区的云技术和DevOps系统种类非常之多，如何高效、低成本、安全合规且符合技术潮流等多重维度来选型相应的工具系统对于企业进行数字化转型尤为重要。还有金融互联网业务如雨后春笋发展迅猛，对于业务产品上线速率和用户体验尤为重要，对于灰度发布技术栈的选型和实践也急需提上日程。最后金融级云原生容器云建设如何满足生产级别要求，对于容器化和非容器化系统共存且都应用微服务平台的架构下，如何做网络插件选型改造，针对以上需求痛点进行以下内容分享。

#  二、 “传统”DevOps 如何技术演进为“云原生”DevOps

DevOps关键技术发展历程经历了四代，第一代是基于物理机/独立虚机技术的时代缺点较多，如 资源环境交付 ：资源环境的搭建与应用部署过程割裂开来，创建系统资源环境效率低、耗时、风险高，系统变更需静态配置结合人工协调； 应用软件交付 的周期长、迭代慢，且手工配置、自动化率低，不能可视化交付，不能以环境+系统为单位交付。第二代是基于IaaS技术的时代优势明显，可一键自动化：创建环境到部署安装应用组件整个过程的一键创建和部署，资源和应用同时交付，扩缩容后服务自动注册；集群感知能力强：IaaS资源可编程接口实现集群感知，自动协调控制、动态配置，可提高开发测试和交付的效率。第一代和第二代可定义为“传统”DevOps时代。第三代是基于容器技术的时代，容器技术的轻量级和迁移便捷性体现的淋漓尽致。应用跨云迁移性：迁移后环境一致性，迁移部署速度快，一次打包、到处运行；轻量级交付能力强：快速弹性伸缩、提高资源利用率、故障自动迁移。第四代是基于云原生技术的时代，全面体现在全栈自动化和云原生工具生态能力类。全栈自动化体现为：流水线自动化、故障自愈 、支持跨数据中心调度 、以整套环境为单位交付；云原生工具生态丰富：K8S原生类CI/CD系统 、服务可视化编排 、滚动升级发布 、流量接入/灰度发布能力。
 第三代和第四代可定义为“云化”DevOps时代。
 
![](/home/attachment/202111/15/1218833_163696022787221.png)

#  三、 云原生和DevOps 的结合实践

## **江苏苏宁银行DevOps总体架构**

江苏苏宁银行DevOps总体架构是以平台为支撑，以流程为引擎全面打造金融级云原生DevOps平台架构。从底至上分为三层，支撑平台层：管理DevOps流程中涉及的各类资源，包括代码管理、持续集成、配置文件、应用实例等，同时提供部署、配置等Ops服务。自动化流程引擎层：面向可编排任务流程，提供任务的编排、配置、执行等功能，通过该流程引擎支撑不同应用的不同DevOps流程，实现DevOps的自定义特性；可自定义流程层：把DevOps流程抽象并具体化成一个个独立的动作，形成标准化DevOps流程。
![](/home/attachment/202111/15/1218833_163696024217090.png)
 
##  **江苏苏宁银行DevOps系统选型分析**
 
 上面介绍了“云化”DevOps时代的技术能力，但在当今市面上开源的DevOps系统工具种类繁多，如何正确、高效且符合云原生技术发展趋势等多重维度来选型DevOps工具系统对于企业进行数字化转型尤为重要。那么云化DevOps系统到底是什么？对比分析开源界主流DevOps CI/CD工具系统：Jenkins作为老牌CI/CD工具，具备一定的技术历史背景，但明显感觉太重 、Jenkins的Pipeline语法学习成本较高 、非kubernetes原生态工具；Spinnaker持续交付平台，是一款专注于多云平台的CD平台，功能专注于持续交付，对于CI/CT并不擅长；Gitlab虽带有CI/CD系统，但非kubernetes原生，考虑低耦合设计，为避免和Gitlab耦合，不想用gitlab-ci；Tekton是 Google 开源的 kubernetes 原生 CI/CD 系统，作为CDF四个初始项目之一、基于kubernetes CRD可自定义的pipeline流水线 ，但在工作流控制上的支持较弱；Argo则是一款遵循声明式GitOps理念的持续部署工具，应用定义、配置和环境信息是声明式的且可以进行版本控制，应用部署和生命周期管理是全自动化的且可审计，支持对多环境、多Kubernetes集群上的应用进行统一部署和管理。结合以上分析，我们选择Tekton+ArgoCD进行云原生的DevOps实践。
![](/home/attachment/202111/15/1218833_163696025192741.png)
 
##  **江苏苏宁银行Tekton+ArgoCD 实践-场景**
 
 准备工作：
 1、准备Git Repo
 Tekton Pipeline、app code、kubernetes deploy三部分
 2、安装Tekton/ArgoCD客户端、Tekton Operator、ArgoCD Operator和ArgoCD服务端环境
 3、创建ArgoCD的应用
 4、创建Tekton Pipeline
 5、允许Tekton Pipeline更新Infra Repo中的内容
 6、创建Webhook并配置Code Repo的Webhook
 7、运行Tekton Pipeline
 手动执行tkn pipeline start
 Gitlab上修改及提交Code，Webhook触发
 
 场景描述如下：
 应用代码放在Code Repository中，代码变化后会通过Webhook触发Tekton的Pipeline运行。
 Tekton的Pipeline先从Code Repository中获得应用代码，然后Build成Image，随后将应用Image推送到容器云平台内部的Image Registry中。最后再更新Infra Repository中的部署配置。
 ArgoCD发现Infra Repository中的部署配置发生变化后自动同步到容器云平台。
 容器平台根据新的部署配置从其内部的Image Registry获取最新的应用Image，然后部署到容器云平台。
 ArgoCD+Argo Rollouts支持blue/green、canary多种部署方式，结合开源的keptn做SLI/SLO及自动化测试。
![](/home/attachment/202111/15/1218833_163696026335057.png)
 
## **基于Argocd-Rollouts 进行 blue/green canary发布**
 
 在云计算技术或云原生技术出现之前，一些互联网公司也有灰度发布的需求，也会用基于一些开源工具做定制化研发，如使用Nginx等，使用其定制开发一些 基 于 Request  Header 流量切分、基于服务权重的流量切分、基于 Cooki e 的流量切分 等的规则引擎。目前业内流行的blue/green、canary发布技术有几类，引入和改进适合自身场景的灰度发布技术很重要。如可以使用服务网格Istio的I stio G ateway + VirtualService + DestinationRule **** 做灰度发布，但由于Istio自身技术栈具体有一定深度，要全面掌握其技术运用和维护需要一定的成本，故只为了进行灰度发布选用Istio会导致学习成本和应用成本过高；另外也可以基于K8S的Ingress进行 配置Ingress Annotations来实现不同场景下的灰度发布和测试 ，其本质就是Nginx的应用；第三类则是使用基于Argocd-Rollouts进行blue/green canary发布，既然我们选择使用Tekton+ArgoCD做DevOps系统工具，为保持技术栈统一则继续深度使用基于云原生的Argocd-Rollouts进行灰度发布。提前编写好yaml编排文件，发布流程如下：
![](/home/attachment/202111/15/1218833_163696027252709.png)

##  **新旧灰度对比**
 
 在使用了云原生灰度发布技术后，很大程度上改进了原灰度系统的不足，改善了用户业务系统体验，提升了代码发布质量和业务投产效率。
![](/home/attachment/202111/15/1218833_163696027824560.png)

#  四、 金融生产级云原生容器云平台的优化

## **江苏苏宁银行云平台总体架构**

江苏苏宁银行在南京有两个数据中心，基于双数据中心的基础设施之上构建云计算平台，从底而上的分为四层：底层是基础设施平台，含计算服务器、存储、网络、安全设备等，双数据中心基础设施池化；基于底层基础设施平台构建云计算IaaS层，技术栈分为开源栈OpenStack云平台和闭源栈VMware云平台，两者形成统一混合资源池，资源申请无需关注底层是何技术栈，双数据中心网络二层打通，跨数据中心可迁移云主机；基于IaaS层资源池构建云原生容器云平台；顶层通过多租户管理体系设计统一云管管理和编排调度各类资源，并提供丰富的服务目录含各资源管理类、DevOps类、监控运维类，以此满足金融业的服务指标、服务目标、服务质量等级等。
![](/home/attachment/202111/15/1218833_163696029645941.png)

##  **金融云原生容器云建设以上生产为目标**

如我们是以上生产为目标，列举几个原则： 
 1、尽量不改变现有生产网络架构模式、不改变生产系统IP地址以及防火墙策略，使现有的防火墙规则对K8S集群中的POD也生效，那么可以使用macvlan这种网络模型，这样POD ip和宿主机属于同一网络平面，既所有的网络流量都会经过现有交换机和防火墙（这种场景下可以简单的理解为POD就是虚拟机），需要提前规划足够多的IP地址资源池来给后面所有的POD使用。使用macvlan最大的问题：受技术原理限制（主要是underlay 2层流量不经过宿主机的3层及以上的协议栈，报文没有用iptables，ipvs处理，所以K8s里的Service、QoS、 N etworkpolicy没法实现），二是需要开启混杂模式，这种模式下会造成网卡过多的接受非自身处理的数据包。 
 2、还需要考虑集群内部的网络安全策略以及QoS，虽可通过Calico的 N etwork policy来配置ipvs来实现，但原生Calico均是命令行，操作不方便和易出错。 
 3、需要考虑集群内POD与第三方外围系统（如虚机某端口）安全策略（如核心生产区到外联DMZ区或者核心生产区到互联网DMZ区，需要开点到点的防火墙策略，源和目的都是物理IP），用macvlan也可以解决此需求，但不支持Service 
 4、金融场景下可考虑使用linux brige-vlan模式解决以上痛点。

##  **需要考虑的底层技术栈有很多**
 
 由于金融业对生产系统的高可用、稳定性、性能、安全等要求较高，故云原生容器云要达到生产级别的要求需要考虑、优化解决的底层技术问题有很多，现仅举例如下：
 1、K8S中CPU NUMA调度能力优化
 2、K8S集群调度能力优化，如：宿主机宕机场景后的调度策略
 3、K8S管理Node的能力
 4、弹性伸缩CA、HPA、VPA能力优化
 5、拉取镜像规则：空负载服务器、有负载服务器，计数器规则、就“近”原则
 6、东西向QoS、Networkpolicy，可视化操控等
 7、IPAM能力网络定制
 8、API Server/ETCD性能优化
 9、Harbor需要做双Harbor进行同步，保证镜像仓库高可用
 10、Etcd要用ssd做加速，做两个etcd集群，把存储的数据按事件类型不同分别读写不同的集群
 11、还有很多……

##  **基于Kubernetes构建的云原生DevOps容器云底座**
 
 DevOps 基础架构监控中心
 DevOps基础架构监控中心可全面监控Kubernetes各大组件的核心参数，如Etcd的库大小、客户端流量、gRPC流式消息、WAL日志同步时间、库同步时间、Raft提议等；APIServer的请求延迟时间、每秒请求数等；调度器监控调度次数、调度速率、调度延迟等，可视化监控粒度之细、监控参数之全面性在 K 8S的监控领域并不多见。
![](/home/attachment/202111/15/1218833_163696031088640.png)
![](/home/attachment/202111/15/1218833_163696031699519.png)
![](/home/attachment/202111/15/1218833_163696032223705.png)
![](/home/attachment/202111/15/1218833_163696032950362.png)
![](/home/attachment/202111/15/1218833_163696033655391.png)
DevOps 项目管理
DevOps项目管理可以根据企业空间、用户空间、项目命名空间等有效规划和隔离各类资源和对象的抽象集合，便于DevOps项目日常管理和运维操控。
![](/home/attachment/202111/15/1218833_163696034491557.png)

## **江苏苏宁银行DevOps +容器云实践效果**

容器云实践效果
极大程度的节源提效： 资源利用率提升60%，服务器/机柜成本下降60% ，且在生产环境各场景下发挥自动化和应急的重要作用，具体如下：
![](/home/attachment/202111/15/1218833_163696035199461.png)

云原生DevOps实践效果
环境交付、版本发布周期提速 2-3 倍； 提升投产质量，提升用户体验 ，具体如下：
![](/home/attachment/202111/15/1218833_163696035789772.png)

#  五、 基于云原生 的 DevOps技术趋势

云原生技术已逐渐成为金融科技行业的技术标配，DevOps技术也已发展有十几年，两者的强强联手、有效结合必将是金融业数字化转型的利器和必经之路。基于 云原生 的 DevOps 全行业 技术趋势 预测为：DevSecOps将被优先考虑、将更广泛的深度使用Kubernetes、从CI pipeline转移到DevOps组装线、强调Serverless架构、AI助力DevOps团队实现自动化、Golang将更受欢迎。银行是非常重视安全合规的机构、金融互联网产品发布快且重视用户产品体验、在金融领域会全面使用金融AI技术，因此江苏苏宁银行会重点关注DevOps的安全、基于云原生的灰度发布回滚技术使用、金融AI助力DevOps等方面。
![](/home/attachment/202111/15/1218833_163696036836389.png)

云原生 Kubernetes DevOps

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论10 条评论

larryz填控IICN
2024-05-07 13:37

文章对于DevOps系统的选型分析很有借鉴性

匿名用户
2023-05-31 08:54

请教几个问题，k8s天然devops模式，发布快、敏捷，苏宁银行基于k8s‘架构的devops实践代码审查需要0.5-1天，是不是跟快速交付的理念相悖，除代码审查外的其他安全能力如何在苏宁银行落地的呢，效率如何

h123aix网络工程师ji
2022-10-25 15:01

谢谢分享！

hunshiwangren

技术支持中电信数智科技有限公司
2022-09-15 12:28

不错不错，学习了

Tomas_jiesystem engineer信息技术有限公司
2022-06-14 10:37

学习了

sjsy57系统架构师proven
2022-06-06 16:15

受教了！

匿名用户
2021-12-05 22:49

【文章价值点】 1.作者分享金融级容器云建设如何满足生产级别要求。 2.作者分享了如何做网络插件选型改造。 3.介绍了DevOps从“传统”到“云原生”的技术演进。 4.详细对比介绍了为何选择Tekton+ARgoCD进行云原生的DevOps实践。【文章建议】 1.第四章第二节（金融云原生容器云建设以上生产为目标），不应是“列举几个原则”，而是为什么选择linux brige-vlan的原因。但作者分析的十分透彻。 2.DevOps基础架构监控中心的技术应描述再具体一些。【文章内容疑问】请教一下作者，第四章总体架构中，顶层的云管平台，是自研还是商采。能够详细讲解一下DevOps类和监控运维类具体设计。【个人看法】本文作者分享的案例，干活满满，读后收益很多。建议大家细细品味。若作者能够分享一下PPT就更好了。

jianglj其它SNB
2021-12-01 19:20

您好！基于开源的。

MapleLeafLJ研发工程师兴业银行
2021-11-29 00:30

文章对于DevOps系统的选型分析很有借鉴性，在传统方式和devops实践后的效果对比很清晰，有说服力。另外想请问下文中提到的DevOps 基础架构监控中心是市面上的产品还是自研的呢？

wujiahua

职员某大型国有银行
2021-11-25 17:59

受教了！

Ctrl+Enter 发表

匿名评论

银行基于云原生架构下的 DevOps 建设实践经验

添加新评论10 条评论

本文隶属于专栏

相关文章

相关问题

相关资料