金融行业在互联网时代的转型升级离不开金融科技的支撑。在移动互联、人工智能、区块链、物联网等前沿科技的飞速发展下，城商行将逐步推进战略创新，通过业务和技术来同步驱动战略转型，增强创新变革能力，推动商业创新，建设更具竞争力的金融品牌。

随着城商行科技创新的不断深化，越来越多的城商行有意愿开发微服务架构去承载互联网类型业务，但现有平台很难满足持续集成、持续测试、持续交付等需求，同时也较难适应互联网应用的大促、秒杀等业务特点，制约了业务的发展。因此需要采用成熟且符合业务发展需求的技术框架来搭建容器和微服务架构，服务于城商行，在云原生应用方面积累技术经验，深化探索新时代金融业信息系统和IT架构的移动化、数字化和智能化实践。

本场交流总结如下：

1、 容器云平台如何助力城商行渠道类业务应用微服务化改造？

回复：sf7071 软件开发工程师 , 某大型银行
容器与微服务可以说是最佳组合，容器有轻量化、标准化的特点，微服务有单一职责、技术独立的特点，两者结合可以形成合力。简单总结有如下两方面助力作用：
（1）有利于形成统一的轻量化、标准化交付体系，借助容器云平台的服务自动发现、自动编排调度、故障自愈等机制，降低运维复杂度；
（2）可以提高基础资源利用率，降低成本，容器云平台将底层物理资源进行统一抽象整合，形成资源池，由平台统一调度，按需供给，弹性伸缩，避免资源独占，可有效提高资源效能，如传统模式下一个虚拟机一般就能够部署几个微服务程序，而在容器云平台中，一个虚拟机计算节点可承载上千个微服务容器。

回复：lzj7618937 质控经理 , cib
我觉得这个得分开来看这个问题，首先容器云平台的建设是一个长期的过程。然后相关人才的积累，比如应用支持，平台运维，应用如何使用等等，虽然云平台目前相对来说也比较成熟，但银行业真正用好这个平台的例子还是较少。
其次，微服务化这个架构也是未来，但微服务化这个增加了系统架构的复杂度，而且出现问题如何定位解决也是需要经验积累，而且微服务化这个也是在一定规模下才能展现出优势，如果本身业务量访问量不大完全没必要。
所以到底是助力还是坑还是要看具体情况，没有银弹。

回复：liuxiangwin Sa , Redhat
首先，红帽 OpenShift 是一个混合云企业 Kubernetes 平台。它旨在帮助 IT 开发和运营团队协同工作，以交付和管理基于微服务的应用。它支持容器化应用、传统应用和云原生应用，以及重构为微服务的应用。您可以利用 OpenShift 服务目录极大地简化新服务的置备，只需在目录中选择服务，然后按照一系列简单的对话框的指示进行设置和配置。该目录旨在让您更轻松地为您的企业（或通过 Amazon Web Services 等公共云）置备私有服务，以便能在基于微服务的应用中使用这些服务。运维团队只有一个用于填充和管理服务目录的视图，因此开发团队可以轻松实现自助服务，并通过一系列简单的对话框或命令来整合这些服务。OpenShift 与红帽中

间件集成，可与 Git、Maven 和 Jenkins 等现有自动化工具配合使用。此外，它还整合了企业级 Linux 操作系统，进而提高了整个集群的安全性。无论您是优化传统应用、迁移到云还是构建基于微服务的全新解决方案，红帽 Openshift 都能跨基础架构为这些应用提供更安全、更稳定的平台。

红帽 OpenShift 的应用运行时

通常在数据中心构建服务器是非常耗时和耗费人力成本的工作。并且目前花费大量时间来定期更新环境，并为新软件配置其他服务器是大多数开发人员的梦魇，这项任务不仅毫无成就感，而且异常乏味。红帽 OpenShift应用运行时可以简化编排流程，让您有时间做自己想做的事。红帽 OpenShift 应用运行时为微服务提供了预构建、容器化运行时基础。它们使用多种语言和框架，为微服务设计提供高效能基础。此外，该平台还包含对五个运行时的本机支持：红帽 JBoss 企业应用平台（EAP）、Thorntail（运行 Eclipse MicroProfile）、Spring Boot/Cloud、Eclipse Vert.x 及 Node.js。

