#卷首语
许多年后，如果我们回过头来评点，也许 2016 年是非常重要的一个 时间节点。
2016年的互联网，人工智能大放异彩，年初AlphaGo 4:1战胜李世石， 年底 60 连胜横扫网络围棋，沉寂了数十年的人工智能再次走上前台，颠 覆了人们的既有观念。
同时，随着Google DayDream、微软HoloLens等产品的发布，以及 阿里 Buy+、PokemonGo 等应用的出现，VR/AR 技术离我们越来越近，虽然 目前体验仍有改进空间，但没人可以否认那是最接近我们幻想中未来交互 的样子。
  这些前沿领域的技术人是幸运的，他们的努力，将会推动时代前进的
脚步。
  还有一些领域，虽然变化没那么引人注目，但也都各自在发生着深刻
的变化。
在容器领域，Docker 掀起了编排之争，同时集群管理越来越受重视， Kubernetes 受到重视。  开始逐渐普及。与此同时，容器还成为催化剂，催动着很多领域发生
变化。
在大数据领域，越来越多的公司开始搭建大数据平台，数据资产管理 和流数据处理受到重视，同时，大数据与人工智能的结合是 2016 年最受 瞩目的技术之一，并且在一些企业得到成功应用。
在运维领域，容器技术为运维带来了全新的挑战，DevOps 开始落地， 同时各种云架构让运维情况更加复杂，Google SRE的实践则为运维确定 了全新的标准。
在移动领域，2016 年可谓是国内移动技术的爆发之年，插件化、 热修复、组件化等技术的开源和讨论丰富了移动开发的技术栈，React Native、Weex、微信小程序的强势来袭，让移动开发技术面临变革。
更别提火爆的前端，对于这个一年一更新的技术领域，2016 年发生 了很多有意思的事件，React/Angular/Vue 三大框架开始进入三国鼎立时 代，创新层出不穷。
  变革对于技术人来说并不是坏事，它意味着永远有新的机会。时代交
替，会淘汰的只有不思进取的人，而合格的技术人，永远不会停下学习的
脚步。
  在这新春之际，我们为所有技术人献上过去一年各个领域的盘点和展
望，愿你的学习之路走得更加平坦。

#目录
1.解读 2016 之容器篇:“已死”和“永生”.
2.解读 2016 之深度学习篇:开源深度学习框架发展展望.
3.解读 2016 之大数据篇:跨越巅峰，迈向成熟.
4.2016 移动开发技术巡礼.
5.2016 前端开发技术巡礼.
6.解读 2016，眺望 2017:运维的风口在哪?

第一章

解读 2016 之容器篇:“已死”和“永生”.

  也说不上什么时候起，“XXX Is Dead. Long Live XXX”的句式突然 成为了技术会议上演讲题目的一个标准套路。然而不管已经被引用的多么 烂俗，用这套悖论来总结 2016 年容器技术圈子发生的凡事种种，却实在 有种说不出来的恰到好处。
  无需多言，稍微回顾一下 2016 年容器技术圈子的时间线，我们很容 易就能回想起容器技术如何在这一年迅速登上云计算舞台的中心。这股热 潮，从年初Docker公司闪电收购Unikernel Systems提前扼杀各种“被 颠覆”的苗头，蔓延到 Kubernetes，Mesos，Docker 三家项目在年中掀起 的“编排”之争，再到年末阿里云一举震撼国内创业市场。“编排”，“fork docker”，“OCI runtime”， “镜像标准”，一个又一个令人目不暇接的关键词带着背后的技术爆点填满了 2016 一整年的时间线。只不过，惊 喜不断的同时，嘈杂的容器圈子也难免给我们带来了些许无所适从的挫败 感。回顾这一年的容器技术发展历程，相信大家都有这样的疑惑:当这个 圈子平复下来之后，我们该如何去理性地思考和解读呢?
#Docker
  在 2016 年，当我们再次说出这个关键词的时候，已经很难用一句话 解释清楚我们到底在说的是什么。是 Docker 公司?是 Docker 容器?是 Docker 镜像?还是 Docker 集群?
在创业初期通过一连串极其成功的开源战略迅速蹿红之后，Docker 项目几经重构，最终选择了“大一统”的战略模式，一系列普通认知中应 该是独立项目的功能模块都被编译进了 Docker 项目的二进制文件中，这 其中最引人注目的，当属 SwarmKit 项目。
  2016 年 6 月，Docker 公司宣布将在接下来版本的 Docker 项目中将会 提供内置的“编排”功能，这个功能的实现将主要由一个名叫“SwarmKit” 的依赖库来负责。此新闻一出立刻成为容器圈子一时的舆论热点，尤其 在国内。其中，看涨者不少，有言“生态闭环”、“Docker 正统”， 唱衰者也不缺，直呼“公然越界”、“野心昭然”。时至今日，该项目 本身也日趋稳定，我们不妨再回头来重新解读一下曾经在风口浪尖上的 #SwarmKit。
   SwarmKit 的核心功能乃是“编排”，不过它对这个编排的定义还是 比较模糊的，在初期主要指的是“多容器副本”和“副本负载均衡”两个 核心能力，后面逐渐加入的是更多应用管理功能。说起这个项目发布的初 衷，当时国内的诸多讨论之中，曾有一种误区是认为 SwarmKit 是 DockerSwarm 项目的继承、是 Swarm 项目的“内置版”(当然，这也要部分归 功于 Docker 公司老辣的命名技巧)。但现在回头来看，这些“编排”能 力在Docker Swarm项目中，一直都是不存在的，继承自然无从谈起。 SwarmKit唯一跟Docker Swarm项目重叠的功能乃是“调度”，但实际上 SwarmKit 的调度也是从头做起，它维护了一个 NodeHeap(堆)，然后通 过堆算法配合过滤条件来筛选最符合要求的节点来运行任务。这套调度机 制在Swarm中也是不存在的。而在API层面，Docker Swarm项目提供的 是一套简洁的单容器的 API 来让用户操作容器集群(这个能力非常受欢 迎)，而 SwarmKit 却从一开始就引入了 Service，Task 等一系列面向容 器集群的、平台级别的概念，并且从底层实现上就不兼容 Swarm 风格的单 容器 API。两者的关系正如同“Java”和“JavaScript”一样风马牛不相及。
   那么 Docker 公司内置“编排”能力并且起一个这样的有混淆意味的 名字，到底意义何在呢?
