从标准上对容器做了一个定义，容器相当于寄宿于操作系统的一组进程，为应用提供相互隔离的运行环境，可以做到自动弹性伸缩。作为我们业界首个容器的评估标准，突破了传统的产品性的评估标准，从可交付的应用场景出发，去梳理整个评估的指标。

谢谢大家、谢谢李处，感谢各位同仁今天下午过来我们的分论坛。今天演讲的大概内容是把我们可信云科研解决方案这一部分给大家做一个简单的介绍。可信云的开源解决方案一共来说包含了两部分，刚刚看到披露的结果，其实包含OpenStack和容器两个部分。容器是在2016年开始做，主要是面向于开源的云结算解决方案为主是Open Stack。去年年底我们也开始做容器的，这两年容器技术太火了，Docme、包括DCUS等等。大家对容器技术关注的比较高。

我看一下我们可信云的评估标准体系，可信云现在目前发展到3.0的一个现状，从可信云通2013年开始做到2014年底到2017年年底，也是涵盖了国内185个云服务，也得到市场的广泛认可。随着服务的增加、包括咱们企业自身的业务的全面拓展，也需要进一步的细分市场。借助我们原来可信云的平台建立了一个全新面向私有云解决方案的评估体系。

大概看一下评估的市场的分析，据我们中国信通院的数据调查是2016年中国私有云大概300多亿，相比2015年是增加了25%，这数据相当高了。预计在2017年到2020年的话，大概市场规模是在762亿左右，整个市场规模是成倍的翻。

再看一下具体在详细的话，硬件、软件和U这三部分，2016年的私有云硬件市场247亿还是占据第一为的，占比是71.7%，软件市场规模53.1%，整个的服务市场规模是44.5个亿，跟2015年相比的话，不管是硬件市场同比是下降的，软件和服务同比增长的。数据也是明确地说这私有云的下整个市场规模是在逐年递增的。

我们从评估范围来讲的话，我们首先第一个先定位在开源的领域，为什么选择开源领域呢？就是以我们的了解就是目前在云计算领域开源技术在云计算应用相对比较广泛的。第二个是说在开源解决方案里面，它对企业的研发能力都是有一定的要求。这导致了服务水平的参差不齐。就是整个市场是亟待去规范的。

第三个考量的话，我们是通过开源切入再逐步的扩充私有云整个解决方案和评估。私有云解决方案的评估，我们主要从几个方面，第一个还是S层虚拟化和虚拟管理技术，从虚拟化来讲，包括Vmware Xne KVM五、 HYPE的主流技术，虚拟化就是Cloud Stack还有Open Stack的等等。还包括一些创业公司、有一些虚拟化的管理软件。容器技术和编排的技术是在我们整个评估的范围里，包括比较仍的Docker还有K8S还有Mesos还有Swarm，除此之外我们还会持续的跟进云计算的关键技术，可能会面向于一些特定场景厂商提供的解决方案。

我们大家知道私有云解决方案和传统的软件或者是公有云服务部太一样，私有云至少包含两部分，软件和服务，还包含一些集成和定制化。在服务里面的话像软件、架构、部署、协同还有验证、运维升级都是需要去考虑的问题。包括一些前期的规划、咨询，这一些都是要考虑进去的。

所以我们评估的标准还是说在三个方面去做一个约束或者是要求，第一部分就是企业资质和业务的基本信息，这一块主要还是对于整个公司的，不管是从硬实力还是软实力提出一个要求，第二是解决方案质量评价，这就是面向产品的。第三个是服务完备性和规范性这一块的话更多去关注在用户的售前和售后，包括一些SOA约束。

去年Open Stack的评估的流程，Open Stack是私有云，所以我们的测试也是通过现场部署的方式，厂商入场测试，大概人员是3到5个人不等，测试周期一般是5个工作日这样。它所涉及具体的指标项，包括平台技术功能还有运维系统功能还有高可用、安全性、资源调配能力还有互操作性、还有异构虚拟化还有资源调度效率。其中互操作和调度效率它的测试规范和Open Stack社区是保持同步的。