红帽 Intergation & Openshift

另外红帽 Intergation 是一个分布式云原生整合平台。它以 API 为中心、基于容器的技术基础可以让您独立创建、连接、扩展、部署微服务，并调整其规模。借助Intergation，您可以使用基于模式的集成框架（Apache Camel）开发或组合微服务。Intergation 旨在让开发人员能利用拖放式服务和内置集成模式等工具来构建微服务，而业务用户则可以使用基于 Web 的工具，来开发可集成不同微服务的 API。Intergation 采用混合部署模式，因此您可以在企业内部、在云端或以托管平台即服务（iPaaS）的形式使用它。它还有一个连接器库，其中包含了 200 个用于企业系统的开箱即用连接器。不仅如此，我们还针对红帽 OpenShift 容器平台运行环境对其进行了优化。

红帽 3scale & Openshift

其次微服务灵活多变，但单体式架构可以重复使用。从单体式架构转换到微服务时，您需要一个明确的 API 策略来解决这一问题，并为您提供这些重用功能。这就是强大的 API 管理功能对于微服务平台如此重要的原因。红帽 3scale API 管理是一个屡获殊荣的平台，它可以帮助您管理、分发和共享 API，实现 API 盈利。它使用了提供 API 流量控制的自我管理组件，可提高安全性并执行访问权限策略。它通过独有的策略管理与服务履行相分离的机制来运行，因此不会让您的操作速度变慢。此外，3scale 还可通过一个界面提供所有的策略管理工具（例如访问控制、速率限制、分析、计费和支付）。3scale 可与 Intergation 相集成，因此 Intergation 构建的微服务和集成也同样可采用 3scale 策略。此外，3scale 策略管理还可以作为容器在 OpenShift 中运行，因此 3scale 可让您享受与所有微服务相同的可扩展性和管理功能。

2、针对城商行渠道类业务应用微服务化改造容器平台选型依据及方法论有哪些？2、针对城商行渠道类业务应用微服务化改造容器平台选型依据及方法论有哪些？

回复：liuxiangwin Sa , Redhat
1.红帽针对城商行渠道类业务应用微服务化改造，可以由红帽创新实验室完成，这里面会有非常有经验的敏捷教练带着大家，然后会从不同的人员角色（例如应用开发工程师，UI/UX设计师，平台SRE工程师，产品负责人等）一起采用周为单位的方式梳理需要微服务改造的真正需求，通过相关方法来是设计开发模型，构建自己的生产流水线。
2.红帽针对应用微服务化改造可以有我们给客户提供的Discovery session的方式，帮助客户能够从业务侧，应用侧真正的捋清需要实现的部分，然后进一步到下一阶段。
3.红帽可以带着大家做领域驱动设计还有Event storming， brain storming等不同实践方法的改造实践，最终帮助项目落地。

回复：lzj7618937 质控经理 , cib
个人觉得微服务化的改造还是要结合应用具体的架构情况，建议新应用按最新的微服务架构去处理，而已有的后续慢慢把业务迁移过去。在服务的划分方面可以采用DDD-领域驱动设计来进行相关服务的划分，业务语言的统一。

回复：sf7071 软件开发工程师 , 某大型银行
目前的容器云平台产品，大多有单独的微服务治理模块，形成了云服务，开箱即用。建议在选型时可以重点考察产品这方面的功能，同时考察厂商在微服务治理方面的案例和技术人员能力。

3、由于开源存储和网络无法满足金融行业的要求，在容器云平台选型时如何选择合适的容器存储和容器网络？

回复：liuxiangwin Sa , Redhat
对于容器存储部分
1.首先，软件定义分布式存储是未来的必定的趋势，它符合上层敏捷性应用对底层存储高性能、高可靠性、快速伸缩、统一存储的要求，据IDC统计，未来五年内将有50%以上的企业存储替换为SDS。红帽有Openshift Container Storage 可以为容器存储提供强有力的支持，Openshift Container Storage既可以作为单独存储池使用，也可以作为超融合设备使用、也和Redhat Openstack, Openshit平台天然集成，
2.同时也可以和第三方的平台解决方案结合。其次，作为统一存储，兼具块，对象和文件存储，支持的协议也很广泛：iSCSI，NFS/CIFS, S3，Swift，POSIX，Restful API，有很广泛的使用场景：比如企业私有云，电信云NFV，数据湖，主动归档和备份.
3.再次，Redhat有完整的解决方案堆栈和多年的企业客户体验，我们将开源社区创新与生产级支持，产品和资源访问，生命周期管理，咨询服务以及客户需要成功部署的安全性相结合。"

