一、容器云场景下的数据处理方案该如何选型和建设

1.容器日志的存储与备份有哪些好的方式，目前在大型银行落地较多的方案是怎样的？

mlf 项目经理 , 光大科技有限公司

一般大型银行金融类公司，都会有日志管理平台这一部分的内容相关的建设，目前业内较为流行的应该是ELK吧，做日志的接入、处理、可视化等。当然也有一些graylog等产品。

谷雪峥 产品总监 , 赞同科技股份有限公司

您好，目前常见日志收集方案有以下三种

1.每个应用的镜像中都集成日志收集组件，这种方式的优点是部署时无需特殊的配置就可以使用，但部署便捷的同时就带来了升级与维护等方面的问题，且存在对应用的侵入性问题。

2.单独创建一个日志收集代理容器，跟应用容器一起运行在同一个容器组中，这种方式优点时扩展性很强，方便维护和升级，缺点也较为明显，在部署时需要单独的配置，这样就会显得略加繁琐

3.将所有的容器组的日志都挂载到宿主机上，每台主机上单独起一个日志收集容器，着这种方式的优点时性能最高，同时管理起来也时最方便的。缺点是需要统一的日志收集规则、目录和输出方式等也有限制，并且缺乏隔离性等问题。 通过上述的三种方案都可以达到存储，优缺点也显而易见。 对于我们赞同渠道云平台来说，对于目前常见的方案带来了如下优化： 1.日志容器与业务容器在同一容器组中，无需额外配置就可直接使用，带来了极强的便捷性 2.提供常见的配置文件供您选择，并且支持定制化收集策略 3.将收集数据发送到日志中心进行多副本形式的持久化保存 4.对重要日志提供挂载远程盘方式存储，且支持异地容灾机制 我们长久以来与各大型银行进行密切合作，这种解决方案在大型银行中也是最为常见的。

jerryhuhu 资深架构师 ,红帽企业级开源解决方案中心

一般来讲，基于K8S的容器编排管理解决方案中，日志生成和存储、查询都采用EFK解决方案，包括红帽的Openshift，默认也是使用此方案；当然，大型银行一般有自己的日志存储和备份系统，所以实践中也把这些日志转储到已有的日志管理平台，然后再通过该平台进行查询、分析、备份。

2. 银行渠道类业务应用大多还是有状态的，对于有状态应用的数据存储，有哪些高可用、高性能的落地实践？

SongYaQiang 系统架构师 , 赞同科技

确实如您所指出的，目前行业内渠道应用的建设中，几乎都为有状态应用。对于您所提出的落地实践，我们的建议是结合具体的场景进行合理化的评估。 首先，渠道云平台这边全部遵循云原生CSI相关规范，提供多种类型的存储方案，包括如文件存储、块存储。同时还可以对接红帽主导的优秀存储方案GlusterFS和ceph等，以此两种存储方案为例，都可以做到对业务容器数据的高可用保障。除此之外，渠道云平台也可以直接对接行内的商业版NAS存储，由平台来完成对商业NAS存储的创建和挂载，存储的高可用性交由商业化NAS进行保障。 虽然我们有诸多存储方案，但在应用渠道建设中，我们仍然建议尽可能减低存储使用率，这样我们可以最大化的利用好容器高弹性、高性能等方面的优势。以赞同渠道建设方案为例，赞同已经将绝大多数的状态数据迁移到分布式数据库中，如redis等，这样我们可以尽可能的减少状态数据对存储的依赖性，并且将平台建设尽可能的轻量化。 对于少数可再生的状态数据类型，我们推荐使用本地存储的方式，将容器所在节点机的存储目录提供给容器进行使用，这样可以轻量化整体架构方案，并且对数据也更易维护

jerryhuhu 资深架构师 ,红帽企业级开源解决方案中心

有状态业务也可进行相应的容器化部署，而如何进行高可用、高性能的数据存储落地实践，一般来讲可以进行容器挂载分布式存储，例如Ceph，或各种其它存储解决方案；而如何解决高性能的数据访问，包括可对应用进行数据缓存，如Redis集群，从而保障数据的高可用、高性能存储。