这一页是具体详细的指标，大家可以看到平台的技术功能包含生命周期，虚拟机生命周期还有住户，运几包括资源的监控、故障管理、日志管理，高可用是第一个要保证这是有数据冗余的站位，同时还要保证物理机和虚拟机两种高可用。资源调度效率的话，我们是社区提供的测试工具，对于虚拟机券、网络我们目前仅仅限于说对于虚拟机层面的操作，因为网络比较复杂取决于不同的测试环境、各家的网络架构是不一样，所以我们目前是对于虚拟机资源的一个要求。

以我们的实际测试大概是10个物理节点，我们可能要求上来讲是相对于其他企业自身测试版，要求还比较严格，我们并发是必须要求600，大概资源消耗也在一定程度上考验厂商的调配能力。

异构虚拟化主要是从两个方面，第一个是异构虚拟化主题，第二个异构虚拟化存储。虚拟化主题至少是主持VAMOS不管是（英文） 这种设备型号种类比较多，所以这是我们目前采用厂商自愿披露的方式。资源调配这就没什么可讲了，支持那种虚拟机的升配、降配，还有一个网络QS的调整。安全性至少在管理网和业务网还有一些像前端的WEB应用没有高危的漏洞。互操作性是按照社区来相对于社区来讲它是两个部分，一个是（英文）一个是（英文）要求五个核心组件（英文）这必须过互操作性的。

2016年我们整体通过的企业是11家，大家可以看到名单上第一个是优名、第二哗山、云途腾、易捷思达、烽火、华为、中联、航天、云基数、无锡华云等。2017年刚刚看到颁奖的环节就是新增了四家，他们是上海仪电、赛特斯、北京国电通、浪潮软件。

从我们前期的十几家人员数据提炼，我们大概可以看到这一些厂商采用的Open Stack的版本，其中可以看到用Kilo前期有一家，因为他们在前期版本做了很多的投入，更多厂商都是基于Liberty，这版本有很多，最新的是这一批才出现的有厂商，就是基于这两个版本来做的。

运维系统的话，我们包括集成第三方的运维系统基本上是以Zabbix系统，有两个自研或者包装成独立的产品，还有一些其他的运维系统。部署方式普遍是采用容器化的方式去部署，通过容器快速的部署起来，UI大家都知道是提供工具，像华为自身也有部署的工具。另外有几家是基于脚本化的部署还有进项的ISO文件去布一个主控。从以上的数据可以看到基于Liberty比较多，国内就是每两个版本更新一次，我们从整体来看的话，国内的研发实力是在逐步提升，社区的贡献度也是在空前的高涨，今年像中国电信和浪潮都已经进入了Open Stack社区黄金会员。 第三个两看产品集成度是在逐步的完善，还有一些增强的特性也是在增强。

下面来看我的容器的解决方案评估，容器解决方案跟Open Stack不太一样，它是按照实际的解决方案应用的场景来去做评估的。当然我们会看到下面基本能力的要求，第二是应用场景指标和容器安全要求这三部分。应用场景是按照实际上这容器一般在什么情况下，和典型业务场景下运用到的一些场景去做这种评估。不同的场景也会有指标上的一个交集，但是它的侧重可能不太一样。我们的应用场景指标至少是说满足其中的一项，大家可以看到这四个场景依次是开发测试环境、持续集成CI、运维自动化和微服务。

容器的基础功能要求，第一个像容器网络、容器存储、容器编排、容器调度、容器伸缩、容器高可用，不管在任何场景下你作为一个容器解决方案是要满足的指标，容器网络化其实就是跨物理网络化、跨Iaas网络两个要求。存储其实就是一个简单的券的管理，对于创建券和挂载券和删除的一个操作。容器编排至少通过UI的方式可以把多个容器或者多个应用去组合起来，去统一发布。容器的调度至少支持一些常见的调度酸雨，包括轮询、性能、亲和和标签化。容器的伸缩是在你需要在保证业务连续性，能够实现容器的一个弹性的伸缩。容器高可用性是在故障发生时能够做自动的转移，转移恢复还有一个故障容器它是去主动摘除故障节点。

