从容器到微服务技术架构网络和生态详解.docx

从容器到微服务技术架构网络和生态详解.docx

《从容器到微服务技术架构网络和生态详解.docx》由会员分享，可在线阅读，更多相关《从容器到微服务技术架构网络和生态详解.docx（12页珍藏版）》请在冰点文库上搜索。

从容器到微服务技术架构网络和生态详解

从容器到微服务，技术架构、网络和生态详解

   谈起容器技术，不得不提Docker技术。

   Docker 是 PaaS 提供商 DotCloud 开源的一个高级容器引擎，源代码托管在 Github 上，基于Go语言并遵从Apache2.0协议开源。

Docker相当于物理行业的集装箱对物流的影响一样，成为Container上运行镜象的统一打包和交换的标准。

   我们知道，Docker使用了容器的环境隔离和资源限制技术，把镜像和运行环境打包到Image中。

Register支持容器上传和下载功能。

   Docker同时提供了Build，Ship和Run，运维只需要在环境重配置好Docker，剩下的工作就是部署容器，实现BuildOnceRunAnywhere和ConfigureOnceRunAnything；从而促进了容器技术的爆发。

    在架构上，Docker采用ClientServer模式和插件式架构设计，Docker的后端采用非常松耦合的架构，模块之间相互独立，用户通过DockerClient与DockerDaemon建立通信，并发送请求给DockerDaemon。

   DockerDaemon提供Server功能接受DockerClient的请求；随后通过Engine执行Docker内部的一系列工作，每项工作都是以一个Job的形式的存在。

   Docker讲底层容器运行时剥离出来，实现更好的平台无关性。

LibContainer是对各种容器的抽象，发展为RunC，并贡献给OCP组织作为定义容器环境的标准。

Docker容器的三大编排工具，Compose、Swarm和Machine。

Compose是服务编排工具，是定义和运行Docker主机上多容器应用的工具，通过单独文件，定义多容器应用并运行容器。

    Docker的网络技术和能力一直是容器技术中最难、也是最不看好的技术之一，Libnetwork是Docker公司正在开发的新的网络底层架构，由libcontainer和DockerEngine中的网络相关的代码合并而成。

Libnetwork的目标是引入了容器网络模型（CNM），并为应用程序提供一致的编程API接口以及网络抽象。

 Libnetwork的容器网络模型包含了三个重要概念，NetworkSandbox，Endpoint和Network。

    Weave创建了NetworkingPlugin技术，目前成熟的有NetworkingPlugin和VolumePlugin。

   Weave方案包含两大组件，用户态Shell脚本和Weave虚拟路由容器。

Weave虚拟路由容器需要在每个宿主机上布置第三方插件，把不同宿主机的Route容器连接起来，使得Docker工具生态无缝集成到Docker。

（其他网络方案介绍，请参看<容器技术架构、网络和生态详解>电子书）

    Weave创建一个虚拟网络，链接多个主机的Docker容器，并使他们可以被自动发现，对使用该网络的应用来说，所以容器就像是链接在同一个网络交换机上，无需配置端口映射、链路等参数。

容器和容器OS

   CoreOS是最为受欢迎的容器虚拟化OS，专为Docker设计和内核裁剪。

 CoreOS中有两个关键容器集群管理工具，etcd主要实现集群服务发现、信息共享和数据同步；而Fleet实现集群状态维护、容器操作和确保服务一致可用。

   VMware也推出了容器OS系统Photon，在VMware上创建VM，并且安装Photon系统即可部署运行容器，并且支持目前主流的Docker、Rkt和PGC容器平台。

Photon可以容器管理认证工具Lightwave配合，可以实现更好的权限管理。

Docker容器和存储

   Docker容器在数据读写和存储上，是采用分层和COW的存储技术实现，Docker本身的COW文件系统不支持数据持久保存，在容器被删除或重启后，之前的文件更改就会丢失（变化的数据被以COW写到一个新的位置）。

   Volume的引入虽然解决了数据丢失问题，但是当容器迁移后，数据卷无法跟随Docker容器一起迁移，ClusterHQ的Flocker的出现恰恰解决Volume的不足，使得数据跟随Docker迁移。

   Flocker的容器和存储卷迁移分为全迁移和增量同步两个过程，配置文件描述Docker部署方式和状态，运行配置则生效（迁移Redis）；以迁移本地存储（非共享存储）为例，整个过程为先打快照，全迁移，增量同步。

   Flocker以DockerVolumePlugin的方式部署在Docker中，与Docker集成。

目前共享存储的支持能力比较成熟，支持的产品包括AWSEBS、ScaleIO和XtremIO等，并且支持如AWS、Rackspace等云平台；本地存储方式在技术成熟度上并不高。

   Flocker通过StorageDriver屏蔽存储差异，并通过存储提供的Flocker标准接口实现对底层存储操作，当主机容器在不同主机间迁移时，Flocker只需要对容器的Volume进行主机的重映射。

Docker与PaaS

   随之容器的发展，CaaS容器即服务的概念也应时而生，其大意就是基础设施以容器的方式来供给给应用使用。

以容器为单位成为PaaS的共识，基于Docker的容器打包和分发有望成为PaaS平台的标准,Docker将大幅拓宽PaaS的应用范围，并促进PaaS的快速发展。

   基于容器的打包一统新一代PaaS，第三代PaaS，DEIS、Flynn等均基于Docker，挑战老的PaaS平台。

   PaaS已经出现了数年时间，第一批是Azure和Heroku等公用云服务，之后出现的CloudFoundry和OpensShift允许用户建立自己的PaaS，包括了内部数据中心以及云环境。

