前言

每年的双11都是一个全球狂欢的节日，随着每年交易逐年创造奇迹的背后，按照传统的方式，我们的成本也在逐年上升。双11当天的秒级交易峰值平时的近10多倍，我们要用3-4倍的机器去支撑。但大促过后这批机器的资源利用率不高，到次年的双11会形成较长时间的低效运行。试想一下，电商交易有大促峰值，而阿里云有售卖Buffer，如果能充分发挥云计算的弹性能力，让资源可以两边快速腾挪，就可以解决资源浪费的问题了。把我们的交易单元可以部署在云上面，那么大促的时候我们只需要按照压测模型去云上构建一个符合能力的新单元即可，用完马上释放掉，这样无疑是最优雅的。专有云+公共云 的混合云弹性架构成为一种自然而然的选择，不但可以资源合理利用，降低成本，同时也锻炼了阿里人的的技术能力，为用户提供更优质的服务。

有了架构思路，实现起来似乎也没那么容易。阿里的交易涉及几百个系统，他们之间的依赖错综复杂，如果能够把他们快速的搭建在云上？这次系统之间的依赖如何复杂，如果把他们的容量估算好，快速调整他们的容量水位？这就不得不提到下面的两个秘密武器了：一键建站和弹性容量交付

一键建站

1.1 背景

一键建站是在底层基础设施交付的基础上，快速地在一个空机房部署交易单元，使新机房迅速具备对外提供服务的能力。一键建站的逆过程叫一键下站，即迅速切除单元流量，释放所有单元内应用的物理资源。

从架构的层面看，一键建站的基础是阿里电商体系的异地多活。从运维的角度看，一键建站是运维产品的升华，更是运维效率的核心体现。

一键建站第一次被提出是在2014年，但由于系统多，依赖复杂，加上中间件的复杂性，当时新建一个单元需要耗时近1个月的时间，更是需要所有单元链路上的运维同学参与。去年，DB实现了一次完整意义上的一键建站，中间件的建站实现了半自动化，但是应用的建站过程仍需要很多运维同学的支持。今年，一键建站进行了重构，并提出一天（8小时）一单元的目标，在几乎不用运维同学参与的情况下，顺利支持了3个云单元的建站工作，最快一次耗时6小时建站。

1.2 挑战

今年的双11单元架构是三地五单元，一中心四单元，也是第一次遇到同机房两单元。如何控制单元内的链路封闭，单元与单元、单元与中心的同步与可见性，是异地多活的大挑战，也是一键建站的难点。

首先需要明确单元内部署什么。建站需要维护一份知识库，包括单元的数据库，中间件，统一接入，以及导购、商品、店铺、交易、会员等一百多个应用。需要知道每个产品的服务器配置，软件配件，容量需求，甚至是应用间链路依赖等相关信息。这份知识库会跟随日常运维操作，调用链路日志等不断更新。同时，一个完整单元不仅仅包含线上环境，还需包含预发环境与小流量(测试环境)，每套环境都有自己的一份知识库。

其次是需要明确部署的每个步骤实现。单元内的每个产品，都需要明确部署的操作细节，以及产品之间的前后依赖。今年，一键建站第一次在云上实施，面对全新的服务器资源(ecs)，全新的网络资源(slb)以及全新的部署方式(docker)等，每个环节都需要技术落地。由此可见，一键建站是一个庞大的系统，几乎涉及所有的运维产品。

在明确了建站数据与建站步骤的基础上，还需要有一套技术实现能将单元内所有产品相关的近四千个部署步骤串联起来，这就是建站系统。追求建站效率的同时，安全始终要铭记于心。建站的每个步骤，都需要考虑可能出现的突发情况以及应对策略。

1.3 技术架构

一键建站是一个体系的构建，是要在原有运维产品的基础上进行升华，将相关产品的原子性服务联动起来，最终凝聚成一个按钮。

一键建站涉及的单元产品种类繁多，相关操作保罗万象，而且变化极为频繁。如果为每类产品写死操作流程，那建站只会疲于代码，即使完成了代码，也只会是一次性的玩物。因此建站需要更多的考虑灵活性，在最终的技术实现上，将系统架构分为四个层次，原子服务、功能组件、组件编排以及流程调度。系统架构如下图：

1.4 原子服务

建站平台的能力来源于周边的运维产品，接入相关系统的服务，将最小粒度的一次服务调用称为一个原子操作。服务网关包装一系列原子操作，以提供上层业务调用。

作为唯一的外部系统调用入口，服务网关还需要做统一的日志记录，业务链路跟踪以及故障告警等。

对建站平台的效率要求，很大一部分最终会落在外部系统服务上。最具代表性的是服务器资源申请与docker镜像，这两条链路的背后，凝聚着很多人努力的心血。

1.5 功能组件

功能组件，是将相关的原子服务进行整合，从而形成的一个个有业务含义的独立功能模块。比如创建服务器、添加帐号、创建vip、docker upgrade、应用启动、更新hsf路由等等，将近百个原子服务最终聚合成三四十个功能组件。组件的实现需要能保证幂等。

