wordpress透明,沈阳seo公司,网络项目,全网最低价查询网站本篇文章来自于2018年12月22日举办的《阿里云栖开发者沙龙—Java技术专场》#xff0c;梁笑专家是该专场第一位演讲的嘉宾#xff0c;本篇文章是根据梁笑专家在《阿里云栖开发者沙龙—Java技术专场》的演讲视频以及PPT整理而成。 摘要#xff1a;2018年双十一平稳度过#…本篇文章来自于2018年12月22日举办的《阿里云栖开发者沙龙—Java技术专场》梁笑专家是该专场第一位演讲的嘉宾本篇文章是根据梁笑专家在《阿里云栖开发者沙龙—Java技术专场》的演讲视频以及PPT整理而成。 摘要2018年双十一平稳度过海量订单、零点流量高峰阿里是如何实现供应链99.9%的下单成功率本次分享中阿里2018年双十一大促供应链服务保障平台负责人向大家详细阐述大促前4个月的全程经历。面对大促第一步需要做什么流量峰值如何评估性能优化从何处着手一套有条不紊的供应链服务平台迎接大促的解决方案至关重要。 演讲嘉宾简介
梁笑阿里新零售供应链平台事业部擅长 Java、Spring、OOP、分布式、架构设计参与过供应链服务决策平台、双十一大促等项目对业务开发、大促保障、架构设计等有所涉猎。 本次直播视频精彩回顾戳这里
PPT下载地址https://yq.aliyun.com/download/3183
以下内容根据演讲嘉宾视频分享以及PPT整理而成。 本文围绕双十一大促历程从以下几方面介绍供应链服务平台如何迎接大促
1. 概述
2. 梳理链路
3. 峰值评估
4. 容量评估
5. 性能优化
6. 依赖改造
7. 保障协同
8. 压测检验
9. 项目协同
10. 监控治理
11. 战前准备
12. 总结 一、概述
大家熟悉的供应链服务包括库存控制、计划调拨等这里介绍的供应链服务更偏向于交易侧。例如在淘宝或天猫购买物品时会有今日下单预计某日送达等物流提示这种物流时效承诺即是由供应链服务平台提供。再如购买电冰箱、空调等大件需要预约配送时需要选择指定的配送商或者货到付款、拆单合单等物流透出都需要供应链服务平台的支持。除了这些大家作为消费者可以直观感受到的服务外商家的商品入库发货等操作也都离不开供应链服务平台。因为大促时物流服务需要实时透出服务平台是需迎接双十一实时下单的高流量的此外服务平台还需要承接物流发货的服务透出例如发货的仓库、路线、发货时效及服务等。因此供应链服务平台在阿里体系中扮演了一个上承交易、下接物流的腰部力量主要包括物流服务、物流透出、商家订购、容量管控等功能。物流服务及物流透出上述已提及商家订购包含仓订购和快递资源订购容量管控是指物流干线的容量能力例如从北京到上海可以在当日送达的物流能力为一千单超过一千单外的便无法达到这样的物流时效诉求。至此大家应大致了解了供应链服务平台的概念。
供应链服务平台保障的过程如下图所示 如何在业务容量峰值时保障系统该采取哪些措施这是一个不小的挑战。首先需要分析出哪些接口需要重点保障哪些薄弱点或性能低下的链路需要重点评估。接下来需要对这些进行优化操作。然后对优化后的接口通过自测或压测进行验证。验证过程中可能会发现已有的问题解决了但是出现了新的问题这就需要再次分析优化。这是个螺旋上升形的过程。上图右侧是保障过程的阶段描述会在接下来进行详细阐释。 二、梳理链路
如果给你一个系统在你不了解的情况下让你在流量峰值下保障系统的稳定性首先你需要明确要做的事情清晰目标任务的范围。因此第一步就是梳理系统业务的链路对系统有宏观全面的认识这是保障大促稳定性的前提。但是以服务平台的现状来说有以下几个通病祖传代码、上古应用、文档缺失、无人可问。阿里的服务平台自2011年开始经历过三次较大的升级改造每次升级大部分核心功能会下架升级但仍有某些小功能无法改造。这就造成在2018年的大促保障时还需要阅读2011或2012年的代码甚至某些应用都无法打印日志。文档缺失、无人可问也使系统保障更加困难。
梳理链路可以分为以下四步进行
1. 梳理对外接口。在日常开发中主要的业务逻辑代码大约包含四五个对外接口但是通常来说实际会比这要多。在对服务平台的链路梳理中新老三版系统包含大约80多个对外接口。但在实际工作中只会涉及十个接口左右。可见这些接口存在巨大的冗余。某些接口可能已不再使用或某些接口有使用者但使用者并没有意识到在调用该接口。因此梳理对外接口就是梳理出接口是否在实际提供服务。
2. 移除无用接口。在剩下的70多个接口中一定有无用的部分移除这些接口也是移除了潜在的bug出现。这可以通过查看调用者、分析流量或者咨询使用者来进行移除。在这个阶段阿里的供应链服务系统大约下架了近40个废接口如此大幅缩小了需要保障的系统范围。
3. 梳理剩余接口。这个阶段中将各接口按照重要性进行保障力度的划分例如某些接口是需要重点保障的而某些接口无需重点保障不应占用宝贵的机器资源、数据库资源等例如一些查询功能的端页面在大促时出现问题也不会产生重大影响。
4. 确认强弱依赖。对划分出的需要重点保障的接口需再次梳理出相互间的强弱依赖关系这就需要理清系统的业务逻辑。例如在阿里的大促系统中如果库存出现问题那么紧接其后的订单、配送等接口也都会混乱这便是一个强依赖过程。因此这里应设置成如果库存出现问题下单只能返回失败。弱依赖过程则不同例如根据历史数据得知某消费者经常使用某一个自提站点如果在大促中自提站点的链路挂掉分配的不是这个自提点虽然这可能会导致消费者的愉悦感下降但下单过程不会产生太大的问题。此外还需对接口的调用量和调用比例进行统计梳理例如调用一次A接口可能会在下游调用一次或若干次B或C接口通过这个比例可以根据A接口流量的增长幅度计算下游的接口流量。
如此梳理完成后便可以产出一份链路文档大致掌握了需要重点保障的部分、可能的调用方、可能的消费者、消费的量级、涉及的数据库、缓存中间件、链路的强弱依赖等信息这是后续工作的纲领性文件。 三、峰值评估
在有了这份纲领性文件之后则需要明确任务目标。对这样实时下单的强依赖系统来说最直观的的目标是要支撑住双十一零点的交易峰值。这就需要评估这个交易峰值是多少毕竟每个系统被核心的交易系统调用的频率并不相同。峰值可以根据交易下单量、业务预测和历史经验来进行评估。交易下单量相对来说确定性较高因为这在系统内部可以通过限流解决。当下单量超出了系统的承受力则直接返回下单失败让消费者再次下单即可。因此每秒的最高下单量是相对确定的值。业务预测是指对每个行业线的下单量进行预测。即使知道每秒的下单总量却无法知道例如天猫超市或者某个行业线的细化下单量那么便收集该行业线下的店铺信息再根据一些专业知识进行评估。这样的业务预测值是缺少瞬值的例如它可能可以预测出一天的单量但无法预测0点那一秒的单量。因此还是需要根据历史经验来弥补这个缺陷。例如根据前三年的大促流量分布、双十一前的三八大促九九大促流量分布等数据进行流量预估得到流量漏斗。甚至在大促前对某些链路进行了改造变更等操作的也需要在流量预估的过程中详尽考虑。由上述可见在这样输入有限的情况下需要抽丝剥茧得出一份可能性较高的峰值评估。 这样的峰值评估主要为两方面如下图所示。一部分是接口峰值这会用于指导保障整个系统。例如若下单量为十万那么商品详情接口大约会产生三十万流量渲染下单接口十二万到十五万真正下单扣减约七到八万这些值会指导进行系统下单时的重点保障。另一部分是行业峰值。例如下单量为十万时快消品牌和美妆产品各自的单量为多少这会直接显示出系统各行业所需要的下单承受能力。 四、容量评估
确定了任务目标后就需要评估现有的机器容量是否可以支撑预估的流量峰值。阿里的供应链服务平台是一个单元化的应用可以理解为一个跨城市跨机房的异地部署过程。每个单元机房有不同的流量承受能力例如可以在华北设立机房承受30%流量华南机房承受30%流量华东机房承受40%流量。接着通过压测等方法可以方便的得出单机性能测试出健康情况下单机的QPS流量。例如UNSZ深圳单元需要承担6.52%的流量结合单机性能预估需要的机器数量根据比例得出预估QPS值。接下来需要考虑现有的机器能满足预估状况嘛是否有缺口如果存在缺口是可以通过优化还是申请预算解决呢最短的木板压力最大的部分是哪里因为各个机房的实际性能存在差异这部分差异也需要考虑在内。根据最短木板确定限流保护值重点保障最危险的单元。此外在容量评估时最好预留一定的buffer保障可能超出的流量。 五、性能优化
基于已有的机器预算和之前梳理出的接口链路接下来需要一些手段优化性能来支持峰值流量。不仅包括对古老代码的优化也需要对新产生的代码进行改进。下图展示了供应链服务平台的大促性能优化中采取的主要手段 这些细节化手段这里不再赘述大家可以参考一些web技术文档即可了解这里重点为大家介绍如何梳理上述优化过程。没有一个整体的方法论贸然入手消耗的精力暂且不谈达到的效果可能也不尽人意。这些优化手段主要通过分析阿里的业务特点及双十一的玩法特点得出。例如若某一地区的仓配产能不高无法实现物流时效承诺那么撤下物流时效承诺的同时与其相关的链路也可以一同撤下这便大大提升了这一块的性能。因此提升性能不只是通过内存调优等也可以根据业务逻辑来调整。优化的各个步骤如下
1. 减少流量。在客户端或服务端屏蔽流量降低不必要的调用这样的性能优化效果最为可观。
2. 移除或降级IO。根据业务需求尽可能的下线无用的IO逻辑或者根据业务特点降级部分IO。
3. 减少IO调用。例如在货品查询IO中可能会采用多个for循环来进行查询那么便可以采用批量查询来代替单个查询。
4. 移除本地IO。移除和检查没用的日志和滥用的日志。某些debug代码在平时产生的流量不会引起大家注意但是在全链路压测验证时就可能产生非常多流量以致线程卡住。
5. 使用缓存。短时间内数据不变的情况下进行缓存避免多余的IO。这种方式在大促时效果尤为明显。在电商行业类似某个店铺与货品的绑定关系在大促时间内基本不会变化这种不变的数据使用缓存效果最佳。
6. 缓存命中率。在平时缓存可能设定失效时间为几十分钟但是大促时可以禁止该类影响稳定性的操作将失效时间设置为几个小时甚至十几小时。拉长缓存失效时间可以极大的提高缓存命中率平时的命中率大约在60%-70%左右在大促时这个数据提升到了99.99%。此外还需要充分预热。
7. 缓存吞吐。除了本地缓存外大家可能都会使用远程缓存例如redis等。阿里巴巴使用tair缓存对其序列化方式进行了修改。java自带的序列化方式性能较差得到的序列化对象也字节较大因此将其改成了Hessian方式没有选择kryo或protobuf是因为当时转换成Hessian方式最为简便。同时精简字段假设某个返回对象有十个字段但对外接口只需使用两三个。大家知道带宽一定的情况下单个数据量越大同时能通行的数据就越少。流量峰值时带宽通常都会比较紧张那么便无需将剩下的废字段也存入缓存。进行了上述改进缓存的吞吐有了很大程度的好转。
8. 本地缓存。尽量使用本地缓存在tair前挡一层避免网络IO。本地缓存不可能存太多但是在某些极限情况例如卡券类或红包等当天调用极其频繁并且不会变化这样的数据可以缓存在堆外内存中。
9. 数据库。在解决了数据IO的大部分问题后便可以采取一些更细致的优化手段。例如检查慢的SQL索引使用是否正确有没有离线拖库任务是否可以清理一些碎片等。
10. 本地代码。去掉高频率低效的本地代码。但根据经验这种手段得到的优化效果有限。
因此纵观整个优化思路减少IO和使用缓存是优化性能的效果较为明显的方法。 六、依赖改造
在性能优化后大致不会在峰值时出现宕机的情况但仍需要进行强弱依赖的改造即强依赖改为弱依赖弱依赖改为强依赖。强依赖是指如果对兄弟系统、数据库或缓存的调用出现问题那么流程直接中断。弱依赖指即使这部分宕掉可以直接设置超时或者熔断并不会影响流程的后续。强弱依赖的改造其实是一个兜底的过程。将某些错误的强依赖改为弱依赖使其不会影响核心流程防止雪崩。其次将一些弱依赖改为强依赖。第一种是确定性的依赖更改。例如如果下单成功需要将扣减库存数量如果库存数量没有扣减成功会导致后续各种问题如果之前采用的措施是将这个异常catch住继续后面的流程那么这里就需要更改为抛出异常阻断流程。第二种是下游重依赖的数据。第三种是可能会造成资损的数据。强弱依赖更改实际上就是对业务负责和保障的过程。 七、保障协同
作为系统的负责人做到上述性能优化等工作对本系统来说足够了但是其他兄弟系统的保障协同也是重要的一环。在阿里每次中间件大规模要求升级时大促也就近了。供应链服务平台重度依赖的其他系统例如商品中心、库存中心、订购中心和容量中心等也各自针对大促做了不同程度的优化。例如商品中心预热手段发生了变化重点流量做出分组操作并专门留出了部分机器给服务平台系统做流量分割。库存中心升级了新模型改进了缓存等那么服务平台系统也需要针对这部分进行相应的协同。和订购中心的协同主要在预热和防雪崩假如宕掉时间过长就避免调用数据库而去调用缓存。容量中心之前只支持单个扣减 现在可以支持批量扣减或者修改了表结构。这些兄弟系统诸如此类的优化也从侧面使得服务平台更加健康。 八、压测检验
完成优化和协同保障后当然需要压测检验。在双十一期间总共经历12次全链路压测因为无法再造一个全链路系统所以只能使用真实系统压测。为了不影响真实系统的运行和消费者的感观压测通常在半夜进行。在压测过程中发现了不少问题这里举出以下三个例子 1. 本地线程池满。jstack查看线程堆栈时发现很多线程卡在logback输出日志的地方。查看源码后发现是使用log.error打印了一个很大的JSON对象且每次调用都会打印这就造成本地线程池立刻满了。因为系统较老依靠个人的代码review无法发现此类问题这就需要压测这种真实的流量手段来发现。
2. 超时请求。鹰眼阿里全链路监控系统发现有一个长达3s的请求一般请求为毫秒级别检查后发现是该部分数据缓存未预热查询数据库超时引起。因为该部分数据在大促时不会调用因此在压测时是可以提前将其撤下的。但在压测时出现这个问题可能会影响到其他业务的稳定。
3. Jmap超时。阿里的服务平台通过手工执行jmap命令触发GC来释放内存发现在执行jmap时会先下线对应服务对应的机器仍然对外服务并且大多超时。查看了对应的下线脚本后发现由于镜像升级导致Linux命令输出与老脚本预期不一致。这也影响了线上服务的稳定。
上述问题只有压测验证才会检查出来因此压测的意义不容置否。每一次压测都是对上一轮优化结果的验证同时每次压测发现的问题也是下一次优化的主要方向。 九、项目协同
服务平台内部的工作同事便有10人左右更要包括对外的例如中间件的部门、依赖和被依赖的兄弟系统部门。人员众多导致各种协同问题的产生这就需要一个协同机制。需要明确每个项目的负责人有固定的联系方式。任务拆解要细致每个部分的任务交给指定的人解决。另外需要文档沉淀得出的文档不仅是这次大促的回顾总结也是下次大促的一个参考。2018年的大促能够完成也是依靠了之前的多次大促经验文档。验证考核也必不可少验证此次的优化是否达到了设定的目标。某些在测试时没有显现出的问题会在真实的流量下被发现因此事后的验证考核会帮助发现更潜在的bug。最后风险识别某些问题可能因为历史原因无法修复那么这种问题要识别出来和业务人员或产品人员共同找一个可以弥补的方法。例如可以将由于这个bug产生的问题订单使用工具单独抛出再行安排。这些都是作为一个项目PM需要注意的重点。当然如果能有一个项目间供大家face to face探讨各种问题是最好了。 十、监控治理
传统意义上的监控治理有两个诉求看图和告警。看图主要关注各类曲线是否有波动是否稳定等告警是在产生问题时可以通过短信、邮件等方式告知。除去传统的系统监控指标例如GC次数、内存使用率、QPS高低、系统反应时间还需要业务监控这需要通过日志或离线采集进行统计如此才能对系统和业务都有直观的认识。当然“会出错的事总会出错”过程中难免会出现问题。如果出现问题则需要及时统计产生影响的商家数量、单量、消费者数量以便后续紧急处理采取拉单、扩容或下线服务等手段防止过大损失这便是消防处理。 十一、战前准备
所有优化和监控措施完成后大促开始前1-2天按部就班执行各类计划动作。首先是执行前置预案例如下线了某些业务链路要执行观察效果。其次是预热在大促前一天将一切准备就绪准备迎接峰值流量。接着进行一致性检查单元化的核心应用涉及到成千的机器可以通过计算MD5校验值来确保所有的机器上的zip、jar、war包等是一致的。然后资源检查对于大促当天的数据库、机器、中间件、内存等资源做一个检查确保资源到位。清理数据库如压测使用后废弃的表可以删除。最后jmap释放内存将可能会触发GC的内存全部释放。 十二、总结
回顾整个大促过程今年的供应链服务平台比去年更加稳定核心下单链路成功率接近99.9%没有发生限流等严重影响用户体验的情况。从8月开始思考双十一的筹备工作整个大促保障期间涉及到众多的系统、人员和业务每个系统和业务分别由不同的团队负责需要做链路分析、模型分析、容量评估、目标评估要协调和明确各节点间的职责划分、要做各类优化、压测、监控和反馈等等持续了长达三四个月。
“这个过程是一次人与人、人与对象间的碰撞精密的仪器产生完美的作品。” 原文链接 本文为云栖社区原创内容未经允许不得转载。
