手机淘宝作为阿里集团移动端的“航空母舰”，近两年发展非常迅猛，用户量增长接近10倍。在2015双十一这天，我们的无线端成交占比高达68% 。在高峰期，更有超过4500万人同时在线，每秒14万笔下单；今天我们拥有超过3亿的月活跃用户，是全球最大的消费类移动APP。而这些，都对我们的系统能力提出巨大挑战。
阿里巴巴打造的不是一个软件系统平台，而是一个电子商务操作系统。这样的电商操作系统，支撑了过去10年的快速发展。同样，我们在移动端也在重新思考如何继续升级，如何在手机APP中完成生态建设。
移动互联网不仅仅是传统互联网的延伸。这个共识一方面来自于手机终端的强大特性对产品和商业模式产生的“破坏式”影响，另一方面来自于技术的变化趋势。
在Web的时代，我们说B/S架构，通常也可以理解为是C/S架构的一种变体。只不过在Client端，我们运行在Browser这样一个容器环境中，通过稳定的宽带网络接入，通过HTML这样简单、透明的协议与服务端进行通讯。由于浏览器只提供了非常简单的能力接口。所以，客户端上只有非常薄的一层，只做渲染的工作。而在这里工程师的主要工作是在集中解决兼容性的问题。 而所有的逻辑计算和我们所有要解决的核心问题，扩展性、伸缩性、稳定性、性能等等，其实都集中在后端。
随着个人计算机计算能力的发展，前端技术像Ajax、Angular这样的技术如雨后春笋般冒出，我们进入Web2.0时代。但这个时候云和端之间的边界并没有发生本质变化。
在移动时代，移动设备的计算能力发展的越来越迅猛。更重要的是，移动操作系统将移动设备上百个sensor的能力暴露了给上层的应用，使得我们能获得比在Broswer里更强的能力。这样app侧就能够做到更多的以前在Browser无法做到的事情。所以，互联网发展到今天，到了移动互联网的时代，我们真正意义进入到了一个富客户端时代，之前简单清晰的云端界限被彻底的模糊。
在这个阶段，我们原来谈论的很多架构问题，扩展性、隔离性、稳定性、性能等很多问题就不在仅仅只是服务端的问题，客户端也需要开始从架构的维度来思考这些问题。同时云端之间通讯的简单的协议，稳定的通道，也在发生了很多的变化。移动网络随时随地需要接入的特点，也对我们的基础架构提出了更高的要求。接下来我们就展开看一下这里的区别。
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的开发和集成方式并不适合企业级开发。一个具备很好隔离性的模块化架构是大规模并行开发的基础。
动态性：互联网追求唯快不破，从架构上将我们希望能够在富客户端时代同样也能保留web的轻盈和灵活。动态性是很重要的前提。
极致的网络体验：全双工的接入平台保障了接入层的伸缩性和稳定体验，不管用户在何种网络环境下都能拥有顺畅的体验。
相比PC时代，移动开发非常复杂。用户既想要一个惊艳的体验，又期望安装包尽可能小。那么开发者们就既要具备如web时代的轻量级开发部署能力，又要能获取到native的能力、性能和扩展性。
平台级产品的并行开发和独立部署架构
一个好的架构需要支持并行的开发、独立的部署，这样才能够满足灵活多变的业务增长。同时，发挥航母级的平台优势，支撑更多元的客户端应用，产生规模效应，拓展商业边界。所以，我们的解决方案是在native平台（准确来说是Android）上构建一个隔离性的架构，在此之上，功能尽可能的切割的越小越简单越好；同时，在不损失native性能和能力的前提下，我们也引入了更多的web特性到移动开发中来。
我们的客户端容器架构设计的原则是“everything is a component”，在Android平台上，基于我们的隔离化容器架构设计，我们既可以提高在集成期的多团队协作效率，又收获了在运行时的灵活部署。通过把庞大的工程拆分成一系列的独立服务，以及我们具备的容器自升级能力，就不需要同时编译和集成所有的功能模块。一旦一个模块完成了测试，我们就可以按需对他进行升级。另外，我们的APP还具备线上可热修复的能力。
跨平台的思考引发了敏捷性（WEEX）
另一个残酷的事实是，我们所有的功能需要在Android、iOS和H5上重复实现。当我们面对客户端包大小，方法数的限制的同时又需要支持200+的功能升级、多平台持续交付、覆盖度、容错、热修复等等庞杂的事情 。所以在设备和OS的限制下做伸缩，我们需要一个超轻量灵活的解决方案，能够基于某个高度重用的东西上进行低成本的并行开发、快速发布。
这套方案跟业界相似方案的效果对比如何呢？ 首先我们选择了一个标准场景：渲染一个定制化的图片列表，展示200+的页面。
下图是我们实际测量的数据情况，包含渲染时间、内存消耗、CPU消耗和帧率。我们并不是想通过这个图来强调我们比所有其他方案都好，因为场景不同所有效果也会有所不同，我们想说的是能通过这么一个方案取得性能和动态性的双丰收。
灵活高效、安全稳定的网络调度服务（ACCS）
接下来，我们需要解决的是端到端的伸缩性。随着手机淘宝业务的扩张，我们的活跃用户也在不断的增长，为了提供更好的端到端的能力，我们必须提高连接服务的质量。这得益于在以下四个方面的努力：
作为服务消费方，我们不能决定网络的延迟和带宽，但是我们可以努力减少round-trips。
阿里的后端系统采用多数据中心多活的架构部署方式，所以无线网关需要具备正确的、灵活可变的用户调度能力。
我们把网络能力整体封装成了标准的SDK，一方面以确保我们的APP群能够一起享受整个优化的收益，另一方面也确保了H5页面能够使用到Native通道的能力。
在阐述完客户端架构和网络架构之后，我们再次把目光聚焦到后端服务上。2010年左右，我们开始考虑多数据中心的事。一方面，我们做到了服务和数据的水平扩展。随着业务规模的不停增长，我们的应用伸缩规模也越来越庞大，单点不稳定性带来的风险也成倍放大。另一方面，部署的应用越来越多，覆盖电商、物流、大数据等等，而一个城市能够提供给我们的空间毕竟是有限的。更加致命的是，如果单机房发生故障，这对于电商来说基本上不可接受的，所以我们在2011年开始进入双活乃至多活的改造。
架构是非常值得分享和讨论的，好的技术架构能够持续支持伟大的商业梦想。所以今天阿里具备的无线能力，很多都将会通过开源或云服务和外界共享，希望回馈整个社区。同时也希望我们的技术思考能够给大家带来启发。大家如果感兴趣，欢迎持续关注我们的Github地址。
技术发展将从面向生产效率的IT时代进入面向智能的DT时代，数据最终将成为水电煤一样的基础设施 。在这样一个背景下，我认为移动时代只是一个过渡阶段，这个阶段我们的所有工作其实都专注在三件事上：
首先，各种设备最终都会具备联网的能力 ，我们的基础设施要做好准备。这就是为什么我们会做ACCS这样的亿级无线云平台，打造强大的无线基础设施，迎接万物互联时代的到来。其次，云和端的界限势必会经历一个越来越模糊再到重新清晰的过程。过去w3c和浏览器厂商付出了大量的努力，传统互联网是一个开放分享透明的生态。现有的移动终端平台其实并没有为超级App做过任何准备，反而很多时候限制了超级App的发展。这个过程我们也很愿意参与进来，让移动互联网也能够更加开放分享和透明。
最后，终端不应该仅仅是被动的数据消费，而更重要的是成为更多维度的数据生产者。