功能组件需要遵循一定的规范，从而使得同一组件能被不同的应用，不同的流程复用。

1.6 组件编排

组件编排是建站灵活性的核心。建站平台支持在web页面动态编排功能组件，从而组装成一个个可以运行的流程。单元内的每类中间件或应用都可能存在部署上的差异，通过服务编排，使每一类产品都能对应到一类流程。

建站需要涉及整套中间件以及一百多个单元应用，这些产品在部署启动上还存在先后链路依赖。去除弱依赖，将单元产品依赖描述成一张无环有向图，每个节点代表一个产品的部署流程。将整张图描述成一个流程，这个流程就是建站流程！

1.7 流程调度

流程调度是建站稳定性的有力保障。流程调度负责建站流程的分布式执行，是流程引擎的一个实现，至少需要达到下述几点要求：

1. 高可用。服务器宕机不能影响流程执行；
2. 系统容错。下游系统异常诊断，自动重试；
3. 并发访问控制。流程节点不应该同时在多台服务器被调度；

在结构上，流程调度可以分为流程实例管控、任务队列、任务调度、组件执行器与分布式协同组件等。每个节点按照自身的负载情况加载流程实例到本地任务队列，组件执行器负责每个组件的入參注入，出參收集以及反射调用，分布式协同保障同一时刻仅有一个节点在调度流程实例。

一键建站流程是一个包含众多子流程的嵌套流程结构，建站时，流程调度需要同时执行上千个流程。

一键建站只是完成了最小单元的建站工作，如果想让这个单元支撑好大促的流量，还需要对这个单元进行容量评估和扩容，如何快速的评估各个应用的容量并自动扩容呢？这时就需要弹性容量交付出场了。

弹性容量交付

今年弹性技术在实时容量评估算法上作了一定的改良，期初主要出于提升效率，最大程度地降低实施成本,与保障集群稳定性的目的: 更加智能，使用在线机器学习实时测算应用性能变化，并可作出简单的故障原因分析, 通过算法对各个单元的应用集群进行自然水位拉平。
1.如何用机器在无人介入的情况下，预测应用集群各个单元的性能；需要做很多事情：日常性能变化测量；应用发布性能变化测量；集群中单机的性能变化预测，与目标交易量下会有多少比例机器挂掉的预测，容量问题还是性能问题的判断等等等等。
2.为支持XX笔交易的业务目标，需要多少资源；或者说，现有XX些资源，最高可以支撑多高的交易量?
3.一个应用集群在什么样的物理资源利用率下稳定性与成本会是一个最佳配比?

4.资源预算

我们先简单以一个在线web服务类应用进行分析，在线电商每天的流量波动与资源利用率是存在一定的关系的(当然也可以换成其它指标进行测算)，我们将两项指标叠加，呈散点图形态：

现在假设，我们设定资源利用率阀值为70%的cpu利用率，预测该应用集群的服务能力，我们利用上面呈现的散点图做一次拟合，延长趋势线，呈以下形态:

则求出，该应用极限能力在X%的资源利用率下的服务能力大致是Y。

但实际场景中，情况要复杂得多，在不同压力下，随着物理机的利用率整体饱和度的上升，性能会有一定的损耗，将不同压力下测算的服务能力记录，并作一次回归，预测出目标压力下，大致损耗度，并用刚才计算好的服务能力减去目标压力下的损耗度即可。

那下一个问题来了，应用集群的资源利用率多少为极限值？这里只是一个假定，每个应用集群的极限能力都不相同; 首先前文已经提到，由于各个应用集群布署的物理机坑位不同，有可能超卖，也有可能会与资源占用多的应用布署在同一个物理核内，超线程会带来一定的影响，而一个物理核通常分为两个逻辑核，是否一个物理核的总能力/2则为两项占用该物理核逻辑核上的能力；假定100%的资源利用率为满负荷，则两个逻辑核各分50%的能力相对合理?

但实际情况是，占用两个逻辑核的应用集群利用率，在容量层次不齐的宏观情况下，有的偏高，有的偏低，这就会出现资源抢占问题。

如何识别某项应用集群合理的资源利用率是多少？ 我们需要做一些事情，即除了对整个应用集群作上文中讲到的资源测算，还需要对每台单机作能力测算，这里我们随便拟定一个值，如单机负载如果超过80%是不可承受的，则我们在整体全链路压测时，会对每台单机做实时的负载预测，看在目标交易量下，多少比例的机器会超过最大的承受能力，该集群的总qps会有出现多少比例的损耗。 这里假定我们认为不允许有机器出现这样的情况，则当某台机器预测值达到最大承受能力时，则认为当前集群能力的合理负载应该在多少。

根据上文的描述，我们可以直接拿到测算好的各个应用集群的容量配比进行在线备容即可.通过后续每次的压测，对各个应用集群的预期资源利用率进行逐步逼近，最终达到整体备容目标。

正因为有了以上两个秘密武器，我们在双11之前就快速的做好了容量准备，同时双11一过，我们立刻对云资源进行一键下站，把资源归还到云的Buffer里，对公共云进行售卖。