引言

8月6号，阿里巴巴在西雅图举办技术论坛，经过4个月的思考，张建锋选择这个场合，首次围绕数据、计算和算法三个核心，系统阐述了阿里的技术布局。本文内容素材出自云栖社区。

张建锋花名行癫，加入阿里12年，亲历了淘宝、天猫、聚划算组成的中国零售平台一路发展成全球最大的电商平台。曾带领过多个技术团队，也担任过中国零售平台事业群的总裁，今年4月被任命为集团CTO。

“不论是人工智能还是其他前沿技术，都离不开高质量的数据、强大的计算平台和高效的算法平台。”阿里巴巴集团CTO张建锋在西雅图表示，“只有这三件事放在一起，才能真正在机器学习和人工智能领域取得突破。”

数据特征

阿里巴巴之所以将自己定位成大数据公司，是因为拥有非常多的高质量数据。 “今天大数据做得最好的，都是平台性的企业，比如Facebook和Google，因为他们有海量的高质量的数据。与之相比，阿里的数据不但种类丰富，而且含金量特别高。”

阿里的数据有三个明显的特征：首先阿里的数据是用户通过购买行为投票产生的，和搜索等场景相比，更加真实；其次相较于社交等数据，阿里的数据高度结构化，例如淘宝上的商品描述就高达一百多个纬度；第三非常密集而且实时，不管在无线还是PC端，阿里日常都有超过1亿用户在访问。

数据训练

在计算平台的构建方面，得益于大规模数据训练的优势，阿里巴巴做了大量的技术创新。除了围绕开源计算平台Hadoop生态所做的各项工作，如流计算和批处理，阿里还有两个非常高效的自研计算平台：离线计算平台ODPS和实时计算平台Galaxy，不但承载阿里日常的海量计算工作，而且通过阿里云对外提供服务。

为什么阿里巴巴能够在7年之前就洞察到云计算的未来，“阿里一直做平台化业务，交易平台既然可以共享，计算能力为什么不能？所以我们比大多数公司更早意识到，计算可以变成水电煤一样的公共服务。”

高效的算法

张建锋认为，算法必须和行业场景进行高度的结合，在实验室中并不能研究出真正高效的算法，而阿里巴巴最大的优势就是能够提供多样化的、极其丰富的场景。数据、计算平台和算法的结合，是未来非常重要的趋势。

强大的计算平台加上高效算法，能够进一步挖掘数据价值，最大化数据效率，形成正向循环。而云计算则能加速数据融合，例如孤立的看气象数据价值有限，但和农业或商业结合，就会产生巨大化学反应。而传统制造业如果能充分利用大数据，也将有助于大幅提升良品率。

技术布局

目前人工智能的技术方向很多，爆发性的出口还没有明确答案，在张建锋看来，最有可能获得成功的，是对消费的趋势、对数据和场景规模化有研究的人，阿里将在这方面投入更多的资源。

物联网经过长期发展，目前解决了很多核心的问题。第一，感知能力，目前传感技术的发展非常迅速；第二，联网技术，NB-IoT协议推动广域网组网，为物联网打开了一扇窗。当这两个问题解决后，互联网将迎来新一轮的爆发。

张建锋强调，有了感知互联之后，才能真正拥有大数据，才可能实现人工智能，从而使得整个平台更加智能化和人性化。据悉，阿里巴巴6年前开始研发的YunOS操作系统，目前已成为全球第三大操作系统。阿里将在操作系统、物联网、云计算等方面持续投入资源。

接下来，让我们看看阿里基于大数据的全球电商、阿里数据库AliSQL的开源，以及基于大数据的人工智能，希望能对阿里巴巴的大局窥一斑而知全貌。

基于大数据的全球电商系统

AliExpress从一开始就是一个全球性的平台。任何一款商品的上架，来自全球200多个国家的消费者都可以进行购买， 而不同国家的商家都可以在这个平台的平等竞争。

