阿里双十一背后的技术「淘宝网站体系架构」

淘宝双十一当日要处理千亿级的交易额，堪称当今世界IT系统独一无二的挑战，其背后有着怎样的技术架构和技术支撑体系？

双十一背后的技术架构

按需伸缩：弹性混合云架构

每年淘宝都要应对双11、新春红包等活动的极高交易量。尽管单元化架构让阿里具备应对峰值的能力，但要降低高峰期的资源投入，系统还需具备按需伸缩的能力。

阿里解决这个问题的方法是，活动前在云计算平台快速申请资源，构建新的单元、部署应用与数据库。然后将流量与数据“弹出”到新的单元，快速提升系统容量。当活动结束后，再将流量与数据“弹回”，释放云计算平台上的资源。

通过这种方式，可以大大降低资源采购与运行成本。弹性操作，需要在流量、数据与资源之间协调一致地操作，尤其是有状态的数据的弹性操作最困难，既不能不中断业务，又要保证数据的一致性。这些操作如果依靠运维人员人工执行则会十分复杂低效，因而需要架构、中间件与管控系统的支持。

云平台是把海量机器资源，通过统一的资源管理，抽象为一个资源整体，在之上可按需动态申请硬件资源（如CPU、内存、网络等），并且之上提供通用的操作系统，提供常用的技术组件（如Hadoop技术栈，MPP数据库等）供用户使用，甚至提供开发好的应用，用户不需要关系应用内部使用了什么技术，就能够解决需求（如音视频转码服务、邮件服务、个人博客等）。

异地多活与容灾：单元化架构

异地多活与容灾架构的基础是对系统进行单元化。每个单元可以认为是一个缩小规模的、包含从接入网关、应用服务到数据存储的全功能系统。每个单元负责一定比例的数据与用户访问。

有以下关键特性：

自包含性：比如用户的一次账户充值交易，涉及的所有计算与数据都在一个单元内完成。

松耦合性：跨单元之间只能进行服务调用，不能直接访问数据库或其他存储。对于一些必须跨单元的交易处理，比如分属于两个不同单元的用户之间的转账交易，跨单元的服务调用次数尽可能少，在业务与用户体验允许的情况下尽量异步处理。这样，即使两个单元之间相距上千千米，也可以容忍跨单元的访问时延。

故障独立性：一个单元内的故障，不会传播到其他单元。

容灾性：单元之间相互备份，确保每个单元在同城和异地都有可在故障期间进行接管的单元。数据在单元间的备份方式，阿里以OceanBase提供的多地多中心强一致方案为主。

通过异地多活，系统可以在全国范围内任意扩展，服务器资源得到了充分利用，提升了系统应对地区级灾难的能力。

金融级分布式数据库：OceanBase

OceanBase（中文名“海钡云”）是阿里巴巴/蚂蚁金服集团自主研发的面向云时代的关系数据库，它构建在普通服务器组成的分布式集群之上，具备可扩展、高可用、高性能、低成本及多租户等核心技术优势。OceanBase应用于蚂蚁金服的会员、交易、支付、账务、计费等核心系统和网商银行等业务系统，并开始对外提供云服务。在刚刚过去的双11，用户每一笔支付订单背后的数据和事务处理都由OceanBase完成。

从产品的角度看，云数据库具备线性扩展、高可用、低成本等核心优势，并内置多租户支持，兼容MySQL，适合部署在云环境。相比传统的IOE架构，OceanBase能够将成本降低一到两个数量级，并提供更好的扩展性及高可用能力。另外，OceanBase支持平滑迁移，无须业务改造，就可以将原先使用MySQL的业务迁移到OceanBase。

从技术的角度看，云数据库采用无共享（Share-nothing）的分布式架构，如图所示。

P1~P8：OceanBase将表格按照传统数据库分区表的方式进行分区，并将不同的分区自动调度到不同的服务器。为了实现高可用，P1~P8每个分区都会至少存储三个副本，并且部署到不同的IDC机房。每个分区的副本之间通过Paxox选举协议进行日志同步，跨分区事务通过两阶段提交协议实现。

