容器云平台可行性评估：风险管理和关键技术路线选型 | 最佳实践

容器云项目是我司规划建设的基础设施云计算PaaS平台的尝试，希望通过容器化PaaS平台的建设，支持正在建设的微服务架构应用，同时也为适应公司互联网业务发展，满足业务快速开发和迭代的需求，逐步建立标准化的开发、测试、运维环境，形成适用于公司的DevOps(开发运维一体化)过程，完善开发、测试、部署、运维监控工具链和自动化流程，提升自主敏捷研发、持续集成的能力；同时基于容器云平台，逐步建立起企业级的服务中台，实现大中台-小前端的基础架构，更好的支持公司业务应用的开发，专注于业务应用的研发，提升IT对业务变化需求的快速响应能力。解决传统单体应用之间难以集成和共享的问题；通过采用标准化的容器技术和标准化的镜像输出，为开发测试生产提供一致性的环境；利用容器云的弹性伸缩能力实现对互联网金融业务流量快速变化的支持。

一、背景和原因

目前我司已经完成IaaS（Infrastructure as a Service）虚拟化建设，采用了Vmware和超融合技术；IaaS虚拟化层提供了对存储、网络、计算资源的管理，但无法提供对公司软件、工具、中间件等的管理。按照云计算的三种类型，建设PaaS（ Platform as a Service）平台将有助于我们实现这些目标，同时提升敏捷开发能力，自动化运维能力。但PaaS平台技术一直不成熟，存在诸多技术难点。随着以Docker为代表的容器技术的出现和发展并逐步成熟，使我们看到构建基于容器技术的轻量化PaaS平台——容器云平台的可行性。

1． 容器云定义、作用

容器云，是轻量化PaaS平台的一种容器化实现方式。是基于容器技术、容器调度编排技术和支撑容器运行操作系统技术、分布式技术上构建的云计算平台。

从PaaS功能来说，PaaS提供应用开发、应用托管、应用运维等能力。也就是说在PaaS上，客户可以开发、测试应用，用户可以托管应用到PaaS的运行时环境，同时PaaS提供给客户应用服务运维的能力（比如应用管理、监控、日志、安全等）。

PaaS平台是以应用开发为中心，以解决应用全生命周期管理、中间件云服务、基础资源的高效利用。从应用的开发、部署，到运维的全流程生命周期管理，实现应用的自动伸缩、弹性扩展、灰度发布以及监控告警、故障分析、自动迁移、自动恢复；提供丰富的预集成服务, 把通用的软件能力服务化，使得应用能快速拥有分布式的高可用性、高可扩展性；通过对底层资源的抽象和资源层的隔离，尽可能地共享或平摊资源，以提高资源整体使用率，从而降低基础设施的投入。

要实现这么多能力，PaaS技术存在一些难点，比如如何把IaaS层的能力更无缝的融合到PaaS；如何把开发能力，特别是IDE工具部署到云上(eclipse 提供云上开发服务)；数据存储和动态迁移的问题等。容器技术提供了一种选择，可以首先构建轻量化PaaS，实现应用托管、应用运维能力，同时可以建立持续集成的环境，无缝对接容器云平台。

2． 容器云带来什么新技术新思想

容器云是轻量化PaaS的一种实现方式，容器技术的发展促进了PaaS平台的落地，部分的解决了PaaS平台的技术难点问题。随着容器技术和PaaS平台技术的发展，容器云将会更加成熟。

容器技术特点又非常适合微服务架构，使微服务架构应用的部署和运维更加便利，并且可以很好的解决弹性伸缩、灰度发布等运维难点。

容器和容器云更促进了DevOps思想的发展成熟，并找到了落地的途径。容器云为持续集成和持续部署提供了便利的方式，也提供了开发、测试、生产等环境一致性的途径。

容器技术改变了应用部署和管理的方式。容器云平台、微服务架构和DevOps方法论相辅相成，相互促进，带来了应用开发、应用部署、应用运维等全生命周期管理的新方法和新手段，也为大数据应用、AI应用等在云计算平台的大规模部署提供了便利。以云计算平台为基础设施，支撑基础业务应用，大数据应用、AI应用等，建立全局的系统和服务体系，可以更好的服务于客户，更好的赢得客户的信任。

