金融企容器云平台架构设计的几个问题参考

银行业单体应用系统往往功能复杂，系统庞大，难以维护和扩展；其次如果系统出现问题，则往往难以定位和修复，影响往往是全局性的，造成较大影响和损失；再者，对于这些大的单体系统的功能更新和问题修复，开发人员面临着难以梳理整个系统脉络、只能头疼医头脚疼医脚打补丁堆砌开发，使应用系统可读性、可维护性、可靠性、性能等都越来越差。

面对以上面临的种种困扰，容器云平台给予了我们支撑业务应用的基础设施弹性扩展的能力，而微服务架构则使我们有了在容器云平台甚至非容器化平台更方面梳理业务流程和重构业务应用的机会。但构建微服务应用并不容易，它需要众多的基础设施资源支撑和基础组件支撑能力，它需要开发、测试、运维等团队的协调合作，它需要技术和业务之间的一体化认知和实践，它需要众多的工具支持，方法指导，或者说需要实现DevOps。

对于银行来说在应用开发、测试、运维管理等方面来说，主要面临以下几个方面的痛点：

1）应用迭代缓慢，业务交付经常被推迟；

2）传统的单体架构应用难以维护和扩展；

3）应用的运维管理比较复杂。

为解决以上痛点，特邀请相关技术专家进行分享探讨基于容器云平台的微服务架构设计及DevOps建设和实现具体实践经验。我们将详细探讨容器云平台建设的问题、需求、场景、目标、可行性、选型、主流技术和框架、微服务、DevOps等内容。

科学技术是第一生产力。以技术驱动业务创新和发展，是企业转型和发展的必由之路。新技术的采用既是机遇也可能是压力，如何能把压力变成机遇，考验着每个技术人员能力和素质。

2018年11月17日，社区应浙江地区的金融企业在容器云方面的交流需求，组织了一场金融企业同行技术交流活动，活动中参与企业提出了以下问题，现将问题和解答整理出来，供大家参考。

容器云建设适合在企业发展到哪个阶段进行，需要在应用架构微服务化成熟后进行吗？
解答：
容器平台建设个人觉得其实和微服务架构应用没有必然联系，所以没有先后次序的问题，只不过微服务架构非常适合轻量的容器平台，所以常常把他们放一起讨论，但从系统架构建设层次来说，可以先构建容器平台，容器平台是基础平台，用于业务应用部署运营托管，也可同步建设，这样项目更好推进。

容器云网络配置如何能满足行业监管的要求？
解答：
网络有不同的模型，可能每种模型都无法满足所有需求。
所以我们觉得可以尝试从不同层面来共同实现来满足行业监管要求。比如从业务应用层，多租户的机制实现业务隔离，禁用命令终端，禁止业务用户直接操作系统命令，一是安全、二是减少学习成本，三满足监管要求。
资源层网络有硬性的隔离和软式的隔离，可以搭建不同的集群，采用不同的网络模型，也可以一个集群划分不同的网络区域，使用不同的网络策略。根据具体的要求确定具体的方案

从哪个业务的应用场景切入到容器云平台上去比较好，传统的业务应用有什么好的策略和原则逐步上到容器云平台？
解答：
通常都是从互联网类应用作为切入点，这类应用具备云原生的特点，可以直接部署于容器平台。
传统应用除非必要，否则可以暂不迁云。在云平台功能完善情况下，在业务系统有改造需求下，采用微服务云原生理念重构业务应用，直接部属于云平台。

微服务和数据治理之间是什么关系？数据治理的大体思路是什么？
解答：
服务拆分从业务数据模型监督角度出发，会非常合理。数据治理需要统一数据模型，数据梳理与字段索引等设计调整，最终完成数据模型建设。

重量级中间件应用在迁移容器云的时候应该怎么去做？
解答1：
除非必要，不建议去做
在有需要重构这些系统时，采用微服务云原生理念进行重构，直接部署于云平台
解答2：
configmap 或者env传给容器配置
脚本比如shell脚本+wlst实现wtc配置

微服务治理应该如何去做？
解答：
微服务治理是一个很大的课题，涉及微服务整个生命周期过程，我们只是从技术上尝试提供一些选择

1. 使用API网关、API管理工具来实现微服务的部分治理能力，比如安全、权限、访问控制、流控、路由、熔断、容错等
2. 基于基础设施平台，业务应用微服务托管运维平台，比如容器平台，实现微服务的管理、治理。和API管理配置实现微服务的运营运维监控反馈。
3. 基于DevOps方法论实现持续集成流程，将微服务的规划、研发、测试、缺陷管理、文档管理需求等实现治理。

容器云建设成本如何？后续运维成本主要构成如何？
解答：
要做好都不容易都需要很大的投入。
首先是人力的投入，这个成本往往是隐性成本，往往也最大，更是后期运维成本的大头。
容器平台建设首先考虑是自研、外购产品、或合作研发、或项目形式，不同形式成本不一样。
通常前期项目几十到上百万，类似于验证性的，尝试性的，通常需要配合业务部门的业务上线，才能逐步的扩展。因此容器平台的扩展性、弹性设计非常非常重要。
硬件成本通常是可控的，但关键在于人力成本，以及厂商的能力。项目往往是不可控的，所以建议产品化，购买成熟的产品，或者至少能把控平台建设。
如果能把控项目或走产品化，成本基本上是可预测的。进度也是可预测的。

当下的基于k8s做商业二次增强的落地产品都有哪些厂商，各自的特色和成熟度如何？
解答：
厂商还是很多的，国内的博云、谐云、ucloud、daocould、灵雀、时速、才云、阿里、华为等等,国外的pivotal、redhat, ibm等等，总的来说国外的厂商能力更强，更成熟，但成本更高，比较难影响他们。国内厂商的产品都不怎么样。更多是炒概念。
目前个人觉得市场上还没有真正成熟的产品，还需要时间。