作者rechen2020·2021-11-29 11:01

系统架构师·某大型银行

银行高并发交易类场景下容器云架构如何保障高性能、高可靠性总结

字数 23875阅读 5768评论 0赞 3

随着银行线上客户业务的高度活跃，为了支持客户在双十一、六一八等电商购物节通过第三方支付发送的海量支付请求，按照上级政策要求发行各类纪念币带来的大量预约请求，以及疫情时期内部员工在线办公的大量访问请求，银行各类对客提供服务的业务系统、尤其是承载高并发访问的与支付渠道相关的业务系统为了提高自身性能进行全面微服务容器化改造。为了更好的运行业务系统的微服务应用，保障在高并发场景下的高效性与稳定性，大部分银行会选择最主流的解决方案Docker+Kubernetes为代表的容器技术和应用部署方案实现容器云平台的主要功能，不断满足银行业务系统在各种开发、测试环境、生产环境对资源持续部署、弹性伸缩的需求，减少各个环境人员的工作量，提高工作效率。尤其是对大量中间件平台化的能力，比如在测试环境为支撑快速敏捷构建业务测试场景，可以基于容器云实现各类组件的一键部署和回收，保证环境一致性。另外根据上级部门的要求，银行业务系统国产化改造在加速推进，业务系统在改造时能够快速获得所需的应用资源，根据人行等上级单位的要求快速对业务系统软硬件进行重构。后续将研究与行内的DevOps流水线平台进行全面整合，实现银行业务系统建设的标准部署架构。

Kubernetes作为用于容器调度的平台，其虽然实现了从容器到应用、从网络到存储的诸多基础架构抽象，但其本身还是运行于传统OS的诸多应用进程，仍然需要通过必要的架构设计，来加强自身可靠性及性能提升。本次的银行行业同行交流，我们重点围绕高并发交易场景下如何提升及保证容器云平台的整体性能架构设计进行同行交流探讨。本场交流活动回顾：https://www.talkwithtrend.com/Activity/index/op/question/id/1813

# 一、如何对建设高性能、高可靠的容器云平台的基础设施进行选型和设计？

## 1、容器云平台物理服务器CPU和内存配比如何规划？
**嘉宾回复：陈治文 技术支持经理 , 英特尔云社区**
容器云平台CPU和内存配比取决于运行在其上的业务系统的需求，例如一般的应用可能1：4 的比例满足，但类似于Redis这样的内存计算应用需要1：8或者更高的配比。如果为了提高资源利用率，资源超分是常用的配置策略，需要注意的是CPU资源可以超分，但内存资源是不能超分的，所以资源池往往受限于物理内存的大小，在这方面，英特尔持久化内存可以提供更低成本更大容量的选择。

**嘉宾回复：杜东明  解决方案架构师 灵雀云Alauda**
容器云平台通常采用Kubernetes作为底层基础设施，k8s集群可以看作是将一组单个节点抽象为的“超级节点”。该超级节点的总计算能力（CPU和内存）是所有组成节点的能力之和。所以在容器云平台整体视角下看，每个节点的CPU和内存配比一般有『很少大节点』和『很多小节点』两种配比原则。例如：集群的总资源为：8c/32g，可以配比为4c/16g的2个 node，或2c/8g 的4个node。

配比模式一：数量少的大资源节点
优势：较少的管理负担、更少的成本、允许运行占用资源多的应用；因为总节点数降低导致集群监控成本降低
劣势：（1）每个节点运行太多的应用，产生一些开销，例如容器运行时、kublet的开销，另外 pod数量变大时，会拖慢系统速度，甚至使得系统不可靠，（2）限制副本数量，由于节点数量的不足，对应用的高可用产生影响；（3）更高的故障影响范围，发生故障的节点的影响会比拥有多个节点的影响大；（4）更大的扩容需求，影响K8s的集群自动伸缩器，缩放比例将增大，无形中增加了成本。

配比模式二：很多小节点
优势：（1）减少故障范围；（2）在不同节点可以有更高的副本数量；
劣势：（1）节点数量增多；（2）更大的系统负载；（3）降低资源利用率；（4）对 pod 的限制。

**嘉宾回复：rechen 云计算架构师 , 招商银行**
1、具体按容器云平台承载的工作负载（注：分业务应用、中间件、数据库），以及所依赖的基础设施的具体能力（注：物理机部署，或者是IAAS的 计算存储分离架构还是超融合架构？IAAS的计算、存储、网络能力），和容器云平台的运维要求（注：故障域，故障爆炸半径，使用率）来综合进行规划。  
2、譬如采用虚拟机部署容器云平台，物理服务器硬件规格常为2U机架式，承载业务应用系统的POD以2c/4G，一个容器平台宿主的虚拟机节点容纳20个pod，则虚拟机规格为20c/80G, 所在的物理服务器应为IAAS的计算节点，每台物理机最大容纳6个虚拟机，则规格配置如下：CPU为2颗INTEL至强5XXX型号，物理core数目为2*16=32 core, 在虚拟化层超分比为4，则vCPU为128。 内存的超分比率为0.8, 则配置768G为宜。

## 2、容器云平台数据持久化存储除了nfs是否还有其他选择？
**嘉宾回复：hsuyuan 资深架构师 , 英特尔云社区**
容器云平台的存储解决方案，可以参考 k8s 的 CSI 项目。 https://kubernetes.io/blog/2019/01/15/container-storage-interface-ga/
持久化方案实际上并不只限于 SDS 等存储解决方案， Intel 针对持久化有傲腾产品线，包括了傲腾持久内存和傲腾固态盘 。在高速内存设备和延迟底几个数量级的传统的 SSD 设备加入了新的存储层，能够提升持久化的效率和可靠性，您可以关注了解。

**嘉宾回复：rechen 云计算架构师 , 招商银行 **
1、容器云平台的底座主流是Kubernetes, 所以只要支持K8S CSI存储接口的商用存储产品，就可以选择使用。 2、容器云平台数据持久化存储的选型，还需要看应用场景的需求，以及自身的运维支持。

**嘉宾回复：杜东明 解决方案架构师 , 灵雀云Alauda**
容器云平台在数据持久化方面NFS是最简单实现的方式，也是最常见的协议。容器自身可以支持文件、块、对象三类存储形式。可以依据行内的情况，选择最合适的存储协议。
文件存储：适合少量数据存储、配置文件场景
块存储：适合数据库等高性能场景（当然，也有一些文件存储可以提供极高的性能，取决于存储）

对象存储：适合存放图片、视频、网盘文件等场景，需要应用支持
Kubernetes是基于CSI插件的方式提供对于存储实现扩展，不仅仅是存储协议，具体存储设备也需要提供对应的CSI才能实现与k8s最佳的融合。
另外，也可以用灵雀云的块解决方案TopoLVM，适用于中间件或数据服务相关场景。灵雀云产品中也内嵌了Ceph提供分布式存储能力，可实现存算一体或存算分离两种使用场景。