3．企业业面临的问题和挑战--现状分析

互联网金融的出现和迅速发展，给予传统金融企业极大的压力，被迫考虑转型和调整。互联网金融，关键点在于互联网：互联网思维、互联网技术。先进的思想引领先进的技术，先进的技术支撑先进的架构，先进的架构提升先进的业务，先进的业务更好的服务客户、更多的赢得客户！

对于我们传统的金融企业，还存在传统的思维、落后的技术。一项新业务从提出需求到立项、招标、实施、上线，一年半载已经过去了。最最关键的是，开发出来的可能已经不是最初的样子了，似是而非，一线员工不满意，IT人员觉得委屈，客户失望流失。这种传统的IT研发方式已经无法适应新业务发展的要求。

我们提出建设容器云平台也是基于现实的挑战：

1) 受厂商影响，开发测试部署交付等环节各不相同，各Team有各异的环境、工具、方法、规范，团队之间难以实现共享和高效合作。

2) 传统单体应用各系统独立，互连互通、共享难，虽有ESB可以实现集成，但对一些需求无法满足性能、扩展、低延迟、快速上线等要求。

3) 自动化测试、自动化运维程度低；一个系统通常从立项到运维都是由一个人来负责，形成了大大小小上百个系统，占用大量的人力资源。在系统出现异常时定位问题慢，经常受到多个系统的影响，处理起来很慢。

4) 一台PC一套环境，资源利用率低，而且PC有限；虚拟化后虚拟机OS消耗大量的计算、存储资源；虚拟机OS实际运维管理成本等同于物理服务器，虚拟机数量增加导致管理成本增加。

5) 不易复制，搭建环境麻烦。生产与测试环境不一致，脏环境的问题，无法保证每次运行的环境完全一致。在测试环境可以，在生产环境可能怎么都不行。

6) 扩容慢，遇到突发流量，疲于奔命；迁移慢且比较繁琐。

7) 系统重载，应用伸缩周期长，对VM做伸缩，系统负载大，APP的VM环境无法快速复制，无法满足应用的大规模快速弹性部署需求。

8) 不支持快速迭代，业务上线效率低，不支持在线应用环境申请和配置及切换、频繁发布、频繁升级背后的人力投入巨大，缺少在线验证机制、难以快速定位修复线上问题。出现问题后的解决问题的手段非常有限，且低效；

4．实施容器云项目的原因

为了解决面临的问题和挑战，重要的是在快速变化的时代生存下去，要变革，要与时俱进。

首先要改变思想，重视IT技术投入，认识到科学技术是第一生产力。已经不能靠人海战术来赢得未来。IT系统和平台是业务的基础，可以极大的协助人来提高业务处理能力。互联网、移动业务、物联网的发展，必须靠强大的基础设施来支撑，需要强大的互连互通能力、强大的运算分析能力、针对性的服务能力、瞬时的响应能力、舒适的客户体验能力等等，这些都需要IT系统和平台的支撑。

业务建立在平台之上！没有好的平台就难以推出好的业务。传统单体应用彼此独立，所采用的技术、开发语言、开发框架各不相同；数据分离，各自有自己的一套数据库；数据冗余导致浪费，最重要的是数据不一致造成很多问题。数据是一个企业的核心资产，所以企业的重要数据不能轻易放到公有云，需要建设自己的私有云平台、建设企业内的基础设施平台来支撑企业业务的运行和发展。从而实现基础设施平台为数据和业务服务；数据层建立通用数据模型，实现全局唯一数据源，解决数据不通、不一致、冗余等问题；业务层实现服务共享，在基础服务的基础上快速构建业务应用，快速部署发布投入运营。

SOA技术的发展，微服务被大家接受并受到推崇。其解决了单体应用系统大而重的问题，也很好的避免了ESB集成存在的瓶颈。其采用组件服务化、分布式的部署方式，非常贴合容器技术的特点，小而轻量，以小拼大。

具体的，为了配合正在进行中的客户中心、账户中心、产品中心等的建设，适应公司互联网业务发展，满足业务应用快速开发及迭代的需求，采用微服务架构，逐步建立标准化的开发、测试、运维环境，形成适用于公司的DevOps（开发和运维一体化）过程，完善开发、测试、部署、运维监控工具链，提升自主开发技术和管理水平。