对于容器网络部分
1、从应用视角红帽可以提供最有力的Service Mesh作为容器应用南北向流量还有东西流量的最有效管控手段，另外可以很好的支持容器应用在平台实现蓝绿，多版本，测试发布一体的功能.

2、从Cloud infra角度，Openshift 可以和相关SDN产品做很好的支持和整合，例如F5 ,Nignx.其实这样是把更多的自主可控权留给了客户，而不是无法满足

回复：lzj7618937 质控经理 , cib
容器网络和存储无非是那几种协议，无法满足金融行业的要求也要看，只要不是核心交易系统，我觉得一些内部管理系统完全没啥问题，无论选择开源自主建设还是选择厂商产品主要还是看行方自身的能力，如果你整个技术部门就几个人管理，你还是放弃自主弄吧，找个厂商搞定。如果你有几十人甚至上百人，可以考虑自已拿开源的来定制化，然后找些外部专家做咨询。

回复：sf7071 软件开发工程师 , 某大型银行
一般容器云产品肯定会有自身推荐的容器网络方案，但也会根据甲方需求进行合适的方案选择。打铁还需自身硬，采购软件产品亦是如此，建议甲方自身要有一定的基础技术储备，有自己的判断和实验能力，这样在选型时可以根据自身实际需求，结合厂商的建议，进行合理取舍。

4、中小银行使用容器云是选用成熟的互联网公司的产品，还是选用商用的产品比较好？

回复：sf7071 软件开发工程师 , 某大型银行
建议从成本预算和自身人员技术能力等方面看，一分钱一分货，选型时也要看厂商公司实力，一般可通过案例情况反映，同时也可以对其售后服务体系的完备性进行评估和判断。银行首要要求就是安全和稳定，可通过poc等方式进行实际测试验证，深入了解产品技术细节，综合多家产品进行对比。

回复：lzj7618937 质控经理 , cib
国内互联网企业的技术水平没得说，不过对于自身产品的封装及通用能力和咨询水平相对来说不如一些传统的商用公司。如果你是想拿个能用的一步步改造并且可以有一定的容错，你可以找互联网公司。如果你不想太多定制需求，就是能有一个好的平台来用，建议选择商用公司。

回复：liuxiangwin Sa , Redhat
首先大部分成熟互联网公司都是在开源的Kubernetes做相应的DIY.
Kubernetes 因为属于开源技术。所以，没有正式的技术支持机构可以为您的商业业务提供支持。如果生产过程中 Kubernetes 出现实施问题，您一定会感到非常担心，您的客户可能也会如此。

相比之下，红帽 OpenShift 是企业版的 Kubernetes，此外，它还具备更多功能。OpenShift 引入了额外的先进技术，从而使 Kubernetes 成为可供企业使用的强大平台，这些技术包括：注册表、联网、遥测、安全性、自动化和服务。借助 OpenShift 的可扩展性以及控制和编排功能，您的开发人员可以构建新的容器化应用、对其进行托管并在云端加以部署，从而轻松快速地将各种创新想法转变为新业务。

最重要的是，OpenShift 是由开源领域的领导者红帽所开发，并将由其提供全面支持。

红帽是上游 Kubernetes 项目的第二大贡献机构，也是 Kubernetes 许多关键特性、组件和相关容器技术的创始机构。红帽在云端运行 Kubernetes 方面拥有多年经验，并为广大企业在生产环境中应用容器的计划提供支持。目前，红帽正在与云原生社区合作，扩大容器和 Kubernetes 的功能边界，从无服务器计算迈向机器学习。红帽能够帮您从容应对堆栈的所有层面。不管是运行容器的主机操作系统、经验证的容器镜像、容器注册表，还是控制生产环境所需的编排平台和管理工具，红帽都能为您提供值得信赖的解决方案。