ObServer：OceanBase后台的数据库工作机，用来存储数据并执行用户的SQL请求。ObServer之间无共享，每台ObServer只会服务一部分分区。当集群容量不足时，只需要增加ObServer即可。

ObProxy：OceanBase代理服务器，用户的请求首先发送到ObProxy，再由由ObProxy转发给用户请求的数据所在的ObServer。

RootService：OceanBase会动态地从集群中选出一台ObServer提供总控服务，包括集群服务器管理、负载均衡等全局调度与管控操作。这个总控服务是一个集成在ObServer进程中的模块，称为RootService。

保障双十一稳定的技术支撑体系

图：蚂蚁金服架构与技术体系

规模和场景是驱动技术发展的关键要素。支撑双11最大的困难就在于零点峰值的稳定性保障。面对这种世界级的场景、独一无二的挑战，阿里建设了大量高可用技术产品，形成了全链路一体化的解决方案，用更加逼真和自动的方式，去评估、优化和保护整个技术链条，确保双11的稳定性。

容量规划

阿里有着非常丰富的业务形态，众所周知的如淘宝、天猫、聚划算、菜鸟等，每一块业务背后都有几十个甚至上几百个与之对应的业务系统，每个业务系统都部署在多台服务器上。在如此庞大的分布式系统架构下，该为每一个业务系统分配多少机器，什么时候需要加机器，什么时候需要减机器，该加多少机器，减多少机器，成为一大技术挑战。

阿里采用CSP（ContinuouslyStable Platform）持续稳定性平台，为线上应用稳定运行提供一系列的保障。CSP容量规划平台从业务流量的预测到机器资源的预估，提供了一整套系统化、自动化的解决方案，从容量的维度以最低的成本保障了阿里业务的稳定性。

全链路压测

全链路压测被阿里誉为大促备战的“核武器”。

每年双11前夕，全链路压测都要组织好几次，不断地通过压测发现问题进行迭代优化，全方位验证业务的稳定性，阿里的业务系统也只有在经过了全链路压测的验证之后才有信心迎接双11零点的到来。全链路压测将大促稳定性保障提升到新的高度，是双11、双12等大促备战最重要的“核武器”，并且随着业务的发展不断进化，持续发挥着不可替代的作用。

图：全链路压测生态

全链路验证功能

全链路功能是阿里第一个基于大数据、基于电商交易链路规则建模，进行大促功能可用性验证的项目。随着智能化和智慧化的深入人心，全链路功能搭建并经过验证的基础能力，包括影子数据同步能力、规则模型分析归类输出能力、隔离环境提前验证能力等，正在被越来越多的创新项目依赖和使用，成为创新的源泉。

自动化备战

大促备战通俗来讲就是电商BU下的10多个作战团队（技术团队）在双11前期，通过完成几十种工作序列，让这个由几百个应用系统、数据库、中间件等所组成的庞大的电商体系能够在双11当天稳定地经受住零点大流量的考验，让大家在双11期间顺畅安心地买买买。

逐步将这些工作进一步抽象与串联在一起，如图所示。抽象与串联简单来说要做的就是要串联备战环节的公共节点，从全链路压测链路模型的自动计算，全链路数据准备和流量发送的无缝衔接，应用容量的弹性伸缩，自动化预案执行和验证，高可用业务保障等多个维度将大家共用的工作序列抽象出来，将其中人工的操作自动化，再沉淀为一种公共的基础能力。这样在每届大促备战中就能得以延续与演进，并且也能在日常工作中运用起来，就不是原来的各技术团队相互之间的多样化与定制化的工作了。

自动化备战项目：

实时业务审计