5．项目可能带来的好处

实现了共享，适应快速的业务变化，企业能生存、能发展、员工能有高收入，为社会公众带来便利和利益：

1) 技术上，初步搭建容器云平台，建立统一的服务托管、部署、运维平台，逐步建立并完善统一的权限管理体系、授权认证体系、服务配置治理体系、日志收集分析体系、监控告警预警体系等，实现公司内统一的应用服务部署运维监控生态系统。

2) 管理上，通过引入DevOps理念，根据公司实际逐步建立开发、测试、运维等适合自身发展需要的流程，定义相关数据、业务、技术等标准、规范，实现开发、测试、生产环境的一致性，提升敏捷开发的能力，提升自动化运维的水平。

3) 业务上，提供快速业务原型的开发以支持业务变化需求，让业务人员更早的介入，熟悉使用并有效持续反馈，形成业务和开发的良性循环。

总的来说，容器轻量化PaaS平台可以利用容器技术的特点，其技术特点非常适合互联网化应用的快速迭代开发、弹性伸缩部署、基于标签体系的灰度发布机制等需求。我们同时考虑采用目前分布式的微服务架构，结合容器云平台，实现提高开发端的响应能力，自主开发；统一技术路线，逐步实现技术积累和共享；实现持续集成，开发测试与生产环境一致；持续部署能力，提高发布速度；实现弹性伸缩能力，快速的实现扩容和缩容；解放运维、实行自动化运维等以满足公司互联网应用业务发展的需要以及传统应用改造和集成的需求。

6．行业内应用情况现状调查及趋势预测--市场调研

目前公司的业务系统开发、测试、部署及运维还以传统模式为主，开发人员在应用开发测试及部署阶段还需要准备操作系统、中间件、Web服务等软件运行环境并进行配置，业务应用的上线及变更周期较长，不能满足近几年兴起的互联网化应用所要求的快速、弹性、敏捷要求，缺少整合、高效的基础平台支持。

为此，项目组对行业内容器云的建设情况进行了广泛调研。

国内银行采用容器云技术的相对比较多，证券公司目前大多数还在调研和PoC测试阶段。也有几家已应用到生产环境。

某证券从2013年开始研究容器技术，2014年尝试在生产环境使用，2015年开始大规模使用，根据2017年现场调研情况，某证券在生产环境使用的容器实例个数行情云4000多个容器实例，分布在6个机房。承载实时并发超过30万，整个行情云每秒的吞吐在1.5Gbps左右,服务客户超过200万； 

上海证交所也已实施容器云平台，自身从顶层规划，多厂商参与，应用采用微服务架构，平台实现了容器云、持续集成持续部署等，并获得了2016“开源云计算﹒实效应用”奖。

某证券在测试环境和生产环境部署了超过360个容器实例，应用在用户中心——某e账通、任务中心流数据处理、支付中心——某内部支付服务等业务场景。

某证券容器技术主要使用在应用开发持续集成流程方面，实现自己的研发流程平台，目前在开发测试环境部署有上百容器，20多个项目开发及测试流程。

7．建设目标

容器云的建设目标是建设一个以容器技术为基础，支持微服务架构应用软件运行的基础平台，以降低应用开发、测试、部署和运维过程中软件基础环境的复杂度，使开发人员更关注业务实现，提高开发、测试、运维效率，提升技术对业务需求的相应速度。

容器云的建设以服务应用开发为中心，将业务应用中的功能性需求如高可用、弹性伸缩、灰度发布、监控告警、日志存储等，通过容器云平台统一实现，并解决应用全生命周期管理、中间件云服务、基础资源利用率等问题，从而降低基础设施的投入，容器云平台主要对应用开发及运维提供以下支持：

 开发环境支持：即开发人员使用提容器云平台供的快速部署能力，建立开发应用所需的技术环境、编程语言框架、中间件服务等，实现开发环境的快速准备。

 应用部署服务：即开发人员创建的应用可通过镜像方式快速部署到容器云上，在测试环境和生产环境实现应用快速部署及更新。

 微服务架构支持：提供微服务应用的应用注册中心、日志中心、监控中心、容器调度及编排服务，为客户中心、服务中心等这类按照微服务架构开发的应用提供基础环境支持。