嘉宾回复： 常见的容器数据持久化资源除了NFS外，还有nas、san、本地存储等选择。   
NAS，主要是利用客户原有的商业产品，通过CSI实现对接。   
SAN，也是通过CSI对接，主要存储性能好，但价格比较高。   
本地存储，存储性能最好，但不支持数据漂移及维护繁琐的问题，基本没太多人使用。但随着数据库/中间件容器化的趋势凸显，本地存储作为其数据承载又是一个比较好的选择。

## 3、银行两地三中心架构中如何对接活改造容器平台的网络？
目前各大行纷纷效仿工行搞两地三中心，或者异地灾备建设。如何对接或改造容器平台的网络，以满足容器平台中应用与传统虚拟机、物理机中旧业务系统的相互通信，避免或尽可能减少对银行现有网络管理模式的冲击？

**嘉宾回复：杜东明 解决方案架构师 , 灵雀云Alauda**
目前银行容器平台中的容器应用与传统虚拟机、物理机中旧业务系统的相互通信遇到最多的问题都集中在IP有状态这件事情上，因为传统容器平台上应用如果要实现对外通讯主要是有两种：一种是基于宿主机IP+端口，另外一种是基于域名，这两种应用的对外暴露模式都隐藏了容器平台上应用的真实IP信息，所以不仅会造成传统虚拟机、物理机中旧业务系统无法和容器平台中应用的IP扁平化访问的问题，同时也让银行现有网络管理模式无法对于容器平台上的应用进行IP定位和网络资源管理。

针对以上问题和冲击，银行在两地三中心架构中可以采用灵雀云开源的Kube-OVN Underlay网络解决方案对接或改造容器平台网络，Kube-OVN underlay网络解决方案通过采用OpenStack的ovs二层虚拟交换技术，将容器平台上的应用和传统虚拟机、物理机中旧业务系统拉平到一个二层网络平面，让容器平台上的容器应用和传统虚拟机、物理机一样的使用底层网络资源并实现IP直达通讯。这样可以使银行现有的网络管理模式在Kube-OVN的underlay容器网络下依然有效。

Kube-OVN目前是CNCF的沙箱项目（https://github.com/kubeovn/kube-ovn） ，性能和安全性都能够完全满足金融企业的要求，某大型股份制银行正在计划构建基于Kube-OVN插件、支持IPV4和IPV6双栈，以及VPC级别租户隔离的完整解决方案，感兴趣的话大家可以来了解一下。

**嘉宾回复：rechen 云计算架构师 , 招商银行 **
需要看容器平台所依赖的IAAS能力而定。譬如容器平台部署在传统虚拟化平台，也没有启用SDN网络，如果容器网络设计为hostnetwork模式，则容器POD的应用和传统虚拟机、物理机的旧业务系统是直接可以通信的。 如果容器平台的宿主节点在用IAAS的虚拟机，且启用了SDN网络，容器平台启用的CNI特性，则容器POD的应用可以和IAAS虚拟机的业务应用直接通信。如果和传统网络中的旧应用，则需要开启IAAS的NAT特性或者为宿 主节点配置 EIP地址。

## 4、容器部署在裸金属和虚拟机上 性能差距有多大，是否有实际数据？
容器部署在裸金属和虚拟机上 性能差距有多大，是否有实际数据？

**嘉宾回复：hsuyuan 资深架构师 , 英特尔云社区**
基于容器的云原生的价值之一就是直接和硬件层打交道，减少了软件层的损耗提升了性能，具体的性能提升要看应用场景。例如人工智能的推理场景，借助 CPU 的 AI 优化指令集， AI 推理的性能可能带来几十倍甚至上百倍的性能提升。

**嘉宾回复：杜东明 解决方案架构师 , 灵雀云Alauda**
按照我们此前的经验，使用VM+容器方案，相比物理机直接跑容器中间多了一层Hypervisor，性能大概损耗10%～20%。

**嘉宾回复：** 其实两者的差异主要是在虚拟化这一层资源的占用上。   
我们之前项目经验，性能差异大约在25%~30%之间。   
过去，大家喜欢将容器部署在虚拟机上，感觉虚拟机管理、容灾比较方便。现在，越来越的用户会选择裸金属服务器部署容器，提高资源利用，节省虚拟化带来的成本增加。

## 5、中小银行容器云选择裸金属服务器还是虚拟机作为底层计算资源？各自有怎样的优劣势？

**嘉宾回复：rechen 云计算架构师 , 招商银行**
如果单位的IAAS能力提供祼金属服务，特别是软硬一体化加速的祼金属服务，则优先祼金属服务，可获得高性能的同时，也得到了扩缩容的弹性支持。
否则，建议采用虚拟机以提升交付效率、弹性伸缩和降低运维成本。

**嘉宾回复：hsuyuan 资深架构师 , 英特尔云社区**
容器云当然既可以选择裸金属，也可以选择虚拟机。
选择裸金属，可以避免损耗提高资源的利用率，提升 ROI 。同时也能更高效的利用硬件级别的创新，如计算加速设备，低延迟大带宽网络设备，高性能持久化设备等。应用裸金属的问题在于如何提高底层硬件资源的管理和监控能力，相对于传统的云计算平台， k8s 本身作为一个服务和负载的调配平台，目前对底层资源的管理能力相对较弱。
选择虚拟机可以最大化利用现有的基于虚拟化的云计算资源，虚拟化本身也带来更强的资源隔离性。但相对裸金属，一是有资源的消耗，另外很多硬件创新无法及时、高效的提供给应用使用。
我个人的观点是，裸金属应该是未来的发展方向。云原生技术重要的优势之一就是能够减少软件层的隔离，使硬件创新能够更好地支持应用的运行，提升性能可靠性等。云原生社区也在针对裸金属架构下，提升硬件资源的管理能力做出努力。 kube-virt 等项目也在尝试打通 k8s 和传统的虚拟化云平台。另外，针对容器本身资源隔离性不如传统虚拟化的问题，也有 kata container ， gvisor 等项目在提供解决方案。这个领域 Intel 同样在做出贡献，您可以参考 https://01.org/kubernetes 。

**嘉宾回复：杜东明 解决方案架构师 , 灵雀云Alauda**
对于Alauda来说，理论上我们的容器可以运行在任意基础设施上，包括虚拟机和裸金属。
在早期2018~2019年之前，中小银行容器云建设一般大部分会选择虚拟机作底层计算资源，但是随着容器技术的成熟，目前渐渐有一种趋势是选择裸金属服务器作为容器云平台建设的底层计算资源 。

裸金属服务器作为底层计算资源相比与虚拟机的优点：
1、性能层面：由于少了虚拟机这一层的性能损耗，裸金属服务器构建出来的容器平台性能损失较小；
2、成本层面：由于少了虚拟机部分的建设投入，裸金属服务器构建出来的容器平台成本投入较低；
3、管理层面：由于少了虚拟机这一层的运维管理，裸金属服务器构建出来的容器平台运维管理更为简单。
裸金属服务器作为底层计算资源相比与虚拟机也有一些缺点，主要是在容器云扩容层面，容器云的节点扩容性不如虚拟机，毕竟裸金属服务器的采购周期较长。
另外想要提一下，Intel基础设施层面的优化工具里面包括一些CPU调度相关组件（CPU Management，Resource Management Daemon等），可以帮助我们实现裸金属的高级部署方式，目前在测试与引入阶段，下一步会在我们的容器平台上进行应用优化。

