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

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

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

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

上云虽好，落地不易

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

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

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

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

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

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

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

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

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

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

文章知识点与官方知识档案匹配，可进一步学习相关知识算法技能树首页概览34475 人正在系统学习中