应用运维支持：应用运维人员无需管理底层硬件资源、操作系统及中间件等，可以按照统一的镜像方式部署和变更应用，大幅降低应用运维的复杂度，逐步实现应用运维管理（伸缩、配置、升级等）自动化。

我司容器云平台建设的基本目标是：提供应用托管、应用运维的统一平台，通过容器云提供的配置中心、注册发现中心、日志中心、监控告警中心等为所有业务应用提供基础服务，研发人员专注于业务应用的研发而不用关注应用的部署和运维。基于云计算的多租户体系和权限管理体系，可以很好的实现应用之间的隔离，提供安全的访问控制体系。

以建设容器化PaaS平台为契机，搭建基础的统一监控、告警、日志、配置、认证、API管理等服务能力，同时结合大数据平台建设，预研机器学习、深度学习等人工智能应用场景，融合各系统的优点和能力，避免各个系统的独立建设导致的系统隔离、数据分散、数据冗余、数据不一致等问题，逐步建设形成统一认证中心、监控告警中心、服务注册中心、服务配置中心、日志管理中心、API网关和API管理等能力。

8．PoC测试情况分析--厂家评估

项目组根据前期调研和国内容器云产品厂商的技术能力和项目实施情况，选取了A、B、C、D、E、F、G七家厂商的产品进行了PoC测试，目前测试已经完成，我们选择了以下几个方面作为评估维度：

 多租户：考察租户隔离能力，对组织架构、用户、权限、角色的支持能力。

 资源管理： 集群、主机、计算、存储、网络资源的管理分配能力。

 DevOps：敏捷研发运维的能力。持续集成、持续部署能力。

 应用管理：包括应用发布（灰度发布）、部署、应用模板、弹性伸缩、应用运维、服务、实例、Pods、容器等管理功能。

 微服务支持：包括支持的微服务框架、服务编排、服务治理能力等。

 镜像仓库/中间件支持：镜像仓库能力和公用中间件支持能力。

 基础组件：日志、监控、调度、权限、健康检查等基础组件的能力。

 易用性：操作、理解的便捷程度。主要是考虑客户使用体验。包括安装配置、部署操作、更新升级、高可用等。命名定义是否贴切、操作是否便利、配置是否复杂化、是否符合人的习惯等。

 厂商情况：背景、技术实力、运维支持、项目经验等。

根据评估综合结果来选择进入招标阶段厂商。

9．实施规划

按照试点先行、分步推进的原则，容器云平台建设计划分为两个阶段：

第一阶段：容器云基础平台建设。部署容器引擎和容器管理调度系统，支持客户中心、服务中心系统的上线部署，为客户中心、账户中心、产品中心等应用和用到的中间件服务提供托管和运行管理平台；同步搭建微服务架构支撑体系，建立服务配置中心、服务注册中心、服务日志处理中心、服务监控告警中心等组件，以更好的支持服务运维要求。基于微服务架构设计的服务可以很好的跟容器云结合，实现服务的弹性伸缩、灰度发布、路由配置、熔断保护、应用监控等能力。同时尝试在容器云平台提供公共的中间件服务，如负载均衡服务、消息中间件服务、Redis缓存集群服务、应用服务器服务等。第一阶段预计工期N个月。

第二阶段：已有服务开发迁移及DevOps流程实现阶段。本阶段迁移部分适合容器化部署的部分已有应用如企业服务总线、大数据应用、OTC、产品中心等，使上述业务应用具备弹性伸缩能力以及日志收集、日志分析、监控告警等运维能力；实现开发、测试、生产环境的一致性，完成持续集成、持续发布流程和标准规范，逐步形成适合公司自身的DevOps体系并持续改进，并逐步推广到其他团队。预计工期N个月。

二、容器云项目本期工程实施的预期具体应用效果

前面我们提到，容器云项目实施采用试点先行、分步实施的方式，第一阶段先建设容器云基础平台，并同步支持微服务架构的应用。第二阶段实现DevOps持续集成、持续部署、持续反馈闭环流程，完成整个工具链选择和集成，同时迁移已有的服务化应用，以及需要改造的单体应用等。这些工作完成之后，将对企业、IT系统建设、运维和开发人员带来极大收益。