开发测试环境的话，它是像服务目录，就是说通过服务目录来去简化这编排，你去提高交付的一个效率，特别是说在简化复杂集群的编排上区市县服务目录，对于整个开发测试是非常有效的。

第二个是代码发布就是支持本地的代码到容器中。权限管理就是平台具备至少两个角色，第一个撇管理员，可以跨部门或者跨角色的交付、协同。环境销毁是在物理换下是物理删除的。下一个是持续集成、持续消费。代码版本管理就是具备集成企业自身管理的系统。比如说SBN或者GET能体验目前用到代码版本去做一个集成。构建镜像是支持容器的镜像。自动部署就是调用容器部署能力的时候能够把整个的环境部署起来用于测试。环境销毁其实是跟刚刚开发测试差不多，并行测试是在整个CI构建项目中能够对多个分支进行并行的测试。度量系统是支持CICD它在过程中对数据比如说构建的版本和构建的速度和数量进行一个统一的展示。开放性是指对于第三分的GIT、JenKins Maven做一个集成。

运维自动化必须支持整个应用的整体升极和滚动升极。滚动升级是按照不同的步长是按比例或者是按数量去支持这种快速的回滚和发布。配置变更就是CIBB能够在配置像类似于配比，健康检查就是能够对容器的状态的检查。日志管理是平台具备这种搜集聚合、检索等一些常见的功能。监控报警是对主机或者容器资源超过设定的阀值会有一个告警通知。

讲最后一个就是微服务，像微服务编排能够支持多个微服务的统一的编排，服务注册多个微服务它的一个创建和调用你能够去自动的注册。服务调动多个微服务之间的通过Rest和Rpc接口做调用，还有服务限流就是保证在特定的微服务，它会对你的访问流量和并发做一个统一的限制，这样防止核心业务突发的大的流量导致整个系统的一个崩溃。服务熔断就是说在微服务里面，这服务熔断是相对来说比较，也体现了微服务整个的架构，它部分的微服务如果是中断或者是故障，它不会影响全局的。服务容错是指微服务应该具备容错能力，当某个服务发生问题其他服务可以在应用层面实现平滑过渡，而不是直接报一个400或者500的方式。链路追踪分析是微服务里面，我觉得必不可少的，因为在微服务的架构里面应用特别的分散，需要你去监控每一个微服务的链路分析和它一个健康情况，包括你这样才能出现故障及时的排除问题。

容器的安全指标目前来说是我们在做标准的时候，已经考虑到的，是跟laas结合跟递增的结合，哪一些安全是容器应该具备，或者跟容器没有关系，我们尽量把它提出来，至少在我们的多次讨论中其实看到容器具备的第一个容器扫描，还有很多方式容器的数字签名、日志的审计、用户的权限，包括容器本身资源配额的管理。

说了这么多，我们这一次测试情况大概做一个汇报，因为容器它本身就是轻量化的，我们在测试环境下其实没有太多要求，既可以在铺在公有云，也可以在本地的环境，我们保证测试地是相同的就可以。今年是首批做了容器解决方案的预评估，我们首批产品厂商大概是七八个，最后实际来得是五个，这五个对于四个应用场景支持的程度还不太一样，我们今天结果这五家，一个是新华三一个上海七牛、烽火、还有中兴、云栈科技。

从我们对容器解决方案评估中目前来说这基数比较小，所以我们能提炼出来的数据也相对较少一点，我们涉及到一个容器的编排技术，其实就是更多基于Kubernets还有Mesos，其实像Kubernets还是呈现出不懂的阵营，容器技术本身都是默认采用Docker的。从我们这一些应用场景是有不同的，开发测试环境和运动维智能化这一些都是支持，最后一个是微服务，比较相对来说是没那么容易实现，或者说做的可能目前来说集成化还不是太好。

好，我的介绍就到这里，谢谢大家。