前言
早在十多年前国内外的一些大厂就开始投入研发和使用容器技术，比如Google，对他们来说，使用容器能够充分利用计算资源节省硬件成本。而这几年——众所周知——真正把容器技术发扬光大的是Docker。Docker的slogan“Build，Ship & Run anywhere”定位非常清晰，Docker的出现打破了传统运维模式里从打包到部署的过程中环境、语言、平台不一致的乱象，将这一整套开发运维模式标准化了，从而真正帮助企业实践了DevOps和微服务化。
但是，国内的大型企业面临技术转型的的时候，历史包袱太沉重，对Docker的接受和部署非常缓慢。同样地，多数的中小型企业也并未把Docker作为生产环境上部署和管理服务的标配，而选择继续使用传统的运维方案。造成这种现象的原因是什么呢？可能原因之一是企业从业人员对Docker的学习认知并不够。之二是目前市面上Docker的容器编排系统很多，常见的就有K8s，Mesos，Swarm，Rancher，Newben，编排系统的学习和认知成本也进一步提升了企业应用Docker的难度。
企业为什么要使用Docker
这个问题的本质是企业用Docker究竟能做什么，要回答这个问题，需要我们回归到Docker本身来分析。Docker本身只是提供了一个运行环境，除了把服务跑起来之外，要让多个服务容器协同起来工作，实际还需要一个容器编排系统。一般来说企业期望编排系统能帮助实现如下几个目的：
- 定义服务栈
提供一种机制，可以用配置文件来定义服务的网络端口，镜像及版本，在需要的时候通过配置可再现的创建出一整套服务。
- 服务发现、注册和注销
需要在创建服务后自动创建DNS记录用于访问相关容器，容器状态健康后注册SRV信息。
- 健康检查
可以精细化控制服务注册时机，以支持容器正常启动后的初始化完成后再注册服务，以对外提供稳定可用的服务。
- 自动扩容和缩容
实时监测容器CPU和内存使用情况，当容器平均性能指标超过阈值一段时间后启动自动扩容，创建更多容器以达到阈值要求，当没有主机资源运行新容器时，自动申请新主机。当一段时间负载持续低于阈值启动缩容优先删除新创建容器和主机，以释放资源和降低运营成本。
- 合理的调度
要求最大限度的榨取主机资源避免浪费，并可实现快速的创建容器，减少镜像拉取时间和磁盘空间浪费。
- 负载均衡和高可用
使用Docker的三个阶段
根据我们的观察，根据企业规模和阶段性需求的不同，在使用Docker技术的时候分了三个阶段来进行。
- 阶段一：利用开源工具实现一定功能
由于一个Docker容器只是一个（或一组）进程的封装，一个容器需要绑定宿主机的端口来向宿主机之外的网络提供服务，为了避免端口冲突，对于需要暴露端口的容器，Docker会随机绑定一个宿主机端口，这个时候就需要服务发现来帮助不同机器上的服务来进行通信了。举例一个简单的方案：Docker-discover和Docker-register。
这个方案提供了一套系统的几个基本功能：应用发布，服务发现，负载均衡和进程守护。除了提供一致的运行环境使服务的发布和回滚比较可控，这套简单的系统在发布流程上还是像传统运维一样需要远程执行脚本，功能比较简单，适用于小企业，随着后端系统成长起来，很快就不够用了。
- 阶段二：开源容器编排工具
第二个阶段是选择开源容器编排框架来管理，常见的开源容器编排工具有Kubernetes，Swarm和Mesos。市面上也有同时支持这三种开源容器编排引擎的容器管理打包方案，通常作为入门级容器管理平台使用。这种入门级的方案虽然是开源的，但技术上的文档明显欠缺，社区中的使用难题也很少有公司之外的contributor，当暴露一些难题的时候就很难解决，这点和Kubernetes有很大不同。
Kubernetes提供的是一个框架，要求使用者对他的组件有一定程度了解，使用之前需要不少配置工作，对Docker入门者来说，学习能力要求很高，不过好在社区有各种contributor，提供了很多帮助部署的installer。除了对学习能力有要求以外，对中小企业来说，对基础设施的投入肯定不如大企业，一般没有专人去熟悉Kubernetes这种大型开源项目。
当然，像Kubernetes这样的容器编排系统本身很复杂，体量很大，很多企业也出现过当丢包严重的时候问题排查起来很困难的局面，毕竟要深入到庞大的代码中定位问题本身就是件很不容易的事情。
虽然现在Kubernetes是容器调度主力军，但我们认为调度引擎是容器最核心的模块，在PaaS这个关键的云计算领域不应该由国外来主导，特别是在军工、政务、金融等领域，我们需要自主研发的调度引擎，只有这样我们才能掌握云计算基础架构的核心技术。于是就有了第三个阶段的使用建议：高定制化的容器云平台。
基于Docker的PaaS/CaaS平台
为了适应国内的企业需求，出现了很多运用Docker开源调度框架的容器云平台，这些平台大都有一个特点：“服务本地化，核心开源化”。我们认为这并不是真正的本地化，真正的本地化应该是在满足不同领域不同企业的上云和转型需求的同时能随时响应定制化需求。基于这样的思想，被称为“中国的K8s”的容器调度引擎Newben应运而生。
Newben是精灵云全自主研发的容器调度引擎，也是目前国内唯一自研引擎，具备多项技术专利和著作专利，定制能力强、支撑功能丰富，能为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能。如下图所示，将Newben、K8s、Mesos和Swarm进行详细对比，会发现Newben事实上吸取了各开源调度引擎的长处，在网络、服务发现、负载均衡、弹性伸缩、高可用、CI/CD集成、镜像集成、日志监控等方面都有着非常大的优势。
（Newben和开源容器调度框架的对比）
Ghostcloud EcOS平台是精灵云旗下的企业级容器云平台，内置自研容器调度引擎Newben，同时适配多种开源框架，如K8s、Swarm等。由Ghostcloud精灵云全自主研发的EcOS平台基于精灵云PaaS/CaaS云核心功能模块，能支持私有云和混合云部署，满足企业的容器云部署需求，为企业研发、运维及新业务上线部署提供了一整套解决方案和管理平台。不仅帮助企业大幅削减成本和提升效率，帮助传统企业加速所需业务互联网化进程，更能帮助互联网企业加快产品迭代，提高产品市场占有率。
（EcOS的平台架构）
GhostcloudEcOS的应用场景
Ghostcloud EcOS平台作为统一的平台, 可服务于多个解决方案，应用到政务、教育、金融、互联网、医疗等多个行业和领域。接下来我们以金融行业为例来说明。
（EcOS应用场景）
传统的金融行业受迫于银监会的要求（容器作为两项最核心技术之一被写入十三五规划）需要在企业内部推行云计算技术，同时互联网金融的爆发式增长，传统金融公司在技术上无法应对自如。蚂蚁金服和万达金融等大型互联网金融公司都在使用容器作为后台支撑平台，传统金融企业也需要类似的PaaS/CaaS平台，但是本身没有搭建和维护能力。
面对这些需求，需要从几个方面解决：
整合系统内部资源，推行基于容器的开发、测试、生产和运维一体的PaaS平台；
推行DevOps，开发运维一体化，降低运维成本；
推行敏捷和CI/CD，加快系统交付和部署；
使用基于容器的弹性负载均衡系统，适配突发流量；
加固开源容器系统，对镜像及镜像仓库进行私有化定制。
在具体的实施中，使用EcOS容器云平台，对仓库和镜像进行加固，在内网和公网环境混合管理做安全隔离，借助平台自带的CI/CD流程，标准化研发流程；借助EcOS的资源调度框架，动态资源调配。通过容器只暴露特定端口，提升了整个系统的安全性，系统开发速度和上线速度大幅度提升，团队整体响应速度也大幅度提升。通过商用Docker云平台，提升了IT部门的技术能力，更好的适应了未来业务发展需求，物理资源利用率提升，能够很好的应对突发的流量暴增，在有限资源下提升了系统并发量。
结语
国内的企业需要在使用Docker进程中选择更本土化的容器编排系统，只有拥有核心可控的技术才能真正开展云计算基础设施建设。推荐选择能针对个性化需求做定制化解决方案的PaaS/CaaS容器云平台——Ghostcloud EcOS。