随着Docker容器的兴起，云原生应用越来越流行。事实上，云原生应用的设计理念和原则，在Docker产生之前就已经被软件架构大师们提出来，只不过在容器出现之前，以虚拟机镜像为基础的应用打包发布方式开销过大，普通开发人员较少使用，流行不起来。以云原生应用的核心设计原则12要素来看，我们可以发现Docker正是在设计中融入了对云原生应用的深层支持，才得以风靡软件的世界。随着对12要素的理解加深，我们也同时会发现12要素之间的彼此联系紧密，是围绕一个核心目标的12项具体指导原则。而这个核心目标就是提高应用的可移植性和移动性。
XDocker对12要素的支持
基准代码
应用有一套基准代码，可以部署到多种环境中。这样可以保证同一套代码容易迁移到不同环境中去运行。
在Docker的体系中，Dockerfile与也是基准代码的一部分，跟应用业务代码保存在同一个代码仓库中，用同一套版本标号。基于Docker体系交付的软件产品不再是一个可执行程序，而是一个Docker镜像。Docker镜像的移动性比传统的可执行程序高得多。
依赖
应用要清楚地声明和隔离自己依赖的程序库。这样才能保证应用移动到其他环境时，自己所依赖的程序库也正常运行，并且与环境中其他软件不互相干扰。
Docker通过Dockerfile中的命令将自己依赖的程序声明出来，并通过dockerbuild命令将这些依赖的程序库打包到交付的Docker镜像中。
配置
运行时配置要存储到运行时环境中。一个应用的行为逻辑受两方面因素控制，一方面因素是代码，另一方面因素是配置；代码是与运行时环境无关的，要保存在应用开发的代码仓库中，而配置是与运行时环境相关的。将配置存储到运行时环境中保证了配置与环境的一致性。
Docker在Dockerfile中用ENV命令声明自己运行时所依赖的环境
变量和环境变量的默认值，在docker run命令的--env参数可以在运行时设定环境变量的值。
后端支撑服务
将数据库、缓存、消息队列服务这些后台支撑服务当作可挂载的资源。保证这些后端支撑服务对应用业务完全透明，应用只是把这些服务当作一种透明的资源来使用，这样更换环境部署应用只需要更改与资源相关的环境变量。
在Docker体系中，通行的做法正是将数据库、缓存和消息队列等后台支撑服务当作资源在Docker容器运行时挂载。而应用程序在构建镜像时，需要将所需要的资源的环境变量用ENV声明出来，在容器运行时，实际环境中的资源环境变量则以--env参数的方式设置到容器中。
构建发布运行
严格区分构建和运行这两个不同的阶段。通过清楚地区分构建期和运行期两个阶段，对应的软件控制因素也清楚地分为代码和配置两类；代码在构建完成后是不会改变的，而且一套代码可以自由地部署到多套环境中去运行，不同环境中应用软件运行所需要改变的仅仅是配置。
在Docker体系中，构建器的“代码”不仅仅是应用程序编程语言的代码（例如Java，C，Python等），也包括这些代码运行时所固定依赖的程序库和这些程序库的“静态配置”。称其为“静态配置”主要是指这些配置不会因为部署环境的改变而改变，因此这些“静态配置”实际上成为的Docker镜像的“代码”。因此，对Docker镜像来说，应用业务代码和静态配置都是“代码”；只有根据部署环境可能变动的“动态配置”，才是真正的“配置”，而这些配置对应了Docker运行时的环境变量。
进程
将应用作为无状态的进程来运行。无状态进程保证应用可以随时启动和关闭，随时根据业务压力而增加或减少运行实例数，保证应用的移动性。
由于Docker容器技术相对于虚拟机技术来说，大大降低了运行应用实例的开销，提高了启动和关闭应用实例的速度，应用Docker体系发布的应用与无状态应用的模型更加匹配。
端口绑定
通过端口绑定来发布服务。保证一个应用服务在不同的运行环境中，可以用指定的任何端口来发布，这也是提高应用移动性的一个重要原则。
Docker在Dockerfile中用EXPOSE命令声明自己运行时容器所要发布的端口，在dockerrun命令的-p参数可以指定主机上发布服务的端口与容器端口的映射，这样的设计帮助应用开发者自然而然的实现云原生应用对端口绑定的要求：内部的端口在构建期决定，而对外发布的实际端口在在运行环境中决定。
并发
可以通过水平伸缩应用的进程数来增大或缩小系统的容量。
如前所述，Docker容器的设计保证了水平伸缩的高效率。
可丢弃性
应用进程可以快速启动也可以优雅地关闭。
Docker容器在快速启动和优雅关闭方面的效率要大大高于传统虚拟机，使得结合Docker容器实现应用的可丢弃性成为自然而然的事情。
开发生产对等
保持开发环境、测试环境、预发布环境和生产环境尽量一致。保持各种环境一致，才能减少因为环境不一致造成的与业务代码无关的错误，提高应用的可移动性。
Docker容器流行起来的一大原因，就是它将应用程序所依赖的程序库以及这些程序库的“静态配置”一并打包成Docker镜像，以Docker镜像部署到不同的环境中，从而大大减少了不同环境上应用的差别，保证了一次构建，任何地方部署运行。
日志
将日志以带时间戳的事件流方式来管理。把日志当作事件流来管理，实际是将日志作为结构化的数据而不是非结构化的文件来管理，这样使得日志方便在云环境中由云平台统一管理和分析；否则，在云环境中分布在各处各自为政的日志将给系统分析和排错打来极大困难。
Docker正是将日志以事件来管理的。利用dockerlogs命令可以查询指定容器的日志，同时，所有容器的日志正是以结构化JSON数据的格式默认保存在/var/lib/docker/containers//目录中。云平台管理软件可以统一管理处理相应的日志文件给用户提供方便的差错工具。
管理进程
将管理任务当作一次性任务来运行。这样保证所有的管理任务都是可以在云平台环境下自动化的，从而为大规模应用的自动运维，大幅度的自动伸缩提供了基础。
在Docker体系下，所有的管理工作都有相应的docker客户端命令和docker的RESTAPI服务提供支持，使得云平台可以通过调用命令行或REST API来管理容器。
Docker对云原生应用的构建和小规模测试有很好的支持，但是对于管理跨主机、大规模的云原生应用环境，Kubernetes则更为功能强大，我将在后文予以介绍。
参考：
http://