红帽提供集成容器平台，用于实施完全编排的多容器应用。或者，您只是有一些在标准工作负载间运行的“测试”容器？我们也能帮上忙。

容器技术来源于社区。它们是社区驱动的、基于开放标准的开源技术。在选择和实施容器等新技术时，务必要找到一个懂行的合作伙伴，为您提供关于参与开源社区，以及在其中实现创新的深刻洞见。这个合作伙伴还应知道如何将这些技术引入到您的企业中，并提供便利、持续的支持。想要加速创新，最佳途径是携手一家以社区为中心的开源项目和开放标准为基础打造产品和服务的公司。合作伙伴还必须要值得信赖，而且绝不会束缚您。红帽就是这样的技术合作伙伴。

5、相比于k8s、其他容器云产品，OpenShift在企业容器云平台建设中有哪些优势？

回复：liuxiangwin Sa , Redhat
Kubernetes（和Docker）是OpenShift的主要组件。也许最简单的思考方式是，OpenShift是一个企业级的Kubernetes发行版，就像红帽企业Linux是Linux的企业级分发版一样。

"Kubernetes 属于开源技术。所以，没有正式的技术支持机构可以为您的商业业务提供支持。如果生产过程中 Kubernetes 出现实施问题，您一定会感到非常担心，您的客户可能也会如此。相比之下，红帽 OpenShift 是企业版的 Kubernetes，此外，它还具备更多功能。OpenShift 引入了额外的先进技术，从而使 Kubernetes 成为可供企业使用的强大平台，这些技术包括：注册表、联网、遥测、安全性、自动化和服务。借助 OpenShift 的可扩展性以及控制和编排功能，您的开发人员可以构建新的容器化应用、对其进行托管并在云端加以部署，从而轻松快速地将各种创新想法转变为新业务。

最重要的是，OpenShift 是由开源领域的领导者红帽所开发，并将由其提供全面支持。

回复：lzj7618937 质控经理 , cib
OpenShift依靠的是RedHat，目前国内银行业大部分都用的红帽产品，支持相对于完善，而且生态完整，其它大部分公司都是基于k8s做些管理界面相关的改造。最主要的是有支持有背书，在银行业这点还是很重要的。

回复：sf7071 软件开发工程师 , 某大型银行
openshift运行稳定、安全，服务全面响应有保障，且自带操作系统、web服务器中间件优势，在开源社区很有影响力。
红帽公司为国际大厂，值得信赖。

6、部分应用容器化后，需要固定IP运行，以开通跨区的网络访问策略，calico网络方案是否有好的解决办法？

银行业有较多网络安全区域划分和隔离要求，不同网络区域间应用互访需要开放IP到IP的网络策略，部分应用容器化后，就需要固定IP运行，以开通跨区的网络访问策略，calico网络方案对这类需求是否有好的解决办法？

回复：lzj7618937 质控经理 , cib
Calico是Kubernetes生态系统中另一种流行的网络选择。虽然Flannel被公认为是最简单的选择，但Calico以其性能、灵活性而闻名。Calico的功能更为全面，不仅提供主机和pod之间的网络连接，还涉及网络安全和管理。Calico CNI插件在CNI框架内封装了Calico的功能。

Calico是一个基于BGP的纯三层的网络方案，与OpenStack、Kubernetes、AWS、GCE等云平台都能够良好地集成。Calico在每个计算节点都利用Linux Kernel实现了一个高效的虚拟路由器vRouter来负责数据转发。每个vRouter都通过BGP1协议把在本节点上运行的容器的路由信息向整个Calico网络广播，并自动设置到达其他节点的路由转发规则。Calico保证所有容器之间的数据流量都是通过IP路由的方式完成互联互通的。Calico节点组网时可以直接利用数据中心的网络结构（L2或者L3），不需要额外的NAT、隧道或者Overlay Network，没有额外的封包解包，能够节约CPU运算，提高网络效率。

Calico 在小规模集群中可以直接互联，在大规模集群中可以通过额外的 BGP route reflector 来完成。

