达观动态

容器技术的火爆和日益普及已经成为不争的事实，众多公有云平台纷纷支持Docker，AWS、Google、Azure、阿里云以及国内的各大公有云厂商都推出了容器云业务，国内也有不少创业公司通过构建容器Paas平台帮助企业实现微服务架构改造。

达观数据作为领先的人工智能企业，在容器技术领域也积累了比较多的实践经验。达观提供的文本挖掘、智能推荐、垂直搜索，无论是公有云服务，或者私有化部署，主要是基于容器云实现，从而保证部署的高效率、服务的稳定性、快速可扩展性和应用的隔离性，为我们的客户提供了持续升级的长久稳定服务。

发布一个应用的经典过程一般是这样：首先要在测试服务器上进行开发，配置环境依赖并测通；再到生产环境中，为一台台服务器配置环境依赖并部署应用。即使现在已经进入云计算时代，整个发布过程依然没有太大变化。当我们有大量架构迥异的应用服务，需要发布到多种环境，如本地环境、虚拟机环境、公有云环境等等，底层使用的又是各种不同类型的硬件，稍有不慎就会导致发布失败。

图 1 异构应用部署到多样硬件的问题

从下面的矩阵图可以更直观的感受到我们面对的困难之大，矩阵的列代表不同的硬件环境，行代表各种应用/服务。矩阵列出了一个应用的发布或者重构所要考虑的复杂情况，不管是应用的开发人员，还是系统运维人员，都必须从一开始就要考虑复杂环境带来的问题，以保证发布和升级的顺利。

图 2 异构应用和多样硬件矩阵

解决这个问题的思路非常有意思。Docker公司给出了非常形象的比喻：集装箱运输。1960年之前的全球化运输过程如下图所示，不同的货物和不同的运输方式也构成了一个庞大的矩阵。托运货物的人，和搬运工会担心不同类型的货物放在一起会造成相互碰撞、挤压导致损坏。

然而将不同货物分类进行运输是一种非常高成本、低效率的解决方式，货物在运输途中可能需要在某个港口卸货，与来自其他地方的同类型货物一起装车，再运到下一个目的地。整个运输过程导致大量的货物被损坏，或者被盗。

图 3 1960年以前的货物运输

全球化运输现在已经不是问题，各个港口整齐堆放的集装箱就是完美的解决方案。各种类型的货物，小到奶粉、化妆品，大到特斯拉跑车，都可以被装箱到一个标准的集装箱内。托运货物的人只需要保证货物在集装箱内的密封和固定，而无需关心集装箱如何被摆放和运输。

负责运输的人则无需关心一个个集装箱内装的不同货物，只需把集装箱当做一个封闭、无差别的独立个体，进行装载，卸货，堆放，运输，整个过程中集装箱保持封闭状态直到被运送到目的地。从轮船到火车，再到卡车运输，都可以利用起重机（吊车）对集装箱进行操作，实现流程的自动化，从而以非常廉价的方式，有效解决了不同类型货物在长距离运输中的问题。

图 4 标准化集装箱解决运输问题

将Docker比喻为代码方面的集装箱综合运输系统，确实非常形象而恰当。Docker将任何类型的应用（货物）和它的依赖打包成为一个标准的，轻量级的，便携的，独立的集装箱，让各类应用都支持一套标准的运作模式，只要安装了Docker程序的服务器都可以运行。

开发者在笔记本上开发和测试完成的Docker容器，可以无差别的运行在测试环境、生产环境，无论服务器是物理机、虚拟机、公有云服务器上，或者是以上各种类型服务器的组合。应用开发过程只需执行一次，即可保证应用在任何环境上运行的一致性。对于运维人员，则只需要配置一次不同环境的服务器，即可运行任何Docker容器，不管容器是web服务还是api系统，规避了传统部署方式中开发、测试、生产和其他环境的不一致性问题。

图 5 标准化的Docker技术解决代码“运输”问题

Docker技术的有多重特点和优势，我们基于实践经验进行简单总结，其在实际应用中体现出的主要特性有以下三个方面：

前面已经提到，传统的开发和部署的生命周期中，常常因为不同环境的细微差异导致应用运行失败，例如依赖的缺失或者版本不匹配。Docker的出现很好的解决了这一问题，保证了从开发、测试到部署的环境一致性。Docker将应用和所需的配置和依赖一起打包到镜像中，在不同环境中只要使用同一个镜像，即可保证应用的正常运行，无需其他人工干预，这也是Docker对开发和运维人员都有巨大吸引力的原因。

Docker不同容器志坚是相互隔离的，每个容器使用自己的环境和资源。使用不同堆栈的应用程序基于Docker可以运行在同一个宿主机上，相互之间不会产生影响，也就不会产生使用源码部署常常会遇到的依赖相互冲突的问题。使用源码部署的另一个问题，是当从宿主机上删除应用的时候，删除依赖的时候就需要考虑是否有别的应用也在使用，经常导致误删依赖影响其他应用，或者忘记删除无用的依赖。基于Docker则不会有此类问题，当我们不再需要某个应用的时候，可以简单的通过删除容器，则应用的代码和依赖会作为一个整体一并删除，同时也不影响其他应用。