1．对于企业的价值

容器云是基础设施平台，就像我们建楼房的地基，楼房结不结实、抗不抗震，地基是关键。对企业来说，建设一套企业应用系统的开发运维基础设施平台，将是企业实现敏捷应用开发和快速业务响应的基础。

传统单体应用的开发周期基本上都是以半年、年来计算，采用SOA/ESB集成服务化之后，受制于ESB的设计思想，虽然可以提高响应能力，将应用功能解耦合，缩短应用开发周期为月、周甚至天，但性能和低延迟方面常常无法满足需求。ESB是基于系统的集成，受制于底层各系统的能力，无法自由扩展。微服务架构强调组件从下到上的服务化，对应用系统做彻底的改造，实现应用系统微服务化。容器云平台为微服务应用提供环境，可以方便的建设企业的服务中台。这是一个企业的关键能力。有了服务中台，才能真正的实现快速的业务响应能力和应用快速构建部署运营能力。

容器云弹性伸缩能力，让基础的、共用的组件可以真正的解耦出来，不再受制于单台机器资源的限制，可以支撑整个企业的需求。比如日志中心，就可以实现整个公司所有应用系统、应用服务的日志的归集、分析。容器云多租户能力有可以很好的满足不同业务、不同部门或团队的隔离需求。

有了这些能力，在响应业务需求时，将只专注于业务的实现，不再考虑平台、存储、框架等，服务中台的服务组合和编排可以迅速的实现业务服务，使业务人员能抓住业务时机，及时为客户提供合适业务服务，留住老客户，赢得新客户。

2．对于IT系统的好处

在建设容器云之后，我们关注的将是一个个业务应用，不再是一个个IT系统。所有的业务应用构成一个企业级的IT系统，是一个整体，一个生态系统。公共的服务、公共的组件是共享的，不再有重复的建设。比如日志，传统单体应用每个系统都需要有日志模块，导致重复和冗余，也造成很多的不一致和数据隔离，给综合的长期的业务分析造成麻烦。基于容器云的IT生态系统，只有一套日志组件服务，它可能有很多个日志服务实例，基于分布式部署在容器云平台。其他组件服务和业务应用服务也是一样。比如消息服务，为整个企业提供消息的发布、订阅提供支持，对接不同的渠道，如手机App、微信、短信、网站应用等。任何一个业务应用或者新的业务需求需要用到消息服务，直接就可以通过消息服务API实现快速集成，不用再开发自己的消息服务。这将节省大量的工作量，从而提高响应速度和节约成本。

3．对于运维人员的好处

采用容器云平台之后，运维人员职责可能划分为资源运维和应用运维。资源运维人员专注于IT基础设施资源的运营维护，为应用服务提供计算、存储、网络等资源。应用运维人员也可能由应用开发人员兼任，实现业务应用的自动化运维监控。健康检查、日志、监控、告警、反馈自动化。通过自动化流程和工具来解放运维，帮助快速定位异常、快速反馈、快速的解决问题。

这样各司其职，资源运维人员不会因为应用的缺陷被抱怨，应用运维人员对自己开发的业务应用熟悉，又可利用自身的技术能力选择、开发合适的运维工具来支持应用运维。

4．对研发人员的好处

容器云平台为研发人员提供了持续集成的平台和一致性的环境，不用再花时间去搭建基础开发环境、测试环境，可能几天的准备工作可以在分钟级内完成。开发人员可以专注于业务应用的开发，不用考虑底层数据的存储、模型、系统的架构、部署方式等等，只需要考虑如何使用服务中台的服务来构建业务应用。不但简化了开发、提高了对业务响应能力，而且标准化、规范化、一致性的接口服务对普通开发人员的能力要求降低，学习成本减少。

三、重大风险揭示与管理

风险总是无处不在。容器云有诸多好处，但采用和实施容器云也存在不少风险。容器技术是新兴开源技术，发展变化快，首先存在技术风险。发展变化快意味着很多人可能跟不上技术的变化，技能和经验不足，缺乏深入的认知。这是人力风险。对于新的开源技术，企业往往认识和投入不足，缺乏好的实践案例，从技术成熟到真正落地，往往需要一到几年的时间。

1. 技术风险

