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