二、 行业内的安全和业务连续性问题一直是关注焦点，如何在容器环境下更好的做到数据安全，业务系统上容器其安全性和连续性又该如何保障？

1. 容器安全与虚拟化安全的本质区别有哪些？在前期设计以及后期运维时的侧重点是什么？

容器安全与虚拟化安全的本质区别有哪些？在前期设计以及后期运维时的侧重点是什么？

jerryhuhu资深架构师 ,红帽企业级开源解决方案中心

容器技术的特性为较长的镜像生命周期、较短的容器实例生命周期，而容器本质是进行进程和资源隔离的；基于这些特性，相比虚拟化时代需要解决的安全问题，提出了更多新的安全挑战，包括：

应用构建性挑战：快速迭代的云原生应用和镜像生成，加大了引入漏洞/bug，病毒和不安全API，secrets等机会，公开热门镜像有大量漏洞。 运行动态性挑战：大量容器实例、短生命周期，安全无法监控，出现入侵时，具有潜伏性，入侵程序可以在被攻克的容器节点上，躲在暗处不断监控和获取其上应用的信息 资源共享性挑战：多租户共享主机Kernel，黑客利用一些漏洞或配置问题，从容器环境中跳出而获得宿主机权限，导致宿主机沦陷，出现安全逃逸问题。 部署多样性挑战：容器部署方式多样，底层环境复杂、混合云部署，带来数据，网络隔离等新问题

容器安全管理分为三步，包括前期设计的预防检查，后期运维的监控探测和响应保护，具体可参考实现如下重点： 预防检查: 安全左移、DevSecOps协作、合规基线检查、容器漏洞分析、应用配置分析、安全策略管理 监控探测: 定制安全策略、告警上下文、运行时行为分析、攻击可视化、威胁可视化、网络可视化 响应保护: 合规报告评估、合规基线修复、攻击链分析、资产可视化等

mlf项目经理 , 光大科技有限公司

传统虚拟化技术与Docker容器技术在运行时的安全性差异主要体现在隔离性方面，包括进程隔离、文件系统隔离、设备隔离、进程间通信隔离、网络隔离、资源限制等。 在Docker容器环境中，由于各容器共享操作系统内核，而容器仅为运行在宿主机上的若干进程，其安全性特别是隔离性与传统虚拟机相比在理论上与实际上都存在一定的差距。

2. 在信创环境下，现在平台支持什么架构方式？

谷雪峥产品总监 , 赞同科技股份有限公司

您好，目前渠道云平台是满足6+2信创要求的。 容器云平台和服务端支持以海光，兆芯为代表的x86芯片架构，同时也支持飞腾，鲲鹏为代表的arm芯片架构，龙芯为代表的MIPS芯片架构。 渠道平台客户端同样支持以海光，兆芯为代表的x86芯片架构，也支持飞腾，鲲鹏为代表的arm芯片架构，龙芯为代表的MIPS芯片架构。

jerryhuhu**资深架构师 ,红帽企业级开源解决方案中心

目前渠道类业务底层的容器管理调度平台Openshift主要支持X86架构部署，而目前已经有基于ARM方式版本待发布。

mlf项目经理 , 光大科技有限公司

目前我国的信创领域的CPU市场主要以X86架构为主，长期被Inter和AMD长期垄断，国内主流的芯片主要以ARM架构和X86架构为主，同时还有MIPS和ALPHA架构。主流的芯片产品包括鲲鹏、飞腾、海光、兆芯、龙芯和申威等。由于MIPS和ALPHA架构生态不完善（主要是软件兼容性），我们重点看好生态完善的X86和具备潜力的ARM架构产品：鲲鹏（华为）、海光（中科曙光）、飞腾（中国长城）、龙芯。目前渠道云平台主要以X86架构为主。

3. 容器云相关制度和标准的建立？

随着容器云的发展，在金融行业中，相关制度的建立与批准的统一，包括统一的管理，接口、开发、运维平台的建设等

mlf项目经理 , 光大科技有限公司

