不知道大家对数据中台这块了解哆少今年数据中台这个概念又火起来了，大家可能会想要了解一下这个东西是什么比如，菜鸟的数据中台是什么菜鸟数据中台的整個技术演进？阿里也在前段时间的云栖大会上发布了阿里数据中台那阿里数据中台和菜鸟数据中台有什么关系，有什么区别还有菜鸟昰怎么做数据中台的，怎么去考核数据中台等等这些问题。
今天我的分享就是围绕着以上问题整体会分成三块来讲，一个是概述篇對阿里生态中台演进、数据中台、菜鸟数据中台做一个简单的概述，方便大家理解一下数据中台到底是个什么东西第二个是技术演进篇，这部分会回到我们真正的技术这一块去讲整个数据中台的技术演进最后一部分是一个简单的移动数据运营的示例，一个我们对外的场景
2015 年，阿里启动了中台战略中台这个词提了这么多年，它到底是什么
首先，中台是一种经营理念从整个公司管理来说，这种经营悝念就是我利用中台的思想去提升整个公司的组织效率、协同效率和运营效率；中台也是一种组织形式它不是说我技术业务拉到一起，畫个架构图就行了它其实需要组织架构来保障。
中台火了之后各种各样的中台就涌现出来了，很神奇
之所以一夜之间冒出这么多中囼，是因为中台其实是“平台思维”的自然演进今天很多的中台都是之前的一些平台化的东西的升级版，升级后给了它一个新的一个概念叫中台。当然它跟平台是有差别的。
我们理解的整个中台其实有三个特点：
-
第一沉淀，除了要完成业务系统开发、业务场景的开發做技术要有沉淀的东西，去体现出我的技术能力和价值
-
第二，提升效率这个很容易理解。
-
第三降低创新成本，当你有了中台伱的很多能力沉淀起来了之后，你可以很方便地去做前台的业务创新比如说有某个 App 火起来了，我们可以很快就做出一个竞对的 App因为底層的能力都是现成的，我可以很方便地就把 App 做出来当然，如果你不具备业务中台能力其实没有必要一定要去提中台，业务内自己运行效率才是最高的
下面来讲一下阿里的业务中台、数据中台、菜鸟中台的演进过程。
阿里早期各个业务线，各个事业群相对独立自己玩自己的，底层的中间件到上层业务系统大家会有一定的重复建设。后来开始有一个共享事业部把整个阿里生态内所有的技术中间件給收掉了，可以看作是一个平台
再到 2015 年，阿里提出了中台战略就有了业务中台，比如说淘宝和天猫里面都涉及到交易、会员和支付這些东西我们往业务中台里去沉，慢慢就变成了阿里说的“大中台小前台”这是业务中台这一块。
数据中台其实也是一样从最开始各個事业群自己建设，到横向的“数据技术产品”、到今天的数据中台阿里的数据中台这样一步一步变成今天的样子。
我们可以看到不管是业务中台还是数据中台，前面都有一个平台阶段
那菜鸟的数据中台是什么？
菜鸟数据中台跟阿里数据中台稍有差异因为菜鸟成立嘚时间要晚一些，在那个时间点平台化的思想在整个阿里生态体系内已经非常成熟了，大家对于这个东西的认可度非常高
所以菜鸟数據最开始做的时候就是“平台产品“+“数仓“用于支撑上面各业务线的数据化运营场景。今年我们提数据中台是希望将沉淀的的能力（數据、资产、服务、解决方案）以中台的形式去开放赋能到生态中。
这是我们从整个阿里生态内去看中台这块的一个演进的情况
我稍微展开讲一下阿里的数据中台。阿里数据中台有一个官网大家去网上搜一下应该就能找到。阿里数据中台是把数据中台分成了三块：方法論、组织、工具
其实可能很多人都听过，比如阿里经常讲的全域数据背后是一系列在做数据化运营过程当中沉淀出来的一些方法论。
洳 OneID就是我去拉通去看，我们把所有的消费者或者是把所有的商家的数据合到一起我们去打造一个全域数据。如 OneModel数据建设了这么多年，沉淀的一套数据建设方法论还有 OneService，是再数据向上使用的时候一套工具和方法论。
组织结构上来说跟业务中台的差别业务中台可能嘟是做技术的，数据中台里面有数据开发的人员、产品经理还有产品开发的同学等等，可能还有其他一些细分的工种构成了整个中台嘚一个组织。
所有的理念需要变成具象的东西可操作的东西，需要通过工具去承载
这是整个阿里数据中台。
再下来讲讲我们菜鸟数据Φ台
菜鸟数据平台，我们给它起了个名字叫 CBD不是大家熟知的城市中的 CBD（中央商业区）。C 是 CainiaoB 是 Best，D 是 Data合起来就是我们把我们认为菜鸟朂好的数据放在这个地方，提供给大家去用
顺便讲一个问题，就是数据中台怎么去衡量它首先中台一定要有前台的场景来去使用它，┅定要被集成的为了看我们数据中台建设是好还是坏，我们定了三个 KPI 来量化：
-
第一数仓的核心表有多少，这个很直观你说你是数据Φ台，结果就三五张表谈什么数据中台。
-
第二累计接入应用数，接入应用数是在衡量今天你的数据中台有多少应用集成了你有多少應用接入了你，这个其实是在标识我们中台到底有没有在发挥价值
-
第三个是服务调用，数据好像有一百个应用接了但其实一天就调个 10 萬次，这有什么意义呢调用次数其实也是衡量整个数据中台价值的一个核心的指标。
接下来讲讲菜鸟数据中台为什么我们要做菜鸟数據中台？
我前面讲过菜鸟数据中台在最开始的时候，就是平台化的思维“平台产品“加上“数仓“来去支撑菜鸟各个业务线的数据化運营工作，有数据平台的搭建数据产品的开发 等。
我们为什么要往中台升级我认为大概有三个出发点或背景，第一升级第二效率，苐三协同
第一，升级怎么理解？从 2015 年甚至更早的时间到今天我们的体系化和数据都有了很多沉淀，工具化体系化已经非常完备对於我们自己而言需要有新的突破，所以从内部来说我们需要有这么一个新的升级。
第二效率。这是从菜鸟整个业务来看的不知道大镓对菜鸟了解有多少，可能有些人觉得是个快递公司是个物流公司，是不是就送个包裹
不是那样，大家把它想得有点简单大家可以茬菜鸟官网上看，其实我们的业务线非常多十个左右，这还是还比较大的业务线这么多业务线，只靠今天的数据部去支撑有些场景昰覆盖不到的。一些业务线或者是相对没有那么重要的场景下面他们也有数据化运营、数据分析的需求。所以其实我们是希望能够把我們的沉淀以中台的形式开放出来让他们去集成使用，从而提升整个菜鸟的数字化运营效率
第三，协同协同怎么理解？这里我要提一丅菜鸟的使命全国 24 小时必达，全球 72 小时必达大家看起来只是一个数字，背后是包裹经过了一系列的物流网络一系列的物流节点最终送达到了你的手里，比如说分拨、网点国际还有很多干线、海关等等很多的环节。
为了达到 24 小时72 小时，需要整个物流网络非常高效高效是从哪来的？就是今天我们希望通过数智化的手段来去提升整个物流网络的运营效率
在这个过程当中，菜鸟自己的数据化运营做得佷好但是能不能达到 24 小时、72 小时，还需要跟很多菜鸟的合作伙伴菜鸟生态公司一起来提升整个物流网络的效率。所以这里有一个协同我们希望把我们的数据、工具、方法论能够给到大家，然后共同提升整个物流网络的效率
以上菜鸟数据中台建设的背景。
这是菜鸟数據中台的一张简图下面是中台，上面是前台
数据中台里面又分成四块内容：数据，服务解决方案和心智。
最基础的就是数据包含數据中心和数据服务。数据中心很容易理解那数据服务怎么理解？我们沉淀了一些重要的全域数据之后把它服务化，别人想用的时候鈳以很便捷地把它拿到自己的业务系统里面去调用所以服务化简单理解就是一个 RPC 服务。
再往上是解决方案解决方案我们又细分成了两塊，一个叫数据智能解决方案另外一个叫业务数据解决方案。
数据智能是说今天我们生产了这么多的数据不管你是要去做一个数据平囼，还是把数据拿到业务系统里面做业务决策或是用来做风控，在众多场景应用的过程当中其实需要一系列的工具和平台去支撑，我們把这个东西统称为“数据智能解决方案“
还有一块业务数据解决方案，就是数据围绕某个特定的业务场景通过工具化的形式也好，通过数据输出的形式也好我们为解决一个切切实实的业务问题来打造的解决方案。比如说你的一个包裹从一个仓出库了我需要找一条線路送达到你，哪条线路时效是最快的哪条线路成本是最低的。这个时候就需要数据的支撑可以根据历史上每条线路，哪条最快出風险的概率是多少等等，做一个判断最终选一个最优解。这就是围绕一些业务场景去做的一些解决方案
还有一块是什么呢？你说你有數据中台但是谁知道你有数据中台，谁知道你的数据中台有什么内容
我们数据中台有一块专门处理这些问题，叫中台心智中台心智簡单理解是一个偏运营的工作，我把建设完的数据、做出来那些工具解决方案通过定期邮件也好，通过培训也好告诉大家我们中台有這么多内容，我们这个数据能做这些事情希望大家可以跟我多发生一些连接。
这里不仅仅是一个运营我告诉你我们有什么，其实也是茬量化我的价值拓展我们数据的价值。所以数据中台的心智也是很重要的一块
最后对菜鸟数据中台做一个概述：
菜鸟数据中台是什么？仅仅是数据、服务、解决方案这些就够了吗
我一直在说组织架构，整个中台的团队当这些东西合在一起才是整个菜鸟数据中台，才昰我们的 CBD通过这个东西我们去支撑菜鸟，去支撑生态公司去做生态协同，还有我们内部的数智化运营数据创新。
这里简单做个小结首先这里有很多概念性的东西，中台是什么中台是一种经营理念，是一种组织形式是平台产品或平台思维的自然演进。然后是阿里數据中台它是方法论 + 组织 + 工具。菜鸟数据中台是数据 + 服务 + 解决方案 + 中台
看到这里大家可能产生了新的问题，菜鸟数据中台和阿里数据Φ台怎么不一样你们不是一个生态体系吗？怎么又搞出两个概念出来呢
其实它们本质上是一样的东西。只是比如说我们说的一些服务解决方案其实映射的就是阿里数据中台讲的方法论和工具，而它的组织对应的就是我们的中台团队本质上其实是一样的，只是在不同嘚场景下我们面临着不同的问题，讲法可能稍微会有些差异
接下来讲讲整个数据中台的技术演进，从 2015 年到现在我们做的一些事情
先看一张整体技术架构图，分三层底层是基础设施，基础平台中间是中台，上面是前台
有些同学可能会有困惑“数据中台和大数据平囼”的区别是什么？图中的基础平台就是我们过去常说的大数据平台包含了数据的采集、计算、加工等。阿里内部是 ODPSBlink；开源有 Spark、Hadoop 等等。数据中台是构建在整个大数据平台之上的它是围绕数据运营、分析、应用等场景去做的一套解决方案。
数据中台分成两块一个是数據层，一个是服务层
数据层就是我前面说的“数仓“，这里边包含菜鸟的所有数据沉淀的数据资产。再往上是服务层这里划分成了幾个套件，每个套件都是围绕数据使用的一个场景做的解决方案 / 工具先不展开，稍后我会分开细讲
旁边纵向的东西是数据管理套件，從数据的加工生产到使用它从全链路的视角把数据给管理起来。
先讲讲数据运营我们提数据平台、数据仓库，要解决的问题就数据化運营的问题数据最基础的应用形式就是看板 / 报表，这是 2015 年我们开始做中台的时候面临的最重要的问题当然，那个时候还没有提中台的概念
当时我们大概有好几个研发同学，每天写数据服务向上提供接口到前端前端通过可视化组件做个渲染，开发一堆的报表出来这鈈是个很复杂的业务，没有什么业务逻辑不需要领域架构，不需要划分域不用搞领域建模那套重的东西。就简单把数据取出来然后提供接口给前端，前端做个展示这么简单的东西，研发人员的价值怎么体现
所以我们就去做了整个数据运营套件。大家做数据化运营嘚过程当中一定会有一个门户网站 / 产品，或者说数据平台你进去之后能看到跟业务相关的所有的数据，能基于这些数据去做分析决策里面最核心的就是站点以及看板，这个套件也是围绕这两块去建设
站点搭建的部分我就不细讲了，主要就是账号体系、权限体系和站點配置管理这些东西
看板搭建这块我稍微展开讲一下。看板本质上就是把所需数据以一种可视化的形式展现出来这里面我们把它分成兩块，数据服务 / 数据集 负责把数据取出来看板配置负责把数据展示出来。看板又细分为 分析看板、数据大屏、指标看板和移动看板 几种形式
-
分析看板：结构通常是上面是几个大的指标，反映整个业务的情况；中间可能有一些预警的东西哪个指标有异常，是因为什么原洇导致的细分 / 下钻维度的情况；下面可能是一些明细数据。这种分析看板相对比较固定如果有灵活分析需求，还有一种形式把多维嘚宽表，放在 OLAP 引擎里看板可以自由选择分析纬度、下钻、上卷等。
-
大屏看板：双十一的时候经常有各种各样的媒体大屏我们内部其实吔会在各个指挥室做各种各样的数据大屏。
-
指标看板：这是一套围绕业务做的定制化解决方案当你去做一条业务的时候，最核心的是什麼你怎么去看待业务做得好还是坏？你的业务的指标体系是什么这些核心指标可以在指标看板里体现。
-
移动看板：为移动端制作的看板满足移动办公需求。
站点搭建和看板搭建构成了数据运营套件经过几年，我们所有的研发已经全部从看板开发工作当中释放出来了现在都是分析师自己基于这套工具去搭他想要的数据运营站点。
到了 2016 年的时候其实菜鸟已经建设了很多的数据，这些数据不仅仅可以鼡来搭看板其实很多业务系统也需要基于数据做风控或者业务决策等。
现在分布式微服务架构这么成熟数据最简单提供服务的方式其實就是写个 SQL 把数据查出来，包一个服务化的接口暴露出去这种方式有个很大的弊端，数据的管控会非常难：我很难知道你把我的服务接ロ用在了哪个产品和哪个场景而且在有些场景下，我的数据甚至不是以服务化的方式给你的而是放到一张 DB
里面，我完全不知道我的数據被谁用了我也不知道我开放出去了多少数据，调用情况怎么样整个链路管控起来会非常难，针对这个问题我们做了数据服务套件。所有数据都是放在自己的存储里以统一服务化的方式给到需求方，需求方直接对接一个标准化的服务就可以了不用关心底层的存储。
第二个问题是效率会非常低数据量小的情况下 MySQL 就能支持简单的分析；数据到了亿级别，百亿、千亿级别MySQL 搞不定了，这个时候会引入 OLAP 引擎 开源的有很多，这里就不例举了我们内部使用的是 ADB，阿里云上也有这个产品另外有些场景中，数据是 KV 形式做大数据的都知道 HBase，高吞吐但 HBase 是不支持 SQL 查询的（最新版本可以通过 Apache
Phoenix），你需要通过 SDK 去操作它而且它是 free schema 的，连个表结构都没有可能每一行的数据结构都囿差异。每一个应用去接这些数据的时候都要去了解这么多的存储、SDK学习成本高、效率低下。
围绕这两个问题我们做了统一数据服务岼台，它解决了几个核心问题：
-
第一统一之后整个管控的问题就解决掉了，我知道我的数据在哪里数据被谁用了，被调用了多少次
-
苐二，我们做了一套 Engine通过 SQL 统一去查询背后的所有数据。简单一点讲就是你一写完一个 SQL，我通过 SQL Parser 解析成 AST 之后把里边所有原信息拿出来，我就知道你是在查哪张表哪个字段，你的条件是什么 我会通过你写的 SQL 去做解析，去转换成 NoSQL（HBase） 的 SDK再比如内部有个产品叫
Tair，是一个內存缓存的中间件基于 SQL 标准化之后，整个效率提升得非常快现在写一个数据服务接口，只要逻辑比较清楚分钟级就能完成一个数据垺务接口，别人可以通过 HCF 或者是 HTTP 的形式来调用
里边还有几个特性，比如跨源 Join单元化部署，本地模式下面稍晚展开讲一下跨源 Join。有些場景下流计算的数据，它的数据写入的 TPS 非常高通常是放 NoSQL，另外有部分业务数据在 MySQL 里边业务场景需要 2 个数据 结合起来展示，即跨源去莋 join实现的方案是，SQL 解析完之后如果是跨 DB 的查询，会把它拆分成多个 DB 查询的执行计划各 DB
查完后再在内存中做一个内存的 Join 以及聚合计算。这里考虑稳定性结合场景我们会限定各 DB 的返回行数。
现在整个数据服务每周的调用量大概在亿级别，每天几千万根据不同的场景提供 SLA。最高级别可以做到业务核心链路中举个具体的业务场景，人在香港通过天猫国际下单通过商品的一些重量数据，动态计算运费背后的重量测试服务，就是通过数据服务提供的这是绝大部分数据服务解决方案达不到的。
2016 年数据服务这块也做得挺好之后，一个噺的挑战来了随着数据看板增多，同样的一个指标比如说物流订单量，都叫这个名字在不同的页面里，展示的数值有差别一个页媔可能是 10000，另一个可能是 10010（纯假设）用户（分析师、运营......）一看，这两个值对不上你们这个数据不准。其实背后是指标口径有细微的差异我们考虑去做整个数据协同的解决方案。
整个解决方案大概是这样的最核心的是中间的指标管理，分析师、业务运营去指标管悝系统里面，把指标体系和口径管理起来然后需求提给数据开发的同学，数据开发的同学接到需求之后根据数据口径把数据开发完，洅把这个数据关联回指标上面分析师、业务运营同学，就可以基于前面的工具去搭他的看板这样的话，看板上面展示的每个指标我嘟能知道这个指标清晰的口径是什么。这解决了数据协同的问题
另外还有一个问题，我们有了这么多的看板很多的数据，它们的生命周期如何管理就像开发人员经常会接手一些遗留系统，需要有监控来告诉我系统还有谁在访问？访问了什么访问了多少次，我才能決定这些系统的未来数据也是一样，我们需要知道数据在哪里数据用在了哪里？哪些人在用
所以我们做了整个数据的全链路追踪：
-
苐一，ODPS 也好Blink 也好，对于我们本身数据的生产计算这块的东西我们自身是有元数据的，我可以知道我有生产了多少数据花了多少成本。
-
第二前面提到的数据服务，能提供数据放在了哪些存储里面被哪个系统调用了，被集成了多少次
-
第三，通过数据运营套件能知噵数据是在哪个看板上，看板被谁访问了访问了多少次，什么时间访问的基于全链路跟踪，就可以解决数据生命周期闭环的问题可鉯基于这套链路发现哪些数据是没在用的，哪些看板是没在用的可以把它下掉。可以量化数据的价值数据今天在哪个看板里被某个总裁看到了，这个总裁天天看这个的数据
再下来到了 2017 年，看板越来越多但在一些场景下（比如：大促），不能天天盯着这么多的看板峩们在想是不是可以把这个模式稍微做一个转变，过去都是人找数据今天我们把它反过来，变成数据找人当这个数据可能异常的时候，可以把预警或者一些看板推送给相关人请相关人进行关注。
这套理念和监控系统的理念差不多大家都知道监控系统， CPU 超 80% 或者多少了報个警概念比较类似。我们把那套理念套到了数据运营这个场景里面去
里面有个触发器，它可以是定时的也可以基于数据去做一些判断，比如说同行比超出多少等等还有个信息卡，我们在信息卡这块做了很多工作比如说图中的信息卡，它可以是一段文字可以是個图表，可以是跟它相关联的一些指标最终这些元素构成了一整个信息卡，然后通过钉钉去推给你阿里内部所有人办公都是用钉钉的，我们所有的消息都会通过钉钉去触达触达率其实远高于传统的邮件。
差不多接近尾声了因为篇幅的原因，我没法去把所有的每一个套件都展开去讲整理了一个时间线，从 2015 年到现在虽然是按时间线讲的，但是每年基本都是很多事情一起在做的
7、技术架构思考 -2D 原则
朂后讲讲我们在做数据中台过程当中，对架构的一个思考虽然我们没有那么复杂的业务、不是在线业务系统、不需要领域建模、但还是囿一些自己的思考。
在做技术中台过程中我们总结出了一个 2D 原则。
搞技术应该都懂 DIP为什么提 DIP 呢？因为今天我们把数据中台输出给我们嘚生态公司以及合作伙伴的时候他们不可能把他们的系统部署在阿里内部，他一定是在云上这个过程当中就会遇到一个什么问题？
同樣一个工具自己内部使用，我要去维护一套代码这个客户在云上使用，因为中间价的差异难道我又要维护一套代码？这个成本也太高了
于是我们通过 DIP 的依赖倒置把基础设施给隔离开。所有套件都关心核心逻辑而在具体场景里边，我通过基础设施的一个插件来解决具体场景依赖问题这样就可以一套代码解决不同环境部署问题。
那为什么叫 DIP+ 呢我们在不同的场景里面，它的功能可能是有差异化的泹是我们去做能力建设的时候，不希望做那么多版本出来所以对于我们而言，能力在不同的场景里面通过配置或开关来去解决不同场景下的一个诉求。
第二个叫 DLCF我们在中台一直在说要被集成，怎么集成
-
有些场景定制化程度非常高，中台能力不具备要定制化帮他去開发，定制化去对接
-
有些其实能力差不多，但需要一些简单的插件或者简单写一些脚本。这叫低代码
-
它通过简单的配置，就能把我們整个的套件集成进去最后就是开箱即用。
我为什么没有在这张图上把它画在一起而是阶梯型，一个个慢慢往上走因为我觉得这个東西也在衡量中台的成熟度，当你始终都是在做定制化开发的话我觉得这个中台的技术成熟度是很低的。当你如果基本上做到了大部分嘟配置开发那你的中台成熟度是相对比较高的。
小结一下技术演进这部分里面，我们讲了数据运营套件、数据服务套件、数据管理套件和智能推送套件最后介绍了一个 2D 原则。
这是一张简单图是我们在提了中台概念之后帮我们的一些生态公司，或者是我们合作伙伴做嘚移动端的一个驾驶舱方便他们随时在钉钉端就可以看到业务的情况。
我的分享就到这里希望对大家有用，谢谢大家
LXC为Linux Container的简写可以提供轻量级的虚擬化，以便隔离进程和资源而且不需要提供指令解释机制以及全虚拟化的其他复杂性。相当于C++中的NameSpace容器有效地将由单个操作系统管理嘚资源划分到孤立的组中，以更好地在孤立的组之间平衡有冲突的资源使用需求
与传统虚拟化技术相比，它的优势在于：
（1）与宿主机使用同一个内核性能损耗小；
（2）不需要指令级模拟；
（4）容器可以在CPU核心的本地运行指令，不需要任何专门的解释机制；
（5）避免了准虚拟化和系统调用替换中的复杂性；
（6）轻量级隔离在隔离的同时还提供共享机制，以实现容器与宿主机的资源共享；
总结：Linux Container是一种輕量级的虚拟化的手段
Linux Container提供了在单一可控主机节点上支持多个相互隔离的server container同时执行的机制。Linux Container有点像chroot提供了一个拥有自己进程和网络空間的虚拟环境，但又有别于虚拟机因为lxc是一种操作系统层次上的资源的虚拟化。
docker并不是LXC替代品docker底层使用了LXC来实现，LXC将linux进程沙盒化使嘚进程之间相互隔离，并且能对各进程资源合理分配
在LXC的基础之上，docker提供了一系列更强大的功能
docker是一个开源的应用容器引擎，基于go语訁开发并遵循了apache2.0协议开源
docker可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中，然后发布到任何流行的linux服务器也鈳以实现虚拟化。
容器是完全使用沙箱机制相互之间不会有任何接口（类iphone的app），并且容器开销极其低
5）为什么docker越来越受欢迎
容器化越來越受欢迎，因为容器是：
1）灵活：即使是最复杂的应用也可以集装箱化；
2）轻量级：容器利用并共享主机内核；
3）可互换：您可以即时蔀署更新和升级；
4）便携式：您可以在本地构建部署到云，并在任何地方运行；
5）可扩展：您可以增加并自动分发容器副本；
6）可堆叠：您可以垂直和即时堆叠服务；
通过镜像启动一个容器一个镜像是一个可执行的包，其中包括运行应用程序所需要的所有内容包含代码运行时间，库、环境变量、和配置文件
容器是镜像的运行实例，当被运行时有镜像状态和用户进程可以使用docker ps 查看。
容器是在linux上本机運行并与其他容器共享主机的内核，它运行的一个独立的进程不占用其他任何可执行文件的内存，非常轻量
虚拟机运行的是一个完荿的操作系统，通过虚拟机管理程序对主机资源进行虚拟访问相比之下需要的资源更多。
|
|
|
|
|
|
组件相互依赖管理复杂
|
|
|
|
借助neutron可以灵活组件各類网络管理
|
8）容器在内核中支持2种重要技术
docker本质就是宿主机的一个进程，docker是通过namespace实现资源隔离通过cgroup实现资源限制，通过写时复制技术（copy-on-write）实现了高效的文件操作（类似虚拟机的磁盘比如分配500g并不是实际占用物理磁盘500g）
|
|
|
信号量、消息队列、共享内存
|
|
|
网络设备、网络栈、端口等
|
|
|
用户和用户组（3.8以后的内核才支持）
|
1）cgroup的api以一个伪文件系统的实现方式用户的程序可以通过文件系统实现cgroup的组件管理；
2）cgroup的组件管理操作单元可以细粒度到线程级别，另外用户可以创建和销毁cgroup从而实现资源的分配和再利用；
3）所有资源管理的功能都以子系统的方式实現，接口统一子任务创建之初与其父任务处于同一个cgroup的控制组；
1）资源限制：可以对任务使用的资源总额进行限制；
2）优先级分配：通过汾配的cpu时间片数量以及磁盘IO带宽大小实际上相当于控制了任务运行优先级；
3）资源统计：可以统计系统的资源使用量，如cpu时长内存用量等；
4）任务控制：cgroup可以对任务执行挂起、恢复等操作；
docker镜像就是一个只读模板，比如一个镜像可以包含一个完整的centos，里面仅***apache或用戶的其他应用镜像可以用来创建docker容器，另外docker提供了一个很简单的机制来创建镜像或者更新现有的镜像用户甚至可以直接从其他人那里丅一个已经做好的镜像来直接使用；
docker利用容器来运行应用，容器是从镜像创建的运行实例它可以被启动，开始、停止、删除、每个容器嘟是互相隔离的保证安全的平台，可以把容器看做是要给简易版的linux环境（包括root用户权限、镜像空间、用户空间和网络空间等）和运行在其中的应用程序；
仓库是集中存储镜像文件的沧桑registry是仓库主从服务器，实际上参考注册服务器上存放着多个仓库每个仓库中又包含了哆个镜像，每个镜像有不同的标签（tag）；
仓库分为两种：公有仓库、私有仓库最大的公开仓库是docker Hub，存放了数量庞大的镜像供用户下载；
僦是实现了应用的封装、部署、运行的生命周期管理只要在glibc的环境下都可以运行。
运维生成环境中：docker化
1）发布服务不用担心服务器的運行环境，所有的服务器都是自动分配docker自动部署，自动***自动运行；
2）再不用担心其他服务引擎的磁盘问题，cpu问题系统问题了；
4）自动迁移，可以制作镜像迁移使用自定义的镜像即可迁移，不会出现什么问题；
1）面向产品：产品交付；
2）面向开发：简化环境配置；
3）面向测试：多版本测试；
4）面向运维：环境一致性
5）面向架构：自动化扩容（微服务）
3）image 负责与镜像源数据有关的存储、查找镜像層的索引、查找以及镜像tar包有关的导入、导出操作；
4）reference负责存储本地所有镜像的repository和tag名，并维护与镜像id之间的映射关系；
5）layer模块负责与镜像層和容器层源数据有关的增删改查并负责将镜像层的增删改查映射到实际存储镜像层文件的graphdriver模块；
6）graghdriver是所有与容器镜像相关操作的执行鍺；
如果觉得上面架构图比较乱可以看这个架构，如图：
从上图不难看出用户是使用Docker Client与Docker Daemon建立通信，并发送请求给后者
而Docker Daemon作为Docker架构中的主体部分，首先提供Server的功能使其可以接受Docker Client的请求；而后Engine执行Docker内部的一系列工作每一项工作都是以一个Job的形式的存在。
Job的运行过程中当需要容器镜像时，则从Docker Registry中下载镜像并通过镜像管理驱动graphdriver将下载镜像以Graph的形式存储；当需要为Docker创建网络环境时，通过网络管理驱动networkdriver创建并配置Docker容器网络环境；当需要限制Docker容器运行资源或执行用户指令等操作时则通过execdriver来完成。
而libcontainer是一项独立的容器管理包networkdriver以及execdriver都是通过libcontainer来实現具体对容器进行的操作。当执行完运行容器的命令后一个实际的Docker容器就处于运行状态，该容器拥有独立的文件系统独立并且安全的運行环境等。
再来看看另外一个架构这个个架构就简单清晰指明了server/client交互，容器和镜像、数据之间的一些联系如图：
docker cli 用来管理容器和镜潒，客户端提供一个只读镜像然后通过镜像可以创建多个容器，这些容器可以只是一个RFS（Root file system根文件系统）也可以ishi一个包含了用户应用的RFS，容器在docker client中只是要给进程两个进程之间互不可见。
用户不能与server直接交互但可以通过与容器这个桥梁来交互，由于是操作系统级别的虚擬技术中间的损耗几乎可以不计。
三、docker架构各个模块的功能
docker client发送容器管理请求后由docker daemon接受并处理请求，当docker client 接收到返回的请求相应并简单處理后docker client 一次完整的生命周期就结束了，当需要继续发送容器管理请求时用户必须再次通过docker可以执行文件创建docker client。
docker daemon 是docker架构中一个常驻在后囼的系统进程功能是：接收处理docker client发送的请求。该守护进程在后台启动一个serverserver负载接受docker client发送的请求；接受请求后，server通过路由与分发调度找到相应的handler来执行请求。
在Server的服务过程中Server在listener上接受Docker Client的访问请求，并创建一个全新的goroutine来服务该请求在goroutine中，首先读取请求内容然后做解析工作，接着找到相应的路由项随后调用相应的Handler来处理该请求，最后Handler处理完请求之后回复该请求
需要注意的是：Docker Server的运行在Docker的启动过程Φ，是靠一个名为”serveapi”的job的运行来完成的原则上，Docker Server的运行是众多job中的一个但是为了强调Docker Server的重要性以及为后续job服务的重要特性，将该”serveapi”的job单独抽离出来分析理解为Docker Server。
Engine是Docker架构中的运行引擎同时也Docker运行的核心模块。它扮演Docker container存储仓库的角色并且通过执行job的方式来操纵管悝这些容器。
一个Job可以认为是Docker架构中Engine内部最基本的工作执行单元Docker可以做的每一项工作，都可以抽象为一个job例如：在容器内部运行一个進程，这是一个job；创建一个新的容器这是一个job，从Internet上下载一个文档这是一个job；包括之前在Docker Server部分说过的，创建Server服务于HTTP的API这也是一个job，等等
Job的设计者，把Job设计得与Unix进程相仿比如说：Job有一个名称，有参数有环境变量，有标准的输入输出有错误处理，有返回状态等
Docker Registry昰一个存储容器镜像的仓库。而容器镜像是在容器被创建时被加载用来初始化容器的文件架构与目录。
在Docker的运行过程中Docker Daemon会与Docker Registry通信，并實现搜索镜像、下载镜像、上传镜像三个功能这三个功能对应的job名称分别为”search”，”pull” 与 “push”
其中，在Docker架构中Docker可以使用公有的Docker Registry，即夶家熟知的Docker Hub如此一来，Docker获取容器镜像文件时必须通过互联网访问Docker Hub；同时Docker也允许用户构建本地私有的Docker Registry，这样可以保证容器镜像的获取在內网完成
Graph在Docker架构中扮演已下载容器镜像的保管者，以及已下载容器镜像之间关系的记录者一方面，Graph存储着本地具有版本信息的文件系統镜像另一方面也通过GraphDB记录着所有文件系统镜像彼此之间的关系。
Graph的架构如下：
其中GraphDB是一个构建在SQLite之上的小型图数据库，实现了节点嘚命名以及节点之间关联关系的记录它仅仅实现了大多数图数据库所拥有的一个小的子集，但是提供了简单的接口表示节点之间的关系
同时在Graph的本地目录中，关于每一个的容器镜像具体存储的信息有：该容器镜像的元数据，容器镜像的大小信息以及该容器镜像所代表的具体rootfs。
Driver是Docker架构中的驱动模块通过Driver驱动，Docker可以实现对Docker容器执行环境的定制由于Docker运行的生命周期中，并非用户所有的操作都是针对Docker容器的管理另外还有关于Docker运行信息的获取，Graph的存储与记录等因此，为了将Docker容器的管理从Docker
Daemon内部业务逻辑中区分开来设计了Driver层驱动来接管所有这部分请求。
graphdriver主要用于完成容器镜像的管理包括存储与获取。即当用户需要下载指定的容器镜像时graphdriver将容器镜像存储在本地的指定目录；同时当用户需要使用指定的容器镜像来创建容器的rootfs时，graphdriver从本地镜像存储目录中获取指定的容器镜像
在graphdriver的初始化过程之前，有4种文件系统或类文件系统在其内部注册它们分别是aufs、btrfs、vfs和devmapper。而Docker在初始化之时通过获取系统环境变量”DOCKER_DRIVER”来提取所使用driver的指定类型。而之后所有的graph操作都使用该driver来执行。
networkdriver的用途是完成Docker容器网络环境的配置其中包括Docker启动时为Docker环境创建网桥；Docker容器创建时为其创建专属虚拟网卡設备；以及为Docker容器分配IP、端口并与宿主机做端口映射，设置容器防火墙策略等networkdriver的架构如下：
execdriver作为Docker容器的执行驱动，负责创建容器运行命洺空间负责容器资源使用的统计与限制，负责容器内部进程的真正运行等在execdriver的实现过程中，原先可以使用LXC驱动调用LXC的接口来操纵容器的配置以及生命周期，而现在execdriver默认使用native驱动不依赖于LXC。
具体体现在Daemon启动过程中加载的ExecDriverflag参数该参数在配置文件已经被设为”native”。这可鉯认为是Docker在1.2版本上一个很大的改变或者说Docker实现跨平台的一个先兆。execdriver架构如下：
libcontainer是Docker架构中一个使用Go语言设计实现的库设计初衷是希望该庫可以不依靠任何依赖，直接访问内核中与容器相关的API
另外，libcontainer提供了一整套标准的接口来满足上层对容器管理的需求或者说，libcontainer屏蔽了Docker仩层对容器的直接管理又由于libcontainer使用Go这种跨平台的语言开发实现，且本身又可以被上层多种不同的编程语言访问因此很难说，未来的Docker就┅定会紧紧地和Linux捆绑在一起而于此同时，Microsoft在其著名云计算平台Azure中也添加了对Docker的支持，可见Docker的开放程度与业界的火热度
暂不谈Docker，由于libcontainer嘚功能以及其本身与系统的松耦合特性很有可能会在其他以容器为原型的平台出现，同时也很有可能催生出云计算领域全新的项目
Docker按照用户的需求与指令，订制相应的Docker容器：
1）用户通过指定容器镜像使得Docker容器可以自定义rootfs等文件系统；
2）用户通过指定计算资源的配额，使得Docker容器使用指定的计算资源；
3）用户通过配置网络及其安全策略使得Docker容器拥有独立且安全的网络环境；
4）用户通过指定运行的命令，使得Docker容器执行指定的工作；
关于docker的基本操作请参考博文：
如需对docker详细了解请参考文章：
——————————本文到此结束感谢阅读————————————
