posts - 16,&
comments - 15,&
trackbacks - 0
这篇文章是对这段时间学习并行编程中的设计模式的一个总结。有不当之处，希望得到大家的批评、指正。
首先，所谓“并行编程中的设计模式”（patterns in parallel programming）仍处于不断的被发现、发掘的阶段。当前已经有各路人马对这一领域进行了研究，但远远没有达到统一认识的高度。也没有一套业界普遍认同的体系或者描述。这就造成了当前这一领域的现状：从事研究的人有不同的背景，他们各自总结出的模式种类不尽相同。即使是同一个模式，不同的团队给它们取得名字也可能不一样。不过这并不妨碍我们对“并行编程中的设计模式”进行一定的了解，并在实际的软件开发工作中有所借鉴。
本文分两部分，第一部分会简单介绍这一领域的发展现状：首先是进行研究的主要团体及其代表人物，然后介绍一下他们各自总结的模式体系，最后着重介绍一下加州大学伯克利分校的体系，A pattern language for parallel programming。第二部分则从该体系中挑出八个常用的设计模式作稍微详细一点的介绍。每个设计模式都附有实际的应用例子来帮助理解。我始终相信，通过例子的学习是最容易理解的一种方式。
1. 并行编程模式的发展现状
在这一领域比较活跃的研究团体包括：
1. 加州大学伯克利分校。其代表人物是Kurt Keutzer教授，他曾是Synopsys公司的CTO。
2. Intel公司。代表人物是Tim Mattson，他是Intel的Principle Engineer和并行计算的布道师(evangelist)，是“Patterns for Parallel Programming”一书的作者。
3. 伊利诺伊大学。代表人物是Ralph Johnson教授。他是著名的设计模式“Gang of Four”中的一员。
4. 其他团体：包括微软、麻省理工大学… 等等。
他们总结出的并行编程模式体系不尽相同，互相之间又有着紧密的联系。主要有：
1. 加州大学伯克利分校的
2. 伊利诺伊大学的
3. Tim Mattson 的著作
这其中，我最为喜欢加州大学伯克利分校的体系:
伯克利的研究人员认为，写出高质量并行软件的关键在于拥有好的软件设计：从软件的总体架构，一直到系统的底层实现。将这些“好的设计”以一种系统的方式描述出来，并在各个不同的软件项目当中重用是解决构建高质量并行软件问题的关键。这远比各种具体的编程模型以及其支撑环境来得重要。因为拥有了一个好的设计之后，我们可以很容易的在各种开发平台上编写源代码。
伯克利的模式体系包含了几个不同的层次，上自软件架构，下至程序指令执行的策略。最上面的两块分别是“架构模式”(Structural patterns) 和“计算模式”(Computational patterns)。这两块并不单单包括并行软件，也包括传统的串行软件模式。用我们常用来表达系统架构的线框图打比方，“架构模式”指的就是那些箭头和框框，它们表示的是程序总体的组织结构，以及各部分之间是怎么交互的。“计算模式”指的是框框里面的计算类型。例如，是基于图的算法，还是有限状态机，还是线性代数运算，等等。程序设计师通常需要在这两大类模式之间翻来覆去的进行选择。例如，我们可能先选择了一种架构模式，然后考虑使用某些合适的计算模式。但是选择的计算模式可能更适合于在另一种架构模式下运行，所以我们又得重新选择一种架构模式… …如此反复。上面这张图在“架构模式”和“计算模式”这两大块之间画了两个反复的箭头，表达的就是这个意思。
这张图下方的三大块就专指并行编程当中的模式了。它们包括“算法模式”(Algorithm strategy patterns)，“实现模式”(Implementation strategy patterns)和“并行执行模式”(Parallel execution patterns)。顾名思义，“算法模式”指的是程序算法层面的模式。它们表达的是，为了解决某一类实际问题，怎么样在较高的算法层面实现并行。“实现模式”指的是我们在编写源代码的时候，利用什么样的一些程序控制结构和数据结构来实现并行。例如“parallel_for”，例如并行容器，等等。最后一个“并行执行模式”指的是为了在计算机中有效的执行一个并行程序，我们应该采取哪些方法。这包括指令的执行模式，例如是MIMD还是SIMD，也包括一些任务调度的策略。这三类模式是紧密联系在一起的。例如，为了解决一个问题，我们可能使用“recursive splitting”的算法模式。而为了实现这个算法，我们很有可能使用“fork-join”的实现模式。在执行层面，并行程序库则通常会用“thread pool”的并行执行模式来支持“fork-join”的运行。
由于我们在编写程序时，“并行执行模式”往往由编译器或并行程序库例如TBB的编写人员考虑，我们并不需要关心；“实现模式”和我们选择的具体并行运算平台有关（OpenMP， TBB，MPI，…,，等等），不同的平台有不同的API；“计算模式”则和具体的问题域联接紧密。而且，看上去伯克利所总结的“计算模式”大部分和高性能计算有关，普通的应用程序员并不熟悉。所以在本文，我将只挑选和并行计算密切相关的两个“架构模式”和六个常见的“算法模式”举例进行说明。
2. 八个常用的并行编程模式
2.1 Agent and Repository
这是一个“架构模式”，它针对这样一类问题：我们有一组数据，它们会随机的被一些不同的对象进行修改。解决这一类问题的方案是，创建一个集中管理的数据仓库（data repository），然后定义一组自治的agent来操作这些数据，可能还有一个manager来对agent的操作进行协调，并保证数据仓库中数据的一致性。我们常见的源代码版本控制软件例如Perforce就是实现这种架构的典型代表：源代码都存放在一个统一的服务器中（或是一组服务器中，但对client而言是透明的），不同的程序员们使用各自的客户端对源代码文件进行读，写，加，删的操作。由Perforce负责保证源代码数据的一致性。
2.2 Map Reduce
Map Reduce这个名词原来是函数式编程里面的一个概念，但是自从Google于2004年推出同名的并行计算程序库后，提到这个名词大家大多想到的是Google的这个Framework。在这里，Map Reduce是一个“架构模式”的名称。当然，我们这里的Map Reduce指的就是类似Google Map Reduce工作原理的一类模式。
那么什么是Map Reduce的模式呢？用较为简单的语言描述，它指的是这样一类问题的解决方案：我们可以分两步来解决这类问题。第一步，使用一个串行的Mapper函数分别处理一组不同的数据，生成一个中间结果。第二步，将第一步的处理结果用一个Reducer函数进行处理（例如，归并操作），生成最后的结果。从使用Google的Map Reduce程序库的角度而言，作为应用程序员，我们只需提供一组输入数据，和两个普通的串行函数（Mapper和Reducer），Google的Map Reduce框架就会接管一切，保证输入数据有效的在一个分布式的计算机集群里面分配，然后Mapper和Reducer函数在其上有效的运行、处理，并最后汇总生成我们想要的处理结果。所有一切的细节，例如并行化、数据的分配、不同机器之间的计算误差，通通被隐藏在程序库内。
那么Map Reduce到底是什么样的一个过程呢？
我们讲过，使用Map Reduce，程序员必须提供一组输入数据，以及一个Mapper和一个Reducer函数。在这里，输入数据必须是一个按(input_key,input_value)方式组织的列表。
mapper函数的任务是处理输入列表中的某一个单元数据：mapper(input_key,input_value)，并产生如下输出结果：
接下来，把对所有单元数据的处理结果按照intermediate_key归类：同样的intermediate_key放在一起，它们的intermediate_value简单的串接起来，得到：
Reducer函数的任务是对上述的中间结果进行处理：reducer(intermediate_key, intermediate_value_list)，并产生如下最终输出结果：
我们会举两个例子说明这一过程。第一个例子是一个简单的统计单词出现次数的小程序。第二个例子是Google曾经怎样使用Map Reduce FrameWork来计算Page Rank。
第一个例子，假设我们要写一个小程序，来统计在几篇不同文章里所有出现过的单词各自总共出现的次数。我们应该怎么做呢？下面描述的利用Map Reduce的方法肯定不是大多数程序员第一感会想到的方法。但这种方法非常好的揭示了Map Reduce的基本思想。并且，这种方法很容易被扩展到处理上千万甚至是上亿的文件数据，并且能够在一个分布的计算机集群里面运行。这可不是传统的方法能够轻易做到的。
具体而言，假设我们有如下三个文本文件，a.txt, b.txt和c.txt：
对于输入数据而言，input_key就是文件名，input_value就是一个大的string，包含的是文件内容。所以我们的输入数据看上去会是这样的：
我们会写一个简单的串行的mapper(fileName, fileContent)函数。这个函数做的事情很简单，读入一个文本文件，把每一个遇到的单词当作一个新的intermediate_key，并赋其intermediate_value为1。将mapper函数处理文件a，我们会得到如下结果：
将所有三个文件的处理结果放在一起，我们得到：
然后将中间结果按intermediate_key归类：
最后，由reducer(intermediate_key, intermediate_value_list)对中间结果进行处理。它做的事也很简单，仅仅是把某intermediate_key对应的所有intermediate_value相加。我们于是得到最终结果:
第二个例子，怎样使用Map Reduce计算PageRank。什么是PageRank？可能大家都有所了解，这是Google用来量度一个网页的重要性的值。简单而言，有越多的其它网页链接到这个网页，这个网页的PageRank越高。链接到这个网页的网页PageRank越高，这个网页的PageRank也越高。假设我们一共有n个网页0, 1, …, n-1。对第j个网页我们给它赋一个PageRank值qj。所有的qj组合起来成为一个向量q = (q0,q1, …qn-1)。这个向量满足概率分布。即qj的值都在0和1之间，并且所有的qj加起来等于1。qj越大，网页的重要性越高。那么q是怎么计算出来的呢？答案是使用迭代的方法：
我们从一个初始的PageRank向量分布P开始，乘以一个n*n的矩阵M，得到一个新的PageRank向量。把新的PageRank向量继续乘以M得到下一步的PageRank… … 如此迭代有限步后，PageRank向量的值会趋于收敛，于是我们得到最终的PageRank。
这里需要回答两个问题：1. 如何确定初始的PageRank，即迭代的起点？答案是任意选择一个概率分布就可以，无论你选择什么初始值，都不影响其收敛到最终的结果。我们通常使用均匀概率分布，即。2. 如何定义M？这个问题稍显复杂，有兴趣的读者可以参见Michael Nielsen 的博文了解更详细的内容。在这里，我们将其简化的定义为一个描述网页间互相链接结构的超大矩阵。假设网络里有n个网页，那么我们这个矩阵就是一个n*n的方阵。矩阵的每一列代表一个网页对外的超链接情况。例如，我们定义#(j)为第j个网页对外的所有超链接的数量。那么对于矩阵M的第j列而言，如果网页j对网页k没有超链接，那么第k行元素Mkj=0，否则Mkj=1/#(j)。这里隐含的意思是当一个读者在浏览网页j时，有1/#(j)的可能性跳转到网页k。
那么如何使用Map Reduce来计算PageRank呢？虽然整个迭代的过程必须是串行的，迭代的每一步我们还是可以用Map Reduce来并行的计算的。这里也必须并行的计算因为这个矩阵和向量的规模是超大的（想象一下整个互联网的网页数量）。使用Map Reduce来计算迭代的一步实际上是用Map Reduce来计算矩阵和向量的乘法。假设我们要计算如下一个方阵和向量的乘法。其实质是将第i个向量元素的值pi乘以矩阵第i列的每一元素，然后放在矩阵元素原来的位置。最后，把矩阵第i行的所有元素相加，得到结果向量的第i个元素的值。
类似的，我们可以得到用MapReduce计算PageRank的方法：
第一步，输入的(input_key, input_value)。input_key是某个网页的编号，如j。input_value是一个列表，元素值是M矩阵的第j列元素，最后再加上一个pj，就是当前网页j的PageRank值。
第二步，Map。Mapper(input_key, input_value)所做的事情很简单，就是把pj乘以列表元素的每一个值，然后输出一组(intermediate_key, intermediate_value)。intermediate_key就是矩阵的行号，k。intermediate_value就是pj列表元素的值，即pj乘以矩阵第k行第j列的元素的值。
第三步，汇总。把所有intermediate_key相同的中间结果放到一起。即是把第k行所有的intermediate_value放在一个列表intermediate_value_list内。
第四步，Reduce。Reducer(intermediate_key, intermediate_value_list)做的事也很简单，就是把intermediate_value_list内所有的值相加。最后形成的(output_key, output_value)就是结果向量第k行的元素值。
以上就是利用Map Reduce计算PageRank的简略过程。这个过程相当粗略和不精确，只是为了揭示Map Reduce的工作过程和Google曾经用来计算PageRank的大致方法。认真的读者应该查阅其它更严谨的著作。
最后，和上述计算矩阵和向量乘法的例子相似，Map Reduce也可以用来计算两个向量的点乘。具体怎么做留给读者自己去思考，一个提示是我们所有的intermediate_key都是相同的，可以取同一个值例如1。
2.3 Data Parallelism
这是一个“算法模式”。事实上，把Data Parallelism和下节将要提到的Task Parallelism都称之为一种“算法模式”我觉得有过于笼统之嫌。到最后，哪一种并行算法不是被分解为并行执行的task呢（task parallelism）？ 而并行执行的task不都是处理着各自的那份数据吗（data parallelism）？所以如果硬要把Data Parallelism和Task Parallelism称为两种算法模式，我只能说它们的地位要高于其它的算法模式。它们是其它算法模式的基础。只不过对于有些问题而言，比较明显的我们可以把它看成是Data Parallelism的或是Task Parallelism的。也许Data Parallelism模式和Task Parallelism模式特指的就是这类比较明显的问题。
那么什么是Data Parallelism? 顾名思义，就是这类问题可以表达为同样的一组操作被施加在不同的相互独立的数据上。
一个比较典型的例子就是计算机图形学里面的Ray tracing算法。Ray tracing算法可以大致描述为从一个虚拟相机的光心射出一条射线，透过屏幕的某个像素点，投射在要渲染的几何模型上。找到射线和物体的交点后，再根据该点的材料属性、光照条件等，算出该像素点的颜色值，赋给屏幕上的像素点。由于物体的几何模型很多个小的三角面片表示，算法的第一步就是要求出射线与哪个三角面片有交点。射线与各个单独的三角面片求交显然是相互独立的，所以这可以看做是Data Parallelism的例子。
2.4 Task Parallelism
Task Parallelism的算法模式可以表述为，一组互相独立的Task各自处理自己的数据。和Data Parallelism不同，这里关注的重点不是数据的划分，而是Task的划分。
如前所述，Task Parallelism和Data Parallelism是密不可分的。互相独立的Task肯定也是运行在互相独立的数据上。这主要是看我们以什么样的视角去看问题。例如，上一节RayTracing的例子中，我们也可以把射线和一个独立的三角面片求交看作是一个独立的Task。这样就也可以当它做是Task Parallelism的例子。然而，咬文嚼字的去区分到底是Task Parallelism还是Data Parallelism不是我们的目的，我们关注的应该是问题本身。对于某一个具体问题，从Data Parallelism出发考虑方便还是从Task Parallelism出发考虑方便，完全取决于问题本身的应用场景以及设计人员自身的经验、背景。事实上，很多时候，不管你是从Task Parallelism出发还是从Data Parallelism出发，经过不断的优化，最终的解决方案可能是趋同的。
下面一个矩阵乘法的例子很好的说明了这个问题。我们都知道矩阵乘法的定义：假如有n行k列的矩阵A乘以k行m列的矩阵B，那么我们可以得到一个n行m列的的矩阵C。矩阵C的第n行第m列的元素的值等于矩阵A的第n行和矩阵B的第m列的点乘。
从Task Parallelism的角度出发，我们可能把计算C的每一个元素当做一个独立的Task。接下来，为了提高CPU的缓存利用率，我们可能把邻近几个单元格的计算合并成一个大一点的Task。从Data Parallelism的角度出发，我们可能一开始把C按行分成不同的块。为了探索到底怎样的划分更加有效率，我们可能调整划分的方式和大小，最后，可能发现，最有效率的做法是把A，B，C都分成几个不同的小块，进行分块矩阵的乘法。可以看到，这个结果实际上和从Task Parallelism出发考虑的方案是殊途同归的。
2.5 Recursive Splitting
Recursive Splitting指的是这样一种算法模式：为了解决一个大问题，把它分解为可以独立求解的小问题。分解出来的小问题，可能又可以进一步分解为更小的问题。把问题分解到足够小的规模后，就可以直接求解了。最后，把各个小问题的解合并为原始的大问题的解。这实际上是我们传统的串行算法领域里面也有的“divide and conquer”的思想。
举两个例子。第一个是传统的归并排序。例如，要排序下面的8个元素的数组，我们不管三七二十一先把它一分为二。排序4个元素的数组还是显得太复杂了，于是又一分为二。现在，排序2个元素的数组很简单，按照大小交换顺序就行。最后，把排好序的数组按序依次组合起来，就得到我们最终的输出结果。
第二个例子稍微有趣一点，是一个如何用程序解“数独”游戏的例子。“数独”就是在一个9*9的大九宫格内有9个3*3的小九宫格。里面有些格子已经填入了数字，玩家必须在剩下的空格里也填入1到9的数字，使每个数字在每行、每列以及每个小九宫格内只出现一次。
这里作为举例说明，我们考虑一个简单一点的情况：在一个4*4的格子里填入1~4的数字，使其在每行、每列以及每个2*2的格子里只出现一次。
解“数独”游戏的算法可以有很多种。如果是人来解，大概会按照上图的次序依次填入1,2,3到相应的格子当中。每填入一个新数字，都会重新按规则评估周围的空格，看能否按现有情况再填入一些数字。这个方法当然没错，不过看上去不太容易并行化。下面介绍一个按照“recursive splitting”的方法可以很容易做到并行化的解法。
1） 首先，将二维的数独格子展开成一个一维的数组。已经有数字的地方是原来的数字，空格子的地方填上。
2） 接下来，从前到后对数组进行扫描。第一格是，已经有数字了，跳过。移动搜索指针到下一格。
3） 第二格是，意味着我们需要填入一个新的数字。这个新的数字有4种可能性：1， 2， 3， 4。所以创建4个新的搜索分支：
4） 接下来根据现有的数字信息检查各个搜索分支。明显，第三和第四个搜索分支是非法的。因为我们在同一行中已经有了数字和。所以忽略这两个分支。第一和第二条分支用现有的数字检查不出冲突，所以继续从这两个分支各派生出4条新的分支进行搜索… …
这个思路像极了我们之前的归并排序的例子，都是在算法运行的过程中不断产生出新的任务。所以实际上这也是一个“Task Parallelism”的例子。
2.6 Pipeline
“Pipeline”也是一种比较常见的算法模式。通常，我们都会用汽车装配中的流水线、CPU中指令执行的流水线来类比的说明这一模式。它说的是我们会对一批数据进行有序、分阶段的处理，前一阶段处理的输出作为下一阶段处理的输入。每一个阶段永远只重复自己这一阶段的任务，不停的接受新的数据进行处理。用一个软件上的例子打比方，我们要打开一批文本文件，将里面每一个单词的字母全部改成大写，然后写到一批新的文件里面去，就可以创建一条有3个stage的流水线：读文件，改大写，写文件。
“Pipeline”模式的概念看上去很容易理解，可是也不是每一个人都能一下子理解的那么透彻的。例如有这样一个问题：我们有一个for循环，循环体是一条有3个stage的pipeline，每个stage的运行时间分别是10， 40， 和10个CPU的时钟间隔。请问这个for循环执行N次大概需要多长时间（N是一个很大的数）？
请仔细思考并选择一个答案。:-)
答案是40*N。流水线总的执行时间是由它最慢的一个stage决定的。原因请见下图。
2.7 Geometric decomposition
接下来这两个算法模式看上去都显得比较特殊化，只针对某些特定的应用类型。“Geometric decomposition”说的是对于一些线性的数据结构（例如数组），我们可以把数据切分成几个连续的子集。因为这种切分模式看上去和把一块几何区域切分成连续的几块很类似，我们就把它叫做”Geometric decomposition”。
最常用的例子是分块矩阵的乘法。例如，为了计算两个矩阵A，B的乘法。我们可以把他们切分成各自可以相乘的小块。
结果矩阵当然也是分块的：
结果矩阵每一分块的计算按照如下公式进行：
最终的结果就是：
下面这幅图显示了两个4*4的分块矩阵A，B进行乘法时，计算结果矩阵C的某一分块时，需要依次访问的A，B矩阵的分块。黑色矩阵分块代表要计算的C的分块，行方向上的灰色矩阵代表要访问的矩阵A的分块，列方向上的灰色分块代表要访问的矩阵B的分块。
2.8 Non-work-efficient Parallelism
这个模式的名字取得很怪异，也有其他人把它叫做“Recursive Data”。不过相比而言，还是这个名字更为贴切。它指的是这一类模式：有些问题的处理使用传统的方法，必须依赖于对数据进行有序的访问，例如深度优先搜索，这样就很难并行化。但是假如我们愿意花费一些额外的计算量，我们就能够采用并行的方法来解决这个问题。
常用的一个例子是如下的“寻找根节点”的问题。假设我们有一个森林，里面每一个节点都只记录了自己的前向节点，根节点的前向节点就是它自己。我们要给每一个节点找到它的根节点。用传统的方法，我们只能从当前节点出发，依次查找它的前向节点，直到前向节点是它自身。这种算法对每一个节点的时间复杂度是O(N)。总的时间复杂度是N*O(N)。
如果我们能换一种思路来解这个问题就可以将其并行化了。我们可以给每一个节点定义一个successor（后继结点），successor的初始值都是其前向节点。然后我们可以同步的更新每一个节点的successor，令其等于“successor的successor”，直到successor的值不再变化为止。这样对于上图的例子，最快两次更新，我们就可以找到每个节点的根节点了。这种方法能同时找到所有节点的根节点，总的时间复杂度是N*log (N)。
如前所述，“并行编程中的设计模式”是一个仍在不断变化、发展的领域。这篇博文简要介绍了这一领域当前的发展现状，并选取八个常用的模式进行了介绍。我涉足并行编程领域不久，很多理解也并不深入。所以文章的缺点错误在所难免，真诚希望能得到大家的批评指正。
4. 参考文献
本文的写作参考了如下资源，可以作为进一步阅读的材料：
· UC Berkeley,
· Eun-Gyu Kim,
· Jim Browne,
· Tim Mattson,
· Michael Nielsen,
· Aater Suleman,
阅读(...) 评论()分会场主题
日-15日北京富力万丽酒店
高可用架构
得益于移动互联网、云计算和大数据等技术的发展，产品的上线周期大大缩短。用户的爆发式增长使应用开发者面临着严峻的技术挑战。如何在系统构建之初就采用高可用架构来有效避免服务不可用、容量不足、用户体验下降这些问题呢？通过本专场的学习，高可用将不再高不可攀。
出品人：赖春波
滴滴出行平台技术部
高级技术总监
2008年加入百度，担任百度基础架构部主任架构师，存储方向技术负责人。长期专注于大规模分布式存储和计算系统的研发，领导了百度新存储体系的建设，支撑了百度网页存储、在离线文件存储和百度云存储等业务。2015年底加入滴滴，领导了专快车系统的平台化、服务化技术改造工作，目前担任平台技术部高级技术总监、工程技术委员会副主席，负责核心出行平台的研发工作。
4月14日（星期五） 下午 13：30-17：10
13:30-14:15
新时代下的微博LAMP架构侯青龙 新浪微博主站研发负责人
新浪微博在2016年Q3季度公布月活跃用户（MAU）较上年同期增长34%，至2.97亿；日活跃用户（DAU）较上年同期增长32%，至1.32亿，总注册用户达8亿多。PC主站作为重要的流量入口，承载几乎所以PC端产品的落地,面对业务的高速增长，与之对应的技术架构也面临着新的挑战。在新的时代下，微博都面临着哪些挑战？对于这些挑战，又都是怎么应对的呢？本次分享，将会为你一一道来。
14:25-15:10
网易数据传输服务NDC高可用实践马进 网易资深工程师
NDC,直译为网易数据运河,为网易互联网各大产品线提供平台化的结构化数据迁移,同步和订阅服务.数据迁移和同步方面,NDC支持常用结构化数据库之间，以及OLTP到OLAP的全量迁移和实时同步。数据订阅方面，NDC将线上数据库的增量更新实时传输到下游应用,可解决复杂业务异步解耦,多机房缓存淘汰等疑难问题.这次分享会为大家简单介绍NDC在结构化数据传输上的一些典型解决方案和基本架构原理，重点聚焦NDC在服务平台化和可插拔的背景下，高可用方面的想法和实践。
15:10-15:30
15:30-16:15
海量播放请求下的精准视频播放调度系统邓铮
一下科技高级研发总监
为每日需要处理二十亿以上播放请求的大型视频网站，如何精准高效的将用户的每次请求迅速的真正实现播放，是充满挑战的一件事。秒拍在这方面积累了丰富的经验，我们采用细化用户每次播放请求的上下文，并结合近期内综合调度大数据，动态的实现了在c段IP级别的调度响应及区分，在具体的实践中也取得了比较好的效果。
16:25-17:10
大流量网站的高可用架构演进实践许令波（君山）
滴滴出行技术研究员
之前在阿里的7年时间里，基本经历了网站的从1亿到50亿的增长过程，经历了从端和管道的优化、应用层代码级优化、应用架构的优化、端到端等全链路优化过程，架构上从单个应用到分布式、无线多端、中台以及国际化的演进。而滴滴也正在经历这个类似的发展过程，例如滴滴的业务系统也正在经历服务化、平台化的改造，基础平台也在进行容器化、弹性调度等升级。对历史经验的思考和总结并如何应用到滴滴的实践中是本主题要表达的。
容器技术实践
近两年，以Docker为代表的容器技术持续火热，受到众多开发者社区的亲睐。越来越多的国内公司都已经开始在生产环境中使用容器技术，但是从来就不存在十全十美的技术。本专场，众多经多见广的专家将分享他们在技术选型和问题处理上的经验和解决方案，让大家在容器实践之路避免踩坑。
出品人：李庆丰
新浪微博研发中心
微博研发中心研发总监，当前负责微博开放平台及通讯平台的技术研发工作，曾主导微博平台服务稳定性保障及SLA体系建设项目，推进微博平台化战略改造项目、微博多机房部署、微博容器化及混合云等项目。10年互联网架构研发及技术管理经验，专注高性能高可用架构及服务稳定性保障方向。
4月14日（星期五） 下午 13：30-17：10
13:30-14:15
基于容器技术实现 DevOps Orchestration马全一 华为开源技术专家
业界有很多DevOps工具、服务以及各种各样的插件，但没有任何一个能够解决DevOps的全部问题。当今DevOps领域纷纷推出Pipeline，希望借此提高复杂项目的DevOps效率。华为发布开源的ContainerOps项目，是基于容器技术实现的DevOps g平台，它借用容器技术和各种Pipeline优势的全新项目。议题介绍使用容器技术开发DevOps Orchestration的过程和经验，通过DevOps Orchestration如何为大型、复杂的容器集群构建高效、灵活的DevOps工作流。
14:25-15:10
京东新一代容器集群平台鲍永成 京东商城研发体系-基础平台部 技术总监
京东商城在过去2年内，京东第一代容器集群平台完成京东业务100%全面容器化；在接下来的容器技术2.0时代，希望新的平台可以进一步发挥容器技术优势，有效支撑业务研发效率，并极大降低数据中心TCO；本次分享重点京东容器集群2.0如何有效支持京东业务系统cloud native架构运行。
15:10-15:30
15:30-16:15
网易容器云实践与云计算的那些坑刘超
网易云首席解决方案架构师
很多人以为虚拟化了就算是云平台，把应用移到虚拟机和云主机甚至容器上就算完成了上云。所有影响灵活和弹性能力的设计都会阻碍云计算潜力的发挥。本次分享人们理解和使用云计算的误区以及一个云原生应用设计的正确姿势。
16:25-17:10
新浪微博混合云DCP平台介绍与业务上云实践付稳
新浪微博技术专家
微博在2015年春晚通过Docker实现私有云平台弹性调度能力，随着公有云技术的成熟，我们发现原有私有云比较困难的问题在公有云上比较容易解决，例如突发峰值情况下弹性资源的成本，小业务快速试错等场景。在2016年，微博完成利用Docker构建混合云架构，本次演讲将介绍安全、网络、资源管理、调度管理、跨云服务发现等方面的一些实践经验。
DevOps与持续交付
DevOps的本质是使开发团队和IT运营部门紧密地整合在一起，提高软件和系统的性能、自动化和可扩展性。工具虽然能帮助我们有效的运用DevOps持续交付，但它并不是DevOps的全部。那么，我们究竟该如何正确的推动DevOps?将DevOps应用于企业软件开发中具有哪些优势和挑战？
出品人：刘天斯
腾讯互动娱乐部
高级工程师
从事互联网运维工作已13年，目前就职于腾讯-互动娱乐部，负责游戏大数据的运营，曾就职于天涯社区，担任首席架构师/系统管理员。热衷开源技术的研究，包括系统架构、运维开发、负载均衡、缓存技术、数据库、NOSQL、分布式存储、消息中间件、大数据及云计算、Mesos、Docker、DevOps等领域。擅长大规模集群的运维工作，尤其在自动化运维方面有着非常丰富的经验。同时热衷于互联网前沿技术的研究，活跃在国内社区、业界技术大会，充当一名开源技术的传播与分享者。个人著作有《python自动化运维：技术与实践》、《循序渐进学Docker》，个人发明专利4个。
4月14日（星期五） 下午 13：30-17：10
13:30-14:15
运维平台从0到1张建
百度外卖研发中心运维部资深运维研发工程师及技术负责人
运维平台从0到1 Spinoff创业初期,人力紧张,业务繁杂,如何在这种情况下组建团队,快速实现运维平台满足业务快速迭代的需求,还要夯实基础保证平台及团队可持续的发展。外卖运维研发团队(SRE)在近1年的时间内6个人完成了 11个业务平台,6个通用服务,11+ golang lib库,30+服务对接等。通过分享可以为大家提供些经验参考。
14:25-15:10
DevOps Transformation Design钟健鑫
ThoughtWorks高级咨询师、DevOps Community成都负责人
当下，DevOps由于各种交付流程、技术和工具的兴起，已经在大多数公司和技术人员的眼中初露锋芒，大家都希望从IT的角度，通过DevOps能帮助企业获得商业上的成功。但是对于很多大型企业来说，面临激烈的市场压力和内部流程不高效的现状，还在犹豫是否变化或怎么变化时，尝试先问问自己：是否清晰的认识到DevOps对于企业的价值所在？如何识别出当前组织结构和交付流程之下的痛点和瓶颈？又怎样根据企业和团队的实际情况去设计DevOps转型的策略以及与其对应的落地实践？希望通过此次分享，能够带给大家一些有意义的参考套路。
15:10-15:30
15:30-16:15
腾讯蓝鲸DevOps类应用的设计与实践赵志辉
腾讯高级工程师
蓝鲸是腾讯游戏应用运维（ARE）技术生态体系的代号，越来越多的蓝鲸用户开始关注蓝鲸社区上即插即用的SaaS应用，尤其是DevOps类。这次我们给大家带来的是蓝鲸体系中关于持续集成、持续交付类应用建设思路,DevOops类应用的落地实践等。
16:25-17:10
在向技术管理者转型的路上，很多技术人都有着相同的困惑，如何在保持技术实力的同时提升管理能力？在CTO训练营专场，业内一票对技术管理有深刻理解的技术高管担任CTO导师，结合亲身经历，现身说法，帮助中层的技术管理者对未来有清晰定位和认识，追求更高层次的职业发展。
出品人：祁宏宇
CTO训练营负责人
目前就职于51CTO，负责CTO训练营整体项目策划及导师内容把控，伴随CTO训练营项目成立，主导CTO训练营的变化与成长。曾任职新浪微博 负责客户产品运营工作，推进微博帮助平台上线及优化项目，8年互联网产品运营经验，专注活动策划及内容运营方向。
4月14日（星期五） 下午 13：30-17：10
13:30-14:00
14:00-15:30
CTO的管理之道汤力嘉
一下科技CTO
企业不同发展阶段过程中， CTO的工作重心与职责有哪些变化与挑战？如何培养一支优秀的技术团队以应对快速发展的业务情况？看一路走来的CTO为你分享团队管理中的故事与心得。
15:30-15:40
15:40-17:10
如何打造一支高战斗力的技术团队陈超
豌豆公主技术合伙人
技术成员闷，不善于表达？技术不关注产品细节？技术团队命运总是掌握在产品手里？技术的出路在哪里？什么样的技术团队适合创业公司？豌豆公主陈超，与您分享真实的成长经历！
大数据应用创新
在Hadoop、Spark、Storm等开源技术的影响下，大数据的技术壁垒开始中降低。2016年，场景、技术、服务成为2016年驱动大数据创新和应用的三个关键点。本专场将通过对大数据应用创新经典案例的解读，剖析大数据的提取、分析如何实现全方位、多角度的数据融合与协同，找到大数据价值变现的关键！
出品人：李鹏涛
青龙研发部高级总监
拥有清华大学工商管理硕士和软件工程硕士学位，在大型分布式系统，电子商务和物流领域具有丰富的实践经验。2012年加入京东，担任高级总监，领导京东核心业务系统－－ 物流配送（青龙）系统的研发。在青龙系统设计，研发，推广，升级过程中做出重大贡献，荣获公司最佳舵手等多项奖励，并且，勇于创新，带领团队提出200余项技术专利，本人已经获得5项专利。积极参加技术交流，乐于进行分享，并获得“2016年中国物流信息平台十大风云人物”。个人具有广泛的兴趣爱好，特别喜欢旅游，历史和音乐。
4月15日（星期六） 下午 13：30-17：10
13:30-14:15
数据驱动的决策辅助与产品智能化王建强
Stitch Fix数据科学总监；前Twitter美国总部技术主管
本次演讲我将介绍数据科学在互联网行业的应用实例，主要体现在辅助决策跟构建智能化的产品。在辅助决策方面，我会介绍分析方法比如漏斗分析、群组分析、用户留存及LTV，实验方法A/B测试等。在构建智能化产品方面，会介绍社交媒体中的互联网广告、反欺诈，以及零售业电商中面对的精准营销、需求与库存预测、产品推荐等方面。我还会介绍一些硅谷的新锐大数据驱动公司 跟这些公司的数据科学挑战。
14:25-15:10
O2O广告的探索之路王兴星
美团高级技术专家，外卖商业技术负责人
美团外卖作为最大外卖平台，日均订单量已经接近1000万单，是重要的O2O应用之一。美团外卖链接了百万商家与亿级别的用户，广告是满足商家营销及平台变现诉求的一种有效手段。外卖行业信息化程度低、推广经验少，如何针对业务设计一套合理的变现系统，多种方案间何如选择，是其中较为考究的点，本分享将讲述美团外卖商业变现的成长历程。
15:10-15:30
15:30-16:15
多维分析平台实践王富平
苏宁大数据中心高级架构师
大数据可以做什么？我首先想到的是智能分析，帮助我们理解并预测用户行为。这很振奋人心，大数据帮助我们理解用户，而我们忽略了大数据也更多的帮助我们理解自身：成千上万台服务器监控与日志分析、根据用户行为日志评估推荐算法效果、网站流量分析、公司财务订单报表分析等。这一切都指向了我们该如何观察数据，数据的维度很多，数据量也很大，”可视化“效果也要炫，写一个spark分析任务就ok了吗？ 假设数据有10个维度每个维度有10种取值，如何做到任意组合任意视角的分析？而这正是多维分析平台要解决的问题，这两年涌现了不少的优秀开源产品：kylin、druid，linkedin今年也开源了自家解决方案pinot，多维分析平台的热度可见一斑，期待大家一起深入探讨，擦出火花。
16:25-17:10
客服SAAS实时分析架构演进-从NoSQL到时序数据库李灼灵（千慕）
阿里巴巴资深研发工程师
淘宝、天猫每天会有上亿个不同买卖家进行对话，产生百亿条聊天记录，客服聊天记录实时分析是智能客服的基础。本次将会分享聊天记录与监控数据、物联网数据实时分析的区别以及技术难点，分享为何要从NoSQL迁移到时序数据库，分享使用时序数据库的一些心得。
微服务架构实践
随着云计算技术的成熟和服务的增长，微服务架构越来越多的受到人们的关注。尽管也存在着许多不同的争论，微服务架构模式却正在为敏捷部署以及复杂企业应用实施提供着巨大的帮助。本专场将与大家分享那些从企业实践中总结出来的微服务架构模式。
出品人：沈剑
高级技术总监
现任58到家技术委员会主席，高级技术总监，负责企业，支付，营销、客户关系等多个后端业务部门。本质，技术人一枚。互联网架构技术专家，“架构师之路”公众号作者。曾任百度高级工程师，58同城高级架构师，58同城技术委员会主席，58同城C2C技术部负责人。
4月15日（星期六） 上午 9：30-12：05
9:30-10:15
微服务在大型互联网公司的应用及其挑战罗轶民
LinkedIn资深软件工程技术经理
1. 微服务的产生的历史以及应用场景2. 微服务和单片服务（monolithic service）之间的区别3. 软件构架从单片服务向微服务转型过程中带来的技术挑战4. 软件构架从单片服务向微服务转型过程中带来的企业组织构架的变化和挑战5. 如何合理地选择单片服务构架和为服务构架
10:25-11:10
微博服务化的实践与演进张雷 新浪微博技术专家；MotanRPC框架技术负责人
服务化不是什么新鲜话题，很多公司都实现了不同程度的服务化架构，伴随着Docker容器化的大规模应用，服务化实施效率不断提高，成本也进一步降低，服务化依然是整体架构中需要重点考虑的问题之一。RPC框架作为服务化中重要的服务组件，在不同场景中面对的问题与需要解决的问题也不尽相同，在容器化的云时代，对RPC框架也提出了更高的要求。让我们一起来看看微博基于Motan RPC框架的服务化发展过程、遇到的问题、及解决方案。
11:20-12:05
微服务架构解耦利器与最佳实践沈剑
58到家高级技术总监；58到家技术委员会主席
微服务架构这个术语在过去几年渐成热门,但这不是一个全新架构,更不是一个包治百病的架构。那么，微服务架构究竟解决什么问题？微服务架构会带来哪些问题？在本次演讲中我将与大家探讨微服务架构解耦利器-总线最佳实践及微服务架构解耦利器-配置中心最佳实践，希望对听众有所帮助。
大数据系统架构
大数据问题的分析和解决非常复杂。处理并存储大数据时，会涉及到更多维度，比如治理、安全性和策略。选择一种架构并构建合适的大数据解决方案极具挑战，因为需要考虑非常多的因素。本专场将介绍实际应用场景下的大数据解决方案逻辑架构和层次。
出品人：吕毅
链家网架构师
大数据平台团队负责人
链家网大数据平台架构团队负责人，链家网架构师。2015年8月加入链家网，之前负责过链家网基础服务平台建设。 曾供职于百度移动云事业部（），新浪平台架构部SAE（）。
4月15日（星期六） 上午 9：30-12：05
9:30-10:15
HBase in Alibaba Search李钰(绝顶)
阿里巴巴搜索事业部高级技术专家
HBase作为淘宝全网索引构建以及在线机器学习平台的核心存储系统，是阿里巴巴搜索基础架构的重要组成部分，并且在2016年双11期间经受了集群每秒钟超过3000万次，单机峰值超过10万次读写吞吐压力的考验。在该议题中我们将介绍阿里搜索数据平台的基础架构，以及HBase为应对搜索推荐系统的吞吐压力在架构上进行的改进。
10:25-11:10
Airbnb的Streaming ETL丁辰（海外） Airbnb软件工程师
介绍Airbnb streaming ETL基础设施的设计与架构，其中包括将数据从MySQL，DynamoDB增量实时导入到Airbnb数据仓库的系统SpinalTap，以及利用Spark将衍生出的数据实时导入HBase以供在线查询和生成近实时的数据库快照。
11:20-12:05
今日头条大数据平台的演进王烨
今日头条数据平台架构师
随着今日头条业务的飞速发展，推荐系统和用户产品都产生了越来越庞大的数据，数据平台也面临着业务多样性、分析灵活性等的持续挑战。本次分享会介绍头条大数据平台架构和在平台演进过程中我们的决策思路。
云服务架构
云带来的革命性改变显而易见。万物皆云、一切皆服务的时代正席卷而来，企业的业务和产品不断演进，系统架构也随之发生天翻地覆的变化。本专场的分享嘉宾将结合实际业务场景，介绍在云服务架构演进过程中的主要思路、遇到的难题、用到的开源技术和未来的规划。
出品人：张立刚
1号店技术部
电商云平台技术总监
2012年7月加入1号店，先后担任过1号店订单、库存、拆单、运费、第三方平台订单等电商核心交易系统负责人。期间主导并参与了1号店SOA治理、订单Service化、订单水平拆库&去Oracle迁Mysql、下单接口性能优化、无线性能优化及拆pool、运费体系重构、库存准确率优化等重要项目，负责1号店与Tmall、百度、当当、B2B2C平台等第三方平台订单业务，从0开始建立了1号店完善的订单监控、预警、履单体系。对高可用高并发高性能的电商核心交易系统及SOA架构有深入的理解和实践，熟悉电商核心产品、订单、库存等业务，致力于电商平台产品化、智能化、云化，将以OMS为核心规划构建新一代电子商务云平台。
4月15日（星期六） 上午 9：30-12：05
9:30-10:15
阿里企业级互联网架构实践王晶昱（沈询）
阿里巴巴资深技术专家；DRDS负责人
在之前，阿里中间件事业部主要是一个服务于阿里内各个BU，提供企业级高可用互联网应用架构支撑的平台型支撑部门。而最近这两年，我们开始逐渐的将我们的已经比较稳定和可靠的分布式系统架构以服务的形式对外提供。也因为这个契机，我接触了大量的客户和软件服务提供商。在接触的过程中，有一件事让我记忆特别深刻，这就是原来在很多传统企业内……
10:25-11:10
虚拟网络架构设计实践陈峰
京东专家架构师
现在，现有应用中的网络架构种类繁多,造成网络结构复杂难以维护。本次演讲，我将分享虚拟网络的设计目标和挑战，虚拟网络的数据面设计要点，虚拟网络的控制面设计要点以及虚拟网络的架构演进方向，希望对大家有所帮助。
11:20-12:05
YY游戏私有云建设历程刘亚丹
虎牙直播基础运维负责人
基于OpenStack私有云是很多企业的首选，而 OpenStack 由于各种问题，逐渐被抛弃。YY 游戏云团队在2013年基于 OpenStack 上线了云平台1.0版本，在实际的运营过程遇到非常多的OpenStack 的质量问题，踩过很多的坑，随着规模增长，维护难度非常大，稳定性越来越低。基于质量和业务需求，YY 游戏云团队自主开发了第二代云平台，从零开始打造一套适合自己的企业私有云系统。本演讲内容包括 在OpenStack 上踩过的坑，以及基于这些经验教训，如何自主实现基于硬件的 VPC ，从而打造适合自身的企业私有云平台。
高性能直播系统架构
过去一年，网络直播文化迅速崛起。在全民参与直播的今天，如何保证直播平台在大流量、高并发情况下持续稳定运行,确保系统不会因网络、主机、应用、数据库的性能瓶颈以及代码问题,对用户体验造成影响？
出品人：于雪
WOT大会主编
4月14日（星期五） 下午 13：30-17：10
13:30-14:15
Hulu视频直播系统架构：挑战与关键技术李彬
Hulu北京研发中心首席软件开发主管
14:25-15:10
金山云直播点播基础服务演进郝明非
金山云视频技术总监
经过2016年直播元年的打磨，直播、点播服务同质化越来越严重，通过技术手段保证播放质量、降低运维难度就十分重要了。本次分享将介绍金山云视频平台的架构演进和技术探索，包括高可用直播CDN架构，技术推动质量提升、成本节省的直播、点播解决方案，客户端开放架构以及数据统计对客户端自动适配的作用等。
15:10-15:30
15:30-16:15
直播互动系统的设计与实践李淼
融云首席架构师，联合创始人
如果说评选16年最热门火爆的互联网产品，那么非直播平台莫属。由于直播平台的特点，对系统功能设计的可靠性要求更高，同时如何在“直播元年”快速实现直播平台构建成为各大企业的需求，而融云凭借多年在即时通讯云行业的积淀，在此次风口上脱颖而出。本次演讲主要分享融云直播互动系统的设计与实践，详细介绍礼物、红包等消息为基础的互动方案设计思路和实践方案，并阐述如何结合融云自身技术优势，快速助力直播企业布局市场。
移动端架构演进
移动互联时代，APP已然成为互联网企业用来获取用户的核心渠道。伴随着业务量的增长，愈来愈多的APP也在不断地挑战着每一个移动端研发人员的知识深度。如何在庞大的用户群体、高频高并发的业务、交易即时性等重重压力下不断推动移动端的架构演进？本专场将为你指点迷津。
出品人：王朝成
首席移动架构师
饿了么首席移动架构师，浙江大学计算机硕士，多年移动开发和架构设计经验；目前整体负责饿了么移动中间件、移动基础设施功能规划、设计、研发等工作，包括APM、移动安全、热更新等方向。
4月15日（星期六） 上午 9：30-12：05
9:30-10:15
On-Device AI架构及案例分析梁宇凌
Google美国总部高级Android 架构师
当今火热的AI技术，大多需要服务器端强大的运算能力才能被有效运行起来。然而今天，移动端都在收集大量的用户数据，如何有效地在计算能力薄弱的设备上让AI落地，是一个很有挑战的课题。这次演讲，我尝试结合具体案例做一些相关方面的介绍，包含以下内容：1. AI 常用架构简介以及On-Device AI架构对比2. 案例1: Smart Reply on Android Wear 2.03. 案例2: Google Translate4. 案例3: Image Recognition on mobile with Tensorflow
10:25-11:10
第十年的选择唐平麟
咕咚技术总监；SwiftyJSon作者
今年是移动互联网的第十年，单页App扩展到了超级App，甚至有的App开始了向简单的操作系统的演进。我们的App从什么发展而来，未来要到哪里去？如何在快速迭代的同时，继续演进技术和架构来满足业务方需求，保证安全性和提升用户体验？
11:20-12:05
移动动态化方案在蜂鸟的架构演进许锦洋
饿了么资深Android开发工程师
当下移动动态化已经成为各大公司回避不了的问题，快速的产品迭代对技术提出更高的要求，而移动端的动态化方案也是层出不穷：Hybrid、结构化Native View、React Native、Weex，什么样的方案才是适合自己团队的尼？本次分享我们就来聊一聊饿了么蜂鸟团队在过去2年的业务快速增长过程中在移动动态化方面的实践和探索。
电商大促背后的技术挑战
“双十一、双十二、黑色星期五、618…”各大电商在不知不觉中为消费者打造了一个又一个“狂欢节”。这场没有硝烟的战场比拼的不仅仅是各大电商狂飙的数字，更是在其背后物流配送、后台技术、支付能力的“暗战”。本专场将对“电商节”背后的技术进行大起底。
出品人：邓钦华
花名问天，蘑菇街广告、搜索、流量、图像、机器学习负责人。一直从事搜索推荐、机器学习和大数据系统的研发实践，参与开发过百度统计、百度关键词推荐、百度搜索广告系统、360搜索广告系统、360展示广告系统、360推荐系统、迅雷大数据平台、迅雷数据统计分析平台等产品，从零搭建了蘑菇街广告体系、流量体系和搜索体系，并将图像技术用于搜索的排序。
4月15日（星期六） 下午 13：30-17：10
13:30-14:15
网游直充如何应对大促及突发的流量高峰陈康贤(龙隆)
淘宝技术部技术专家
对于网游直充这个行业来说，除了双十一双十二这样的大型促销活动之外，平时也经常会经历各种突发事件，诸如新游戏的发行，各大游戏厂商的促销活动等等，每到这时，系统的访问流量达到平时的十倍甚至更多，如何在这种情况下保障系统的稳定性和可靠性，让充值的交易流程一如既往的流畅，成为了摆在工程师面前的一道不得不解的难题，本次的分享，将为大家介绍，我们的一些解题思路。
14:25-15:10
京东全链路压测军演系统（ForceBot）分享张克房
京东商城资深架构师
每年的京东大促需要提前投入大量的人力物力去备战，如何有效的备战，精准的找到各系统性能瓶颈，提高备战效率？京东新的大促利器：全链路压测军演系统(ForceBot)指引备战方向。
15:10-15:30
15:30-16:15
蘑菇街搜索推荐架构的探索之路丁小明
蘑菇街搜索技术团队负责人
对电商网站来说，搜索推荐是重要的流量入口，系统需要承受海量的请求压力。而在大促期间，瞬时流量往往数十倍于平时，搜索推荐系统是如何应对这种突发高并发流量的，过程中踩到过哪些坑，又积累了哪些经验，以及发展路上的各种探索，会在本次分享上跟大家交流。
16:25-17:10
苏宁易购全站HTTPS实践之路：如何做到兼顾安全与性能朱羿全
苏宁云商IT总部架构师
HTTPS 能够给用户带来更安全的网络体验、更好的隐私保护。然而，HTTPS 增加了 TLS 握手环节，再加上应用数据传输需要经过对称加密，对性能提出了更大的挑战。作为一个好的架构，一定要均衡安全和性能两方面，如果让天秤向任何一方倾斜过多，都会影响最终的用户体验。因此，为了兼顾安全与性能，苏宁的全站HTTPS改造从2015年底开始进行，历时一年多时间，主要包括了三方面工作：（1）系统HTTPS改造；（2）HTTPS性能优化；（3）HTTPS灰度上线。让用户在HTTPS访问下的极致体验成为可能。
创新运维探索
云计算的出现抹杀掉了一切基础性工作，这使运维行业感受到了前所未有的冲击、威胁和变化。“智能运维、数字运维、No-Ops…”，一时间，各种创新运维模式不断涌现。这些是否只是概念？各自的场景在哪里？本专场我们一起探索在大规模、复杂架构的催生下，运维技术如何变化、发展、涨姿势。
出品人：来炜
滴滴出行基础平台部
滴滴出行基础平台部技术总监。热爱开源并积极推动国内开源技术发展，是国内首款开源企业级监控系统Open-Falcon的创始人和社区负责人。关注运维和安全体系建设、高可用架构设计等领域。
4月15日（星期六） 下午 13：30-17：10
13:30-14:15
美团点评分布式监控 CAT 系统架构演进尤勇
美团点评技术工程部技术专家
监控这领域解决问题非常多，包括从移动，网络，业务，应用等各个方面，几乎所有的运行程序都需要监控。此次分享内容从监控分层讲起，将监控领域分为用户层（移动端和浏览器端），业务层，应用层，以及系统层。本次分享会重点介绍分布式监控在美团点评的发展历程，包括分布式CAT一些选型、设计以及一些实施经验，帮助听众在故障快速发现、故障定位、应用性能分析等方面有所借鉴。
14:25-15:10
畅游运维自动化探索之旅黎志刚 搜狐畅游运维总监
畅游游戏自动化运维平台的从无到有，通过在其中踩过的坑、解过的结，来阐述游戏运维的进阶之路。1、畅游传统运维的苦恼。2、我们为什么要打造自动化运维平台。3、畅游游戏运维标准化和自动化。4、畅游未来的运维。
15:10-15:30
15:30-16:15
搜狗智能运维实践张博
搜狗运维保障部总监
搜狗运维/开发比例业界最低，但加班很少，而且女生比例业界最高，怎么做到的？互联网的运维们，有哪些痛点是容易忽略掉的？真正占用你工作时间和精力的事，靠现有的运维自动化工具就能完美解决么？让搜狗的运维总监来告诉你，搜狗的运维价值观是怎样的，哪些事才是真正的最费时间和精力的，用人工智能和深度学习的方法怎么解决这些问题，作为研究界小白的运维工程师，怎么拿起AI的武器。
16:25-17:10
基于Mesos/Docker构建Elasticsearch as a Service马文
去哪儿网平台事业部数据平台研发工程师
Mesos从0.23版本开始提供了动态预留和持久化卷功能，可以利用本地磁盘创建数据卷并挂载到Docker容器内，同时配合动态预留的功能，保证容器，数据卷，机器三者的绑定，解决了Docker一直以来数据落地的问题。本次演讲将介绍去哪儿网的ops团队利用Mesos/Docker开发Elasticsearch（ESAAS）平台的建设的过程，以及实践过程中的经验。
共享经济下的技术变革
互联网工具及使用互联网的方式方法彻底解决了供需双方的沟通问题。现在，越来越多的人使用滴滴叫车、骑摩拜单车出行、用Airbnb提供的方式代替酒店预订。共享平台正在快速增长，这些平台的架构藏着怎样的变革和玄妙之处呢？本专场让我们一起探秘。
出品人：于雪
WOT大会主编
4月15日（星期六） 下午 13：30-17：10
13:30-14:15
互联网＋玩具租赁的典型技术实战单泽兵
共享经济大潮来临，很荣幸也很忐忑成为共享经济的一分子，站在从业者的角度简单描述我所认识的共享经济，以及在我所处的行业实际落地中遇到的各种技术挑战，分享给听众，希望有所参考。整体的演讲内容分为三个部分：1.简单介绍共享经济，以及共享经济带来的经济变革，描述共享经济的几种典型模式和典型企业；2.玩多多在共享经济中的看法和业务描述3.玩多多在发展过程中遇到的各种技术挑战，以及如何应对的，包括架构选型，玩具推荐，仓储物流等方向进行探讨。
14:25-15:10
新美大外卖订单系统架构实践何轼
新美大餐饮平台外卖订单系统技术负责人
新美大外卖从零起步发展到现在日最高订单突破900万，业务发展的不同阶段，会面临不同的问题和挑战，技术架构也在持续优化、调整。本次，我将分享外卖业务不同阶段，订单系统面临的问题及我们的解决方案。
15:10-15:30
15:30-16:15
58到家消息平台架构优化实践任桃术
58到家架构部负责人
随着58到家业务的快速发展，58到家经历了从早期的httpserver上报GPS面临的性能问题，mqtt推送单点可用性问题，以及多套消息推送通道不统一的问题，到现在提供统一的、通用的、实时的、高到达率的消息平台，提供APP端到Server端实时消息上报，以及Server端到APP端实时消息推送(订单实时推送)，多账号体系间的即时聊天功能，以及离线消息推送。在消息平台不断迭代演进的过程中，踩过了哪些坑，解决了哪些技术难点，是本次分享的主要内容。
16:25-17:10
滴滴顺风车的业务架构演进之路奚媛
滴滴出行顺风车事业部 高级专家工程师
滴滴顺风车2015年6月上线后，在不到两年的时间内，产品急速迭代，订单量爆发式增长，快速占领了私家车共享出行领域。在这个过程中，顺风车的业务技术架构和研发体系也经历了数次涅槃以支持更大规模的体量、更大的业务复杂度、以及更高的研发效率和稳定性。在持续巨大的业务压力下，如何制定完整的分步分阶段解决方案，稳步向着理想架构的演进之路迈进。其中的经验分享出来，和大家一起探讨共同学习，也值得快速发展的初创型技术团队借鉴。
主动安全防御体系构建
金融、电商、教育等越来越多的行业正在利用云、移动和大数据应对挑战并加速创新性。与此同时，网络安全威胁的范围和内容不断扩大和演化，形势与挑战日益严峻复杂。如何基于云、大数据技术使系统对网络安全威胁进行可视化呈现，全方位感知网络安全态势，从而主动抵御安全威胁，进行风险评估与控制，是本专场将要讨论的重点。
出品人：于雪
WOT大会主编
4月15日（星期六） 上午 9：30-12：05
9:30-10:15
数据安全流通的技术实践史伟航
京东万象资深架构师
数据资源成为推动数据驱动型经济高速增长的基础战略资源，推动大数据在各行各业的应用，数据的流通和交易是关键的环节，但由于大数据交易缺乏相应的法律法规、尚未形成完整生态链等诸多因素都使得大数据交易和流通不那么容易。究竟如何来破解大数据交易和流通难题？我用创新型技术为你解答！
10:25-11:10
可知、可感、可查、可控——打造新一代Web安全治理体系李春鹏
盛邦安全技术顾问
随着互联网的发展，越来越多的业务依托于Web系统。而使用权与管理权的分离导致了Web系统的治理问题尤为突出，如何能够对内部所有的Web系统做到可知、可感、可查、可控。
11:20-12:05
构建面向威胁的企业网络安全防御体系徐洪涛
思科大中华区安全业务技术总监
网络性能优化实践
宽带的普及，让网速变得越来越快的同时也让网页越来越复杂，用户的耐心越来越少，网页打开时间稍长，就会造成大量的用户流失。于是， 网络性能优化成为网站的日常运营中一项非常重要的工作。对于网站优化和运维人员来说，要进行Web性能优化，你要来听听本专场专家的建议。
出品人：于雪
WOT大会主编
4月15日（星期六） 下午 13：30-17：10
13:30-14:30
WLAN容量设计和性能优化实践聂小云
Brocade SE manager
WLAN网络目前随处可见，已经成为最常见的无线宽带接入手段。最近几年，WLAN的规范和产品的速率也不断提高，但实际上，很多场景下大家的接入体验并不是很好。从WLAN的工作方式开始，结合工作中遇到的各种现象，和大家一起讨论一下如何能最大化WLAN网络的容量性能。
14:40-15:40
美团点评移动网络优化实践张宇石
美团点评高级架构师
网络优化对于App产品的用户体验至关重要，与公司的运营和营收息息相关。本次演讲，我将分享移动网络性能优化的难点和痛点，介绍美团点评在移动网络优化方面遇到的挑战和经验积累，希望对大家有所帮助。
15:50-16:50
Web应用网络性能优化浅谈程捷
博睿宏远研发副总裁
高可用架构
出品人：赖春波滴滴出行平台技术部高级技术总监
容器技术实践
出品人：李庆丰新浪微博研发中心研发总监
DevOps与持续交付
出品人：刘天斯腾讯架构平台部高级工程师
出品人：祁宏宇CTO训练营负责人
大数据应用创新
出品人：李鹏涛京东商城青龙研发部高级总监
微服务架构实践
出品人：沈剑58到家高级技术总监
大数据系统架构
出品人：吕毅链家网架构师大数据平台团队负责人
云服务架构
出品人：张立刚1号店技术部电商云平台技术总监
高性能直播系统架构
出品人：于雪51CTOWOT大会主编
移动端架构演讲
出品人：王朝成饿了么首席移动架构师
电商大促背后的技术挑战
出品人：邓钦华蘑菇街技术总监
创新运维探索
出品人：来炜滴滴出行基础平台部技术总监
共享经济下的技术变革
出品人：于雪51CTOWOT大会主编
主动安全防御体系构建
出品人：于雪51CTOWOT大会主编
网络性能优化实践
出品人：于雪51CTOWOT大会主编
联系我们Contact Us
报名咨询： 010-
报名咨询：010-
市场合作：
商务合作：
议题提交：
点击这里可设置一个提醒，当有最新活动进展，或售票优惠的时候提醒您