## 6、银行高并发交易场景对底层CPU性能是否提出更高的要求？

**嘉宾回复：rechen 云计算架构师 , 招商银行**
银行高并发交易场景，主要依靠容器云的水平扩展能力，不会对单台物理机的底层CPU性能有更高的要求。
譬如：容器云的基础设施层面上，是在多个机房部署有多个集群，分布在不同的区（有不同的风火电供应）作故障域以提升基础设施的高可用性。集群有几十至上百台的物理服务器，一般情况下的机型为2U服务器，里面有2颗CPU，常用Intel至强的5xxx/6xxx型号。

**嘉宾回复：陈治文 技术支持经理 , 英特尔云社区**
一般交易类应用对CPU的基频比较敏感，基频越高性能越好，如果是高并发业务，CPU的多核能力也能更好的发挥，所以CPU型号的选择就是在综合考虑基频，核数，成本的平衡。另外在重要的交易类应用里，除了性能，稳定性也非常重要，稳定性主要体现在CPU RAS特性上。RAS性能指的是机器的可靠性(Reliability)、可用性(Availability)和可服务性(Serviceability)，至强5XXX及以上的CPU型号具备高级RAS特性，相比起4XXX的标准RAS特性，系统容错能力更强。

**嘉宾回复：杜东明 解决方案架构师 , 灵雀云Alauda**
从灵雀云的角度来看，答案是肯定的。
去年，灵雀云与英特尔联合推出了基于灵雀云ACP的英特尔® 精选开源云解决方案，该方案提供了针对特定容器云应用负载进行测试验证和性能优化的硬件配置建议，分别提出了Base 配置和Plus配置。
举个例子，在 Redis 应用中，Plus 配置可以提供的每秒钟执行测试代码的次数（Ops/Sec）比 Base 配置要高 3 倍左右。这在很大程度上是因为，Plus 配置搭载的傲腾持久内存在成本相差不大的前提下，提供了更高的内存容量，可满足在内存中进行数据高速处理的需求。今年我们又重新启动了这个测试，目前的测试结果来看，这个差距会更大，感兴趣的朋友欢迎关注我们接下来发布的测试报告。
基于灵雀云企业级云原生平台ACP的英特尔精选开源云解决方案
https://www.talkwithtrend.com/Document/detail/tid/445981

## 7、 银行的容器网络如何规划？
银行一般都是传统的网络架构，高并发下，网络缺少灵活性。采用容器后，容器网络如何兼容传统网络和安全管理，并提供扩展的灵活性。

**嘉宾回复：rechen 云计算架构师 , 招商银行**
1、容器云有多个集群，其中高并发高性能集群中宿主机上，使用传统网络，容器网络使用ovs。
2、高容量高扩展性的集群，宿主机上采用IaaS的基于VPC隔离的SDN网络，容器网络使用CNI组件，直接offload到宿主机网络上。

**嘉宾回复：杜东明 解决方案架构师 , 灵雀云Alauda**
在金融实践中，我们经常遇到此类话题，这也是每一个金融客户都绕不开的话题。 在演讲中，我也提到了关于平台化思维和条线式思维的矛盾，这个矛盾在银行业是特别突出的。

我提几个比较落地的建议：
underlay和overlay一起搞：目前容器网络两个基本技术思路是overlay和underlay，overlay是建设虚拟网络，容器采用虚拟IP；underlay是复用下层物理网络，容器像虚拟机一样使用下层网络。从某种意义上说，overlay是平台化思维的产物，underlay是条线式管理思维的产物。某些银行可以允许大规模overlay，个别场景采用underlay（例如多播、运管功能等），这样两个一起搞，同时兼顾。另外还有些银行目前基本没有overlay的空间，更多采用underlay管理；而还有些银行在虚拟化上建设容器平台，underlay不能用（underlay可能会和iaas网络有冲突），导致只能用overlay。鉴于这些情况，我的建议是两个都上，不同的集群采用不同的方案，甚至通过多网卡同时采用underlay和overlay。即便仅有一种需求，也两种方案都规划到位，保证未来拓展的可能性。
可以参考IaaS的网络建设思维：IaaS典型的网络思维是三网分离、四网分离，容器网络目前规划中，以前不太考虑这种方案，这是因为以前更多是IaaS负责基础设施网络，但是如果一旦在裸金属上部署容器平台，那么IaaS原来遇到的问题，今天容器平台也会遇到。
容器网络与外部网络通信管控：通过统一的接入点（ingress、egress）管控容器内网的网络互访，加强到“稳态”和“敏态”之间的安全交互
networkpolicy管理：如果有可能，更多采用networkpolicy为每个应用设置安全管控策略，这也是更“云原生”的一种做法。
最后，容器网络是金融客户非常关注的话题，灵雀云的Kube-OVN网络方案已经开源，应该是目前业界比较活跃的方案，有兴趣可以尝试一下。

# 二、为满足银行高并发交易的高性能和高可靠性需求，容器云平台的架构设计中，有哪些具体实践？

## 1、 容器云平台在架构设计中，如何确保银行核心交易在高并发的环境下，安全、可靠、平稳的部署在容器云中？
银行核心交易系统每日的并发交易量很大，目前核心系统交易正在微服务化改造，容器云平台在架构设计中，如何确保银行核心交易在高并发的环境下，安全、可靠、平稳的部署在容器云中？

**嘉宾回复：杜东明 解决方案架构师 , 灵雀云Alauda**
这个问题需要从几个角度回答：
平台基础架构：
管用分离架构：灵雀的产品架构是管理平台和业务平台是分离的，确保管理负载不会影响到业务运行。即使，管理面出现重大事故，业务面也不会受到任何影响。
平台 高可用架构：容器云平台管理控制面和数据面都采用高可用架构模式，所有的组件使用高可用多实例部署 ，例如Ingress多实例、数据库多实例、服务多实例等等。
平台 多活架构：容器云平台的多话架构可以做到故障恢复后不丢数据（即RPO为0），有问题的话恢复时间＜1分钟；

平台的可扩展性：
承载核心系统的容器云平台具有横向扩展性：应用实例具备弹性扩缩容的能力，需要完全能够满足业务的特殊要求或者线性增长，支撑传统金融机构做类似于双十一这样的大促销，金融爆款产品的秒杀，或者是一些高并发的场景金融；
自我管理和自动化运维能力：容器云平台自身需要具备统一的日志收集和存储能力，并且能够进行应用链路分析，自动化收集容器组件日志、事件、审计等数据，通过告警等手段通知到运维人员，确保核心系统可靠平稳运行。

对应用故障的修复时效性
DevOps 流水线方式发布应用：平台需要具备支持银行产品团队能快速敏捷地在容器云平台上，实现新的金融产品和服务。在传统的集中式架构下，上线新的大一些的功能就可能需要大量改动核心内部、关联系统，造成业务上架用时较长。容器云平台具备集成devops 流水线能力，并可以集成流水线工具形成devops模式缩短业务部署交付时间；
最后，能给到大家信心的是，从18年开始灵雀云的平台 已在国内几十家金融机构落地，并承载各类金融应用 ，包括部分A+类应用的持续稳定运行。容器支持核心业务这件事，已经在持续发生中。