因为这个非常特殊的商业模型，面临相当多的不同领域，比如说支付、翻译、物流，订单和库存数据在全球跨大洲的多个机房间的更改，同步和一致性就是一个前所未有的巨大挑战。无论是Google、亚马逊、eBay、LinkedIn这类巨型的互联网公司，还是独角兽级别的电商，比如说Airbnb，都没有这种挑战。

接下来首先介绍了AliExpress电商系统的理论基础，通过页面间跳出率的计算引出了全栈优化的思路。然后，介绍了AliExpress平台的设计思路和性能优化过程，以及AliExpress使用过的几个有效的优化策略。最后，用实例展示了性能优化带来的结果，并对架构设计的过程提出了几点思考和总结。

理论基础

这张图代表流量分布和跳出率的关系。一个用户放弃使用一个网站或者APP的行为叫做跳出。上图中，横轴代表延迟区间，纵轴代表流量分布。绿色的曲线代表顾客来网站或者APP的流量分布，可以发现大部分流量分布在几百到一千毫秒，随着时间延迟的增加，跳出率变高。

整个系统计算时，使用转化率公式：转化率=1-跳出率。在发生性能故障的时候，比如有少部分机器出现延迟大大增加的情况，我们会发现高速性能的流量会变少，有很长延时的流量会增加，跳去率也很快地爬升上去。

这个过程表明，如果延迟越大，那么延迟跳出率会变得越来越高，即转化率变得越来越低。我们可以把虚线看作是优化前，实现看作是优化后，其中的部分就是优化得到的新的转化率。

我们做更深一步的讨论。上图中，红色代表转化率，蓝色代表性能区间的分布。假设我们把性能从a秒压缩到3秒时，转化率的回报是图中绿色的部分。这些回报是怎么得到的？

随着延迟越大，转化率越低，由于回报是单调减的函数，所以压缩之后得到的回报就是图中绿色的部分。如果我们知道压缩的时间，我们就可以预测出单个页面上得到的回报，这个回报称为性能损耗（Performance Loss）。

接下来，我们进行从A页面到B页面的理论跳出率的计算。如上图所示，A是一个页面，0、1、2、3是它的前序页面，end代表跳出页面。我们发现，出口的跳出率=经过补偿后的所有跳出率-自然跳出率。其中，自然跳出率是指自己因为对商品内容不满意、评价不满意而产生的自然跳出。

在此基础上，我们可以将其推广到所有页面。一个大的网站可能有数百个页面，比如上图中的两条链路：搜索—详情—订单；商铺—商铺详情—订单。在这种关系下，如果我们把每条链路的跳出率算出来，其实我们就得到了每条链路的理论最大流量，这样我们就知道了最终页面的最大流量。

这其实就是一个全栈性能损耗的过程，我们可以知道每个细小的过程对全局的贡献。这对于优化方案的制定非常重要。在做优化方案的时候，我们可以选择一个页面做尝试，准确度量一个页面的回报，这样就可以明确知道一种优化方案对整个系统的贡献，即本次优化对电商系统的订单回报量。

平台设计

平台是独立于业务领域的。针对不同的业务领域，有不同的优化方案，显示在图中左下部分。平台的功能是：把当前的性能变得可视化；实时度量目前的性能水平；对全链路做一个性能的监控；所有的领域都可以接到这个平台上；做一个全量的度量。

平台其实就是将性能优化的回报变成一个可度量的、非常容易看到的结果。在整个试验的过程中，数据是不断积累的，数据会带来准确的度量结果，度量结果则决定是否将优化在全栈进行推广。

性能优化

首先，应该有很多业务模块来收集用户的行为数据（请求时间、建联时间等），然后数据经过采集系统进行处理。处理完的数据有两种分析方式：离线分析、实时分析，区别在于离线的处理量比较大一些。分析的结果都会存在一个业务数据库中，最终会送到cache layer中做追溯和同比。后端会支持很多不同的应用场景，比如报警、监控、报表。

优化方案

其实，在DNS层、网络层、CDN层、业内沉淀有很多优化方案。这些优化方案哪些最有效呢？下面列举几个使用过的有效的优化方案。

动态加速

