共计 5008 个字符，预计需要花费 13 分钟才能阅读完成。
017 年支付宝五福红包红包开奖人数是 167966715 人（约 1.68 亿）；除夕当天的参与人数是 2.2 亿；在业务峰值上，活页主页面峰值达到 81W/s；扫福的峰值为 22W/s；除夕当天的登录峰值为 29W/s；除夕开奖峰值是 90W/s。在本文中，蚂蚁金服技术专家天镜飞深入技术背后，为大家讲解了整体活动的稳定性保障、资损防控、运维部署、投产保障、监控管理、安全防护等方面的实战经验。
业务模式
今年支付宝新春红包主要采用了 AR 红包和五福红包两种模式。AR 红包是创新业务的体现，主要分为藏、找、开三个步骤。其中藏是在当前位置扫描指定的物体，输入金额、人数，支付完成之后，该红包就出现在地图上；用户可以在地图上发现该红包或者是通过扫描指定的物体找到该红包，找到红包之后用户可以使用线索图打开红包。AR 红包另一个玩法是商户红包，主要用于商户的推广，商户可以把自己的 Logo 藏在所有门店的地理位置上，通过引导用户去指定的门店扫 Logo、开红包，进而起到商户宣传的作用。
五福红包也就是所谓的敬业福，今年的玩法和去年的类似：搜集福卡、交换福卡，集齐五福之后等待开奖；二者区别在于在收集福卡上，今年的形式更加多样化：扫福字，蚂蚁森林浇水以及钻石会员可以得到万能福；同时金额分配采用随机的方式，做到人人有份。
业务核心指标
上图显示的是今年支付宝红包业务核心指标：五福红包开奖人数是 1.68 亿；除夕当天的参与人数是 2.2 亿；在业务峰值上，活动主页面峰值达到 81w/s；扫福的峰值为 22w/s；除夕当天的登录峰值为 29w/s；除夕开奖峰值是 90w/s。
那么支付宝是如何支持如此高并发的业务和如此庞大的人群呢？背后的支撑的技术体系是怎么样的呢？下面来一探究竟。
支付宝支撑技术体系
支撑支付宝红包产品实现的技术架构可以总结为六个要素：其中稳定性保障、资损防控是核心；运维部署、投产保障是基石；监控管理、安全防护是重要组成部分。这六大要素支撑产品实现技术架构整体的运行以及最后完美地结束。支付宝红包产品实现的技术架构如上图所示。基于业务可变性和用户体验的要求，在终端上主要采用 H5 和 Native 的实现方式：其中 H5 主要用于蚂蚁森林、福卡任务、福卡排行榜等易变的业务；福卡主页、AR 地图、AR 扫一扫、AR 引擎、AR 开红包等业务是采用本地 Native 的方式，因为其用户体验非常好。当然，整体客户端架构都是基于支付宝客户端 &H5 容器的通用能力，如框架、通讯、网络、登录、安全等。
在服务器端，福卡业务平台和 AR 业务平台都是基于支付宝现有的资金能力，其中福卡业务平台是基于现有的营销发奖资金处理能力，在处理过程中，使用了推荐、凭证中心、蚂蚁森林中的产品能力，福卡业务中最为关键的是配置后台（这是因为它是配置型的产品），所以我们搭建了新春配置后台和营销配置后台；AR 业务平台是基于个人红包和商户红包现有的资金能力，其中图像识别服务和地理位置服务是该业务中最为重要的两点。总结来看，服务器端依赖于支付宝新金融引擎的共享能力，如监控、社交、会员、账务、支付、安全、SYNC、中间件等。
在存储方面，除了采用通用的 MySQL 存储，还大量引入了关系型数据库 Geabase，对于分布式缓存采用了 tair，图片存储使用的是 OSS。
下面来逐一讲解支撑产品实现的六个要素。
运维部署运维部署要解决的问题是资源缺口。正常情况下，华东 1 和华南机房的机器数量是无法满足新春活动资源的需求，因此需要周转腾挪。在解决资源缺口的过程中，利用了弹性资源来节省成本，将关键链路“弹”到云上；活动结束之后再将这些流量从云上迁回线下机房中。正常情况下，华东 1 机房和华南机房分别承担 40% 和 60% 的流量，并且它们都是非云的机器；在新春红包业务上，支付宝将 60% 的流量切到华东 2 机房中，并且将其上云，借助了阿里云强大的服务器能力，此外，在华南机房会部署 15% 的云机器，也就是说，新春红包业务中，75% 的机器是在云上运行的，在活动结束后，流量会切出，将机器空闲出来极大的节省了成本。
投产保障
投产保障是技术架构的另外一块基石。今年业务上线过程中，代码开发、产品上线只占了全部精力的 20%；其中 75% 的精力用于演练和压测。针对演练和压测，支付宝设计了三套环境，分别是压测环境、演练环境和正式环境。终端、服务器端和存储都支持这三套环境来回切换，三套环境是基于白名单的隔离控制机制，以防止三套环境相互串扰带来线上稳定性的风险。
在演练中优化产品流程，在压测中打磨代码性能。今年产品上线时的业务流程和最终正式环境下的产品业务流程变化非常大，并且代码的层次也发生了很大的变化，利用这三套环境，通过压测来调优代码，通过线上的演练，不断地完善代码、产品，最终达到基本稳定线上产品状态。这里值得一提的是灰度拉练，在开奖环节，今年设计了灰度开奖的功能，也就是提前一天，某些用户可以提前开奖，在提前开奖过程中修复了一个严重的配置问题，避免了正式上线时产生故障，因此灰度拉练可以说是投产保障中最关键的一环。
监控管理监控管理和安全防护是两个重要的组成部分。监控是产品的“眼睛”，它为技术和产品人员提供了发现线上问题、做出业务决策的依据。今年，依照不同的监控场景和需求，支付宝共部署了四套监控模式：第一套监控模式是利用 Xflush 分析系统的稳定性日志，最终产出系统监控、业务链路大盘、SLA 限流大盘，这部分主要是为各技术负责人提供线上运行状态的监控；第二套监控模式是利用 Kepler 实时计算平台，对业务日志进行分析，产生一些业务指标，最后产出电视大屏、移动直播间、营销大盘，对外输出有绚丽效果的展示；第三套监控模式是利用海纳实时计算平台，对客户端日志进行分析，产生资源下载大盘、性能稳定性大盘、基础网络大盘，可以对客户端的运行状态进行有效的监控和预警；最后一套监控模式是针对客服的安保日志分析，产生安保大屏，对用户投诉情况进行监控。
安全防护只有在产品设计之初就考虑安全防护，才能做到产品运营时的防患于未然。今年，支付宝在 AR 红包和五福红包上采用了三道安全防护策略。前两道防护主要是针对 AR 红包的线索图和 LBS，其中第一道防护是针对 AR 红包的线索图，通过线索图遮挡算法，在线索可识别和线索不泄露之间寻求平衡；第二道安全防护是针对 LBS 篡改的监测，采用的策略是终端采集用户 LBS、位移等数据，然后报送给服务器端，服务器端在用户领取 AR 红包时分析 LBS、位移等数据是否出现漂移等现象，对异常的情况进行领取拦截；第三道防护是基于大数据的安全策略防护，支付宝安全团队对用户的数据进行大数据分析，基于大数据分析会产生相应的安全策略，这些安全策略会在产品的关键流程上进行防护，主要是得福卡、交换福卡、福卡开奖、领 AR 红包和发 AR 红包，针对不同的环节，采用不同的安全防护手段，保障用户操作的有效性。
稳定性保障
在稳定性保障中，第一个较为突出的点是将图片识别散于终端，这是由于图片识别算法是非常耗性能的。图片识别时面临着两个选择：一是在各终端上完成图片识别，直接和用户交流，具有较好的体验，此外还缓解了服务器端的压力，并且由于图片不用上传到服务器端，可节省了流量的开销，但是它面临的最大问题是不安全，因为在终端进行图片识别，用户可以篡改图片识别结果，从而欺骗服务器端，具有较高的风险；另一个选择是在服务器端进行图片识别，也就是图片上传到服务器端，通过服务器端的算法进行识别，保证了识别结果的安全性，它的缺点是用户体验差、服务器资源损耗高、消耗用户大量的流量。
因此，需要在这两种方式中寻求平衡，支付宝采用的策略是针对不同的图片识别场景采用不同的图片识别方式，如地图上领取红包，采用的是客户端严格匹配，服务端按策略再次校验的方式，以安全为上；扫一扫领取红包场景，采用服务端 Top n 匹配，领取时服务端验签的方式，也是为了安全考虑。这两种场景的实际峰值并不高，将其放在服务器端是在可接受范围内；另外三个场景，包括可口可乐红包（出红包福卡）、口碑活动（出红包）、任意福活动（出福卡）主要是识别福字和商户 Logo，其中不牵扯隐私问题，因此对于商户 Logo 采用的是纯客户端匹配，服务器端不再识别，避免了服务器的资源损耗；对于任意福活动，是采用客户端严格匹配福字，当客户端识别不出福字时，再由服务器端进行识别，这种方式可以节省服务器端 70% 以上的资源损耗。
在稳定性保障中，针对扫一扫环节实现了关键链路多档位切换。扫一扫环节的关键点主要包括终端福字识别、附近可领取红包线索匹配、服务端福字识别和福卡领取。支付宝针对扫一扫环节设计了三个档位：档位一，完全模式，即识别福字又识别红包，该模式可承受峰值为 12W/s，在该模式下可以通过调整附近匹配红包个数调整系统性能；档位二是将红包 Top n 匹配环节去掉，服务器端只保留福字识别和福卡领取这两项功能，该档位可承受峰值为 50W/s，该模式下可以通过调整服务端福字识别算法复杂度对系统性能进行调整；档位三是在服务器端仅保留福卡领取功能，该档位预计可承受峰值为 60W/s，节省图片下载等资源损耗。
在实际使用过程中，档位二已满足要求，但多档的思想为稳定性保障提供了很好的支撑。
稳定性保障方面细节特别多，每个细节又非常重要。除了上述两点外，支付宝还在全局上考虑了一些风险点的梳理、规避以及制定了活动前、活动中、活动后的操作手册，制定了相应的应急处理机制，并对关键业务流程进行多次模拟演练。
在终端上采用了限流无感知、资源预下载、用户操作数据缓存、开奖时间离散、数据项与开关动态配置等稳定性操作；在服务端，进行了全链路梳理、全链路压测、限流保护、应急熔断机制等。
资损防控资损防控是今年红包活动中的另一个核心点，这是因为 AR 红包和五福红包涉及的金额巨大；另外由于今年的奖池分配策略采用随机分配的方式，进一步增加了困难：
计算困难，开奖只有 18 分钟，如何在 18 分钟内将 2 亿随机分配并发放出去？
核对困难，资损风险高，并非简单地将金额计算出即可，而是要保障每个人金额总和和总金额相同。
奖池发完难度大，将 2 亿现金全部发放干净，其中涉及预测、保底等问题。
针对计算困难，引入多档位类随机机制，设计多个开奖档位，使得看起来像随机的结果，而不是纯随机的方式；另外采用提前算奖的方式，在用户五福合一时提前计算出部分用户的奖金，实际开奖时只是查看原来计算好的金额。基于这两种策略，支付宝设计了今年资损防控的新模型，该模型包括算奖、抽奖、发奖三个环节，通过监控、预警、核对机制来保证这三个环节的正确性；其中算奖环节设计了可重复算奖，当发现异常时，可重新计算奖金，抽奖环节支持快速订正，发奖环节支持快速调账。核对机制是资损防控中最为关键的环节，今年采用的是基于实时计算平台的核对机制。该核对机制主要包括两种核对策略：一是实时核对，对关键的资金流变动、资金链的切换采用实时核对；另一种是异步核对，也就是所谓的 15 分钟核对、小时核对和 T + 1 核对，对于所有和资金相关的环节都采用异步核对以保证最终的一致性。
实时核对采用了三种基本策略：第一种策略采用了乾坤镜技术，对接口的入参出参实时地检查；第二种策略采用定时调度任务，尽量保证准实时性，将数据库中的相关数据捞出来进行核对；第三种策略是将核对的代码片段糅杂在业务代码中，通过这种方式保证实时核对的一致性。异步核对，包括 15 分钟核对、小时核对、T+ 1 核对，采用的技术架构主要是 DRC（异地多活数据同步）与 TT 结合的方式，将 DB 的数据和日志的数据按 15 分钟、小时、日汇总存储到 ODPS 上，再通过相应的核对机制来保证整体的一致性。
在算奖—抽奖、抽奖—发奖的过程中，下一个环节开始前，必须通过核对的策略保证上一个环节的准确性，包括总金额和明细；这样一来，可以平稳地过渡到下一个阶段而不必担心上一阶段出现问题。
总结
支付宝新春红包产品以运维部署和投产保障为基石，以稳定性保障和资损防控为核心，辅以监控管理和安全防护这两个重要组成部分，完美地解决了五福红包和 AR 红包的高并发业务和庞大的人员参与两大难题，实现了 81w/ s 的活动主页面峰值、22w/ s 的扫福的峰值、29w/ s 的除夕当天的登录峰值以及 90w/ s 的除夕开奖峰值等一系列指标。
原文来自：云栖社区；原文链接：https://yq.aliyun.com/article… 点击阅读更多，查看更多详情