**嘉宾回复：hsuyuan 资深架构师 , 英特尔云社区**
安全稳定是一个端到端的概念，从底层的硬件，甚至数据中心基础架构的建设起，一直到服务，都需要考虑。除了容器平台提供的弹性扩展、负载均衡等高可用能力，您也可以关注类似 kata container 这类增强隔离性的方案，以防止单一容器故障引起整台服务器的宕机。
除此之外，在安全领域，信任链是一个关键的因素。如何通过信任链的构建，确定 “ 他就是他 ” 以防止非法访问是传统安全需要解决的问题。这个领域，您可以参考 Intel 的 SGX 技术，通过使用加密的执行内存区域，防止您的数据在运行中被泄露，同时可以作为运行时的信任根，确保信任链可靠。

**嘉宾回复：rechen 云计算架构师 , 招商银行**
1、容器云平台的基础设施要配套建设，保障银行核心交易系统的两地三中心，或多站点多活的部署架构需求，包括机房、基础网络、IAAS平台高可用保障、 负载均衡 等。
2、银行核心交易系统自身的应用架构设计，包括数据域的分库分表库层和缓存、应用域的无状化设计、部署域的业务单元化部署、配置域的规范、运维域的链路追踪等。

## 2、 容器云高可靠、高性能离不开安全建设，希望可以分享一些容器云的安全实践？

**嘉宾回复：hsuyuan 资深架构师 , 英特尔云社区**
安全这个主题包括了非常多的内容，不仅仅是被动的防御和事后的查漏补缺，也包括态势感知，主动防御等内容，应该作为一个整体去考量和规划。细化到云原生这个方向，目前有容器平台本身的安全，映像安全，开发运维一体化安全（ DevSecOps ）等主题。

和传统平台相比，我认为云原生的安全有两个领域更值得关注。
一是对平台、服务和资源的全面掌控。云原生与传统云计算相比，资源粒度更细、服务数量更多、连接更复杂。带来的问题是监控、排错难度的指数级提升，对监控管理工具的依赖度更高。在部署和运维云原生平台之前，需要提前规划好监控和运维方案，例如目前常见的全链路监控方案（ zipking 、 jaeger 、 skywalking 等）。全面的监管控查为安全建设奠定基础。
二是资源隔离性问题。特别是多租户场景下，传统容器的隔离性无法达到要求，提权、逃逸、 kernel panic 等威胁更大。这个方向，除了使用传统的虚拟化方案外，建议关注 kata container 等云原生隔离增强方案，以提升安全性。

**嘉宾回复：陈治文 技术支持经理 , 英特尔云社区**
安全性的确是用户使用容器技术和业务上云面临的最大挑战之一，其中数据安全问题最为突出。数据在整个生命周期有三种状态：At-Rest（静态）、In-Transit（传输中）和 In-Use（使用中）。At-Rest 状态下，一般会把数据存放在硬盘、闪存或其他的存储设备中。保护 At-Rest 状态的数据有很多方法，比如对文件加密后再存放或者对存储设备加密；In-Transit 是指通过公网或私网把数据从一个地方传输到其他地方，用户可以在传输之前对文件加密或者采用安全的传输协议保证数据在传输中的安全，比如 HTTPS, SSL, TLS, FTPS 等；然而 In-Use 状态的数据很长时间内都没有很好的保护的方法，直到可信执行环境（TEE）的出现，还有一种说法称为机密计算。英特尔® SGX 是英特尔的受信任执行环境（TEE），它提供基于硬件的内存加密，隔离内存中的特定应用代码和数据。英特尔® SGX 使得用户层代码可以分配内存中的受保护区域，即 “飞地”，这些区域不受更高权限等级程序运行的任何影响。英特尔® SGX 在操作系统、驱动、BIOS、虚拟机管理器或系统管理模型已瘫痪的情况下仍可帮助防御软件攻击。因此，英特尔® SGX 在攻击者完全控制平台的情况下仍可增强对数据和密钥的保护。

**嘉宾回复：rechen 云计算架构师 , 招商银行**

1、容器云的基础设施层的安全建设，包括IDC、物理服务器的带外，IAAS平台的安全加固。
2、容器云的宿主机节点的安全加固，包括操作系统，root特权用户管理，堡垒机建设。
3、容器云的底座kubernetes集群的安全加固，包括集群RBAC、证书、kubeconfig配置文件、token管理。集群的备份和恢复保障。
4、DEVOPS平台的安全加固，包括业务应用系统的源码安全扫描，容器的基础镜像安全，编译流水线的安全。
5、容器云平台的业务应用的配置文件，用户密码，SSL证书等重要凭据的安全管理。
6、建设安全接入区、WAF等安全基础设施，应用漏洞扫描、整改的流程。

**嘉宾回复：杜东明 解决方案架构师 , 灵雀云Alauda**

容器安全可以从以下方面着手评估和实践：
一 基础设施层
1. 涉及容器云工作节点的操作系统使用遵循安全准则的操作系统。使用防火墙，端口阻止等安全措施。系统常规安全更新和修补程序在可用后必须立即应用，防止黑客和入侵者利用已知漏洞。使用最小化操作系统，同时精简和平台不相关的预置组件，从而降低系统的攻击面。使用第三方安全加固工具，定义了系统上的应用程序，进程和文件的访问控制等。建立审核和日志记录流程，确保构建平台的所用的操作系统是安全合规的；
2. 网络层安全，实现管理平面业务平面流量隔离，最少的端口暴露；
3. 存储安全：定时快照和备份并对敏感数据进行加密。

二 平台层安全
1. 对容器调度和管理平台本身需要实现安全基线测试，平台安全扫描；
2. 对平台层用户操作进行审计，同时也需要项目层面的资源和操作审计；
3. 对平台实行权限控制，能基于角色/项目/功能等不同维度进行授权；
4. 定期备份平台数据；
5. 选用具备自动化巡检能力的平台产品；

三 容器安全
1. 镜像安全：容器使用非root用户运行，使用安全的基础镜像，定时对镜像进行安全漏洞扫描；
2. 运行时安全：主要是对容器在容器平台上运行过程中的对于宿主机系统以内安全设置，例如容器特权、提升权限、主机PID、主机IPC、主机网络、只读文件系统等安全限制。同时建议具备限制容器对于底层宿主机目录的访问限制。 限制容器对于外部网络端口暴露的范围限制。用户限定某些敏感项目独占宿主机，实现业务隔离；
3. 容器网络安全：可以通过Networkpolicy模板，对于所有Pod之间、Namespace和Pod之间等进行IP、端口、标签等细颗粒度的容器安全策略，同时在集群内部为Namespace划分子网、并且对于不同的namespace之间的子网设置白名单，进行访问控制。
灵雀云的云原生平台完全遵循上述规范建设，可以满足各行业客户对于安全的要求。

## 3、容器云平台如何有效保证承载运行数据的一致性？在高并发时候快速扩容，故障快速恢复且相对简单易用?