优化前，用户的动态请求都在源站，请求链路是：用户—运营商—源站。全世界都要去源站拿数据，这样的请求链路会非常长，过程相当耗时。

优化后，尽量把动态数据推到边缘节点，这些边缘节点不需要去源站进行请求，只需直接在边缘节点做请求。另外一个优化：请求既可以是同步的，也可以是异步的，可以同时并行请求多个页面内的元素。整体的动态回源的过程是对内容的动态加速。

另外一个动态加速的做法是，如果需要回源的话，把这个回源网络的最优化路径交给CDN来决定，CDN会帮助找到目前一条最优的链路来回源。动态加速其实是一系列的优化方案，比如包括内容压缩等。整个过程中也有不少的技术挑战：电商需要知道用户的真实IP；源站防止攻击要做请求拦截等等。

静态化+ESI

用户把内容放到边缘节点上，到了机房内其实也是做一个缓存：如果是动态内容则直接回源到数据库，如果是静态的不命中的内容则通过业务逻辑回源到数据库。

请求链路一般是“读链路”，“写链路”会变更db，db被变更消息的消费者消费之后通过业务逻辑更新存入缓存，是缓存内的信息总是最新的。这样的过程相当于用户如果能直接hit到边缘节点就返回（大多数最优的情况），不是最优的情况会hit到缓存层再返回。

元素请求合并

一个页面中会有很多的子元素，如果单独去请求，则每个请求都是回源的调用，那么每个请求都会占用很多时间（包括TCP建联时间等）。元素请求合并就是指把所有的请求合并成一个，统一提供到服务方，然后服务端再将这些请求分发，然后再统一合并再返回。

CDN调度优化

AliExpress在全球的各个国家都有相当多的用户，在巴西是第二大的电商网站，巴西用户可以请求美国的边缘节点，也可以请求巴西的边缘节点。经过测试，巴西用户请求巴西的边缘节点的相对耗时要少一些

可以认为是4个单位，请求美国节点耗时5个单位，但是请求地理位置离巴西近的阿根廷节点需要耗时7个节点。所以得出结论：不能单纯从地理位置来估计请求节点的耗时，以此为基础可以优化CDN调度。

业务结果

上述理论的分析，平台的搭建，业务的优化，带来了：整套系统的分析能力提升；过去的优化直接为整个网站带来5.07%的订单；性能损耗明显下降；购买力增强。

思考总结

-- 这套系统给大家带来的最大价值是：在做这套架构设计的过程中是不是能有新的创新？通过这个创新能否带来业务价值？

-- 把技术变民主，每个有想法的人都可以去尝试优化，每个人都可以做贡献。

-- 所有做的事情能不能量化？能不能做比较？不同的人对性能优化的贡献都应该能准确度量，这样可以把一个人的力量放大到整个团队的力量。

-- 怎么一步一步赢得这个团队的信任？

阿里云数据库AliSQL

AliSQL 是基于 MySQL 官方版本的一个分支，由阿里云数据库团队维护，目前也应用于阿里巴巴集团业务以及阿里云数据库服务。该版本在 MySQL 社区版的基础上做了大量的性能与功能的优化改进，尤其适合电商、云计算以及金融等行业环境。

最新的 AliSQL 版本不仅从其他开源分支，比如Percona，MariaDB，WebScaleSQL 等社区汲取精华，也沉淀了阿里巴巴多年在 MySQL 领域的经验和解决方案。

AliSQL 增加更多监控指标，并针对电商秒杀、物联网大数据压缩、金融数据安全等场景提供个性化的解决方案。在通用基准测试场景下，AliSQL 版本比 MySQL 官方版本有着 70% 的性能提升。在秒杀场景下，性能提升 100 倍。

性能优化

功能、稳定性增强

接下来主要讲解一个很小的功能——在线执行计划优化。

在MySQL内部，每一个SQL执行都会解析，在解析的过程中可能会解析出一个错误的执行计划，致使执行效率大大降低，甚至会把整个系统打爆。针对这个问题，其实Oracle是有解法的，即所谓的执行计划绑定。

