在过去的十年里，阿里逐渐影响和改变了中国人的生活方式。在此之前，大家都只能在线下门店消费，但是现在大家都养成了线上购物的习惯，并且乐在其中。一方面，到目前为止有超过千万的卖家选择在阿里开线上的门店；另外一方面，阿里构建了中国最大的公共云计算平台，并跻身世界前三。在中国，阿里云目前服务了超过30%的网站和超过50%的中小型企业。
阿里巴巴是一家国际化的公司，从今年的双十一就可见一斑。除了把各种海外尖货带到国内，我们也把国内的优质商品带到全世界。成立于2010年的AliExpress，已经发展成为全球最大的跨地域交易平台。除了电子商务，阿里巴巴在全球的业务还包括金融、物流、健康、娱乐和云计算。这也是为什么我觉得把阿里看做是中国的Amazon和ebay是不准确的。如同马云所说“如果把亚马逊或者京东比作苹果，那么阿里就应该是一颗苹果树”。我们把自己看做是一个生态系统，是未来生活的水电煤。我们的目标是创建一个开放、透明、合作的商务平台，让天下没有难做的生意。
过去两年，阿里电商平台中移动成交占比提升了2倍，达到60%以上，这得益于我们在移动和系统架构上做了很大的改造。接下来我重点介绍今年双11阿里巴巴在无线领域的几大创新：
电子商务操作系统如何在移动环境下应势而变，通过架构升级从容应对移动端的各种新挑战，让一款APP成就一种生活方式。
我们如何重塑手机淘宝的后端系统架构，满足业务爆发式的增长。
我们如何建立单元化系统架构，实现异地多活甚至未来的弹性伸缩。
7年前，双十一在中国还被戏称为光棍节，但在2009年，阿里巴巴第一次决定在这一天举办购物促销，把这个日子变成了世人瞩目的购物狂欢节。
5天前，我和团队刚刚经历了第7年的双十一，这一天阿里巴巴的交易额约143亿美元（912.17亿人民币）。去年黑色星期五期间的全美总交易额是114亿美元（包括了线下和线上所有的电商公司的销售总额），而双十一产生的143亿美元，仅仅是阿里巴巴电商平台一天的交易额，整个狂欢覆盖了200多个国家和地区。全社会共同参与，把平凡的一天变成全球狂欢的节日，这就是阿里巴巴生态的力量、互联网的力量。
手机淘宝作为阿里集团移动端的“航空母舰”，近两年发展非常迅猛，用户量增长接近10倍。在2015双十一这天，我们的无线端成交占比高达68% 。在高峰期，更有超过4500万人同时在线，每秒14万笔下单；今天我们拥有超过3亿的月活跃用户，是全球最大的消费类移动APP。而这些，都对我们的系统能力提出巨大挑战。
下面给大家分享一个典型用户在手淘的一天。
移动架构的反思
阿里巴巴打造的不是一个软件系统平台，而是一个电子商务操作系统。这样的电商操作系统，支撑了过去10年的快速发展。同样，我们在移动端也在重新思考如何继续升级，如何在手机APP中完成生态建设。
移动互联网不仅仅是传统互联网的延伸。这个共识一方面来自于手机终端的强大特性对产品和商业模式产生的“破坏式”影响，另一方面来自于技术的变化趋势。
在Web 1.0时代（1999-2005），客户端非常“薄”，工程师的主要工作集中在浏览器兼容性处理。核心问题如扩展性、伸缩性、稳定性、性能等，都集中在后端。随着硬件设备和网络能力大幅度提升，尤其AJAX通信的出现，Web进入到2.0时代（2005至今），这是一个富交互的客户端时代。
今天，移动时代的Web仍继承了Web 2.0的形态，但有多了更多系统调用的能力，如sensor，尤其是在客户端内。此外，Native除了继承移动Web 2.0的能力之外，更是在底层调用、性能、框架上有了进一步的突破，但随之而来的是集中式开发模式、多平台差异等问题。
此时，我们原来谈论的很多架构问题，扩展性、隔离性、稳定性、性能等就不仅是服务端的问题，客户端也需要从架构的维度来思考这些问题。同时云端之间通讯的简单的协议，稳定的通道，也发生了很多变化。移动网络随时随地需要接入的特点，也对我们的基础架构提出了更高的要求。接下来我们就展开看一下其中区别。
Rethinking Mobile Architecture-夹心面包的尴尬
但这个问题的解决之道并不像服务端。在这个过程中我们全面反思，大家看到这张图里面我们用了一个形象的比喻来体现传统的服务端软件。最下层是操作系统，通常是linux，最上层是我们的业务功能和服务。在服务端架构，我们很习惯用增加一个架构层次的方式来解决问题。例如缓存层、数据访问层等。我们在架构上按照自己的意愿去搭建不同层次的衔接环节，使架构具有足够的灵活性和扩展性。即使堆成这个样子，它依旧是非常合理的。
而移动app架构则是一个完全不同的场景。我们必须回到远古的CS架构时代，一个丧失web灵活性的时代，因为所有功能都必须集成到一个APP里面。
我称之为“看上去简单，但实际上却非常尴尬的夹心层“ 。
所以，我们需要有一个优雅的客户端架构设计，让我们能够重拾以前web互联时代的能力。在这种背景下，我们构建了手机淘宝这样一个能够支撑电商生态系统的客户端架构。概要来说，设计理念可以为总结如下几点：
设计时的隔离性。这个架构必须具备设计时的隔离性，这样我们在开发、打包时才能够最大化并发能力；
运行时的隔离性。这个隔离性作用在客户端，主旨在于提高端侧可靠性。我们必须确保单个模块的故障影响范围内敛到自己内部，不会引发整体crash。
动态渲染能力和部署能力。这个架构必须具备一定程度上的运行期调整和动态部署能力。在这个过程中，我们构建了一个速度更快的类HTML5渲染引擎；同时，我们也实现了一个私有的容器，支持模块的动态加载和更新。坐拥这两大利器，线上问题的修复和新模块的自动更新都脱离了版本发布的依赖。不幸的是，由于AppStore和GooglePlay尤其是前者较封闭和严苛的审核制度，我们的动态部署能力常常无法施展，尽管在中国的安卓应用市场上已得到充分的使用。
最大力度的兼容性保证，以确保我们在系统版本升级过程中不出现整体的阵痛。
整体的架构反思过程中，我们重新定义了客户端和服务端（云端）的边界。一旦确立这样一个合理的架构，就能保证我们的移动APP在相当时间内，持续高效的支撑业务发展。
Challenge in mobile architecture -移动架构的挑战
另一个挑战来自于不稳定的移动网络环境。PC时代，我们访问网站的接入条件是相对恒定的，所以在开发时很少考虑网络对于用户体验的影响。
但是移动APP则不然，尤其是在中国，基础的移动网络环境并不好，而且我们有很多用户的访问是发生在地铁、公交车这样的环境下，移动基站的频繁切换进一步增加了网络的不稳定。从手机淘宝的数据可以看出，我们每天活跃用户中有15%来自于类似2G这样的弱网环境。如果端到云的连接不稳定，有高延时，那么所有的用户体验都无从谈起。
基础网络的效率就像一辆列车，时延是火车的速度(启动时间)，而带宽就像火车的车厢装载量，整个传输的物理链路就像火车的铁轨。我们面对的移动网络条件非常复杂，既有高铁这样先进的传输渠道，也有不少老旧缓慢的绿皮车还在服务很多用户。我们的目标很简单，就是想让所有用户都能在手机淘宝获得流畅的体验，不论你坐的是“高铁”还是“绿皮车”。
下面这张图，能够让大家更加直观的了解中国的移动网络环境。它描述了从用户到IDC的端到端的路由情况，不仅数据传输耗时长，而且丢包率高，同时安全性也相当糟糕，DNS劫持、内容劫持在中国就是家常便饭。
因此，我们在改善网络通道上做了很多的事情，探索突破运营商基础网络的局限性，力争为用户创造极致的购物体验：
减少网络交互：使用更高效的通讯传输技术，提高了连接复用，减少roundtrip次数；
降低流量：通过更高效的压缩技术和同步技术减少了网络的流量；
更安全：在不降低体验的基础上通过对tls1.3的优化提高数据的安全性；
更稳定：更灵活的调度系统实现异地多活，缩短故障切换的时间。
阿里的无线技术实践
以上整体介绍了阿里对移动时代架构重新思考的过程。基于这些思考，我们对架构演进的方向提出了以下几个核心要求：
隔离性：这是大规模并行开发的基础，传统的移动App的开发和集成方式并不适合企业级开发。
动态性：重新定义云端边界。我们的业务通常是灵活多变的，尤其是在双十一这样的大促场景，所以我们需要有足够快的交付能力。
丝般顺滑：全双工的接入平台保障接入层的伸缩性，不管用户在何种网络环境下都能拥有顺畅的体验。
相比PC时代，移动开发非常复杂。用户既想要一个惊艳的体验，又期望安装包尽可能小。那么开发者们就既要具备如web时代的轻量级开发部署能力，又要能获取到native的能力、性能和扩展性。
一个好的架构需要支持并行的开发、独立的部署，这样才能够满足灵活多变的业务增长。同时，发挥航母级的平台优势，支撑更多元的客户端应用，产生规模效应，拓展商业边界。所以，我们的解决方案是在native平台（准确来说是Android）上构建一个隔离性的架构，在此之上，功能尽可能的切割的越小越简单越好；同时，在不损失native性能和能力的前提下，我们也引入了更多的web特性到移动开发中来。
我们的客户端容器架构设计的原则是“everything is a component”，在Android平台上，基于我们的隔离化容器架构设计，我们既可以提高在集成期的多团队协作效率，又收获了在运行时的灵活部署。通过把庞大的工程拆分成一系列的独立服务，以及我们具备的容器自升级能力，就不需要同时编译和集成所有的功能模块。一旦一个模块完成了测试，我们就可以按需对他进行升级。另外，我们的APP还具备线上可热修复的能力。
另一个残酷的事实是，我们所有的功能需要在Android、iOS和H5上重复实现。当我们面对客户端包大小，方法数的限制的同时又需要支持200+的功能升级、多平台持续交付、覆盖度、容错、热修复等等庞杂的事情 。所以在设备和OS的限制下做伸缩，我们需要一个超轻量灵活的解决方案，能够基于某个高度重用的东西上进行低成本的并行开发、快速发布。
Weex就是我们想要的杀手锏，开发者可以通过一套跨平台的代码构建iOS和Android的APP。在构建应用UI的时候，开发者可以使用我们的基础库，这个库抽象了不同平台之间的差异性。开发者面对的DSL是基于一个叫做Vue.js的轻量级js库，相对于React的JSX语法，这是一个更加面向组件的、脚本样式分离的语言，对于开发者来说更加友好，更利于开发者和设计师之间的协作。JSBundle可以所见即所得的进行及时更新，V-DOM的抽象层提供了跨平台渲染能力，同时也具备native组件优雅降级的能力。
这套方案跟业界相似方案的效果对比如何呢？ 首先我们选择了一个标准场景：渲染一个定制化的图片列表，展示200+的页面。
下图是我们实际测量的数据情况，包含渲染时间、内存消耗、CPU消耗和帧率。我们无意于强调我们的解决方案由于其他的参照，因为在不同的场景里面印象渲染性能的关键性元素可能会发生变化。我们想表达的是，一个既能够满足用户体验的、具备动态UI能力的、跨平台的解决方案是可行的。
接下来，我们需要解决的是端到端的伸缩性。随着手机淘宝业务的扩张，我们的活跃用户也在不断的增长，为了提供更好的端到端的能力，我们必须提高连接服务的质量。这得益于在以下四个方面的努力：
作为服务消费方，我们不能决定网络的延迟和带宽，但是我们可以努力减少round-trips。
我们建立了httpdns服务并缓存在本地，减少客户端DSN检索的时间损耗；而且基于TLS1.3进行了改造，在保障链路安全的情况下性能得到的较大提升。
阿里的后端系统采用多数据中心多活的架构部署方式，所以无线网关需要具备正确的、灵活可变的用户调度能力。
我们把网络能力整体封装成了标准的SDK，一方面以确保我们的APP群能够一起享受整个优化的收益，另一方面也确保了H5页面能够使用到Native通道的能力。
在阐述完客户端架构和网络架构之后，我们再次把目光聚焦到后端服务上。2010年左右，我们开始考虑多数据中心的事。一方面，我们做到了服务和数据的水平扩展。随着业务规模的不停增长，我们的应用伸缩规模也越来越庞大，单点不稳定性带来的风险也成倍放大。另一方面，部署的应用越来越多，覆盖电商、物流、大数据等等，而一个城市能够提供给我们的空间毕竟是有限的。更加致命的是，如果单机房发生故障，这对于电商来说基本上不可接受的，所以我们在2011年开始进入双活乃至多活的改造。
阿里无线技术的开源计划
架构是非常值得分享和讨论的，好的技术架构能够持续支持伟大的商业梦想。所以今天阿里具备的无线能力，很多都将会通过开源或云服务和外界共享，希望回馈整个社区。同时也希望我们的技术思考能够给大家带来启发。大家如果感兴趣，欢迎持续关注我们的github地址。
移动时代知识DT时代的过渡
技术发展将从面向生产效率的IT时代进入面向智能的DT时代，数据最终将成为水电煤一样的基础设施 。在这样一个背景下，我认为移动时代只是一个过渡阶段，这个阶段我们的所有工作其实都专注在三件事上：
首先，各种设备最终都会具备联网的能力 ，我们的基础设施要做好准备。这就是为什么我们会做ACCS这样的亿级无线云平台，打造强大的无线基础设施，迎接万物互联时代的到来。
其次，云和端的界限势必会经历一个越来越模糊再到越来越清晰的过程。现有的移动终端平台不但没有做好迎接超级App的准备，反而限制了超级App的诞生。我们最终希望让客户端有服务端的灵活，让服务端有客户端的体验。
最后，终端不应该仅仅是数据的消费，而更重要的是成为更多维度的数据生产者，每个个体都是数据的来源。
专家介绍
庄卓然 拥有10余年的互联网研发和管理经验，是见证并主导阿里业务架构演进的当事人之一。他于2009年加入阿里巴巴，先后在淘宝、天猫负责营销、会员、交易、导购等系统的架构和研发工作，经历了淘宝从简单应用到承载数亿用户的分布式服务化业务平台的技术演进过程。同时，他还是2011-2013年双十一的天猫技术负责人，持续推动双十一的产品架构演进、稳定性改造和性能优化等研发工作。2013年转战移动研发战场，带领团队专注于手机淘宝和移动基础平台的研发建设。
徐昭 2012年加入天猫成为技术核心，前后带领过天猫卖家、导购详情等多支技术团队，亲身打造并见证双11成为电商行业的重要节日。现任手机淘宝卖家生态团队技术负责人，专注在无线整体架构、大型复杂移动应用构建框架及无线技术开放等领域，同时关注新技术和开发模式在移动互联网产品中的演进和落地。