**嘉宾回复：rechen 云计算架构师 , 招商银行**
1、需对容器云平台的运行数据进行细分看，如果是指业务应用的数据，则重要的业务数据应保存在数据库、对象存储等基础服务软件以保障数据的一致性。
如果是指容器云平台本身的管理数据，则K8S的基础软件：etcd，数据库等有保障数据一致性的能力。
2、要应对高并发的快速扩容，需要提前做架构规划，譬如：规范好各个重要业务应用的部署架构，要求流量接入层，支持负载均衡的分发，应用服务层支持单元化部署或无状态，数据库层支持分布式数据库或者分库分表或缓存加速。
3、要达成故障快速恢复且相对简单易用的目标，需要运维大数据和自动化运维体系的支持，譬如：实施分布式链路追踪和统一日志监控，以先实现快速地故障定位和根因分析，结合自动化运维的能力实现故障快速恢复和易用。

**嘉宾回复：hsuyuan 资深架构师 , 英特尔云社区**
容器平台通常运行的是无状态的应用，而有状态的应用，一致性通常需要借助持久化设备，通过数据库等技术实现。

分布式系统 CAP 原理决定了没有完美的解决方案。但通过微服务架构，将传统的单体应用解耦，使与事务无关的业务逻辑并行运行，结合消息队列 / 服务网格、关系型数据库等，针对不同业务需求分别实现最终一致性和强一致性，可以尽可能的满足快速扩容故障恢复和一致性的需求。

**嘉宾回复：杜东明 解决方案架构师 , 灵雀云Alauda**
简单的说，一致性问题应该分为业务一致性和数据一致性两个方面，通常，业务一致性应该由微服务或上层应用保证。 
而数据一致性问题如果面对单一应用，应用层面会通过操作系统保证崩溃一致性，存储层面会保证多lun的一致性及复制一致性。例如在某个场景下，数据库的数据文件和日志文件，分别存储在两个lun里，那么通常数据库会通过dependency write保证一定会先写日志再写数据，但是存储down机的瞬间，存储是否能保证日志文件和数据文件两个lun是一致的，这是存储对崩溃一致性的处理能力。同时，如果把两个卷分别通过async/sync复制到远端存储，那么就会涉及目标lun的复制一致性，即必须保证在某个时刻，哪怕发生了某种灾难，远端的两个卷里的数据也是一致的。

在容器场景里，这两种一致性问题的处理方式是不一样的：
1. 对于业务，一般在微服务领域会处理分布式一致性问题，这点已经通过开源方案做得很好了，在灵雀云实施的客户里，也有不少客户需要这些方案；
2. 对于数据一致性，这点上，单一容器内并不会有额外的处理，OS对崩溃一致性的处理并不会更好或坏，而存储侧的能力还需要存储来解决。
但是一个相关的话题是应用状态保留的问题，或者我自己命名为“重启一致性“，毕竟容器领域，重启是常见现象，也可以拿出来分享：
容器平台采用 K8s的statefulset工作负载来保证平台承载的应用数据的一致性，稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现。

statefulset 工作负载有以下特性：
1. 稳定的网络标志：即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现；
2. 有序部署，有序扩展：即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现；
3. 有序收缩，有序删除（即从N-1到0）：容器云平台一般采用HPA（Horizontal Pod Autoscaler）Pod自动弹性伸缩进行故障快速恢复，可以通过对Pod中运行的容器各项指标（CPU占用、内存占用、网络请求量）的检测，实现对Pod实例个数的动态新增和减少。

现在国内容器云产品在K8s 的工作负载支持方面都做得不错，除此之外，灵雀云在产品中使用K8s的operator技术进行有状态应用的部署、运维等能力，并且提供中间件的容器化服务 RDS 能力，是对数据服务（中间件、数据库）的进一步增强。
针对您刚才提到的高并发时刻快速扩容、故障恢复，这个问题本身是容器平台的优势所在，不管手工还是自动都已经有大量客户实践的案例产生，已经是非常成熟的技术。
另外，上面虽然探讨了数据一致性问题，但是通过存储保证数据一致性并非容器平台的最佳实践，我的建议是：

应用的容器化改造 - 确保故障自愈
应用的无状态化改造 - 确保弹性伸缩与故障自愈
应用的微服务化改造 - 确保业务一致性，降低对数据库的要求，从而进一步降低存储一致性的要求。

## 4、使用了容器云，原有的数据库如何扩展？
在使用容器云之前，我们都是使用虚机，虚机的数量基本还是可控的，我们一套Oracle RAC 可以承载10个应用左右。自从使用了容器云之后，应用的数量急剧增加，导致数据库单个节点的连接数轻松突破3000，这样多个应用共存一套库就变得很紧张，为此，我们的互联网类应用，每个大类应用都使用了一套独立的库。我想请问各位专家，你们真实的生产环境是如何为容器云分配数据库资源的，多谢！

**嘉宾回复：rechen 云计算架构师 , 招商银行**
1、容器云上各个业务应用的数据库，是由DBaaS平台提供。DBaaS平台提供了多种数据库服务，譬如MySQL，分布式数据库TDSQL、TIDB， Oracle, Mongodb， redis等。
2、互联网应用，一般选择分布式数据库服务，和redis缓存服务。
3、DBaaS平台提供资源管理和调度，经过迭代调优的调度策略，以及充足的资源池供应，避免了多个应用共存一套库，数据库单个节点的连接数轻松突破3000的问明。

## 5、中小城商行容器化改造最佳适配厂商及实施过程相关运行安全问题规避？
如果可以的话，请推荐些适合中小城商行进行改造的厂商及实施方案以及如何规避生产运行安全问题，例如：行方与厂商共同进行实施维护或者选用后期自行维护。

**嘉宾回复：杜东明 解决方案架构师 , 灵雀云Alauda**
容器运维与传统运维之间有很多大的技术门槛，通过多年的项目经验总结，在中小金融单位决定上容器平台，同时也会采购一定量的人天驻场服务，第一年基本都是合作运维，之后每年根据规模或需求采购订阅服务和重保人天。

在过去三年也看到一些业界容器失败的案例，基本问题就是：测试业务系统迁移到容器平台过程中，出问题运维团队不能及时处理，导致业务开发人员容器平台的稳定性、可靠性产生质疑，最终导致项目失败。

综上，容器项目不是短期内可以交钥匙的，也和稳态（例如IaaS）平台不一样需要紧跟社区，所以后期还存在功能规划、平台运维、升级实施、安全重保、应用迁移、服务改造、流程设计等问题。故，建议行方采购产品的同时，重视服务，采用甲乙双方更加紧密配合的项目建设/服务模式。

**嘉宾回复：rechen 云计算架构师 , 招商银行**
1、中小城商行容器化改造，建议在项目实施过程中，对接现有的运维体系、安全体系和相关工具平台，则可在整体纳入到现有IT保障体系的基础上，将有限资源聚焦于容器台的保障上。
2、行方可购置厂商的驻场服务，解决平台的安全加固和平台运维问题。行方自己聚焦于容器平台的培训、应用推广等产生IT价值的工作。