在在线执行计划优化技术出现之前，我们能做的是告诉应用我们现在有SQL走错了执行计划，让应用加hint把执行计划固定下来，这种做法耗时非常长，并且需要应用介入，对可持续服务是一个很大的挑战。所以，我们可以做这么一件事，在线把一个应用的执行计划绑定好。

具体做法是：我们识别在线的SQL，对SQL进行模式识别，对于错误的SQL，我们在SQL发到MySQL之后再对它识别之后做一个hint来把执行计划固定下来。这样一个功能能够很快把整个系统的响应时间降下来，使业务马上恢复服务。

大连接、高并发下的数据库稳定性保障

大连接、高并发下的数据库会出现什么问题呢？

这是一个商品库的监控图。上边是threads running，用于在MySQL内部监控活跃线程数，下面是response time（响应时间），这两个是MySQL里面两个重要的指标。一般情况下，这两个数值都是非常低的，但是偶尔会出现图中的高峰，高峰的持续时间也很短，但是峰值特别高。

在压力很低的情况下，数据库为什么会时不时的停止服务？如上图所示，下面是数据库，上面是APP Servers，每一个应用服务器到达数据库的时间是不固定的。如果很多用户恰巧在同一时间访问相同商品的话，从系统看来就是几万个连接同时活跃，就会出现之前所说的问题。这个问题并不是阿里特有的问题，它其实是一个排队论的问题。

解决方案1：高低水位限流

高水位限流方法：当发现数据库的threads running超过一个阈值时，直接将超过阈值的连接数抛弃掉。这种方式虽然保证了部分请求能够顺利的执行并且有很好的响应时间，但是却抛弃了很大一部分的并发用户请求。

考虑到抛弃的不可行性，想到了排队，即低水位限流：在数据库内部做了一个队列，所有的用户请求到达的时候，先hash到队列上。当数据库出现并发的请求数激增时，可以先服务一批，服务完成之后再服务下一批，这样就可以在不抛弃的基础上保证数据库的稳定。低水位限流有了一些线程池的思想在里面，是一个比较粗的线程池。

解决方案2：线程池

处理并发请求，线程池是一个很好的解决思路，上图就是线程池的简单架构图。在MySQL中，一个用户请求对应到MySQL的一个工作线程。线程池是把用户请求线程和工作线程进行解耦，用户请求线程可以非常多，比如用户请求线程可以有成千上万，而工作线程只有固定的几十个上百个。

把这些工作线程进行聚合，每一个Group里面有多个工作线程。用户线程通过哈希算法映射到Group中。如果Group中所有的工作线程都正在服务，那么就进行排队等待。

为什么所有工作线程不放到一起，而是分开成一个个的Group？因为Group是可以与CPU的核进行绑定的，可以减少很多CPU的调度开销，这样又进一步提高了整个线程池的效率。

使用线程池时应该注意哪些问题？

--慢SQL是线程池的大敌！如果慢SQL比较多的话，所有的工作线程就会被占满，这样导致非常快的SQL也不能去抢占工作单元，相当于慢SQL把整个系统完全堵住了。

所以，使用线程池时要对整个数据库系统进行一个很大的优化，把数据库的SQL性能进行比较好的调优，频繁执行的SQL不能是慢SQL。慢SQL的来源包括：正常业务SQL、定时任务、系统后台操作（例如：binlog dump）。

--无论任何原因导致线程池堵塞，确保管理命令不受影响！管理命令不应该走正常的业务线程池，而应该走一个单独的接口。当线程池堵塞时，管理命令可以通过Extra port将慢SQL处理掉。

--线程池和用户的登录请求也是有关的。登录到数据库的那些请求其实走的也是线程池。使用线程池之后，处理连接风暴的能力也会变弱。

库存热点更新

“双十一”时，有很多商品是大家都想去抢购的，库存在数据库内部只是一行标识商品剩余件数的记录，买商品的行为其实是大家在并发的扣减商品记录。