BCP（Business Check Platform），实时业务审计平台，是一个用来实时检测线上系统产生的数据是否正确的系统。试想一下，一个用户刚刚在双11活动下了一单，付完款。但有可能由于网络突然出现闪断，导致他“已付款”这个状态的数据并没有传输过来。如果是以往，有可能呈现给买家的就是“交易失败”的状态。但现在，BCP能在这个问题被消费者发现之前，就开始报警，并且转交技术人员处理。从而可能让用户感受不到“交易失败”曾经出现过。

故障演练

故障演练的基本要求是故障模拟要真实，具有通用性，故障影响要可控，实施成本要低。

由近十个业务部门参与，数百个演练场景设计，数十次大大小小的演习，发现并解决了大量的问题。在对故障做了全面的分析之后，发现除了系统功能类bug和人为失误故障，剩余的故障主要为技术缺陷导致。技术缺陷型的故障原因主要分布在网络、磁盘、进程、CPU、数据库、中间件等诸多大类。故障演练的场景主要就是围绕这几个大类来细化：

故障演练策略主要从故障重现、故障演练、故障突袭三个角度切入，满足不同系统或人的需求。

故障突袭：一种以黑盒测试的模式验收稳定性的演练策略。宏观上，可以通过机房断网、断电的演练，推进架构的改进和成熟。微观上，也可以在大家不知情的情况下搞一些小破坏，观察系统的问题发现、自愈能力，故障处理流程是否合理，或制造更多的机会来锻炼新人的问题处理能力。

系统自我保护体系

系统保护体系主要由5大子系统构成：限流、自动降级、流量调度、负载保护和预案，每一个子系统对应一种典型的系统保护场景。

限流：通过限流让系统工作在最高吞吐量的水位上，防止系统被击垮。限流策略根据请求的被动响应和主动发起分为两种：当请求被动响应时，请求的发起方通常是用户，这种情况下将启用“洪峰限流”策略；当请求为主动发起时，一般情况下为定时任务的执行频度或者消息的消费速度，这种情况下将启用“回调限流”策略。回调限流的实现通过漏桶算法来解决，水（请求）先进入漏桶里，漏桶以一定的速度出水，当水流入速度过大时会直接溢出，通过这种方式来调节请求的处理速度。

自动降级：整个下单链路上不是所有环节都是下单的必要条件。例如，下单时，店铺的“相关物品推荐”、商品评价，这些对于下单这一场景来说都是锦上添花的事情。当弱依赖环节出现不可用的情况，将弱依赖自动降级，可保障核心环节的稳定可靠，在实际的生活中类似于“弃车保帅”的策略。自动降级需要对链路进行强弱依赖梳理，了解这个链路上哪些环节是可以降级的。通过监控可以知道每个调用的响应时间、线程数、异常，这样在调用链路中，如果一个环节不可用对于发起调用的应用来说，是可以自动感知并且探测到的。一旦探测到某个弱依赖不可用，将促发自动降级，让业务请求依然可以往下执行。

流量调度：流量调度，就是要屏蔽所有机器的软硬件差异，根据机器的实时服务能力来分配机器的实时流量。实时服务能力好的机器，多分配流量；实时服务能力差的机器，减少流量分配；实时服务能力不可用的机器，迁移流量。

负载保护：当大部分机器的系统负载处在一个比较危险的情况下，会自动对外部的流量进行限制，减少外部流量进来，缓解系统的压力，自动进行负载保护。负载保护使得系统的每台机器都具备自我保护的能力，当限流阈值设置得不合理或者出问题的机器数超过了流量调度的机器数上限之后，单机的自我保护策略成为保命的稻草。

预案：如果因为系统保护或者其他状态而影响到大量用户的体验，会启动另一个策略——执行预案：提前准备好在各种不同的紧急情况下应该如何面对的方案。

-=end=-

本文主要参阅2017年出版的《尽在双11：阿里巴巴技术演进与超越》中国工信出版社、电子工业出版社。

并参阅知乎文章：《淘宝系统这么牛，网站系统用的什么框架技术？如何演变的？》