此外， Calico 基于 iptables 还提供了丰富的网络策略，实现了 Kubernetes 的 Network Policy 策略，提供容器间网络可达性限制的功能。

回复：mtming333 系统架构师 , 甜橙金融翼支付
用nodeport模式这事儿会比较好推

7、非互联网的传统业务系统是否需要上容器云，如果上容器云如何进行微服务改造？

非互联网的传统业务系统是否需要上容器云，如果上容器云如何进行微服务改造。

回复：lzj7618937 质控经理 , cib
首先你有没有容器云平台，如果有，当然可以上，而且势必要上。上了云能提高资源利用率、节约网络、硬件等成本，目前大部分应用运行在服务器上很多都是浪费资源的，CPU和内存使用率基本不超过80%。而至于微服务改造就需要看应用具体的情况了，但首先使用容器你要把你的应用改成无状态系统。后面是否拆分服务等后面可以根据具体情况具体分析。

回复：sf7071 软件开发工程师 , 某大型银行
应用系统上云可以带来让开发人员更专注于业务逻辑实现， 提高研发效率 ，提高资源利用率，节约成本、让运维更便捷等诸多好处，应该说，是否需要上容器云，要看企业自身的需要，即算是对于可能需求不经常变化传统业务系统，上云也能得到很多益处。比如解决环境一致性问题、轻松应对双十一这样的业务场景、保障业务连续性等。
微服务改造方面，首先业务人员和架构师都应该对微服务模式和架构有所了解，从理念上达成一致，并建议可以根据业务需要划分微服务颗粒度，依据单一职责理论、清晰界定服务边界，结合容器云平台厂商的服务治理方案，实现业务系统的云上微服务改造。同时注意要实现CI/CD，否则服务多起来后，反而会增加维护成本。

回复：mtming333 系统架构师 , 甜橙金融翼支付
这个问题的答案应该有业务特性决定。个人认为，生产应用少于20种，节点少于50个，发布频率低于每月2次的，没必要使用。

8、渠道类业务应用微服务改造相对传统架构的优势,具体体现在哪些方面？

回复：lzj7618937 质控经理 , cib
渠道类业务应用主要是进行引流，其特点肯定是促销多，所以类似抢购、秒杀，某一时间点访问量特别大，但平时也有很多时间空闲。其实这种最适合微服务+云原生平台这种架构，能动态扩展高峰资源而不影响业务。

回复：liuxiangwin Sa , Redhat
1.渠道类业务应该从自己的业务创新需求和业务赋能需求去考虑自己的IT架构设计，同时结合企业目前的IT系统应用现状去考虑哪些系统是需要做微服务化和微服务改造的，并不是所有的IT系统都立刻需要微服务设计，只有想清楚了业务需求的本质才能捋清楚需要规划微服务的部分。

2.渠道需要构建自己的DevOps，是一个完整和持续的过程，需要有领路人指引，然后带领团队，从具体的业务需求着手，到开发-测试-生产-上线一套完整的流水线的构建和打通，同时构建企业的DevOps需要培养企业的DevOps文化，只有把DevOps的文化植入到团队中，才可能构建企业持续改进的DevOps平台。

3.对现有应用的现代化改造，需要结合业务的需求，可以做应用的容器平台的迁移还是应用架构设计，这需要结合具体应用和业务场景来谈。

4.红帽有全栈的产品可以帮助企业实现数字化转型的目标，同时红帽可以通过通过Discovery sesssion,Innovation lab 等不同方式帮助客户梳理自己的业务，构建自己的业务中台。

9、容器集群中的持久化数据（数据库类）的建议备份方式?

随着分布式应用和容器平台的发展，越来越多的应用尝试使用容器平台部署。数据库类容器的数据 一般存储在存储容器中，为防止数据的误操作（误删、误覆盖）也需要方便的备份恢复机制和异构存放。请问目前容器数据备份有哪些好的方案？备份整个容器？还是提取容器中的数据来备份?

