金融企业容器云平台架构设计需要清楚的8个问题

1、容器云建设适合在企业发展到哪个阶段进行，需要在应用架构微服务化成熟后进行吗？

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

2、容器云网络配置如何能满足行业监管的要求？

网络有不同的模型，可能每种模型都无法满足所有需求。

所以我们觉得可以尝试从不同层面来共同实现来满足行业监管要求。比如从业务应用层，多租户的机制实现业务隔离，禁用命令终端，禁止业务用户直接操作系统命令，一是安全、二是减少学习成本，三满足监管要求。

资源层网络有硬性的隔离和软式的隔离，可以搭建不同的集群，采用不同的网络模型，也可以一个集群划分不同的网络区域，使用不同的网络策略。根据具体的要求确定具体的方案。

3、从哪个业务的应用场景切入到容器云平台上去比较好，传统的业务应用有什么好的策略和原则逐步上到容器云平台？

通常都是从互联网类应用作为切入点，这类应用具备云原生的特点，可以直接部署于容器平台。

传统应用除非必要，否则可以暂不迁云。在云平台功能完善情况下，在业务系统有改造需求下，采用微服务云原生理念重构业务应用，直接部属于云平台。

4、微服务和数据治理之间是什么关系？数据治理的大体思路是什么？

服务拆分从业务数据模型监督角度出发，会非常合理。数据治理需要统一数据模型，数据梳理与字段索引等设计调整，最终完成数据模型建设。

5、重量级中间件应用在迁移容器云的时候应该怎么去做？

观点1：

除非必要，不建议去做。

在有需要重构这些系统时，采用微服务云原生理念进行重构，直接部署于云平台。

观点2：

configmap 或者env传给容器配置。

脚本比如shell脚本+wlst实现wtc配置。

6、微服务治理应该如何去做？

微服务治理是一个很大的课题，涉及微服务整个生命周期过程，我们只是从技术上尝试提供一些选择

1. 使用API网关、API管理工具来实现微服务的部分治理能力，比如安全、权限、访问控制、流控、路由、熔断、容错等

2. 基于基础设施平台，业务应用微服务托管运维平台，比如容器平台，实现微服务的管理、治理。和API管理配置实现微服务的运营运维监控反馈。

3. 基于DevOps方法论实现持续集成流程，将微服务的规划、研发、测试、缺陷管理、文档管理需求等实现治理。

7、容器云建设成本如何？后续运维成本主要构成如何？

要做好都不容易都需要很大的投入。

首先是人力的投入，这个成本往往是隐性成本，往往也最大，更是后期运维成本的大头。

容器平台建设首先考虑是自研、外购产品、或合作研发、或项目形式，不同形式成本不一样。

通常前期项目几十到上百万，类似于验证性的，尝试性的，通常需要配合业务部门的业务上线，才能逐步的扩展。因此容器平台的扩展性、弹性设计非常非常重要。

硬件成本通常是可控的，但关键在于人力成本，以及厂商的能力。项目往往是不可控的，所以建议产品化，购买成熟的产品，或者至少能把控平台建设。

如果能把控项目或走产品化，成本基本上是可预测的。进度也是可预测的。

8、当下的基于k8s做商业二次增强的落地产品都有哪些厂商，各自的特色和成熟度如何？

厂商还是很多的，国内的博云、谐云、ucloud、daocould、灵雀、时速、阿里、华为等等，国外的RedHat、IBM、pivotal等等，总的来说国外的厂商能力更强，更成熟，但成本更高。真正成熟的产品还需要时间。

更多相关文章