关于容器云建设，这个在传统金融行业也刚刚起步，在这方面的标准和制度每个公司的认知是不一的，适合自己的才最好的。。像DevOps理念09年就提出了，但是他确实没有一个明确的定义和标准（四大龙头IT企业对其看定义思考都不一呢），但是其最佳实践可以参考信通院的DevOps能力成熟度模型结合实际应用场景。。容器云的标准和实践是否也可以这样理解呢。仅供参考

SongYaQiang系统架构师 , 赞同科技

您好，我说一下个人想法，我认为目前其实没有真正严格意义上的标准化统一，更多的是在满足一定的设计原则后可以为我们提供更多的便捷性、安全性和稳定性。我认为可以从如下几个设计原则进行思考，您也可以进行参考： 1. 高可用原则：核心组件进行高可用设计，同时考虑在不可抗力情况下的容灾机制，保障容器应用的高度可用性 2. 成熟稳定性原则：在进行技术选型时，选择成熟、稳定的技术，在满足功能需求的前提下，确保平台整体稳定性 3. 技术社区活跃：选择的技术社区具备一定的活跃性，具有稳定的版本更新迭代、问题的更新和处理 4. 兼容性原则：使用标准化的技术兼容市面上主流的软件和工具，同时提供开放性的API接口，可以与客户已采购或自建的系统进行集成、扩展、替换 5. 安全性原则：应该进行全方位的安全防护，对各个层面所涉及到的点和面都要采用完善的安全防护机制，确保平台和数据信息的安全性、私密性。 6. 完善的生态体系：应具备完善的生态体系，提供诸如注册发现、安全认证、权限控制、日志、监控告警、服务治理（熔断限流、链路追踪等）、多种更新策略等能力，最大程度的在金融行业支持应用业务系统需求

jerryhuhu资深架构师 ,红帽企业级开源解决方案中心

我认为容器云相关制度和标准的建立是一个逐步且长期的过程，包括对现有的运维、开发的过程的改变，每个企业都有不同的情况，需要根据自己实际需要，结合有容器云建设经验外部顾问方式，一起构建合适自己的容器云相关制度和标准。

4. 业务系统上容器其安全性如何保障？

随着业务系统越来越多往容器平台上迁移，其安全运维这块如何保障 1，容器云平台自身的安全方面？ 2，人员，权限，流程类的安全设定与管理？ 3，相关辅助安全工具有哪些？和传统环境的差别在哪？

jerryhuhu资深架构师 ,红帽企业级开源解决方案中心

可以采用多种方式对业务系统上容器进行安全保障，包括：