容器技术出现也就短短几年时间，仍在不断的发展变化。开源的技术容易凝聚大家的智慧，但同时也由于考虑问题的角度不同，也造成开源技术的大杂烩，为技术选型带来纷扰。

去年我们考虑采用容器技术并开始选型时，面临着Mesos、Docker Swarm、Kubernetes等容器调度管理框架的选择。但等我们完成PoC测试、Mesos和Docker Swarm已经没落，国内所有的容器厂商都转向Kubernetes。快速的技术变化，为项目的选型和建设带来一些问题。错误的选型可能为后期的运维带来难题。

容器技术是开源技术，开源社区和商业企业关注点不同，社区开源版本相对于商业企业版本往往缺乏强力的支持。

容器云技术又涉及众多的组件，众多的技术，不仅仅是Docker + Kubernetes，网络、存储、日志、监控、安全、微服务等等，要想一下子全部掌握很难，存在技术风险。

2. 人力风险

容器云是一个基础设施平台，需要相应的基础组件服务支撑才能真正的实现轻量化PaaS，如果仅仅是Docker + Kubernetes，其不足以支撑企业的业务应用开发和运维等需求。但目前国内整个一个容器云市场的认识还大多停留在Docker + Kubernetes，甚至把Kubernetes等同于容器云。认知和技术的不成熟可能是容器云建设失败的主要原因。

人员技能和经验不足，使容器云项目实施存在诸多变量。大部分人都是一知半解，缺少实践经验。在实际的项目中，如果没有一个在过往经验上、技术上和管理上掌控全局的人员，容器云项目是不会成功的。

IT项目上，人是最大的不可控因素。项目人员的技能是否匹配、主观能动性能否发挥、责任心是否具备、人员的流动、对项目的理解、认知、把控是否到位等等都影响着项目的质量。

3. 资金投入不足风险

目前大部分企业对新技术存在怀疑，投入与支持不足。很多企业都是在做PoC测试验证，或者实施一个小项目做个试点。这限制了容器云基础设施平台的完整搭建，也无法真正体现出容器云平台的优势。只有在有一定规模的基础上，实现了或者部分实现了服务中台的能力，才能真正表现出其价值和能力。

4. 如何避免这些风险

为避免上述风险，我司建议采用购买或者合作研发容器云产品的方式来实施容器云项目。我们可以提供产品研发的详细需求、使用场景、架构设计和详细设计，支持容器云厂商基于这些需求、场景、设计来实现，如果最终产品满足要求则进入招标候选厂商。这样对容器云厂商来说是一个完善产品，领先同行的机会，对我司来说，可以避免一定的风险和节省成本。

1) 产品要求

我们要求厂商提供的产品能基本满足我们的需求，对于不满足的部分在后期必须实现并交付使用。对于我们在使用过程中可能需要做一些定制化更改需求，可以友好协商，支付一定的额外报酬，后续分期完善。对产品的缺陷，要及时修正，不能影响到我们业务的正常运行。对于超出能力不能及时修复的缺陷，要找到相应的解决办法。另外要求产品各组件之间是松耦合的架构，方便更新替换。

2) 产品安装、部署、升级、迁移

容器技术属于新兴技术，虽然已经逐步成熟，但仍在迅速发展变化之中，各种组件不断的涌现，所以我们要求产品必须能支持不同系统平台之上的安装、部署，支持物理机、虚拟机等系统；容器云容器引擎及容器管理调度系统能够及时的提供无缝升级、迁移能力；提供升级、迁移预案，识别潜在风险并能规避这些风险。

3) 后期需求及新特性开发，定制开发

产品不可能满足我们所有需求，因此在我们使用一段时候后会根据各团队使用情况的反馈意见提出新的修改及新特性的需求。对于非缺陷性的新功能需求，我们可以基于协商的基础上支付一定的合理的研发费用。

4) 技术支持

产品使用初期可能需要提供现场服务支持，后期可提供远程服务支持。在产品使用过程中如果有重大缺陷引起的重大事故，厂商必须安排技术人员在2小时内达到现场解决问题。并需要在24小时内修复缺陷，完成部署。

5) 高可用要求

对于产品的关键组件实现高可用部署，同时提供潜在风险点的备份机制。