Docker另一个重要功能，是提供了类似git仓库一样的镜像仓库Docker hub，支持开发人员将镜像的变更提交到Docker hub仓库，并通过版本号进行管理。发布变更的时候也只需要修改镜像版本号并重启容器，假设发布的变更引入了一个bug，也可以非常快速的回滚到前一个版本。相比虚拟机，Docker的启动和停止非常快速，如同运行一个进程一般，整个变更的过程往往只需几分钟时间。

传统的虚拟机通过硬件虚拟化创造一个虚拟的系统，每个虚拟机都有自己的内存、硬盘和操作系统，预分配的资源会被虚拟机完全占用。使用虚拟机来隔离应用会造成比较大的资源浪费，一个应用加上依赖只有几十到几百M的大小，而操作系统往往还需要消耗10G左右容量。

图 6 容器技术和虚拟机的对比

上图展示了容器技术和虚拟机的区别。容器包含了应用和所需的依赖，但不需要独占资源，没有一个虚拟系统，而是和宿主机共享硬件资源和操作系统，和其他容器共享内核，从而实现资源的动态分配。多个容器在同一个宿主机操作系统中的用户空间以独立的进程运行。因此，容器相比虚拟机要轻量许多，在一个主机上可以同时启动近百个容器，一个应用要在数量上横向扩展非常便捷，而虚拟机则几乎不可能启动同样多的数量。对于重启操作，容器近似于重启一个进程，而虚拟机则相当于重启操作系统。

随着容器技术的日益成熟，微服务架构也有了越来越多的实践落地。传统集中式架构开发的大型应用，比如CRM、ERP等系统，在今天看来已经显得过于庞大复杂，缺乏灵活性，随着新需求的不断出现，对集中式架构的升级和调整变得日益困难，比如修改原有系统以适配移动设备。技术层面上，现在已经有大量的轻量级开源技术，包括容器技术，在互联网、云计算、人工智能领域被大量运用，催生了微服务架构的出现。下图展示了服务架构的演变。

图 7 软件系统架构演变

微服务架构是指一个较为复杂的应用由多个相对“微小”的服务组成，每个微服务只负责完成一个特定的任务，可以被独立部署，支持快速的横向扩展。各个微服务之间以松耦合的方式相互配合，不同的服务可以部署在不同的服务器上。每个微服务将相关的业务逻辑和数据放在一起，可以看作是整个应用的组件，可以被独立升级甚至替换。这样做的好处是保证各个微服务相互独立，从而实现快速交付和迭代升级。

Docker容器技术的特性使其天然地适用于微服务的落地实现，一个容器实现一个微服务，在服务器集群上运行各个微服务容器，来构建一套完整的应用。为了支持多租户，甚至可以部署多套完全相同的应用，每套应用服务一个或一部分租户，应用之间相互隔离，应用的资源也按照租户的使用量来分配。

当容器和服务器的数量达到一定规模的时候，就会碰到管理的问题，即如何有效管理大量的服务器和容器，保证应用的稳定运行、方便升级和故障的快速解决。容器编排工具提供图形化界面或者命令行来管理容器和服务器集群，提供容器配置、任务发布、服务发现、负载均衡、系统监控和故障恢复、声明式系统配置以及有关容器部署和性能的规则和约束定义机制等。

从最新趋势来看，Google开发的Kubernetes从众多编排工具中脱颖而出，赢下了容器编排工具大战。基于达观数据自身的容器实践经验，Kubernetes是所有编排工具中稳定性最高的，尤其是在管理较大规模的容器集群时，这和业界同行的实践经验基本吻合。Kubernetes针对pods进行调度，pod是最小的基本单位。一个pod封装一个或多个容器、存储资源、一个独立的网络IP以及管理控制容器运行的策略。Pod封装的多个容器一定是紧耦合的，它们之间能共享资源。

相比Kubernetes，Docker原生编排工具Swarm在集群搭建和使用上要相对简单一些，学习和部署成本相对低一些。较新版本的Docker已经集成了Swarm。Swarm支持跨多个主机进行编排，管理较小规模的容器集群也绰绰有余，对于初学者也可以很快的部署和运行。

容器技术为软件开发和系统运维带来了颠覆性的突破，在达观数据的客户中，不管是新晋的互联网企业，还是久居行业重心的传统企业，都纷纷拥抱容器技术，开启了系统架构的容器化升级和微服务转型。如此大规模的不分行业的普及，足以预示容器技术无可限量的发展前景，而随着容器技术的普及，系统开发和管理的效率必将上升到一个新的台阶，为企业带来效益的提升。