现在，第三代PaaS浪潮正在到来。

   Flynn是一个开源的PaaS平台，可自动构建部署任何应用到Docker容器集群上运行，其功能特性与组件设计大量参考了传统的PaaS平台Heroku。

Flynn目前还不是很稳定。

但整个系统非常灵活，相互松耦合，便于任意组件的替换。

Docker与IaaS平台

   主流IaaS云平台都支持Docker的运行 （AWS、GoogleComputeEngine、Rackspace等）。

Docker弥合了不同IaaS之间的差异，Docker的轻量和可移动性使得其比较适合用在HybridCloud中。

降低了IaaS服务商用户粘性，使得跨云服务商迁移更加自由。

从而使得IaaS服务商被管道化。

如果Container把安全问题解决了，可能就会有比较大的变化。

  出现基于Docker的ContainerasaService或OrchestrationasaService，如Tutum，可以避免IaaS的锁定，甚至不用关心是运行在物理设施上，还是运行在哪家IaaS平台上。

   2014年6月Rackspace宣布和CoreOS合作提供BaremetalasaService方案OnMetal，结合了云计算的灵活性和基于container的高性能虚拟化，提供singletenantbaremetalcloudserivce。

   这种模式将影响当前以虚拟机为核心的IaaS平台，预计后续可能出现同时提供DockeroverBaremetal、 DockeroverVM和VM三种混合的资源分配和调度云平台。

   Docker也引发了基于容器的应用集群管理平台，如Kubernetes得到了微软、红帽、IBM、Vmware、Docker、Mesosphere、CoreOS和SaltStack等多家厂商的支持。

容器集群管理技术可能导致Openstack边缘化。

Docker与DevOps

   基于Docker可以更好的实现DevOps。

虽然有许多工具适合DevOps部署，使开发人员和操作更贴近，但Docker是一个与DevOps原则密切相关的框架。

使用Docker，开发人员可以专注于他们的代码，而不必担心在生产环境中运行它们的负面影响。

   DevOps团队可以将整个容器作为容器处理，文件系统和依赖关系管理的分层方法使得环境的配置更容易维护。

在相同的源代码控制系统（如Git工作流程）中版本化和维护Dockerfiles使得它非常有效地管理多个开发/测试环境。

不同环境的多个容器可以在同一VM上运行时被隔离。

Docker还可以很好地使用现有的工具，如Jenkins，Chef，Puppet，Ansible，SaltStack，Nagios和Opsworks。

   Docker有可能对DevOps生态系统产生重大影响。

它可以从根本上改变开发人员和运营专业人员合作的方式。

新兴DevOps公司，如CloudMunch，Factor.io，Drone.io可能必须采用Docker并将其带入他们的CI和CD解决方案。

Docker与微服务架构

   基于Docker容器和其生态系统的微服务架构是下一代PaaS的核心，在Docker出现之前，虽然我们谈论微服务架构，但是其实是很难实现的。

微服务要运行，首先需要一套执行的环境。

这套环境不能对外部有依赖性。

同时，执行环境的粒度又必须足够的小，这样才能称之为”微“，否则必然是对资源的巨大浪费。

   一个微服务可以跑在一台虚拟机上面，但是虚拟机粒度太大，即使最小的虚拟机，也至少也有1个核。

服务一个用户的服务，显然用不了一个核。

同时，虚拟机有没有一套方便的管理机制，能够快速的让这些服务之间能够组合和重构。

   Docker出现以后，我们看到了微服务的一个非常完美的运行环境。

一个容器就是一个完整的执行环境，不依赖外部任何的东西，具备独立性。

一台物理机器可以同时运行成百上千个容器，粒度细。

其计算粒度足够的小。

容器可以在秒级进行创建和销毁，非常适合服务的快速构建和重组。

数量众多的容器编排管理工具，能够快速的实现 服务的组合和调度。

从Docker到微服务

此篇文章通俗易懂讲解了Docker的概念和原理，但与微服务的知识海洋相比，这只是沧海一粟。

微服务代表IT架构未来架构发展趋势和演进方向，目前已有大量关于微服务技术原理、实践总结和部署实施的文章，但对于初学者而言，零散学习并不能完全领会文章精髓，也无法构建完善的知识体系。

但值得庆幸的是，极客时间推出热门微服务课程，帮你从0开始构建微服务体系。

具体来说，该专栏把微服务知识分为四个部分，帮助学习者循序渐进的掌握微服务知识。

限时优惠，分享返现。

具体每部分内容介绍如下:

第一部分，我会尽量用最通俗的语言去讲解微服务架构的基本原理，帮你解答三个问题：

什么是微服务？

什么时候适合微服务改造？

微服务架构到底是什么样的？

第二部分，我会结合在实际业务中的经验，给你讲述微服务架构改造过程中可能会遇到的问题和对应的解决方案，以及搭建微服务架构时，如何做技术选型。

第三部分，我会给你讲述微服务、容器化、DevOps这三者之间的关系，以及在具体实践中如何运用这三种技术以给业务的架构带来质的飞跃。

第四部分，我会给你介绍下一代微服务体系可能的发展方向，并分享作者对此的看法。

微服务也是当下移动互联网最火的后端架构之一，而专栏作者通过这几年亲自践行微服务的思想，使自己的技术水平不断提升，成长为一名技术专家。

作为程序员的你，也一定渴望在技术的道路上不断进步，那么微服务能助力你纵身一跃，跳到优秀的架构师的行列。