回复：sf7071 软件开发工程师 , 某大型银行
容器中的数据要持久化，一般会挂载宿主机上的本地存储，或者分布式存储，即使容器销毁了，数据仍然在，新建的容器照样挂在原来的存储就能恢复数据。在容器云上部署数据库，部署架构也要是高可用的集群，集群各节点间应该有数据同步机制。所以，备份容器是没用的，容器是静态的镜像运行起来后的实例，容器里本身不应该存放持久化的数据。

10、容器云有哪些较为重要的监控告警指标？业内对于容器流量监控是否有较好的解决方案？

容器云有哪些较为重要的监控告警指标？
哪些场景下需要zabbix进行监控，哪些场景适合Prometheus进行监控？
是否有合适的监控方式可以相对实时获取POD的资源使用率，目前采用的Prometheus监控容器POD资源使用率，可能由于计算方式问题，按照分钟维度计算使用率与实际使用率存在较大出入，是否有必要对容器POD资源的使用率情况进行实时监控？
业内对于容器流量监控是否有较好的解决方案.

回复 :lzj7618937 质控经理 , cib

回复：liuxiangwin Sa , Redhat
1.首先容器云如果是采用红帽的Openshift的话，可以安装Elasticsearch+Logstash+Kibana ,或是Elasticsearch+Fluentd+Kibana对相应的系统日志，应用日志，log 日志做统一收集管理，在这个基础上Openshift内置了Prometheus，对集群节点和应用pod都可以做全面的管控和监控要求，可以按需定制化你的需求和特性。

2.其次如果要对应用层级的pod 做监控和使用率情况，Openshift 资深的health check 就可以做到一部分功能，另外可以结合Redhat Service mesh对相应的pod的流量，访问，request,反应时间等等不同的指标都可以做全面的管理和控制。

3.最后所有的这些监控组件都可以在Openshift通过Operator市场去管理，并且进行安装。

11、在企业应用微服务化改造建设中，OpenShift能为城商行用户提供哪些帮助？

回复：sf7071 软件开发工程师 , 某大型银行
可以让红帽公司的技术服务人员根据行内具体需求，制定一套完整的微服务化改造方案。

回复：liuxiangwin Sa , Redhat
1.企业应该从自己的业务创新需求和业务赋能需求去考虑自己的IT架构设计，同时结合企业目前的IT系统应用现状去考虑哪些系统是需要做微服务化和微服务改造的，并不是所有的IT系统都立刻需要微服务设计，只有想清楚了业务需求的本质才能捋清楚需要规划微服务的部分。

2.企业构建自己的DevOps，是一个完整和持续的过程，需要有领路人指引，然后带领团队，从具体的业务需求着手，到开发-测试-生产-上线一套完整的流水线的构建和打通，同时构建企业的DevOps需要培养企业的DevOps文化，只有把DevOps的文化植入到团队中，才可能构建企业持续改进的DevOps平台。

3.对现有应用的现代化改造，需要结合业务的需求，可以做应用的容器平台的迁移还是应用架构设计，这需要结合具体应用和业务场景来谈

4.红帽有全栈的产品可以帮助企业实现数字化转型的目标，同时红帽可以通过通过Discovery sesssion,Innovation lab 等不同方式帮助客户梳理自己的业务，构建自己的业务平台。"

12、应用大多还是以vm方式运行，面向容器化改造有哪些前提条件？

应用大多还是以vm方式运行，面向容器化改造有哪些前提条件？同时，容器云平台与传统虚拟化的主要差别在哪里，特别是网络方面，该如何做基础架构的配套建设

回复：liuxiangwin Sa , Redhat
1.如果应用还是放在虚机当中跑的话，可以大致分为两种Java的应用和非Java的应用，如果是Java的应用可以无缝的迁移到红帽Openshift平台上来，如果是非Java的应用可以考虑采用先做容器化，成为镜像的方式，然后在把对应的镜像部署到容器平台上，例如Openshift平台，同时Openshift平台也会对容器镜像和容器镜像的依赖提供很好的支持。

2.另外一种应用为数据库的应用，部署在虚拟机vm当中.这个时候需要区分和识别数据库应用的场景，如果是使用Oracle RAC这样的应用不推荐迁移到容器平台，
如果是使用场景如web应用的MySQL,Redis等是可以考虑直接迁移到容器化平台。