• 支持平台控制节点高可用；

• 支持应用服务高可用部署；

• 支持镜像仓库高可用；

• 支持负载均衡高可用；

• 平台控制节点宕机不能影响容器中服务的正常运行

四、预算评估

本项目预算XX万元，用于购置服务器硬件、容器云软件产品授权及实施服务，详见下表：

如前所述，我们建议选择相对成熟的产品，避免项目形式交付，人是最大的变量，最大的不可控因素，所以尽可能减少人的变量，减小风险，从而使成本可控。

经过2次询价和多次沟通交流，容器云产品软件一套约XX万元，另外按节点数量产生授权使用费用，每节点约XX万元，根据节点数的量提供一定的折扣比例。容器云产品部署、配置、测试、调试等实施费用约XX万元。服务器硬件根据应用部署需求确定，目前需要X台PC服务器，XXXG内存和XX颗Xeon 6150 CPU，以及硬盘、网卡等（如上表）。容器云厂商后期服务费首年免费，后期约按项目总额的10%-20%收取。经过总的测算，以目前的需求，实施容器云项目总预算包含软硬件、实施和3年维保服务大概在XX万。不同的厂商价格会有差别。

五、关键技术路线选型

在规划容器云项目的时候面对多个技术路线选择，首先是容器引擎技术，容器编排调度技术、微服务框架等。

1. 容器引擎

容器引擎技术主要有Docker公司的docker引擎和CentOs的rkt引擎，rkt理论上在安全性和兼容性方面更好，但缺乏生产实践，目前用户大部分使用Docker。Docker社区也更活跃，这可能跟Docker发布比较早和参与的人更多有关。目前大部分容器厂商都首选Docker支持，rkt的成熟度仍显不足，因此容器引擎我们选择Docker引擎。

2. 容器编排调度框架

容器编排调度框架主要有Mesos、Docker Swarm、Kubernetes、Openshift等。

Docker Swarm简单易用。原生支持Docker，安装Docker后开启Swarm模式即可使用。比较适合小型的集群管理。

Kubernetes除支持主流Docker容器（需单独安装Docker组件）以外也支持CoreOS rkt等容器技术，目前社区最活跃，受厂商支持也最多，基本上所有的容器云厂商都已转向支持Kubernetes。

Mesos上无需安装docker程序也可以运行docker容器，mesos可以自己解析docker镜像来启动容器。Mesos应该来说更成熟，Kubernetes已经测试了数千个节点，而Mesos已经测试了成千上万的节点。Mesos社区不再活跃，对超大集群的支持Mesos更合适。

Openshift是Redhat基于Docker和Kubernetes之上做了封装的开源容器应用平台。RedHat增加了很多新的特性以支持应用的快速开发、部署、扩展等生命周期管理能力。Openshift的实施一般是由RedHat合作伙伴执行。合作伙伴的能力决定着项目的质量。

考虑到技术的快速变化，为了后期升级维护的需要，适合选择社区活跃、支持度高的容器编排调度框架，综合考虑，Kubernetes或者Openshift是目前比较好的选择。

3. 微服务框架

目前比较流行的微服务框架是SpringCloud和Dubbo。SpringCloud是Pivotal公司基于SpringBoot框架的基础上推出的微服务开发开源框架，它提供相对完善的服务配置、注册发现、服务网关、服务消息总线、熔断、日志收集等能力。Dubbo是阿里公司的开源产品，相对简单，国内用的较多，但中断了一段时间维护，缺乏Pivotal公司系统的支持能力。阿里的产品总的来说是阿里自身需求的结果，所以往往缺乏标准化规范化的考虑，只是为了追求某方面的性能。综合来看，选择SpringCloud来开发微服务是比较好的选择。

六、可行性评估结果及建议

基于以上的分析评估，我们建议可以尽快采用容器云技术实施容器云。以尽快搭建公司私有容器云基础设施平台，建设持续集成、持续部署、持续反馈的闭环应用研发流程。提升公司自主研发能力，提高对业务需求的响应能力。采用购买产品的方式来建设公司容器云平台，避免项目周期长带来的技术风险和人力风险。

（原题：容器云平台可行性评估）

扩展阅读：

更多相关内容请点击阅读原文

长按二维码关注公众号