技术员看双11
双11业务生态前端
在开始介绍这些挑战以前，咱们先用一张图来看一看，做为消费者，你在2013年的双11大促中都会经历哪些业务过程，如图1所示。算法
图1 双11大促时的业务过程数据库
首先，你会经过各类终端（PC、手机、平板）访问淘宝、天猫、聚划算的导购市场，丰富多样的导购产品会帮助你发现和挑选本身心仪的商品。大数据的基础平台支撑了大量有价值的数据应用，以保证你在这个环节的购物体验。稳定的交易平台确保了优惠价格的准确计算、库存的及时扣减和担保交易的订单有效生成。这时，你就能够经过支付宝安全放心地进行支付宝余额或者网上银行支付，满心欢喜地等待包裹的送达。缓存
这时就开始轮到面向商家的系统忙碌起来了。聚石塔提供的云推送功能在第一时间将交易订单同步到部署在聚石塔云工做平台上的商家ERP、WMS、CRM软件中，而且为这部分软件提供了动态弹性扩容的能力和安全方面的有效保护，以便大商家在大量订单面前，能够像平常状况同样，快速组织商品出库和发货，而不用额外担忧本身软件的处理能力。安全
最后出场的是菜鸟网络打造的雷达预警系统，经过大数据的力量，对商家的备货、消费者购买行为、物流服务能力进行预测，并与国家气象局、交通部实时发布的天气、道路状况进行同步运算，将将来半天至七天的预测结果反馈到13家快递公司，以便快递公司提早调配运力。最终，全部的包裹得以第一时间送到消费者的手中。服务器
挑战和技术准备网络
业务跨数量级的快速发展对总体架构带来了新挑战架构
经历了过去几年“去IOE”（IBM小型机、Oracle、EMC高端存储）总体架构改造，整个阿里集团创建了基于中间件、PC Server的轻量级分布式SOA架构，保证了服务器、数据库、网络、机房各个层面无单点，能够以较小的成本支持水平扩展，提高网站的负载能力。但随着这几年双11业务的飞速增加，PV、同时在线用户数、峰值交易和峰值支付等核心指标都开始跨越到新的数量级，架构在更高负载能力要求下的一些缺陷开始暴露出来。运维
第一，大规模访问请求带来的机房网络瓶颈。机器学习
双11当天有数亿用户访问天猫和淘宝的系统，高峰期甚至有数千万人同时在线。以天猫的“商品详情”页面为例，集群峰值QPS达到了十万以上的量级，是平时峰值QPS的数十倍。这样的突发性流量增加，使得机房的网络容量面临着巨大压力。如何可以利用合理的成本应对瞬间飙高所带来的网络压力，确保活动完整周期内用户响应时间的稳定性，以及局部出现问题时的高可用性，成了首先须要面对的问题。
着眼于将来，从2011年起，咱们就开始了对浏览型的应用进行新的架构改造。历经页面细粒度的动静分离、统一缓存接入、CDN静态化三个阶段。最终，将更新频率不高的内容伪静态化直接缓存到CDN，经过统一的秒级失效机制控制缓存的更新操做，让绝大多数内容请求不须要回流到主机房，直接在用户最近的CDN节点就可以完成。这种方式一方面极大地缓解了主机房网络的压力，另外一方面也优化了用户页面的响应时间。徐昭的《天猫浏览型应用的CDN静态化架构演变》将带你们更深刻地了解咱们是如何经历这一过程的。
第二，超大规模系统如何继续保持在不一样层面上的水平伸缩性。
首先，服务器需求的增多，致使将来单一地区的IDC资源已没法知足容量增加的需求，机房供电能力成为短时间内没法逾越的瓶颈。其次，简单地横向扩展IDC机房，机房之间的网络流量又成为了新的瓶颈。多机房的应用、缓存、数据库等访问的相互穿透，也加重着跨机房的流量增加。最后，核心服务集群的应用服务器的规模增加，使对应的数据库链接数成为了瓶颈。每增长一台数据库服务器，对应的应用服务器都须要链接上来，数据库的链接数立刻就不够分配了。也就是说，在今天的业务规模下，咱们没法继续针对核心服务的数据库层再作横向的水平扩展了。
为了解决以上问题，2013年双11咱们尝试了新的逻辑机房的架构方案，将数据水平拆分（Sharding）的思路向上提到接入层。以支付宝为例，先将完成某一特定业务须要的系统、核心服务、数据库组合抽象成一个业务单元（Zone）的概念，业务单元从应用服务器、缓存到数据库能够独立封闭运行。而后，从入口处根据用户请求路由到不一样的逻辑业务单元，实现了单元级别的可伸缩性。再也不依赖同城IDC，让交易、支付这样复杂的业务单元具有了大规模跨地域部署的能力。胡喜的《支付宝的架构变迁》会有更加深刻和全面的介绍。
第三，如何更大程度地“压榨”单服务器的系统资源。
虚拟化技术已做为各大网站提高物理机资源利用率的基础技术。以天猫和淘宝网为例，2010年咱们引入Xen虚拟化技术，1台物理机装3个虚拟机，必定程度上下降了成本。但随着机器规模的快速增加，咱们发现其中1/3的虚拟机的Peak load<0.5，这意味着咱们的运维成本仍是不够低。主要有如下几方面缘由：
单台物理机上跑的应用不够多；
分给应用的机型及机器数是静态的；
集群的资源利用率不均衡。
为了最大化物理机的资源性能，从2012年开始，咱们大规模地应用了新的基于LXC的虚拟化方案，成功地在每台物理机（16Core/48GB）运行了12个应用实例，物理机的load提高到2~10。这对大促时期的成本控制很是有帮助，也为内部私有云的完整构建，摸索了一条可行的路径。
消费者对用户体验有了更高的要求
千人千面的购物体验
有一个很现实的问题摆在了咱们面前：大促当天有几亿消费者会来到咱们的网站，在上百万商家和过亿商品里面挑选本身心仪的宝贝。光靠运营人肉制做的活动页面和消费者的主动搜索已远远不可能知足需求。所以，须要在产品上转变思路，营造从以业务为中心到以用户为中心的大促体验。双11应该是面向消费者的“个人双11”，而不是“天猫的双11”。
基于此，2013年的双11大促中大面积应用了个性化算法，从PC到无线，从“会场”到“详情”，真正意义上为消费者打造了一个“个人双11”。从最终效果来看，2013年双11的用户购买转化率提升了10个百分点。张奇会在《个性化技术在双11的应用》中介绍在个性化推荐系统架构、机器学习算法应用和算法的快速评测方面的思考。
多终端的业务一致性
移动智能终端的快速崛起，让更多的消费者能够随时随地访问天猫和淘宝，但也让咱们开始深刻地思考，在业务快速发展的前提下，如何在不一样终端上快速提供本质相同的服务。2013年咱们首次在预热期的大型活动中尝试了基于Canvas的Web App解决方案，极大程度地提高了开发效率。天猫前端团队的鄢学鹍会在《双11的前端实践》一文中分享Mobile First的理念是如何在双11中实践的。
稳定性的极致要求
容量预估、依赖治理、监控
这一环节是历年双11技术成功与否的关键环节。中间件团队的《中间件技术的双11实践》除了会介绍在SOA架构体系中扮演重要角色的中间件产品以外，也会就容量预估、依赖治理和监控的双11实践作精彩介绍。
业务降级、限流预案
从2010年双11开始，每一年都会针对性地准备一些技术预案，在流量超出预期时作好限流保护，在局部系统处理能力出现瓶颈时进行优雅降级，以提高总体的吞吐率，保证核心业务的正常运行。
2013年，咱们在技术环节准备了2000多套应急预案，大到遭受骇客***、各种业务应急动做，小到服务器机房空调发生故障，均有详细预案。不只各服务器机房，甚至西溪园区双11大促指挥办公现场都准备了柴油发电机。此外，2013年针对双11进行了上百次的内部演习，其中全网大规模演习就进行了10余次，以确保每个预案的有效性。
全链路压测
压力测试对于评估网站性能的重要性是不言而喻的，但不管是线下模拟的单一集群压测，仍是线上引流压测，都只能暴露一些基本的单点问题。对于双11当天高峰期的真实压力模拟，这两种传统的压力测试方式还存在着巨大误差。
首先是业务处理链路的复杂性，对于像天猫这样一个分布式处理平台，一笔交易的建立会涉及多个应用集群的处理，在能力评估时也应该考虑的是一个处理链路而不只仅是单一应用集群的处理能力。其次是应用以外的风险点，像网络、数据库等，很难在传统压测中体现出来。
为了精确评估核心交易集群中各个环节的能力瓶颈，2013年咱们实现了一套新的全链路压测评估体系。经过线上真实用户数据与人为测试数据相结合的方式，首次成功地在生产环境中模拟出相对真实的超大规模访问流量，将前端系统、网络、数据库等一整套系统环境完整地归入压测范围，贴近实际的应用场景，为评估淘宝和天猫交易核心链路的实际承载能力提供有说服力的数据依据。这一方面能够验证交易核心链路上各类限流和预案的准确性，另外一方面也能够充分暴露全链路上的各类瓶颈和隐藏的风险点，让压力测试的工做真正落实到了肯定性的层面上。
基础运维能力提高的预研
在支撑好现有业务的同时，如何将基础运维能力（高稳定性、弹性调度、低能耗、快速交付等）提高到新的量级，成了阿里技术团队将来面临的新挑战。为了迎接这方面的挑战，2013年双11咱们也小范围作了一些面向将来的基础运维预研工做。
首先，能够预见的是，随着业务的不断发展，阿里会有愈来愈多IDC布点。虽然逻辑机房的方案已能解决交易支付环节场景下的跨机房调用问题，但随着云计算的推广，咱们依然面临着大量跨机房调用的场景。现阶段，交换机的网络路由主要是基于IP作简单识别，并不会经过识别应用类型提供智能调度。当大规模出现多个IDC时，跨机房的用户体验问题会愈来愈成为瓶颈。为了解决这一问题，咱们2013年在交换机的OS层面作了大量自主研发工做，定制自主的交换机OS，实现软件定义网络（SDN），对管控和成本两个层面都有较大的改进。庞俊英的《阿里的SDN实践》将简单介绍咱们如何让应用流量经过SDN识别出来，从而实现不一样流量的长途链路和短途链路调度。
其次，在将来的3~5年，阿里的服务器将扩大到几十万甚至百万级的规模，若是延续之前按服务器进行交付的模式，交付速度和能耗都会很快出现瓶颈。所以，咱们2013年尝试了整机架服务器解决方案，经过标准化、流程化、定制化，解耦各个交付环节在IDC现场部署的时间串行关系，提高交付的质量和效率。除此以外，其中例如统一机架Backbone模块这样的设计，将总体的耗电量下降了接近10%。放在百万级服务器的规模下，无疑会节省一笔极大的开销。武鹏的《阿里整机架服务器解决方案》会展现咱们在低能耗、快速交付上的思考和方案。
经验小结
对于技术人员而言，双11绝对是一次奇幻体验，在这里有丰富的场景能够实现我的技术上的奇思妙想，同时也经历着最极致的技术考验。经历了5年双11，我来小结一下技术准备上的一些经验心得。
提早明确架构目标。
架构和基础技术的调整每每带来应用系统的伤筋动骨，前面介绍的一些大架构改造，周期每每须要2~3年，试错成本很是高。所以对于架构师和技术核心决策者而言，要有足够的前瞻性，在选型设计上必定从全局发展和核心问题出发，准肯定位、明确目标，才能统一团队的总体方向。
不过分追求过程当中的完美。
咱们在内部总把系统架构的过程类比为建造水坝——上下游级联，同时兼顾对于全局生态的影响。但落实到实施层面才是挑战的开始，你们老是会倾向于考虑是否优雅完美，从而让方案的复杂度不断提高。架构师须要可以兼顾成本、资源、时间等各方面的因素，勇于作取舍，敢于舍弃一些收效甚微的优化。到准备后期更是如此，发生问题不可怕，可怕的是解决问题的时候又引入新问题。没有100%完美的方案，能知足业务现阶段发展须要的方案就是好方案。
细节决定成败。
分布式系统的好处在于松耦合、灵活性和可快速扩展，但同时也带来了一系列麻烦，包括数据的一致性、分布式事务、各类应用在服务层的数据相互干扰等。在大促这样的峰值压力下，这些小问题都会被无限放大。所以，前期准备过程当中要谨记不能放过任何微小的细节，侥幸心理更是万万要不得，担忧出问题的角落每每必定会出问题，最没问题的地方或许会是风险最大的地方。另外，尽量工具化一切人为操做环节，在架构上作好约束，同时时刻确保留有“Plan B”，只有这样才可以确保对最终结果有把握。