## 6、云原生架构下应用转型的规范有哪些，该如何定义？
金融业已有项目、新建项目如何适配已有的容器云平台实现应用的转型？落地过程中需要参考哪些规范？这些技术规范内容是什么？目前我能想到的就是应用容器化的技术规范、私有镜像管理规范。

**嘉宾回复：杜东明 解决方案架构师 , 灵雀云Alauda**
我们自己在项目落地的过程中，尤其是涉及应用架构改造的项目，会遵循一些技术规范。通常情况下，我们会和客户做深度沟通后，出具《软件集成技术规范书》、《代码规范》、《微服务实施方法论及最佳实践》、《微服务开发规范》、《微服务拆分标准》等材料，也会依据客户的需求进行某个领域更深入的探讨和输出。

在应用架构转型的语境里和组织自我进化的角度，建议可以参考一下Heroku平台的创始人Adam Wiggins提出的云原生应用开发的12要素和Pivotal公司Kevin Hoffman基于云原生12要素新增的云原生15要素。这些要素几乎涵盖了云原生架构下应用转型的各个方面。这里也把云原生应用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）
另外，今年年初，我们参与了信通院牵头的云原生成熟度标准体系的讨论和标准制定，在这个体系里面包括一个云原生业务应用成熟度的评估标准，根据基础设施域、应用研发域、服务治理域以及组织管理域成熟度综合计算，共分为五级，五个级别有明确的定义，比如在初始级，技术架构局部范围开始尝试云原生化改造，并取得初步效果，而卓越级，技术架构已完成全面云原生化改造，且个技术模块功能已相当完善，能够很好地支撑上层应用。目前这个标准的细则还在酝酿中。

**嘉宾回复：hsuyuan 资深架构师 , 英特尔云社区**
向云原生的转型不仅仅涉及到技术，还有关于流程、组织的变革以及如何适应业务的变化。业务领域和组织架构领域的的变革通常需要根据实际情况去规划。但常见的方式通常基于两种策略，“试点扩大”和 “ 小步快跑 ” 。云的迁移方法论有很多， Intel 有关于云的迁移的方案论供参考： https://www.intel.com/content/www/us/en/cloud-computing/6ms-cloud-transformation-infographic.html 。

在规范领域，云原生作为新型的技术，目前还没有特别针对性的行业规范，但有部分相关的规范正在制定中。实际上规范是现有经验的总结，云原生也同样可以参考其他规范，从可靠性、稳定性、安全性、可管理性、可追溯性等方面去提升管理运维能力。和传统运维最大区别，在于云原生领域高度的自动化和开发运维一体化。

# 三、建设高性能、高可靠的容器云平台的项目实施和上线运维中，有哪些实践和可参考的经验？

## 1、对于中小城商行而言如何引入云计算建设？路线应该如何选择？
对于中小城商行而言，业务量和敏捷开发要求都不如大行和互联网公司，在此情形下，是否引用云计算，什么情况下引入？如何引入？是否根据业务特点（如敏态、稳态）采用不同的云计算建设路线？敏态、稳态业务所需的云服务侧重点也不同？（如稳态主要提供Iaas，敏态提供Iaas、PaaS，并以K8S为核心，建设PaaS平台？）

**嘉宾回复：ggffss 安全工程师 , 某银行**
首先不要人云亦云，先问一下几个问题：
（1）计算资源的分配对日常工作是否有压力？
（2）有没有分支机构需要自己申请资源？
（3）业务系统是否已经敏捷化部署？
（4）业务系统有没有突发的高并发需求？

中小城市商业银行的云计算路径往往如下：
（1）先搭建测试云环境
（2）再搭建互联网云环境
（3）再搭建内网业务系统云环境

传统的核心业务系统，往往采用传统小机部署，或者虚拟化部署。
对中小城市商业银行来说，基础运维团队人员有限，技术能力有限，通过测试云磨炼技术和队伍，再往生产环境慢慢部署，业务系统，从非生产业务系统-生产业务系统-核心业务系统逐步迁移，小步慢走。除非业务系统敏捷话倒逼云计算升级，不建议直接建设PASS平台。

**嘉宾回复：hsuyuan 资深架构师 , 英特尔云社区**
云计算是技术趋势，云计算本身确实具有降低 TCO ，提高灵活性等优势。
但对企业来说，云计算的建设本身需要考虑的是 ROI 。投入的建设成本、运维成本、组织架构变革成本、知识更新成本等显性和隐性的成本，加上项目部署、运维的潜在风险是否能大于收益。收益则需要根据企业的显示情况分析，对不同的企业来说可能完全不同。

除了 “ 试点扩大 ” 、 “ 小步快跑 ” 等实施策略外，中小行也可以借助大行的经验，通过尝试大行提供的金融云平台。

**杜东明 解决方案架构师 , 灵雀云Alauda**
中小城商行在云计算建设和技术引入时，建议考虑基于以Kubernetes为核心的云原生平台来做，Kubernetes作为云的操作系统，可以屏蔽下面各种各样不同的云环境、云基础设施，它自身是一个可移植层，这样在做混合云和多云管理时，对应用迁移以及其他工作负载非常有好处，可以做到跨环境的兼容。由于Kubernetes的可扩展性，本身平台之平台的属性，导致它天生适合用来作为整个混合云的控制面板，用它去编排不同类型的云环境以及云基础设施和各类云服务。

在建设路线上应该以应用为中心，覆盖应用全生命周期为目标进行云计算的建设方向。充分考虑平台融合基础设施、微服务框架、数据服务、DevOps工具等模块作为平台组件，以建设具备全栈能力的云平台为发展方向。

## 2、 有没有将核心系统放在容器云平台中去运行的？

**嘉宾回复：杜东明 解决方案架构师 , 灵雀云Alauda**
灵雀云在2018年左右开始服务并部署容器云平台的几个大股份制银行，已经将核心交易系统以容器化方式运行在容器云平台，其中大约有30%的A+类业务系统和70%的A类业务系统。
以某股份制银行为例，其手机银行有80%模块以容器方式在运行，目前生产环境已有3000+物理节点，24个业务集群，有280个生产业务系统已迁移至容器云平台。

**嘉宾回复：rechen 云计算架构师 , 招商银行**
有的。原先在IBM AS400，S390主机的核心业务应用，用java重写后，就是部署在容器云上。

**嘉宾回复：hsuyuan 资深架构师 , 英特尔云社区**
有， 保险行业某客户，保险核心系统运行在容器云平台上。

## 3、对于中小型银行，容器云是否会明显降低人力成本、构建成本、维护成本？

**嘉宾回复：hsuyuan 资深架构师 , 英特尔云社区**
从成本的角度看，除了建设成本，运维成本等显性的成本外，还有组织架构变革成本、知识更新成本等隐性成本。例如，通过容器化和 k8s 自动化管理，运维的成本可能大大降低，但容器化本身带来了应用程序迁移或改造的成本。同样，成本也分近期成本、中期成本和远期成本，很难一概而论。
容器云平台在行业内的应用越来越广泛实际上说明了对于大多数客户来说，收益是大于成本的。
实际上，容器云平台最大的价值不是成本降低，而是灵活性和可用性的提升，这对业务来说可能会带来更大的价值。