答案很简单:“平台(Platform)”。或者说成是“应用 / 容器集群 管理”，或者说成是“PaaS”甚至“CaaS”，都可以，一个意思。
这个改变的关键就在于，从今以后Docker项目就变成了一个“平台” 项目而不再是一个单纯的“容器”项目了。它要站在 Kubernetes，DC/ OS，Cloud Foundry一样的位置上直面云的终端用户，而不是继续做这些 平台背后的容器技术(甚至只是容器技术中的一种)。
  这种平台级别的能力对于 Docker 公司来说是至关重要。容器的热度 终究会冷却，用户很快就不会关心底层的容器技术为何物，他们只会记 得Kubernetes API，Service，Replication Controller，DC/OS，顶多 在编写 Dockerfile 的时候，才回忆起 Docker 公司的存在。很多人批评 Docker 公司野心太大，其实对于一家拒绝了微软 40 亿美金收购的后端
 术创业公司来说，有怎样的进取心都不为过。Docker 公司的目标是下一 个 VMware，下一个 Intel，一个实实在在能盈利能上市的商业公司，在这 个巨头如林的云计算行业里，这是令人钦佩的。
  Docker 公司在 2016 年在集群领域所做的努力离不开“平台”二字， 不过国内曾经一度涌现出来的过分解读着实让这个项目背负了太多的压 力。其实打开 SwarmKit 项目的代码看看，从编排到调度，模块设计，代 码实现，跟其他项目并无二异，ipvs 也是普通的 NAT 模式，Master 节点 一样维护着 Apiserver, Scheduler, Orchestrator，同宿主机上的 Agent 通过 gRPC 交互，就连 Agent 也跟其他“第三方”项目一样也要通过 client去调用Docker Engine的API。所谓的各种“颠覆性”、“大道至简”、 “容器 OS 化”、“从下往上改变容器云形态”等观点，实在无从谈起。
  还有一种可能性是Docker公司依靠Docker Swarm这样一个独立 的、以单容器操作 API 为核心的项目来完成 PaaS 的使命(业界基于 Swarm 构建 PaaS 的用户不在少数)。但现实是，几乎同时发布的 Google Kubernetes 项目却出人意料地狙击了 Swarm 的发展势头。下图是自发布起， Swarm 项目和 Kubernetes 项目 GitHub Star 数目的变化统计。
  事实上，Docker Swarm项目“使用单容器API来操作集群”的理念 是相当有吸引力的。但是这个能力在接下来 Docker 公司想要重点发展的 企业私有云市场却陷入了窘境:单容器 API 纵然简单友好，但企业级用户 却没办法直接用它来实现哪怕一个最简单的“容器集群负载均衡”的需求。 所以很多企业私有云用户更倾向于把Docker Swarm项目作为容器云的一 个环节，然后自己来实现各种平台级别功能(往往还要参考 Kubernetes 的各种理念和设计)。照这个趋势发展，如果不推翻重来提供类似的面向 集群的 API，Docker 公司的平台之梦恐怕就很难实现了。这也正是为什么 我们前面简单一对比就不难发现，SwarmKit 相比 Swarm 项目其实是翻天 覆地的自我革命，而非继承或者内置，所谓向后兼容的问题自然也无从谈 起。
  其实，很多人可能已经忘记了早在Docker Swarm项目发布之前， Docker 公司已经发布过一个集群管理的项目叫“libswarm”(访问该项 目地址有彩蛋:https://github.com/docker/libswarm)。这个项目的初 衷非常单纯，就如同 Docker 项目最开始发布时一样“冰雪通透”，“libswarm 项目的初衷是提供一套不依赖与现有分布式系统的集群管理 API，并使得 其他项目可以使用它来方便的构建容器集群......”
  彼时的 Docker 公司，还希望 Mesos，Fleet 们使用 libswarm 来管理 Docker 容器云呢。
所谓“Swarm 已死，Swarm 永生”，Docker 项目又何尝不是呢。
在经历了 OCI 成立、贡献出了核心组件 libcontainer 之后，Docker 公司坚定地走向了独立发展的道路。在巨头们的围剿之中，这是一家创业 公司从默默无闻到炙手可热，再到痛定思痛之后的必然选择，SwarmKit， 以及其他所有外界看来“野心太大”的项目和举措，都只是这个信念的间接产物而已。在未来，Docker 公司依然会不遗余力的构建自己的平台世 界，网络，存储，Infra Layer，CI/CD，一个全功能平台级项目所欠缺的 版块都会被一一补全，各种各样内置于Docker Daemon中的Kit库和收购 还会层出不穷，Docker 公司还会以此为基础重点推广可以盈利的 Docker Cloud 和 Docker Datacenter。这样的选择很正确，并且唯一。
另一方面，在补全平台级别功能的过程中，Docker 项目会依然选择 将这些管理组件跟原先的Docker Daemon耦合在一起。从技术角度来看， 这并不是个明智之选，过高的耦合度所带来的不稳定性、Data Race和维 护的问题会愈加凸显。但从推广的角度来看，这个做法非常厉害:Docker 项目需要努力争取现有用户和粉丝的青睐，引导他们放弃单容器 API，转 而接纳新的、平台级别的 API。这个转变是站上“Platform”这个舞台在 所难免的，也是从 Swarm 项目上所得来的经验教训。
  2016年末，Docker项目将容器运行时相关的最后一个组件 containerd 也正式剥离，“Docker”这个名字离“容器”渐行渐远，离“PaaS” 越来越近。可能有人会疑惑:像 Kubernetes，DC/OS，或者未来的 Docker 项目，它们跟 PaaS 不是还有所不同吗?实际上，在这股正是由 Docker 掀 起的容器浪潮下，PaaS 的定义恐怕早已悄然变化。
正所谓“PaaS 已死，PaaS 永生”。
在容器集群管理和企业级需求的支持上，Docker 公司还是个新生儿， 但 Docker 项目成功的哲学乃是“simple but powerful”，它一直坚持提 供尽量简单的命令行界面，并不惜为此选择更复杂的实现方式，这将是它 在未来会继续火热的杀手锏之一:对于任何希望快速寻求一个“可用”的 容器工具的开发者和运维者来说，这个吸引力是巨大的。
#Kubernetes
  尽管 Docker 公司整整一年都在““平台”领域发力，Kubernetes 依 然是这个领域最瞩目的项目。这并非意外，在开源的世界里，一旦在某 个领域树立了标杆，就很容易跟竞争对手拉开质的差距。Kubernetes 幸 运的成为了“容器集群管理“领域的开创者，其他的后进项目，无论是 Marathon 还是 SwarmKit，都只能主动或者被动地 follow 开创者的提出 的理念。这正如同如果让 Google 再做一个容器，它也会十有八九 follow Docker 一样。“如果大家只是再造一个 Kubernetes，那有什么理由会比 Kubernetes 团队做的更好?”
  当然，含着“千呼万唤始出来”的 Borg 论文出生，又是 Google 公司 在Big Data领域错失机会之后着重推出的平台级开源项目，Kubernetes 本身自然有其过人之处。
Kubernetes 的发布给整个容器圈子带来了一系列前所未闻的概念: Service，Replication Controller，Pod，Labels & Label Selector， DaemonSet, Cron Job等等等等。当时，不少用户还在评论Kubernetes 的理念太超前了。而现在回头来看，这些特性不仅被用户所接受，而且很 多还被其他平台项目比如 Docker、Marathon、DC/OS 所采纳，变成了它们 的内置功能:正如同做容器不支持 Docker 就显得“落伍”一样，搞平台 不谈“Service”、”Replica“，你的编排就不够 fancy。
Kubernetes这种相对超前的技术视野与它背后原Google Borg和 Omega 团队成员的经验和努力密关系巨大。Borg/Omega 系统在 Google 基 础设施体系中的声誉和地位无需多言，而用户在 Kubernetes 中接触到的 很多概念，其实在Borg/Omega系统中都有等价的特性。从这个角度来说，把 Kubernetes 项目描述为 Borg 系统在开源领域的重生并不为过。 在这一年里，Kubernetes 不断地强化自己在容器集群管理领域的优 势，密集发布了一系列让人称道的设计。不难预料，这些概念很快也会在
其他项目中被借鉴和采纳。
就比如 Secret，它允许用户将加密过的 Credentials 信息保在
Etcd 中，然后在容器中通过环境变量或者挂载文件的方式访问它们，从 而避免明文密码被随意写在环境变量、配置文件或者 Dockerfile 中的问 题。
类似的还有 ConfigMap，只不过保存在 Etcd 的内容，是应用所需的 配置信息。
  再比如 Deployment，它使得用户可以直接编辑容器化任务的属性， 然后直接触发 Rolling Updae，还允许用户随意回滚任务到以前的版本。
再比如 DaementSet，它允许用户一键部署运行在所有节点上的守护 进程任务。
  而最近推出的 StatefulSet，则提供了原生支持有状态的应用的强大 能力，并且既包括了拓扑结构状态，也包括了存储状态。
  还有备受欢迎的ScheduledJob，它允许用户用标准的Cron Job格式 来定义从镜像启动的定时任务，并保证这个任务执行的正确性和唯一性。 如此种种，都是 Kubernetes 在容器编排和管理领域树立标杆的手段， 而这些设计背后的思想又十分朴素:如果在 Borg 里，或者在没有容器的 传统环境下，我们能够通过脚本或者其他手段自动化地做某些事情，那么 Kubernetes同样应该帮你做到。这个过程，正是Kubernetes所定义的(也 是我们传统运维意义上的)“编排”，也是DevOps 理念中所追求的“NoOPs”的主要手段。  
     在 2016 年，Kubernetes 另一个重点发力的领域则是 CRI(Container Runtime Interface)。值得一提的是，CRI的提出者和推广者正是 2015年InfoQ CNUT容器大会讲师、华人女工程师Dawn Chen，她也是 Kubernetes 的几位元老级(Elder)成员之一。早在 Docker 公司在集群 领域发力之前，Dawn所领导的Node Team就已经颇有远见地开始制定解 耦容器运行时的方案并持续在社区推动。通过制定这样固定的访问接口， Kubernetes 不再对任何容器 API 产生多余的依赖，也避免了锁定在某种 容器运行时之上的尴尬。目前，Kubernetes CRI 主要由来自 Google 公司、 Hyper 国内团队、以及 CoreOS 的工程师负责维护。
  得益于 CRI 的逐渐成熟，Kubernetes 项目在容器运行时领域的支持 能力得到了巨大的提升，除了默认的 Docker 容器之外，基于虚拟化技术 的 HyperContainer，CoreOS 公司的 rkt 都已经能够通过 CRI 原生接入 了 Kubernetes。而 runC 团队也不甘寂寞，来自 SUSE 和 RedHat 的 runC Maintainer 提交了了一个叫做 CRI-O 的孵化项目用来直接将 runC 接到 Kubernetes 中。此外，来自微软的 Windows 容器也已经进入 Kubernetes 体系。尽管还未完全
release，Kubernetes CRI的受欢迎程度已经略见一 斑。
在接下来的进展中，Kubernetes 会继续加强自己的已有优势，更多 新的容器编排和管理能力会接踵而至，其中有状态应用的支持、更加完 善的网络规则、GPU和NUMA的支持、批处理和Big Data任务支持都是 值得关注的特性。值得注意的是，Kubernetes 在定义容器编排和容器管 理方面有一个先天的优势:由于 OpenShift(Redhat 基于 Kubernetes 的 PaaS)的存在，Redhat 团队一直在非常谨慎地确保 Kubernetes 不会功能 泛滥。这正是 Kubernetes 保证自己所提供的平台能力恰到好处的一个重要手段。
   与此同时，在捐献给Linux Foundation之后，Kubernetes所属的CNCF 基金会已经构建出了一个围绕 Kubernetes 的平台生态系统，CNCF 的成员项目不仅包括了 Prometheus 这样的明星，还包括了 gRPC 这样的 底层依赖。这些项目之间会尽力兼容 API 和数据格式，减轻用户构建云 平台的负担。一个最典型的例子，就是 Kubernetes 可以直接使用来自 Prometheus 的监控数据来做容器自动扩展，无需做任何格式转换和数据 过滤。而 Kubernetes 正在全面基于 gRPC 进行的全通路上的性能优化(包 括Etcd v3)也得益于该社区的有力支持。日前，国内的PingCAP也得到 了 CNCF 的大力赞助，有望在存储状态管理和基于本地磁盘的持久化卷方 面为社区注入新的血液。
   未来的时间里，Kubernetes 面对的挑战依然严峻，其中最大的问题 在于作为一个试图真正解决问题工业级项目，如何能保证自己功能足够完 善的同时，始终给用户提供简单和友好的交互体验。毕竟在未来一段时 间内，争取用户依然是所有玩家的重中之重。我们已经看到 Kubernetes 正在对 UI/UX 进行优化，最典型的例子是 kubeadm 工具，一举解决了之 前Kubernetes部署不方便的顽疾，用户终于可以用kubeadm init和 kubeadm join 这样的指令来启动完整的集群了。
   在 2016 年的 Kubernetes 生态中，还有一个不能被忽视的因素就是 自家兄弟 Tensorflow 的迅速蹿红(甚至短时间内就超越了 Docker 项 目，速度令人咋舌)，并且直接推动了人工智能元年的诞生。在社区层 面 Tensorflow 目前仍无实质性的竞争对手，无论是大小公司还是机构， 基于该项目的人工智能项目如雨后春笋般涌现，创业公司也层出不穷，而 Kubernetes+Tensorflow 的搭配则成为了默认的“基础设施 + 深度学习平台”的组合。这个机遇恐怕没人能事先预料到。
回想当初 Kubernetes 刚发布时的，不少人还对没有拿到一个真正的开源版的 Borg 表示失望。两年后的今天，再回顾这个项目的发展历 程，我们不得不说 Kubernetes 已经走出了一条独立的、健康的发展路 线。在这条以开源容器技术兴起为源头的道路上，越来越少人会再去谈论 Borg，去做无谓的比较。Kubernetes 项目正继承着这些优秀的思想，开 启了一个关注容器和应用本身、专注编排和集群管理的新领域。
在这个前所未有的、容器为王的世界里:“Borg 已死，Borg 永生”。
#Mesos 生态
  当今容器圈子，除了以 Docker 为主角的容器运行时和以 Kubernetes 为主角的容器集群管理，还有一方“势力”绝不能被忽视，这就是 Mesos 生态。众所周知，Mesos 本身是一个“老”项目，它诞生于伯克利，崛 起于Big Data的爆发。在Docker刚开始成名的头两年，Swarm项目羽 翼未丰，Mesos 独有的支持多种 Framework 的设计使它得以轻松接入 了 Docker 生态，并在当时成为了管理 Docker 容器集群的不二之选，占 满了 DockerCon 的重要位置。毕竟天生就具备管理万级别节点规模的水 准，上层的 Marathon 框架又能提供一套完善的 PaaS 功能，还有喜人的 UI，还能提供生产级别Big Data业务的支撑，Mesos没有理由不受欢 迎。不过紧接着，Marathon+Mesos 的组合开始显现出疲态，在 Docker 和 Kubernetes 各自亮出杀手锏不断刷新用户三观的时候，Apache 社区固有 的响应迟钝拖慢了 Mesos 进化的速度，而由创业公司维护的 Marathon 又 一直没办法构建出更加繁荣和活跃的社区。“社区”两个字，竟成了 Mesos 生态的命门。在 Docker 公司煞费苦心在
    社区争取每一个用户和粉丝、Google 公司放下身段把 Github 作为一线阵 地，用 Kubernetes 全力输出技术理念的时候，一旦错失了先机，哪怕有 一身本事如 Mesos 项目，也只能望用户而心叹。这正是目前 Mesos 生态系 统在容器圈子表现的不够强势的重要原因。当然，既然实力强劲，Mesos 生态在工业界中的案例还是数不甚数，除了 Marathon 框架，Mesosphere 公司重点维护的 DC/OS 项目其实能够提供并不逊于 Kubernetes 的各项 容器编排和管理能力，不可谓不强大。但是社区表现不力，使得 Mesos 生态错失了成为容器圈的“buzz word”(热词)的机会。SwarmKit发 布后，Mesos 生态同 Docker 项目的蜜月期也宣告结束，随后的 Mesos 1.0版本也正式release了Unified Containerizer并通过默认的 MesosContainerizer取代Docker Daemon，且原生支持多种镜像格式，这 个改变比 Kubernetes CRI 要彻底的多。与此同时，CNI 网络(Kubernetes 社区采用的网络插件标准)也已经在 Mesos 项目上得以支持。
    在未来，Mesos 生态会重点完善自己在 15-16 年反应不及时所欠下的 功能缺口，包括网络、存储、多租户、甚至 Pod 支持等重要的功能模块都 已经有方案提交到了 Roadmap。别忘了，Mesos 生态(包括 DC/OS)是目前(包 括未来一段时间)容器圈子唯一支持大数据任务的基础设施依赖，是唯一 有生产级别超大规模集群管理能力的资源管理框架，也是唯一原生提供界 面的应用管理平台。这三个“唯一”在很多用户心目中(尤其是传统企业 里)，占有十足的分量。
    曾经以 Marathon+Mesos 为代表的 Mesos 社区已经逐渐淡去，但围绕 着 DC/OS 的新的 Mesos 生态终将亮剑，正所谓:“Mesos 已死，Mesos 永生”国内外创业生态圈
如果说 2016 年的容器圈子仍然十分热闹，那必然少不了 startup 的 繁荣。围绕容器运行时、编排、网络、存储、镜像管理、CI/CD、PaaS 方案等的一系列生态环节所创立的 startup，是推动这个大环境蓬勃发展的 直接动力。
   除了本身就是创业公司的 Docker，容器圈的另一个主角当然是 CoreOS。虽然创新能力十足，但 CoreOS 公司的 rkt 容器仍然没能在 Docker 的强势下占据容器市场的主流。由于单点突破受阻，2016 年的 CoreOS 公司也做出了跟 Docker 公司类似的转型，开始向一个涵盖范围更 广的“容器云”公司靠拢。除了一系列改名、扩展 rkt 的职能之外，还有 一个重要的手段是:抛弃 Fleet，拥抱 Kubernetes。
   Fleet 曾经是 CoreOS 体系中重要的容器编排和调度项目，也曾同 Mesos 等项目一样在容器云领域占有一席之地。但现实证明，它并不足以 让 CoreOS 在“云”的市场上争取到竞争优势。凭借 Etcd 在 Kubernetes 中的重要作用，CoreOS 的工程师从性能调优作切入口进入了 Kubernetes 生态，并做出了显著的成绩，rkt 也在 CRI 发布之前就成为了 Kubernetes 的可选容器运行时之一，kubelet则被内置到CoreOS Linux中作为默认 的编排和调度框架。2016 年，CoreOS 又围绕 Kubernetes 发布了一系列工 具如 Operator 来完善生态中的“有状态应用管理”，“存储管理”等能力， 已经可以说是最成功的结合 Kubernetes 来创业的 startup。与 CoreOS 不同，国内的创业公司的发力点主要集中于提供容器服务 的 PaaS 产品(也有人称之为 CaaS 以突出自己的容器特性)。相比于创业 初期主要集中于容器管理平台的建设，2016 年的国内容器创业公司则主 要在围绕自己的平台构建生态类产品，涵盖了监控、存储、镜像监管、客 服等一系列工具，其产品能力明显强于同类型的国外 startup。另一个显 著的变化是，2016 年国内创业公司开始更多关注和宣传线下企业私有云 市场的生意，创业初期着重推广的公有云服务的更新和维护力度明显降低。 毕竟，在国内创业公有云盈利困难是一个不争的事实。 产品能力的异常强劲，侧面反衬出了国内创业公司在上游社区层面的影响力的弱势，在社区中推动和提出项目特性的能力依然欠缺。当 然，创业维艰，尤其是国内大环境下，恐怕也只有华为能够在一边维护 和推进 runC 等 OCI 项目的同时，一边在 Kubernetes 上开展完整的“联 邦集群”特性(甚至将 Google 的负责人招致麾下)。还有 Hyper，这只 团队已经是Kubernetes CRI的重要维护者之一(CRI中很大部分代码正 出自他们之手)，同时也是 runC 运行时 cri-o 项目的维护者，已经在 Kubernetes 容器管理部分争取到了一席之地。而其本身维护的虚拟化容 器 HyperContainer 项目和以此为基础的 hyper.sh 容器托管服务，则创下 了占据 HackerNews 首页长达 24 小时的惊人记录。不过放眼全球市场，这 些工作只能说是 Hyper 的本职，并不能掩盖国内团体在整个容器开源社区 里弱势的现状。而这个现状的改变，以目前国内大多数 startup 的运营方 式和核心能力点来看，恐怕还尚需时日。
   2016 年国内另一件新闻则是阿里云同 Docker 公司的牵手。这并非临 时起意，早在 2015 年在国内容器创业氛围正值巅峰时，阿里云并没有直 接进场，“而是在谨慎考察国内环境对容器的接纳程度”(此信息来自阿 里云官方)。时至 2016 年，容器技术已经在国内红透半边天，作为后来 者，体量又如阿里云这般的巨头要想再进场，必须要拿出最强势的姿态来 踏出这第一步。同 Docker 公司展开官方合作，可以说是最佳选择。而对 于 Docker 公司来说，Google 和 AWS 已经成为直接竞争对手，放眼全球， 阿里云即是拿得出手的一线厂商，又对 Docker 公司无毒无害，这次合作 可谓一拍即合。只是从此国内其他公司再想拿“Docker 官方”、“Docker Native”来做宣传，在这个排他性的合作面前，恐怕就需三思而后行了。
#总结
2016 年，容器技术圈子依然热闹非凡，容器社区里的弄潮儿们在 “is dead”和“long live”的悖论里不断地自我否定和进化已成为这 个社区所独有的常态。Docker 公司“萌萌哒”的鲸鱼背后，一只野心勃 勃的海洋霸主正蓄势待发;而作为容器编排管理领域的领导者，纵使有 Google、Redhat 等巨头的撑腰，Kubernetes 恐怕也不会放慢脚步，通 过 CRI 联合 CNCF、OCI 两大开源社区举措也在情理之中。容器技术的圈 子里容不得懈怠，Mesos 生态已经开始励精图治，意在凭借独有的能力拿 回昔日的地位。我们不难发现，在 Docker 公司向平台领域发展的同时， Kubernetes、Mesos 也同样渗透进了容器运行时的范畴。实际上，正如同 那些支付宝与微信之争，几个大佬原生的核心能力恐怕才是它们取得今天 成绩的关键所在。作为终端用户，理清自身真实需求之后，做出适合自己 的选择其实并不太难。
容器技术圈子的繁荣，得益于现代开源软件社区的成功。Docker 自 不必说，Kubernetes、Tensorflow 亦如是。连 Google、Microsoft 这样 的巨头都一改对开发者傲慢的态度和轻视开源社区运营的作风而扎堆到 GitHub 上施展浑身解数，有幸同处一个时代而成为参与者和亲历者的我 们又有何理由作壁上观呢。

第二章

解读 2016 之深度学习篇:开源深度学 习框架发展展望

#引言
深度学习(Deep Learning)的概念由加拿大多伦多大学教授 Geoffrey Hinton等人于2006年提出，它本质上是一种神经网络算法， 其原理是通过模拟人脑进行分析学习，算法训练时可以不用人工干预，因 此它也属于一种无监督式机器学习算法。从深度学习的概念提出到今天， 已历经十年时间，在这十年当中，无论是国际互联网巨头 Google、微软、 百度，还是全世界各大学术研究机构，都投入了巨大的人力、财力用于理 论和工业级应用的探索，并在字符识别(OCR)、图像分类、语音识别、 无人自动驾驭、自然语言处理等众多领域内取得了突破性的进展，极大地 推动了人工智能(AI)的发展。
  2012年斯坦福大学的Andrew Ng和Jeff Dean教授共同主导的 Google Brain项目通过使用深度学习让系统能够自动学习并识别猫，这 项目研究引起了学术界和工业界极大的轰动，激起了全世界范围研究深度 学习的热潮，《纽约时报》披露了Google Brain项目，让普通大众对深 度学习有了最初的认知。2016 年 3 月，Google 旗下 DeepMind 公司开发AlphaGo 以 4:1 的总比分战胜了世界围棋冠军、职业九段选手李世石，这 让人们对人工智能(AI)的认知跨越到一个新的阶段。
    深度学习在众多领域的成功应用，离不开学术界及工业界对该技术的开放态度，在深度学习发展初始，相关代码就被开源，使得深度学习“飞入寻常百姓家”，大大降低了学术界研究及工业界使用的门槛。本文并不打算对深度学习算法的发展趋势进行分析，而是跳出算法层面，对当前主流的开源深度学习框架的发展趋势进行分析。
开源深度学习框架
在计算机视觉领域内，神经网络算法一直被用来解决图像分类识别等 问题，学术界采用的算法研究工具通常是 Matlab、Python，有很多深度学习工具包都是基于 Matlab、Python 语言，在使用海量图像训练深度学 习算法模型时，由于单台机器 CPU 的计算能力非常有限，通常会使用专门 的图形处理器(Graphics Processing Unit，GPU)来提高算法模型速度。 但在工业级应用当中，由于 Matlab、Python、R 语言的性能问题，大部分 算法都会使用 C++ 语言实现，而且随着深度学习在自然语言处理、语音识 别等领域的广泛应用，专用的GPU也慢慢演变为通用图像处理器(General Purpose GPU，GPGPU)，处理器不仅仅被用于渲染处理图像，还可以用于 需要处理大数据量的科学计算的场景，这种提高单台机器的处理能力的方 式属于纵向扩展。
   随着大数据时代的来临，大数据处理技术的日趋成熟为解决深度学习 模型训练耗时问题提供了重要发展方向，因此如何通过大数据训练深度学 习模型在当前引起了广泛关注，大量的研究表明:增加训练样本数或模型 参数的数量，或同时增加训练样本数和模型参数的数量，都能够极大地提 升最终分类的准确性。由于 Hadoop 已经成为构建企业级大数据基础设施 的事实标准，有许多的分布式深度学习算法框架被构建在 Hadoop 生态体 系内，这种通过分布式集群提高处理能力的扩展方式被称为横向扩展。
  虽然利用 Spark 等平台训练深度学习算法可以极大地提高训练速度， 但近年来，存储设备和网络在性能方面的提升远超 CPU,CPU 性能瓶颈极大地限制了分布式环境下，单台节点的处理速度。为 解决这一问题，许多优秀的开源深度学习框架都在尝试将开源大数据处理 技术框架如 Spark 和 GPGPU 结合起来，通过提高集群中每台机器的处理性 能来加速深度学习算法模型的训练，图 3 给出的是 SparkNet 的架构原理图。 这种通过结合横向扩展及纵向扩展提高处理能力的方式被称为融合扩展。 图 4 对深度学习提升性能的方式进行了总结，图中分别给出了横向扩展、 纵向扩展及融合扩展的典型开源深度学习框架。
图 3.SparkNet 中的 Scale Up 和 Scale Out 图 4. 深度学习提升性能的方式
下面将对目前一些优秀的开源深度学习框架进行介绍，包括基于 GPU 的单机开源深度学习框架和融合了 GPU 的开源分布式深度学习框架。让大 家熟悉目前开源深度学习主流框架的同时，又能够进一步窥探开源分布式 深度学习框架的发展方向。
#单机开源深度学习框架
目前拥有众多的学术机构如国际顶级名校加州大学伯克利分校，以及 互联网巨头如 Google、微软等开源的深度学习工具，比较成熟的基于 GPU 的单机开源深度学习框架有:
Theano:深度学习开源工具的鼻祖，由蒙特利尔理工学院时间开发于 2008 年并将其开源，框架使用 Python 语言开发。有许多在学术界和工业界有影响力的深度学习框架都构建在 Theano 之上，并逐步形成了自身的 生态系统，这其中就包含了著名的 Keras，Lasagne 和 Blocks。
Torch:Facebook 和 Twitter主推的一款开源深度学习框架， Google 和多个大学研究机构也在使用 Torch。出于性能的考虑，Torch 使 用一种比较小众的语言(Lua)作为其开发语言，目前在音频、图像及视 频处理方面有着大量的应用。大名鼎鼎的Alpha Go便是基于Torch开发的， 只不过在Google 开源TensorFlow之后，Alpha Go将迁移到TensorFlow 上。
TensorFlow:Google 开源的一款深度学习工具，使用 C++ 语言开发， 上层提供Python API。在开源之后，在工业界和学术界引起了极大的震动， 因为TensorFlow曾经是著名的Google Brain计划中的一部分，Google Brain 项目的成功曾经吸引了众多科学家和研究人员往深度学习这个“坑” 里面跳，这也是当今深度学习如此繁荣的重要原因，足见 TensorFlow 的 影响力。TensorFlow 一直在往分布式方向发展，特别是往 Spark 平台上 迁移，这点在后面会有介绍。
Caffe:Caffe 是加州大学伯克利分校视觉与学习中心(Berkeley Vision and Learning Center ，BVLC)贡献出来的一套深度学习工具， 使用C/C++开发，上层提供Python API。Caffe同样也在走分布式路线， 例如著名的 Caffe On Spark 项目。
CNTK:CNTK (Computational Network Toolkit)是微软开源的深 度学习工具，现已经更名为Microsoft Cognitive Toolkit，同样也使用 C++语言开发并提供Python API。目前在计算视觉、金融领域及自然处理 领域已经被广泛使用。
DeepLearning4J官网有篇文章《DL4J vs. Torch vs. Theanovs.Caffe vs. TensorFlow》，对这些主流的深度学习框架的优劣势进行了详 细的分析比较，感兴趣的读者可以点击查看。 
#分布式开源深度学习框架
  Google 研 究 员 Jeffy Dean 在 2012 发 表 了 一 篇《Large Scale Distributed Deep Networks》对分布式环境下的深度学习算法设计原理 进行了阐述，给出了深度学习在分布式环境下的两种不同的实现思路:模 型并行化(Model parallelism)和数据并行化(Model Parallelism)。 模型并行化将训练的模型分割并发送到各 Worker 节点上;数据并行化将 数据进行切分，然后将模型复本发送到各 Worker 节点，通过参数服务器 (Parameter Server)对训练的参数进行更新。具体原理如图 5 所示。
图 5. 深度学习并行化的两种方式:模型并行化(左)和数据并行化(右)
目前开源分布式深度学习框架大多数采用的是数据并行化的方式进 行设计。目前有两大类:框架自身具备分布式模型训练能力;构建在 Hadoop 生态体系内，通过分布式文件系统(HDFS)、资源调度系统 (Yarn) 及 Spark 计算平台进行深度学习模型训练。其中框架自身具备分布式模型 训练能力的开源深度学习框架有:
• DSSTNE:亚马逊开源的一套深度学习工具，英文全名为Deep Scalable Sparse Tensor Network Engine(DSSTNE)，由C++语言实现，解决稀疏数据场景下的深度学习问题。值得一提的是，亚马 逊在是否走开源的道路上一直扭扭捏捏，开源DSSTNE，似乎也是在 Google、Facebook等巨头抢占开源深度学习领域高地之后的无奈之 举。
• Paddle:百度开源的并行分布式深度学习框架(PArallel Distributed Deep Learning，PADDLE)，由C++语言实现并提供 Python API。Paddle框架已经经过百度内部多个产品线检验，包 括搜索广告中的点击率预估(CTR)、图像分类、光学字符识别 (OCR)、搜索排序、计算机病毒检测等。
由于 Hadoop 生态体系已经占据了企业级大数据市场的大部分份 额，因此目前许多开源分布式都在往 Hadoop 生态体系迁移，这其中有 Caffe、TensorFlow，也有百度的 Paddle。构建在 Hadoop/Spark 生态体 系下的深度学习框架实现原理图如下:
图 6. Hadoop 生态体系分布式深度学习算法实现原理
目前比较有影响力的基于 Hadoop/Spark 的开源分布式深度学习框架 有:
1. SparkNet:由AMPLab于2015年开源，底层封装Caffe和
 Tensorflow，采用集中式的参数服务器进行实现，具体实现原 理及架构参见论文《SPARKNET: TRAINING DEEP NETWORKS IN SPARK》。
2. Deeplearning4J:由Skymind公司于2014年开发并开源的分布式深 度学习项目，采用Java语言实现，同时也支持Scala语言。它使用 的参数服务器模式为IterativeReduce。
3. Caffe On Spark:Yahoo于2015年开源的分布式深度学习框架，采 用Java语言和Scala语言混合实现，使用Spark+MPI架构以保障性 能，其参数服务器采用点对点(Peer-to-Peer)的实现方式。通过 将Caffe纳入到Hadoop/Spark生态系统，解决大规模分布式环境下 的深度学习问题，意图将Caffe On Spark成为继Spark SQL、Spark ML/MLlib、Spark Graphx及Spark Streaming之后的第五个组件。
4. Tensorflow on Spark:2014年由Arimo公司创建，将TensorFlow移 植到Spark平台之上。
5. TensorFrames (TensorFlow on Spark Dataframes) :Databricks 开源的分布式深度学习框架，目的是将Google TensorFlow移植到 Spark的DataFrames，使用DataFrame的优良特性，未来可能会结合 Spark的Structure Streaming对深度学习模型进行实时训练。
6. Inferno:由墨尔本La Trobe大学博士生Matthias Langer开发的基 于Spark平台的深度学习框架，作者正在整理发表关于Inferno的实 现原理论文，同时也承诺在论文发表后会将代码开源到GitHub上。
7. DeepDist:由Facebook的资深数据科学家Dirk Neumann博士开源 的一套基于Spark平台的深度学习框架，用于加速深度信念网络 (Deep Belief Networks)模型的训练，其实现方式可以看作是论文《Large Scale Distributed Deep Networks》中 Downpour随机 梯度下降(Stochastic Gradient Descent，SGD)算法的开源实 现。
8. Angel:腾讯计划于2017年开源的分布式机器学习计算平台，Angel 可以支持Caffe、TensorFlow和Torch等开源分布式学习框架，为 各框架提供计算加速。Angel属于腾讯第三代机器学习计算平台， 第一代基于Hadoop，只支持离线计算场景，第二代基于Spark/ Storm，使用自主研发的Gala调度平台替换YARN，能够同时支持在 线分析和实时计算场景，第三代属于腾讯自研的平台，除底层文件 系统使用HDFS外，资源调度和计算引擎全部为腾讯自研产品。
SparkNet、Deeplearning4J及Caffe On Spark等构建在Spark平 台上的深度学习框架在性能、易用性、功能等方面的详细比较，参见 《Which Is Deeper Comparison of Deep Learning Frameworks Atop Spark》、《Inferno Scalable Deep Learning on Spark》。由于近几年 在大数据技术的日趋成熟和流行，特别是基于 JVM 的语言(主要是 Java 和 Scala)构建的大数据处理框架如 Hadoop、Spark、Kafka 及 Hive 等几 乎引领着大数据技术的发展方向，相信以后将会有越来越多的开源深度学 习框架构建在 Hadoop 生态体系内，并且基于 Java 或 Scala 语言实现。 总结与展望
本文首先介绍了深度学习提升性能的三种方式:纵向扩展(给机器加 GPU)、横向扩展(通过集群训练模型)及融合扩展(在分布式的基础上， 给每个集群中的 Worker 节点加 GPU)，然后对主流的开源深度学习框架 进行了介绍。通过对这些开源深度学习框架的了解，可以看到当前开源深度学习框架的发展有以下几个趋势:
• 分布式深度学习框架特别是构建在Hadoop生态体系内的分布式深度
学习框架(基于Java或Scala语言实现)会越来越流行，并通过融合扩展的方式加速深度学习算法模型的训练。
• 在分布式深度学习方面，大数据的本质除了常说的4V特性之外，还有一个重要的本质那就是Online，数据随时可更新可应用，而且数 据本质上具备天然的流式特征，因此具备实时在线、模型可更新算 法的深度学习框架也是未来发展的方向。
• 当待训练的深度学习算法模型参数较多时，Spark与开源分布式内 存文件系统Tachyon结合使用是提升性能的有效手段。
深度学习作为 AI 领域的一个重要分支，俨然已经成为 AI 的代名词， 人们提起 AI 必定会想到深度学习，相信随着以后大数据和深度学习技术 的不断发展，更多现象级的应用将不断刷新人们对 AI 的认知，让我们尽 情期待“奇点”临近。