618，你秒的不是巨额优惠，是云

今年的“618”，无疑是疫情后消费需求报复性反弹的集中释放，各方巨头积极准备这一场年中大戏。2016年至2019年间“618”参与人次分别是2亿、3亿、3.6亿、4.5亿人，而今年已经超过5亿，交易量也由去年的172亿直接跃升到今年的200亿，支付宝全球日活量预计将突破10亿。

作为一名IT人，笔者最为关心的是，今年的“618”会产生多大的数据量呢？如果对于数据大小没概念的话，这里就举例子，央视各个个频道累计数十年的影音数据加到一起，大概是80P左右。而2019年双11当日，光阿里一家就要处理970P的数据，而今年“618”，阿里处理的数据量预计会超过1000P。

细心的读者也许会发现，作为货币流通枢纽的传统银行在此类营销活动中往往都是缺位的，这肯定不是因为银行业务部门不想做，而是在技术层面，传统银行业的信息系统无法匹配金融云计算，让消费者能够迅速抢到红包、优惠券并在网购中及时应用，这一切的背后，都是云计算在加持。

上云虽好，落地不易

随着应用场景越来越复杂，传统IOE式的集中架构已经难以满足在超大规模计算场景下的需求。同时随着“云”的价值被不断挖掘，云技术带来的快速上线、高效运行、业务的秒级启动等优势也不断被发现。这些都是企业未来快速占领市场，取得领先关键所在，尽快拥抱“云”才能拥有未来。

“云”的价值随着应用复杂性的不断提高，开始慢慢体现出来。但是云时代软件开发的方法论与模式，与之前时代完全不同，因为云最大的特点就是可持续交付和微服务化，完全上云虽然有很多好处，但也意味着巨大的挑战。

分布式与云计算就像一对孪生兄弟，必须要结合使用才能发挥出最大的价值。分布式系统的各节点最好都是整齐划一，这样调度成本都可能会降到最低。而如果出现有的节点算力强，有的节点算力弱，那么受木桶原理制约，系统的性能就很可能被算力最弱的节点所限制。而云这种屏蔽底层，向客户交付标准化硬件的技术，在分布式的架构下就会大显神威。

也恰恰是由于以上原因，我们可以看到主办618这样大型促销活动的企业，往往都是阿里、京东这样的互联网企业。一旦企业有线下网点的布局，在参与红包活动时都需要考虑为网点的发起请求调高优先级，进行区别对待，这种非标准的请求会让系统复杂度呈几何级数增长。
而传统IT行业的IOE架构都是典型的中心化模型，这与云的理念格格不入。也正是因为这个原因，阿里巴巴率先提出来去IOE的口号。但是IOE中尤其是Orcale数据库，已经深度整合到传统IT的业务之中，想进行分布式改造谈何容易。因此，我们看到很多企业由于被中心化产品绑定业务导致无法触云，想完全做到去IOE十分不容易。

秒杀系统技术栈的演进

“618”这样一个短时上亿并发量的场景，即便是世界顶级超算也力会不从心，因此建设这样的系统也必须进行分布式架构的改造。而分布式系统也有一个重要的原则CAP定理。

CAP定理是指在一个分布式系统（Distributed System）中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance），呈不可能三角关系，既三个目标只能同时做到两点，不可能三者兼顾。因为如果满足一致性、高可用性，那么一旦集群内有节点故障，为保证数据一致，必将使系统整体陷入中断。如果既满足可用性、又满足分区容错性，那么必然存在某个节点在系统对外提供服务时出现宕机，而这时各节点的数据一致性又无法完全保证。

结合红包系统的需求分析，系统可用性是要首先保证的。如果活动当天页面无法访问，直接会让用户体验度降到最低，导致用户大批流失。而且在大流量的冲击下，节点故障也是难免。因此分区容错性也需要保证，这样看来，能稍微放一放的只有数据一致性。因此从这个角度上讲，红包的总额必然会围绕期望值上下浮动。

目前分布式系统交易分发，一般有两种方式。一是哈希法，将服务请求序列化后计算哈希值，然后根据这个哈希值将请求分配到不同的节点上。当然直接把请求按照顺序循环发送集群内的服务器，也可以看作是哈希法的变种，不过这会使入口处的负载设备成为瓶颈。二是将所有请求人为分成几份，每个集群只处理自己接到的请求，以此为降低入口流量的压力，但这样的缺点是，很难将请求平均分配。

