大家好，我是李弟兄。自从加入阿里，就听过一句话：“没有经过双十一高峰验证的技术就是玩具”。虽然有些夸张，但不可否认的是，一年一度的双十一是技术最好的孵化器，也是技术同学最向往的阅兵场。很荣幸成为今年年中晋升的技术一号，也就是技术总监。今天就和大家聊一聊我们作为技术人员在大促中需要做哪些技术支持，以及如何做。也希望大家看完后，有身临其境的感觉，有一种大大的提升。我把故事分成三个部分：事前、事中、事后，最后我们总结一下。1.Pre-KOmeeting首先，在提前，我们做的第一件事就是参加KOmeeting（KickOffMeeting，项目启动会）。主要传达以下信息：大促的背景和意义、大促的目的、目标业务的具体玩法、大促在特定时间的人员组织架构。也就是说，在这里，我们的技术需要从中获取以下信息：business预期的DAUbusinessDAT的具体活动和玩法是什么？活动的具体时间段是什么？哪些产品将参与大促？有没有第三方产品？这些产品的存货量是多少？一些细节需要跟业务沟通，比如活动粒度是多少？有多少宣传？如何评估业务的预期DAU和DAT？它准确吗？等待。这一步的目的是为了确认您的信息是否正确，以及了解一些细节。流量测评需要清楚当前阶段的日流量、DAU、DAT是多少，业务侧测评多少，技术侧测评多少，现阶段的表现能否支撑即将到来的大促，如果没有，需要做哪些调整。优化？如何优化？优化哪些业务？现在优化还来得及吗？扩张？应该扩展哪些服务？能扩容到什么程度？为什么要扩展到这么多机器？降级？哪些业务降级了？业务是否支持降级？什么时候降级？问题这么多，看来现在业务也需要梳理一下了。业务梳理我们需要梳理哪些业务是核心业务，哪些业务是非核心业务，哪些业务是可降级业务。这样的数据，从上次的大促中就可以大致得到。加上上次大促产生的新项目（业务项目或技术项目）梳理到本次大促，会不会影响到核心环节？是否进行了压力测试？压力测试结果如何？这些项目可能存在哪些技术风险？你的服务依赖哪些下游服务，这些下游服务如何依赖，是一件很麻烦的事情，因为随着业务的增长，依赖关系会变得非常复杂，很难判断和梳理。虽然困难重重，但这个依赖还是需要理清的。只有整理好了，才有完整的链接。压测有业务排序，有业务指标，所以在技术上必须能够支持这一层的业务，那就是压测。目前压测的方式有两种：不扩容压测和不扩容压测一般不推荐。该方法需要将业务指标贴现作为压力测试的目标。最后，扩容时仍需进行压力测试。曾经，因为分压测试不能完全代表整体压测，如果整体压测出了问题，那么所有的局部压测都白费了。扩容压力测试是指扩容到大促支撑位，再进行压力测试。值得注意的是，压测一定要针对生产！有同学对开发环境、测试环境、预发布环境、灰度环境、模拟环境进行压力测试，推断生产环境的性能。这是绝对不可取的，因为环境不同，服务器的性能不同，DB在生产环境中的性能与其他环境中的性能不同，一些中间件的性能也不同。所以压测必须在生产环境进行，但是有个缺点就是会影响线路的正常通畅，这是不可避免的。因此，一般在流量不大的情况下进行压测时，尽量将对正常流量的影响降到最低，一旦有影响立即停止压测。另外，压力测量需要流量爬坡。切记不要一步完成。按一定比例逐渐加压。观察每个斜坡几分钟。如果没有问题，继续施加压力。到达目标后，观察几分钟，直接停止测压。爱打架！为什么不爱战争？因为大促的流量趋势只有几分钟，长期的压力会对服务器的性能造成一定的影响，比如CPU飙升，频繁GC等，所以需要持续观察整体压力测试期间系统的性能。有时也会影响用户的正常访问。例如，在奥林匹克举重比赛中，你只需要举起三秒钟。训练的时候一定要举三分钟吗？至于压测，我们后面会单独进行一篇文章，这里就不多说了，敬请期待！限流压测完成后，我们需要输出压测报告，比如店铺支持多少qps，订单页面支持多少qps，订单支持多少tps。这些数据显示了我们的系统有多少个实例，以及哪个接口可以承受最大的峰值。那么我们就需要对这个接口或者这些接口进行限流。这里说说单机限流和集群限流。单机限流是指对每台机器自身进行限流，集群限流是指对整个服务集群进行限流。单机限流的目的是保护服务本身，保证自身服务不会被流量压垮。集群限流的目的是保护下游服务，保证下游服务不被当前服务淹没。比如A->B->C，每个服务三个实例，整个B集群最大支持150qps，C集群最大支持100qps，也就是说B服务需要设置一个集群当前100qps的限制，保证C和B三个实例需要设置50qps的单机限流，保证不被压垮。因此，如果流量不倾斜，服务B的每个实例将有33qps，如果倾斜，则最大为50qps。我们又回到了大促的限流状态，所以需要拿我们的压测报告，对我们的服务做单机限流和集群限流。降级限流后，我们可以保证服务本身不会被压垮，下游也不会被压垮。然而，这不是我们的目标。我们的目标是确保大促期间细节没有问题，下单付款没有问题。！因此，我们需要对一些性能密集型服务和一些边缘服务进行降级，为核心服务让路。那么我们需要对这些业务进行梳理。哪些业务需要降级？什么时候降级？谁会降级？什么时候恢复等。应急预案和演练在确保核心环节正常后，还要考虑异常情况。对于电商系统，需要考虑整个生命周期出现异常的可能性，例如：商家详情页面打不开、订单渲染页面打不开、下单失败、合同履行失败等等等，我说的比较笼统。我们当时准备了上千个方案！为了安全起见，淘宝双11大促不会依赖外部系统，因为第三方系统经不起淘宝大促期间的流量浪潮。如果你的电商系统依赖于外部系统，那么你需要梳理好哪些渠道、哪些产品会参与这次大促。这也需要对渠道进行压力测试和限制。可能是系统小，频道不适合。支持压力测试。这时候你可能要在履行合约的时候考虑蓄洪和泄洪，用真实的流量冲击通道来测试通道的性能。另外，在第三方参与的情况下，每个渠道都要有应急预案，展示给用户的文案是不一样的。最重要的是和合作伙伴制定一个SLA（ServiceLevelAgreement）：ServiceLevelAgreement，服务提供商和客户之间的协议，用来确定需要的服务和期望的服务水平，对于互联网公司来说是一个保证网站服务的可用性。在这里，SLA规定了客户对合作伙伴在线运维、计划运维、业务连续性和故障处理能力的要求。完成计划后，需要通过计划平台进行演练，或者手动演练。熟能生巧，只有在大促中出现问题，才会显得岌岌可危。监控大促问题？你怎么知道这件作品有问题？这时候就需要监控和报警。大促监控、全链路监控、核心链路监控、压测监控、限流监控、资源监控、网关监控、通道性能监控……在大促期间，需要制定很多规则，比如发布红线、红线问责、预案实施规范、紧急扩容规范、紧急发布规范……这里统称为大促变更规范。没有规则，制定这些规范的目的是为了让我们明确在出现问题时应该遵循什么样的程序来处理突发事件。还有很多杂七杂八的东西，比如大促前的周会，大促值班人员的调度，大促的作战室，问题上报系统等等。至此，我们有了一切准备就绪，我们只欠东风。2、中间的事情是整个过程中最简单、最短的阶段，但简单并不代表不重要。主要注意以下几点：大促的重点节日会记录大促的节点。大促的问题记录会集中在告警和监控问题上。按照预案和预案规范，按照问题上报规范严格控制大促期间的版本变更和数据变更。为避免影响大促日会，最重要的是要持续关注告警和监控。一旦出现问题，要及时应对和止血，严格按照预案执行。另一种是关注大促每个时段的峰值，通过自动记录或手动记录记录峰值，方便作为下次流量评估的依据。3.活动结束后，我们最重要的是对大促做一个回顾，盘点大促期间的一些好点和坏点，以及如何将好的点延续到下一次大促或更好的，不好的地方如何调整。业务方面，关注哪些产品在哪些领域卖得更好，哪些玩法更容易被用户接受；在产品端，需要重点结合业务对现有产品模型进行一些调整和优化；在技??术方面，专注于性能。大促中是否存在性能瓶颈，瓶颈在哪里，如何优化，是否需要调整架构，如何支持下一次大促等等。二是降级恢复。大促前的降级需要在大促后恢复。我们还需要不断优化和改进系统存在的性能问题，然后进行压力测试，得出结论，重新优化，然后压力测试，优化，压力测试，......Summary&Outlook大促前：KO大会、大促周会、详细沟通、流量评估、业务梳理、压力测试、限流、降级、计划、演练、监控、规范。大促期间：值班、记录、关注告警监控、执行计划、执行规范、日常例会。大促后：审核、降级恢复、持续优化、持续压测、持续发布。每一次大促，如何保证系统能够承受峰值并保持长期稳定，是每一个大促人都必须面对的问题。推广期间出现的每一个问题都可能被无限放大，所以我们需要谨慎，这不是开玩笑的。