Linux 宿主机安全(SELinux+/通用标准认证/提供 FIPS 模式) 认证与授权(内嵌 OAuth Server/支持多种身份认证，包括 AD/LDAP /多级访问控制） Secret 和证书管理（镜像安全、安全扫描） 部署策略(集成审计、日志和监控) 安全策略（SCC/非Root用户运行容器/资源访问的控制） 网络隔离( 入口 / 出口控制,网络策略细粒度配置)

具体可参考容器安全防护的十个层级： https://www.redhat.com/cms/managed-files/cl-container-security-openshift-cloud-devops-tech-detail-f7530kc-201705-a4-zh.pdf

5. 渠道业务连续性保障是否有单点故障风险？

关于业务连续性保障，平台主要有系统级和应用级两个维度，对应用运行态的整个生命周期进行管控，包括自动的数据与应用的故障迁移和恢复、集群的容灾、数据的多副本机制、区域形式的调度策略，及自注册自恢复、故障转移、优雅退出、弹性伸缩等几个方面。对于这些管控措施，平台采取这些管控措施的决策机制和调度策略，是怎样实现的，有哪些物理机和应用软件，是否存在单点故障风险？

jerryhuhu资深架构师 ,红帽企业级开源解决方案中心

基于高可用用性的架构部署，可以消除渠道业务连续性保障是否有单点故障风险。包括，在部署上采用双中心多活部署，或者采用混合云方式部署，在每个数据中心上有多个工作节点，由此来消除架构上的单点故障，保障业务的连续性，此类架构经过了多家大中型银行的验证。

6. 目前数据安全以及成为各行各业关注焦点，如何在容器环境下更好的做到数据安全？

jerryhuhu资深架构师 ,红帽企业级开源解决方案中心

容器环境下的数据安全越来越成为业界关注的焦点，因为容器环境带来应用部署的多样性挑战，如容器部署方式多样，底层环境复杂、混合云部署，带来数据，网络隔离等新问题。要做好容器安全实施，关键要做好以下几点：

应用隔离：解决应用系统没有天然的物理机或虚拟机的隔离边界 网络隔离：不同项目和服务的数据访问是隔离的,POD间也能进行策略隔离； 注入防范：传统的环境更多的侧重于运行时，容器环境下从镜像构建开始，大量不同来源的镜像文件，包括依赖的库，语言等，做好容器镜像的注入防范非常重要； 防篡改：防止底层操作系统、已经被节点缓存的镜像文件被篡改 最小化运行权限：本身依然需要的root权限的Docker容器不建议使用，而是用符合CRI标准的容器； 用户权限管理：从构建、测试到部署的整个全过程，都需要控制好工具与部署环境，运行实例的访问权限 链路安全：确保各个通讯环节所使用证书的有效性，避免用户名密码泄漏到配置文件中 安全审计：安全相关的信息散落在yaml文件和etcd中，需要统一视图并进行审计

三、 数字金融趋势下，银行渠道类业务系统如何进行容器化改造？如何基于渠道云完成渠道业务建设？

1. 渠道容器云管理平台应用软件开发部署方式?

从架构图上看，渠道容器云管理平台应该是居于中间层，我的理解是开发部署渠道服务端应用软件的，能开发部署渠道客户端应用软件吗？也就是客户端适配硬件的部分也在这里开发部署吗？

谷雪峥产品总监 , 赞同科技股份有限公司

您好，是的，图中确实没有明确表述出来。 渠道应用的客户端也是可以开发的。 目前赞同渠道客户端和服务端的发布更新统一是交由服务端进行控制，比如开发人员在完成相关任务开发之后，会进入平台cicd流程，客户端执行逻辑前会先请求最新资源，服务端将客户端的更新数据进行下发，客户端完成相关的更新动作。

2. 容器云的改造？

在对容器云的改造或基础设备迁移中：
1、 如何更好利用基础设备，保障系统的稳定运行？
2、 原有数据的迁移和存储。
3、 数据的安全存储

mlf项目经理 , 光大科技有限公司

我认为可以从以下三方面来规划应用上云，以此保障系统的稳定性和数据的安全性等问题： 1. 上云前准备: 可行性分析，上云方式（私有、公有or混合云），按需选择云服务（IASSSASSPASS），确定云厂商，制定上云方案。 2. 上云实施 部署，应用上云（直接上？改造迁移？重构？），上云后测试（功能、性能、安全性测试等），上云后效果评估 3.上云后的管理 监控运维，风险管理。

jerryhuhu资深架构师 ,红帽企业级开源解决方案中心

容器云改造首先从规划上要明确哪些业务需要上云，哪些模块适合上容器云，以及新建的应用是否是基于云原生； 容器云的平台构建可以基于原来的开发平台，如X86服务器，作为工作节点加入平台，如此可以更好地利用原来基础设施； 数据的迁移和存储需要考虑数据切片、数据分区等符合微服务化应用建设的数据分布原则，让数据进行有效的分布，实现分布式数据存储。

3.容器云解决渠道业务的服务发布难？

针对渠道业务的服务发布难 容器云在版本控制上有一定优势，还有哪些针对发布困难的好方法

mlf项目经理 , 光大科技有限公司

我理解发布困难原因可能有几方面：1.人工操作过多（手动去服务器上传包发布？），端到端交付过程流程割裂。2.平台不支持一些发布策略，风险不可控。3.投产出问题定位难，回滚繁琐等问题。。。 此处可以借鉴光大这边的智能运维这块的二十四小时无人值守发布平台建设思路。 二十四小时无人值守发布平台灵活的支持各种常见发布模式，项目组可根据需求制定发布规则，选择合适的发布模式，将机器稳健的自动部署到测试或者生产机器上。支持单组服务器发布和多组服务器发布，并支持发布中通过负载均衡切换流量。发布平台智能发布平台对发布的机器，有动态的链路跟踪，可看到发布中的机器的进展以及相关的日志。智能发布平台对各种发布模式，均有健全的回滚方案，支持一键回滚。 无人值守发布平台对接devops平台，智能监控平台，实现需求，研发，测试，构建，发布，监控，度量的完整闭环。 仅供参考，业内也很多特别优秀的发布平台相关的产品。

谷雪峥产品总监 , 赞同科技股份有限公司

您好，假如把应用服务理解成行内资产的话，一个应用资产应该包括它的软件包和运行态配置两部分组成，这样我们的应用资产就可以持续积累、并随时供我们使用，所以运行态的配置也要看做资产管理的一部分。 针对您的问题，我们可以分解一下开发测试场景和生产场景来描述 首先，在开发测试场景下，为最大化提升交付效率，我们建议选择合理化的DevOps工具来协助。 以赞同渠道云为例，可以做到从代码层面，到单元测试，编译、打包、部署一站式的流程化处理能力，赞同渠道云深度整合了赞同的渠道业务，对于开发人员，只需要像传统开发方式一样，提交一下代码，后续的流程全部交由渠道云DevOps工具进行实现。 同时，平台具备对应用面向于不同环境的迭代能力，如我们在开发环境完成了相关测试之后，由流程工具链自动同步到测试环境中。 但对于发布生产环境来说，由于环境网络隔离性，安全性的要求，我们是建议采用由人员进行操作的方式，可以讲容器化后的产品理解成资产包，以资产包的视角对应用进行管理。 目前有一些非常优秀的开源项目也可以满足您的诉求，比如云原生社区的helm和红帽所主导的非常优秀的开源软件Operator等

4. 渠道容器云管理平台是怎么与具体业务处理逻辑对接的？

看完白皮书和DEMO视频，我的理解是渠道容器云管理平台是一个可以在其上进行开发的通用平台，因为各家金融机构的组织架构和业务流程是有差别的，这个平台是怎么与具体业务处理逻辑对接的？

谷雪峥产品总监 , 赞同科技股份有限公司

您好，确实如您所说，我们在实际的交付过程中确实存在诸多差别。 首先在组织架构上的权限控制上，平台是支持定制化和组织结构导入的，平台的权限控制是基于RBAC(基于角色的权限控制)进行实现的，通过定制化的方式，可以尽可能的保障金融机构的组织架构。 在业务流程的管理方面，在实际的落地过程中，通常需要与行内的现有的业务发布平台进行对接。此部分需要赞同和行内的老师一同定制化相关需求内容。 在业务的开发方面，渠道云平台是赞同容器平台与赞同渠道业务平台(AB)深度整合方案，渠道应用业务已经完成了微服务化改造，无论服务端，还是客户端，都可以直接通过平台的DevOps工具链对应用的交付、发布、上线进行管控。

5. 赞同科技ACaaS的渠道容器云平台方案能核心解决银行渠道类业务容器化哪些问题？

赞同科技ACaaS的渠道容器云平台方案能核心解决银行渠道类业务容器化哪些问题？相比其他的平台有哪些优势？

谷雪峥 产品总监 , 赞同科技股份有限公司

您好，我这边简要的回答一下您的问题 渠道容器云平台在具备传统容器云平台能力的同时，专门在渠道领域进行一些定制化场景。 首先整合了赞同渠道业务平台(AB),在建设渠道应用时，无论服务端，还是客户端，都可以直接通过平台的DevOps工具链对应用的交付、发布、上线进行管控 其次，渠道容器云平台为应用在灰度发布上，提供了开箱即用的实现手段，平台预设了如网点、柜员、法人等维度的灰度发布策略，系统维护层面可以极大降低运维的成本，有效提升交付效率。 最后，平台在保障业务连续性上也进行了额外的保障，平台主要有系统级和应用级两个维度，对应用运行态的整个生命周期进行管控，包括自动的数据与应用的故障迁移和恢复、集群的容灾、数据的多副本机制、区域形式的调度策略，及自注册自恢复、故障转移、优雅退出、弹性伸缩等几个方面。 渠道云平台是赞同容器平台与赞同渠道业务平台(AB)深度整合方案，渠道平台完成微服务化改造，具备完善的链路追踪能力，可以高效快速针对链路中出现的问题进行解决。

6. 渠道类业务应用（固定IP场景）如何快速发布并提供服务？

渠道类业务应用（固定IP场景）的快速发布，往往受制于负载均衡设备和网络策略制约，除了预先配置负载均衡及网络策略外，有哪些好的落地实践能够自动化实现容器应用快速发布上线的需求？

谷雪峥 产品总监 , 赞同科技股份有限公司

您好，针对您的问题，我们可以分解为开发测试场景和生产场景来描述 首先，在开发测试场景下，我们期望于尽可能的提升交付效率，我们建议选择合理化的DevOps工具来协助。 以赞同渠道云为例，所提供的DevOps可以做到从代码层面，到单元测试，编译、打包、部署一站式的流程化处理能力，可以打通从代码到运行态容器的生命周期管理，并且在渠道的开发方面，赞同渠道云整合了赞同的渠道业务，对于开发人员，只需要像传统开发方式一样，提交代码，后续的流程全部交由渠道云DevOps工具进行实现。 同时，平台也具备对应用面向于不同环境的迭代能力，如我们在开发环境完成了相关测试之后，由流程工具链自动同步到测试环境中。 但对于发布生产环境来说，由于环境网络隔离性，安全性的要求，我们是建议以人工的方式进行操作。可以将容器化后的产品理解成资产包，应用资产包涵盖了镜像包和运行态配置文件等内容，以资产包的视角对应用进行管理。赞同渠道云这边，可以通过平台导出资产包，在生产环境中，由工程师进行导入即可。 同样，目前有一些非常优秀的开源项目也可以满足您的诉求，比如云原生社区的helm和红帽所主导的非常优秀的开源软件Operator等

7. 能介绍线下渠道业务系统容器化改造的落地案例的具体方案？

jerryhuhu 资深架构师 ,红帽企业级开源解决方案中心

有多家银行有线下渠道类业务改造方案，包括渠道类业务容器化改造，例如有城商行进行承载新手机银行、互联网业务、同时对接各种线下渠道类业务的业务改造，也将会作为微服务体系的应用系统的统一运行管理平台，承载更多的敏态应用。如可参考： https://www.cebnet.com.cn/20200422/102655616.html

8. OpenShift在银行线下或线上渠道业务系统有落地实际案例？

jerryhuhu资深架构师 ,红帽企业级开源解决方案中心

有许多客户使用Openshift,特别是金融行业的客户，目前银行客户选择Openshift进行容器化的业务主要为渠道类业务、互联网金融、2C类业务接入等。OpenShift有近3000家客户使用，在国内也有上百家客户使用，其中有许多金融客户，如招商银行、兴业银行、通商银行等，他们的许多渠道业务都部署在Openshift上。

四、 针对于目前流行的IT技术，未来的行业内技术的选型该如何判断，新兴技术架构的方案该如何选择?

1. 渠道建设的选型依据：追求潮流技术or满足业务需求即可？

在技术多样化的潮流下，渠道品台建设是应在最低成本消耗下以满足业务需求为建设目标还是应尽可能引入分布式、微服务、敏捷开发等潮流技术

mlf项目经理 , 光大科技有限公司

赞同谷老师见解，不要盲目追求新技术，要结合业务需求方的实际背景。可以做一些小范围的试点，循序而渐进。 比如之前我们在建设某行的DevOps平台时，我们初期建设时，流水线采用的jenkins，而随着技术的发展，容器和k8s技术的不断演进和繁荣，近期我们也遇到了要不要换个架构的问题，是否流水线要采用云原生的解决方案（比如tekton），都知道云原生技术比较好，但是业务背景、应用架构转型对于这种历史性很重的企业比较难，不是一朝一夕能建设好的。所以目前主要思路是流水线既支持云原生、又支持jenkins这种，慢慢过渡，引导用户做云原生转型。

谷雪峥产品总监 , 赞同科技股份有限公司

您好，我建议您还是以解决实际问题为出发点来进行考虑这件事。 若目前现有架构足够支持业务侧要求，并且运维、可用性等方面足够完善的，建议优先以最低成本消耗为原则。 若考虑后续中长期的一个IT统一化治理，并在以后应用的拓展性更易控制的话，还是建议引入一些更加自动化、灵活技术手段。 我们建议您可以选择小规模的试点，因为分布式、容器云、微服务架构并不一定更适合每一个银行架构现状，您可以在实际使用过程中，可以更清晰的感受架构之间的差异，也更加有助于您的选择。

2. 银行渠道业务对边缘计算容器有需求

渠道业务容器云，对性能要求不高，2-3台服务器做成云端边缘计算容器云能快速迭代适应变化，更新替换成本低 专家有好的搭建建议吗

谷雪峥 产品总监 , 赞同科技股份有限公司

我先尝试 解答 一下 ， 您可以再详细的介绍一下吗 首先 针对您说的2-3台服务器来使用的话，您需要额外注意网络方面的影响，首先保障网络传统的稳定和效率，我不清楚您的容器云建设方式，假如以云原生中主流的网络方案来说(calico、flannel)，通常需要对网络规则配置上，编写一些额外的路由规则，否则处于不同局域网或网段的集群是不能接入到统一的容器云环境中的。 其次是节点状态的检查能力上，以k8s为例，可以优先考虑较为轻量化的节点指标检测工具，可以考虑node-exporter，若存在不满足的点，可以在此基础上进行扩展，不建议将监控组件做的过重。 最后，您在设计中还要有一个对于应用无感知的节点更新机制，至少应该满足在边缘节点更换之后，应用程序的交互，程序的运行，自动拉起机制等是无感知的。这部分可能需要借助一些云原生集群管理的工具来完成。

3. 容器平台是否需要代码质量管理工具？

容器平台是否需要代码质量管理工具，帮助评判研发代码质量，留存历史报告供查阅？

mlf 项目经理 , 光大科技有限公司

您好，代码质量管理工具是在软件开发测试阶段所用到的工具。针对您的提问，容器平台是否需要代码质量管理工具？我理解的是咱们首先的需要明确容器云平台的产品定位，再去思考容器云平台是否需要建设代码质量管理工具。 从租户视角容器云平台更多是定位于一个应用管理和运营的平台,它只是应用生命周期管理的一部分,应用的开发尚未纳入进来。我们把应用的开发阶段和流程分离，作为一个持续集成的组件，以镜像仓库为媒介，完成持续集成和持续部署的衔接,从而使持续集成-持续部署-持续发布-持续监控-持续反馈-持续改进流程形成闭环DevOps链路。 容器云平台的设计直接决定着其建设的能力，其融合微服务架构和DevOps方法论,来支持业务服务和业务应用的完整生命周期管理和治理。而需求、开发、测试这一部分应该在DevOps平台统一管理的， 所以我的看法是代码质量管理工具应建设在DevOps平台一侧更为合适，并且是不可或缺的一部分。

jerryhuhu 资深架构师 ,红帽企 业级开源解 决方案中心

容器平台本身不需要代码质量管理工具，但是在构建容器化的应用过程中，一般采用CI/CD增强整体自动化，例如从代码check in到容器化部署的全流程自动化；而在这个过程中，涉及到对代码质量的检查，例如现在主流很多实用SonarQube进行代码质量管理。 因此可以把代码质量管理当做CI/CD的一个环节，使用相应的代码管理工具，并用CI/CD工具（如Tekton/Jenkins等）把流程自动化串接起来。

谷雪峥 产品总监 , 赞同科技股份有限公司

您好，非常同意上面光大老师的看法~ 目前主流的容器云平台厂商都会内置于类似的devops工具，里面也会携带代码质量管理的相关手段，这可能会给您的判断带来一定的歧义。但我认为这并不是必须要具备的功能。 我也认为质量管理工具更应建设在DevOps平台一侧，您可以尝试通过devops工具将代码到容器的过程进行打通，如设置相关的质量阀，满足预期的结果后，可以触发我们镜像打包的流程，以此来控制代码的质量问题。

4. 渠道平台是否作为中台建设的前置？

中小城商行在目前普遍进行中台建设的大背景下，是否有必要进行渠道整合作为中台的前置纳入整体技术架构中

谷雪峥 产品总监 , 赞同科技股份有限公司

您好，银行中台建设是一个非常庞大的系统架构演进工程，银行的渠道系统是银行非常关键的业务系统的组成部分，中台建设的整体规划一定要考虑对渠道系统能力的总体支撑，业内在中台对渠道系统能力支撑的建设思路一般有两种：

1、在银行中台中规划“渠道中台”

“渠道中台”顾名思义也是中台能力的一部分，但会突出渠道的关键属性，例如：渠道的统一接入（准入）、渠道服务的整合、渠道的跨端协同、渠道管理等等，技术上整体的技术架构、规范、服务治理框架、部署策略都应跟银行中台的整体架构一致，实现银行中台的建设的统一技术规范和运维标准，架构上从技术规则与标准和中台的其他能力中心打通，实现一体化输出；

2、“渠道平台”作为中台的前置

因为渠道服务与传统业务系统的服务还有很多差别，尤其是在流程管控、跨端协同、客户端控制等方面有很多特性，很多中台采用的通用为服务框架很难统一纳管，另外很多银行在架构演进的规划中往往想分批建设，例如：先做后台能力中心的规划，后做渠道系统的对接，在这样的架构下，渠道平台作为银行中台的前置就非常的必要合理，可以非常灵活的保留渠道特性等同时也以松耦合的方式与中台能力中心对接，稳健的完成银行整体的IT架构演进和业务创新支撑；

以上两种模式各有特点，没有好坏，银行可以根据自身客观情况规划中台和渠道平台的建设思路

jerryhuhu资深架构师 ,红帽企业级开源解决方案中心

我认为渠道业务平台可以在技术上可以共享中台建设内容，渠道平台建好后，里面的技术、业务组件也可以作为中台建设的基础，避免重复建设。

mlf 项目经理 , 光大科技有限公司

我的理解是，渠道平台不管是作为中台的前置还是直接在中台中规划建设都可以，两种建设思路，具体得看您在你们公司背景下对渠道平台的定位与整体的建设规划。再者在具体建设中要注意能力复用，避免重复建设。

五、达成的共识

1) 信创大环境上，渠道容器云平台支持信创 6+2 要求，支持的 国内主流的芯片 ， 国内主流的芯片主要以ARM架构和X86架构为主 。

2) 银行 渠道类业务应用大多还是有状态的，对于有状态应用的数据存储 也 可进行相应的容器化部署，而如何进行高可用、高性能的数据存储落地实践，一般来讲可以进行容器挂载分布式存储，例如Ceph，或各种其它存储解决方案；而如何解决高性能的数据访问，包括可对应用进行数据缓存，如Redis集群，从而保障数据的高可用、高性能存储

3) 在技术多样化的潮流下，渠道品台建设 的技术选型上， 要结合业务需求方的实际背景。可以做一些小范围的试点，循序而渐进 ， 以解决实际问题为出发点来进行考虑 ， devops 与容器云在不同金融场景中的应用存在差异。

4) 容器云相关制度和标准的建立 是一个逐步且长期的过程 ， 包括对现有的运维、开发的过程的改变，每个企业都有不同的情况，需要根据自己实际需要，结合有容器云建设经验外部顾问方式，一起构建合适自己的容器云相关制度和标准。

5) 容器日志的存储与备份有哪些好的方式 的选择上，应评估日志规模和建设目标的基础上合理选择日志方案，目前较为流程的方案是 EFK 方案，结合上合理化的存储方案完成对日志的全生命周期管理。