回复：sf7071 软件开发工程师 , 某大型银行
一般建议应用做无状态化架构设计，这样能够更好地适应容器运行的动态特点。当然有状态的也能进行容器化，只是要麻烦一些。对于已经在vm方式运行的存量应用，容器化前要先将应用程序制作成镜像，并且能够容器化运行，确保运行正常后，可将镜像推送到镜像仓库，再用容器云平台进行编排调度，大规模部署服务。

13、从系统部署和系统运维两方面看，容器平台对比传统虚拟化的优劣势？

从系统部署和系统运维两方面看，容器平台对比传统虚拟化的优劣势。同时从结合CICD一体化工具搭建DevOps环境来看，容器平台对比传统虚拟化的优劣势.

回复：sf7071 软件开发工程师 , 某大型银行
系统部署方面，容器平台较传统虚拟化更加快速，可以实现一键自动化大规模部署，扩容时也十分便捷，由于是池化资源管理，基础资源本身已就绪，在资源池充足的情况下，容器平台在进行应用系统规模扩容时，一般是需要修改副本数，便可实现分钟级扩容效率。传统虚拟化在系统部署过程中，基础资源需要准备就绪就需要花费大量时间，重新部署应用需要大量人工配置，很容易出错，而且容器存在环境一致性问题，扩容时更不亚于重新投产。
系统运维方面，容器平台具备故障自愈、自动运维的能力，在良好的监控告警系统辅助下，平时几乎不需要人工干预，同时云集群具备高可用架构，小规模的物理资源故障并不会影响平台的整体运行和云上应用的业务连续性，可以说用户对基础资源故障是无感知的，当需要资源扩展时，也是可以随时做，管理节点和计算节点都可以随时进行横向扩展。平台具有统一编排调度能力，在机房搬迁，设备更换等运维场景下，可以保障容器平台和应用系统的业务连续性。而传统虚拟化对物理资源故障较为敏感，故障时重建需要时间周期也比较长，需要投入更多的人力进行维护保障。
CI/CD方面，容器云平台更便于标准化、轻量化交付，更适合微服务架构应用的运行和管理，在CI过程中，构建机也可以容器化运行，构建时随时启动，完成任务后立即销毁释放资源，只在构建期间占用资源，有利于提高资源利用率，降低维护成本。而传统虚拟机，则需要维护构建资源池，资源是独占的。
容器云平台较传统虚拟化来说，也存在一个劣势，就是技术栈复杂，学习曲线陡峭，传统的监控体系难以适应其动态地特点，需要对监控体系进行改造。

回复：liuxiangwin Sa , Redhat
系统和运维其实要面临的是不同云环境，不同厂商，不同应用配置，或者目前提的最多的混合云概念，那么在混合云下不同的基础设施给应用的技术栈标准化带来挑战。要想做到应用平滑的在混合云环境中运行，需要严格定义应用所使用的支持环境。

公有云环境曾经试图通过其PaaS服务解决这一问题，可是在多云甚至混合云的情况下，这一前提条件并不成立。各基础设施云厂商会带入不同的基础架构和技术标准，使应用在不同的基础架构上统一部署变得更困难了。容器的出现从根本上解决这一难题。通过标准化的容器镜像，应用的部署标准得以固化。容器镜像通过定义层的方式把应用所依赖的基础系统、库、相关的二进制包都集成在一个通用的部署文件中。这个文件能做到真正意义的多环境统一部署。通过容器云平台对配置的管理，实现生产环境的发布。那么对于企业来说，容器镜像就是其真正用于混合云部署的利器。这一利器的安全合规，红帽团队是有一支全球的安全团队，能过提供安全的基础镜像到到层基于各种常用中间件的安全镜像实现其基础安全保护。开发团队交付的镜像到达镜像库后，我们会有一个定期更新的安全扫描工具对其进行安全扫描。以保证在基础镜像上添加的应用层是符合安全要求规范的。相关的CVE漏洞库红帽会通过全球的安全团队定期更新。对于企业构建混合云PaaS平台，可以从基础技术底座和上层运营门户来看待。通常在基础初期，企业需要更关注底层平台，即底座的可靠性、稳定性以及可持续发展。需要与开源社区同一路线，以避免日后技术路线跑偏。上层的运营门户没有统一的标准，需要根据企业自身的业务特点构建，因此，门户，特别是以运营为导向的，并不完全能通过采购获得。更多是自身技术团队能力成长的一个过程的体现。

