中小银行传统架构如何向容器云转变？
目前我行使用的的是传统架构，小型机运行关键数据库，应用部署在vmware虚拟化上，没有使用过容器，也正在调研，如果开始建设容器云的话应该按照怎样的路线去建设？想听听专家们的经验。
8同行回答
传统架构向容器云转变整体上而言需要从业务视角和技术视角进行双重考虑：业务视角需要重点如下几个问题：1.容器运行态的应用服务能够满足银行稳定性，可靠性，安全性的要求保证？2.评估容器云的迁移对现有业务造成的影响，尤其是银行组织架构以及应用开发带来的影响。3.传统架构向容器云转变是否适合所有的业务，需要根据业务形态，运行状态做统筹分析？4.容器云给银行业务带来哪些质变。
技术视角重点考虑如下几个问题：1.数据存储层技术方案。2.网络方案，容器云和传统架构相比，必然会有网络性能的损耗，如何减少业务延迟需要重点考虑；3.容器云的服务调度问题，原来通过CMDB做配置管理的方式转变为容器云调度方式，能否适配应用部署的特定方案。4.传统架构应用的容器化，面临最终的问题是应用容器化，应用容器化取决于原有应用的架构本身，对于单体架构，是否需要考虑引入微服务拆分，对于分布式架构，如何解决服务通信的稳定性和可靠性。
最终容器云的形态应该是服务中台的方式，当然容器云也有自己的局限性，最终是否要上容器云还需要统筹全局去考虑
我们认为架构的发展趋势是向统一的服务中台演进，支撑服务中台需要考虑基础设施平台的建设，容器云提供了可行性。
要建设服务中台，需要考虑微服务架构或SOA等，这意味着系统的重构或至少集成。 SOA ESB重在集成，微服务意在重构。这个一个很大的长期的工程。对人力、资金、时间的投入都很大。
不管ESB或者微服务架构，都需要数据的标准化和良好治理，如果做不到这点，不要轻易服务化。否则很容易一团乱麻。
所以我们觉得，第一步在于数据，第二步才能考虑技术平台和方案路线图
贵公司筹划建设容器云的目的是什么呢？依照我们与客户的交流经验目前在银行领域建设容器云主要出于以下几个需要：
- 对于业务响应的支持
- 临时促销业务需要对资源以及服务进行弹性扩缩以及混合云的管理
- 希望将资源池化减轻项目中资源准备的流程沟通成本以及保证环境的一致性
- 希望通过基于容器的CICD工具链提高项目开发交付速度
- IT交付能力建设
- 打造DevOps工具链以及团队的持续交付能力建设
- 对于新架构应用（微服务）的全生命周期管理支持
容器技术并不是万能的，要了解清楚容器技术的原理以及价值并评估容器云平台到底可以解决内部的什么问题与痛点对于筹划基础设施转变非常重要。
目的清晰的话就需要对主流开源容器编排调度框架的选型，这个部分目前我们接触的国内各大企业基本上都倾向于Kubernetes，各个框架的优缺点以及适合场景目前整个市场的认知已经比较清楚就不再累述了。
对于搭建平台与应用的基础设施资源目前银行主要是两种模式，一种是容器管理平台部署在虚拟机上应用部署在裸机上。还有一种是全部部署在虚拟机上。在虚拟机上的好处是资源管理更加方便，而弊端是多了一层虚拟化对于资源的浪费以及性能上的一点点折扣。这个部署方案可以先确定下来。
下一步，平台只是工具，更重要的是使用平台的人。不管组织团队自研还是购买服务商产品都需要先建立公司内部的容器技术应用种子团队。团队成员最好是跨职能成员包括开发，运维，测试，项目管理等各个云平台的预期用户。容器技术所带来的新的软件封装打包以及应用编排的方式势必会带来IT管理流程上的改变以及对新技能的要求。所以第一步一定是需要组建种子团队通过全程参与项目以及培训储备一定的容器知识。日后可以做为容器平台建设项目管理人员以及流程改造及平台的推广人员帮助项目成功。
最后，就是选择有实实在在行业落地经验以及售后生产支持经验的厂商合作搭建平台并共同完成试点项目上线。
收起并不是是任何应用都需要使用容器云架构，容器云架构主要是解决业务量大并发问题，迅速解决业务性能瓶颈问题。随着互联网金融的发展，容器云在互联网金融业务广泛应用是必然趋势，因此对那些业务并发量小的金融业务或者核心业务，就不需要改造。
对于互联网金融业务架构转型容器云，可以从运维，监控，迁移复杂度，与现有技术架构兼容性，容器云技术发展成熟性等多方面综合考虑
1、首先要考虑是否需要上容器，这个不能跟风，容器目前更适合微服务的架构，如果你们的应用做不到服务化，上容器没有太大意义，建议你去看下什么样的情况适合上容器的相关文章；
2、银行对稳定性要求较高，从虚拟化到容器，建议采用成熟的一些方案，现在开发环境进行测试，当然要保持和应用开发部门的沟通，上容器主要还是应用需求的问题；
3、容器较为轻量化，适合现在一些需要快速上线业务的场景，现在大部分金融机构应该是在一些互联网金融产品方面开始采用容器云，至于一些核心业务目前来看短时间内未必适合上容器。