当我们并发的去扣减记录的时候，为了保证正确性，一定要对这条记录加锁，由于锁的存在，就把商品扣减变成了一个串行的过程。这个问题与之前问题的不同之处是，这个问题是很多用户去抢一个热点商品所带来的问题。

先把它做成一个简化的模型，先开始一个事务，对它做一个插入，更新热点行，读出热点行的后项，最后进行提交。其中，更新热点行需要加锁，提交的时候放锁。MySQL会出现排队等锁的过程，并且每次排队都会进行死锁检测，这样逐渐使得死锁检测时间越来越长。

第一版做了一个很简单的优化，由于很多线程进入到数据库，但是又无事可做，所以控制进入数据库的线程数，保证InnoDB中有固定数目的线程，这样会使死锁检测、线程切换时间等都急剧下降。

继续分析该模型，持有锁的时间是从第三步开始，第五步结束，这个过程中有两个网络交互时间。考虑到降低网络交互时间，把第三步和第四步合并，先对热点行进行更新，更新完之后顺便把热点行返回给应用服务器。

在此基础上，再考虑继续减少网络交互时间，把三四五步都合并。更新库存时，如果更新到了一行，并且更新后项也满足，就直接把这个事务提交；如果说这里面的逻辑不满足，则自动把事务回滚掉。这样一来，所有持有锁的SQL都在数据库内部，没有任何网络交互。

既然串行已经优化到了一定的极致，能不能把所有穿行的用户请求做一个batch合并？怎么演进？用户发SQL过来后，对热点记录做哈希，其中每一个桶是一个热点行，对每个桶做收集，然后由桶里面的第一个事务一批次的把当前桶里收集的所有扣减请求全部一次性提交掉，这样虽然仍旧是串行化，但是用批处理去做了。

为了提升整体性能，当第一批提交的时候第二批开始收集，这样就将单线程的串行变成了批处理的线程。

完整生态体系

数据库追求的是一个体系，而不仅仅是一个数据库。想要用好数据库，需要为数据库构建完整的生态体系。其中，第二层是运维组件层，第三层是运维服务层，最上层是用户服务层。

运维组件层直接和数据库内核打交道，包括一些高可用、数据恢复、测试、调度等。运维服务层提供自动化运维平台DBFree，把整个数据库的申请、交付、扩容、缩容全部做成一个自动化平台。面向用户服务中面向应用开发的可以通过数据服务平台自助完成。

基于大数据的人工智能

阿里云人工智能新形象ET近日重磅亮相，ET前身是成功预测歌王归属的小Ai。

ET在整个互动过程中，表现很精彩，但模拟人的声音、视觉和听觉，还只是人工智能时代的一个开始。

抛开表象看本质，酷炫ET的背后，是阿里云图像和视频实时分析、语音识别、语音合成、自然语言的理解以及知识图谱等技术共同作用的结果。

具体来看，阿里云大数据AI的架构体系分成三层：计算能力、算法能力和解决方案。最底层是阿里云分布式计算引擎，它拥有庞大的CPU和GPU集群；往上一层是语音、文本、图像视频和机器学习等算法框架；再上则是一个生态的解决方案——智能交通、智能视频云和智能物联网等。

人工智能的历史有60年的时间，而它的快速发展却是在最近10年，其非常重要的一个原因是计算能力在最近10年得到了飞速提高。

阿里云总裁胡晓明称，全世界每天产生2500PB的数据，而真正使用到的还不到20％。当阿里的这种技术能力能够批量输出，那么剩余80％待发掘的数据，将会发挥难以想象的价值。

“大军未动，粮草先行”，当人们想做一件事时，总是不得不抽出时间，来考虑业务之外的东西。而当计算能力、技术能力变得唾手可得时，人们将会有越来越多的时间专注于业务的创新，尤其是当下，大家越来越聚焦于通过挖掘数据的价值来提高业务的价值。

当数据能够在地域与地域联通时，互联网时代全面到来；当数据在人与人之间联通时，移动互联网时代全面到来；而当这种数据智能的能力渗透到各行各业时，人工智能时代也或将全面到来。