回复：lzj7618937 质控经理 , cib
容器平台肯定是未来趋势，相对于传统虚拟化来说，他占用磁盘空间更小，启动速度更快，占用计算资源更少，结点扩展更容易等。但所有的这些都是在你有一个成熟的容器PaaS平台及熟悉docker、K8S相关操作及能力的情况下才能发挥更大的作用，如果你还是老的思想去运维、使用容器那就是灾难。

14、金融行业落地的最佳实践，对应的改造系统 ，解决的痛点和带来的价值是哪些？

金融行业落地的最佳实践，对应的改造系统 ，解决的痛点和带来的价值是哪些。

回复：liuxiangwin Sa , Redhat
1.建立容器平台对容器进行统一管理，提高资源使用率和运维管理效率。

2.将开发部门现有的DevOps工具链整合到Openshift中，提高迭代速度。

3.需求交付周期比上一季度少10%，平均交付周期缩短为原来的50%。根据缺陷管理工具统计：比上一季度一次测试通过率提升10%

4.构建传统银行数字银行容器平台，充分证明了Openshift是承载银行数字化转型的优秀平台。

回复：sf7071 软件开发工程师 , 某大型银行
容器云能够很好地保障应用系统的各环境一致性，实现所投即所测；
标准化交付，实现快速部署，提高部署效率，让研发人员不用操心环境的维护，专心做开发，实现业务逻辑，加速业务价值的交付；
统一编排调度，自动化运维，实现瞬间扩容，故障自愈，有效保障业务连续性，轻松应对突发流量，提高运维效率；
资源池化共享，按需供给，有效提高基础资源效能，长期看可有效降低成本；
在同一命名空间内，只要资源量允许，可同时发布多套测试环境，实现并行开发，并行测试，提高研发效率和交付频率。

15、企业如何平稳过渡到云计算，以及如何将微服务快速融入？

技术积累少，但是对新技术的渴望很迫切，在技术和项目管理层面如何操作？
新技术对已存在架构不友好，从哪些方面入手将其”和谐“的引入？

回复：lzj7618937 质控经理 , cib
人是有惰性的，要想让大家进行改造，还是要从高层统一思想，自上而下的推进，以鼓励为主。例如试点项目可以在绩效方面进行些奖励。现在的微服务技术相对来说也比较成熟，无论是Spring Cloud全家桶，还是Dubbo都有比较成熟的一套框架，项目组要上手其实还是比较简单。但到遇到具体问题如何去解决还是比较考验研发能力的，尤其是性能相关问题。所以建议一开始用在一些高可用性、重要性较低的系统，等有了相关经验再逐步总结出自己的一套框架体系进一步推广，同时也积累相关人才资源。对于已有架构，只能一点一点迁移过去了。

回复：sf7071 软件开发工程师 , 某大型银行
新技术的引入，往往会带来新的思想、模式和必要的变化，个人觉得首先要统一组织内的思想认知，自上而下推动。其次，做好技术培训，建立专业的云计算建设和支持团队。任何新事物都需要第一个吃螃蟹的人勇敢尝试，可以先挑内部管理系统进行试点，体现出价值让大家看得见，树立好口碑，做好宣传，然后从新建系统或者重构系统入手进行推广，逐步扩大规模。

16、如何将现有渠道类微服务迁移到容器云平台？迁移过程是怎样的？

回复：sf7071 软件开发工程师 , 某大型银行
个人认为与具体的业务类型无关。 建议在平台厂商的支持下根据实际需要制定适合的迁移方案。 首先要将每一个微服务进行容器化适配，一般建议将服务无状态化，这样才能更好地适应容器云平台的动态调度和故障自愈。其次要选择合适的云上微服务框架，现在很多容器云平台能够支持service mesh，也是未来云上微服务主流方向。然后结合容器云平台的CI/CD工具，实现微服务的持续集成和持续部署，可以极大提高研发效率。最后要考虑是否需要新老服务并行过渡，可通过负载均衡进行流量调配。