抢红包这样的系统，只能将以上两种方案结合。首先根据历史经验，将交易量相邻的地区结合，分为一组，比如北京、天津和辽宁、长春分为一组、上海、苏州、南京分为二组等等以此类推，与之对应的云集群，都有自己独立的红包额度，也只处理发给自己的请求。这样既能避免入口的瓶颈，也尽量平均分配了请求的处理量。

接下来每个集群，也会将额度分配给内部的服务器。每个服务器会将自己库存范围内的请求直接标志为成功，并在自己库存范围的基础上，还会多预留一定比例的需求为待定，待统一减库存后再确定待请求能否成功。

从分布式的角度来看，分区域与分库存是系统设计的基础环节，而接下来要做的就是全面上云了。

“618”大促背后的技术点盛宴

做为一个IT人，笔者认为今年”618“最大的技术看点有以下几个：

OceanBase数据库：OB刚刚再次刷榜拿下TPC冠军的OcceanBase，处理峰值也达到了骇人听闻的7亿次/秒，将自己去年创造的6100万次/秒，提高了11倍，而OcceanBase强大的性能也是天猫能扛住双11史上最大规模的流量洪峰——每秒54.4万笔的关键支柱。

正如我们前面所说，一个秒杀系统中有负载、前端分区库、缓存redis、数据库DB与消息队列等若干模块组成，全部上云难度还是非常大的。如果把信息系统比做一个武林高手，那么如此之大的交易量代表了他的刚猛威武，而全面触云又代表他灵动飘逸。而能把刚猛和灵活完美结合简直是神仙才能达到的境界。而在这样的一个云系统中，由基础到上层有以下几个技术点值得我们关注。

神龙服务器:我们知道云计算虚拟化层的损耗是难以避免的，而神龙云服务器其最大的特点就是把虚拟化层的损耗几乎降低为零。随着物理服务数量的增多，性能却一点也不打折，这其中最大功臣是阿里自研的MOC芯片，MOC是专门用于虚拟化层的调度服务，将宝贵的CPU与内存资源由复杂的云调度中解放出来，开创了一种新型的云服务器形式。

神龙能与阿里云产品家族中其他计算产品无缝对接。比如存储、网络、数据库等产品，完全兼容ECS云服务器实例的镜像系统，可以自由地在普通ECS实例以及神龙云服务器实例间变配，从而更多元化地结合客户业务场景进行资源构建。

飞天云操作系统：飞天（Apsara）是由阿里云完全自主研发、服务全球的超大规模通用计算操作系统。据说阿里研制飞天之初有着与Hadoop等开源平台的5k之争，即哪个集群能先调度5000个节点，就算胜出。不过目前飞天操作已经具备将百万级服务器连成一台超级计算机，还能有条不紊地通过云计算向用户提供计算能力。

我们看到在飞天的基础公共模块之上，有两个最核心的服务，一个是盘古，另一个是伏羲。盘古是存储管理服务，伏羲是资源调度服务，飞天内核之上应用的存储和资源的分配都是由盘古和伏羲管理。其与普遍PC操作系统的区别对比见下图：

飞天最底层是遍布全球的几十个数据中心，成百上千万台服务器，把这么多服务器连成一片变成一个整体，真的是令人叹服。

我们知道在618活动时过后，淘宝和天猫等电商平台的交易量将呈明显的回落状态，而神龙服务器与飞天操作系统的相互配合，使得之前为618投入的计算资源，还能进行有效回收，完美展示了云计算的弹性能力。

RocketMQ: 这是阿里自研的开源消息队列，并已经成为Apache基金会的明星项目了。作为高并发系统的核心组件之一，能够帮助业务系统解构提升开发效率和系统稳定性。其最主要功能就是削峰填谷与系统解耦。

相比于其它如rabbitmq和kafka等产品，RocketMQ最主要的优点是支持事务型消息既消息发送和DB操作双方的最终一致性；并且在consumer端支持tag过滤，减少不必要的网络传输。其架构图如下：

我们知道脉冲式的交易量冲击，是非常不利于发挥数据库最高性能的，而RocketMQ消息队列，在秒杀系统最主要的作用就是将交易流量进行削峰平谷，使得OceanBase等数据库产品构成的核心系统的负载量，能够稳定在一个相对比较平均的水平，为核心系统保驾护航，为客户提供稳定的服务。

通过这次618大阅兵，阿里再次通过自研技术证明了自身在云计算领域的技术领导力。上云虽难但是阿里正在用其上云系统的能力，使云不断下沉落地，变成互联网世界空气和水一样的基础设施。未来云计算的发展空间和使用场景还会不断拓宽，未来可期，拭目以待。