**嘉宾回复：杜东明 解决方案架构师 , 灵雀云Alauda**
首先，答案是“是的”
中小型银行的IT特点是外包开发多，容器云能够提供几个方面的价值，从而降低各方面成本：
通过基于容器的DevOps，构建行内外包开发规范，包括组件使用规范、开发流程规范、自动化测试规范、业务上线规范等，在开发、测试、准生产环境中提升标准化程度，从而降低管理成本和软件质量；
基于容器云提供的ServiceMesh技术，可以降低对“统一开发技术栈”的要求，这件事很重要，技术栈要求越高，外包开发成本越高，如果能够开放技术栈，例如开发语言、SDK等，可以进一步降低成本。这点是对传统“SpringCloud”技术栈的一次增强。我们认为小型银行，可以通过ServiceMesh的方式即保持微服务的优势，又降低微服务团队招募、开发的成本；
在大量的实践中，容器平台能够降低应用的运维成本已经是不争的事实。通过容器自动化运维的能力，降低人力成本，这点不再赘述；
另外， DevOps也可以有效提升开发、测试、运维团队沟通的效率，通过容器界面实现开发和运维的权责分离，有助于降低软件开发、运维过程中沟通的成本 。

## 4、云原生架构下工作职责如何切分？
我目前所在的容器团队负责测试环境的容器资源管理，主要是推进项目的容器化改造，想咨询下容器团队在对接项目组的过程中需要负责做哪些事情？项目组做哪些事情？或者更具体的说镜像制作、服务编排脚本是容器团队写还是项目组写？

**嘉宾回复：**您是想问，在容器平台推广过程中，容器平台运维和应用开发或运维之间的工作分工。
一般来说，容器平台的运维归属在运维部门，而平台提供的是基础能力。比如，应用发布、流水线等。而应用开发或应用运维作为平台的用户或者说使用者，是基于平台进行应用发布、升级、回滚等应用的运维管理工作。
具体到镜像制作，通常运维部门提供基础镜像，应用部门基于基础镜像制作应用镜像。当然，有些应用人员会反馈不了解K8s，需要其他同事配合，这种情况我理解是需要部门之间划清职责，运维是辅助，不能代替应用团队完成其工作。
服务编排脚本，涉及范围比较大，就容器平台来看主要是yaml文件。由于涉及到应用发布，这部分基本都应该是由应用团队来编写。这里面，运维团队能够提供的帮助是，给应用团队做好yaml编写的培训（如果不了解，可以让其上网自学），或者针对常见的应用场景如发布，提供标准发布模板，告诉应用团队只要修改哪些常见参数即可完成发布，比如名称、数量等。

**嘉宾回复：杜东明 解决方案架构师 , 灵雀云Alauda**
首先，我们从什么是云原生架构的角度来理解工作职责的划分会比较容易一些。简单来说就是把原来开发部门需要开发业务功能的工作下沉到基础设施，把运维部门对于基础设施（例如云计算）的一些原生能力赋能上层业务应用，所以在云原生架构之下，原来开发部门和运维部门的工作职责就出现了冲突，那如何来规避这些冲突，目前在金融行业我们看到普遍的做法有三种：
第一种做法：专门成立一个容器管理部门，这个部门介于开发部门和运维部门之间，这个部门不用关心基础设施硬件的建设，它不仅是容器平台建设的计算、存储、网络资源的使用者，同时它也是支撑业务应用开发的开发环境、开发工具、容器应用日志监控等能力的提供者。
第二种做法：从现有开发部门或者运维部门拆分出一个虚拟团队，这个虚拟团队可以专门负责容器平台的日常运维管理事宜，一般建议从运维部门拆分，这样可以提升容器平台日常运维管理的沟通和协调效率。
第三种做法：通过引入针对各个部门不同使用场景的多视图和权限的云原生平台，细化工作职责的划分，也是一个不错的选择，我们有成熟的金融云原生平台使用案例，包括上面提到的具体的问题，方便的话可以进一步交流。

**5、如何更好的提升IT系统产品研发效能和交付效率？**
中小银行设计的容器云平台，如何与银行自身的持续集成系统、测试服务系统或者说是DevOps流水线进行有效对接，更好的提升IT系统产品研发效能和交付效率？

**嘉宾回复：杜东明 解决方案架构师 , 灵雀云Alauda**

中小银行在设计容器云平台的时候，我认为需要注意以下几点：
首先站在产品研发效能提升层面：
1. 银行自身的持续集成系统、测试服务系统或者DevOps流水线工具，我们建议尽可能使用开源工具来建设，目的主要是让整个产品研发的工具链体系和开发流程更加灵活，目前我们看到有大量中小银行都在采用开源工具链来进行DevOps工具体系的建设；
2. 建议引入一些开放的可以整合这些开源工具链的产品，例如灵雀云的DevOps开放平台，充分尊重客户使用的开源工具链，通过工具链集成的形式简化银行DevOps工具体系建设的复杂性，统一DevOps工具链全链路管理能力；
3. 改变应用的交付方式。原来传统的以二进制Jar包、War包为制品的交付方式，最好统一成以标准容器镜像包为制品的交付方式进行交付；
4. 严格规范业务应用运行的中间件版本或者应用运行环境等，例如限定JDK的某几个常用版本，Tomcat的某几个常用版本等；
5. 尽可能使用轻量化、可容器化的中间件作为业务应用的运行环境，例如tomcat、nginx等，不建议使用websphere、weblogic这种比较重的并且对于容器化不够友好的中间件产品；
6. 引入Service Mesh这种下一代微服务网格技术，简化产品研发的人力资源投入，提升整个产品的服务治理和全局可视化管理的能力。

其次站在提升交付效率的层面我们建议：
1. 容器云平台一定要提供开放的API对接能力，目前市面上主流的容器云平台都是基于Kubernetes技术发展出来的，所以Kubernetes的原生对接能力是非常重要的；
2. 银行自身的持续集成系统、测试服务系统或者DevOps流水线需要具备和容器云平台对接的能力，例如这些敏捷开发工具可以直接调用Kubernetes的API来自动进行应用的持续发布；
3. 建议容器云平台最好可以提供一部分DevOps CD的功能，在银行现有敏捷开发工具无法进行容器云平台API对接的情况下，可以通过例如基于制品更新为触发条件的自动化持续发布能力。

**嘉宾回复：** 持续集成体系需要支撑容器构建及部署，不建议为容器云单独打造持续集成。   
有统一的支持集成体系，就会有统一的交付标准及交付流水线   
另外银行的特殊性，每次交付需要具备交付文档等内容，这时候建议使用支持所有制品存储方式（文档、war、镜像）的制品仓库（如JFrog Artifactory或Nexus）进行交付，不建议使用Harbor。因为单独为容器构建交付方式，就无法与体系更好的集成。银行的特殊性，交付docker镜像也需要提供各种测试报告及审批报告等。   
综上：统一的持续集成流水线、统一的质量门襟、支持双态的工具链、统一的制品存储及跨环境制品同步能力。

## 6、中小城商行进行容器化的选型方案及实施步骤？
针对中小城商行科技人员匮乏、技术能力薄弱、至今沿用传统架构等特点：  
在实施容器云架构改造过程中应如何进行选型、如何分批次将现有架构纳入改造、传统核心类应用是否适合进行容器化改造。

**嘉宾回复：杜东明 解决方案架构师 , 灵雀云Alauda**
中小型城商行在容器化选型时应该尽量选择具备丰富落地及咨询经验的企业和产品，选择具备对多容器及基础设施、微服务、DevOps等领域都有企业级支持能力的公司合作。
实施步骤上建议初期以容器基础设施建设结合DevOps工具链建设，让中小城商行能快速享受云原生带来的收益。同时选择具备容器及基础设施、微服务、DevOps三大领域都具备支持能力的产品和公司，能够有效减少后期运维上由于兼容性问题带来的运维成本，这一点适合技术人员相对较少的中小城商行。
在实施容器云架构改造过程中可以优先选择结构简单的轻量型单体应用，例如一些典型的Java应用和自开发单体应用。另外合适优先改造的还有微服务架构的应用，例如spring cloud 等微服务架构的应用进行迁移，这样能够快速平滑地把现有应用资源向容器化环境迁移并体验云原生带来好处。
目前灵雀云产品具备全栈容器云能力以及多家银行的使用案例，可以进行了解。

**嘉宾回复：**微服务架构选型  
常见的微服务架构有SpringCloud、Dobbo、GRPC、Isito等。  
SpringCloud，主要是基于JAVA语言的架构，是最常见也是目前使用最多的微服务架构  
Dobbo，是阿里提供的架构，也是Java语言，可以将其与SC等同为一类架构，当然两者还是有明显的区别。  
GRPC，主要是针对应用开发中，同时涉及到多种开发语言时，选择GRPC会比较好些。  
Isito，就是常说的service mesh，号称微服务2.0，是一种全新的架构。sidecar是其明显的特征。最近两年比较火爆，比较新，还属于技术爬坡期。  
如果，您是技术栈基本为Java，可以考虑SC和Dobbo，SC发展实际比较长，体系十分成熟，了解人比较多，上手相对容易些。

容器云推广：  
一般的推广策略是试点应用--->部分核心应用--->全面推广  
试点阶段，一般从新建应用、计划重构应用入手。应用一般选择不那么重要的业务或者是管理类应用，进行试点。

## 7、高并发场景下容器的自动扩缩容场景如何落地？

**嘉宾回复：杜东明 解决方案架构师 , 灵雀云Alauda**
一般可以在高并发场景下使用 k8s 的Horizontal。
Pod Autoscaling进行自动扩缩容, 通过HPA功能，可以实现容器的自动弹性扩缩容功能。对于K8s集群来说，在高并发场景下HPA可以实现多种纬度的自动化功能，例如当工作负载上升的时候，可以创建新的实例副本来保证业务系统稳定运行，当工作负载并发下降的时候，可以销毁副本实例来减少资源消耗。当前的自动伸缩的指标包括：CPU，内存，并发数，网络传输等。

**嘉宾回复：rechen 云计算架构师 , 招商银行**
1、先做好容器云平台配套的监控、日志的建设。  
2、其次建设自动扩缩容的自动化能力。  
3、聚焦于场景驱动，从某个业务应用开始逐步试点和推广，运维团队逐步积累到各个场景下业务应用的扩缩容的触发指标、阀值和评估 扩缩容成效。

## 8、相比于虚拟机，容器的监控、运维有何优劣势？

**嘉宾回复：hsuyuan 资深架构师 , 英特尔云社区**
我的观点，从监控和运维角度看，虚拟机和容器相比更多是不同场景下的不同的特点。
容器的轻量化使得运维更加灵活高效，更方便应用自动化来提升运维效率。同样，轻量化的容器也带来了监控的复杂度，特别是大量容器运行的平台如何排错和根因分析。在监控这个领域，除了目前比较热门的纯软件层全链路监控以及混沌工程，我认为更应该结合硬件的监控和检测实现端到端的监控和测试，以提升平台的稳定性和效能。

**嘉宾回复：杜东明 解决方案架构师 , 灵雀云Alauda**
容器相比较传统运维它的优势在于：更快速部署和交付，对于应用系统的部署可以极大地节省时间成本和人力成本；更标准化交付物：容器的标准交付物为镜像，包含应用程序和依赖环境，一次构建多次使用，大大简化了应用交付模式：更高效的资源利用，容器不需要虚拟机额外的管理程序，依赖内核运行，在运维资源开销上要低的多。更加敏捷的迁移和扩展，容器可以跨操作系统、跨环境运行，实现无缝迁移的效果；

由于容器是黑盒运行，在运维中容器问题的诊断比较复杂；由于容器运行的密度比虚拟机要大，需要面对的运维实体和对象数量庞大；由于容器的自身特性，容器的创建、销毁等生命周期过程，各类运维数据的采集是个挑战。另外容器启动后，监控系统怎么发现，同时需要对其做哪些数据采集，这些问题都是容器监控自动化过程需要解决的。

# 四、本场交流活动共识总结
（1）当前中小城商行在云计算建设和技术引入时，技术路线宜走基于以Kubernetes为核心的云原生路线；建设目标应该建设以应用为中心，具备全栈能力的容器云平台；产品宜选择具备容器及基础设施、微服务、DevOps三大领域的全栈能力；供应商需有丰富的成功落地实施案例及咨询经验。实施策略宜注重团队建设，譬如通过先建设容器云的测试环境，同时结合DevOps工具链建设，以磨炼技术和队伍，再往生产环境慢慢部署；推广策略是逐步迁移，小步慢走，路径为试点应用--->部分核心应用--->全面推广；试点阶段，一般从新建应用、计划重构应用入手，先一般选择不那么重要的业务或者是管理类应用进行试点。

（2）为满足银行高并发交易系统的高性能和高可靠性需求，容器云平台需要全面且系统性地进行安全加固，包括：基础设施层、容器云平台层（注：集群隔离、租户安全、用户隔离、网络ACL、审计、DevSecOps、NetworkPolicy、平台高可用、HTTPS接入安全）、容器和应用层安全（注：镜像安全、容器运行时安全、容器网络安全、权限安全）、数据层安全等；在承载面向互联网的业务应用，还需叠加前端安全设备的WAF、DDos、防Sql注入等能力。安全加固还需要注重对平台、服务和资源的全面监控，和关注资源隔离的安全性问题。

（3）容器云平台的数据持久化存储，宜依据行内基础设施建设的实际情况，选择支持Kubernetes的 CSI存储插件接口的商用级存储产品，结合容器云平台承载的不同工作负载进行部署规划。存储产品采购时，在做硬件规格配置，可以评估Intel 的傲腾产品：傲腾持久内存和傲腾固态盘 ，Intel的傲腾产品是在高速内存设备和延迟低几个数量级的传统的 SSD 设备加入了新的存储层，可大幅提升数据持久化存储的效率和可靠性。

容器云平台 DevOps

著作权归作者所有

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

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

银行高并发交易类场景下容器云架构如何保障高性能、高可靠性总结

添加新评论0 条评论

作者其他文章

相关文章

相关问题

相关资料