微信目前已经成为了我们这个时代最受欢迎的社交工具之一，因为还有另外一个叫QQ的社交工具所以这里用了之一。但是在微信里面有一个最受欢迎的功能让多少人为此摇坏了手机，摇烂了屏幕，那就是微信红包。据互联网上的一个数据统计除夕晚上红包发送量多达80.8亿个，其中峰值达到40.9万个/秒。当然为了让全国人民都高兴，网络运营商，微信消息系统，银行，支付系统都是下了不少功夫。下面我们就看一看这里面的技术有多深。
针对红包的交易链路做隔离，除了一些公共服务及收款渠道服务（零钱系统和银行清算系统）以外，彻底和商业支付分开；
链路独立后，一个好处是可以针对红包的特点，大幅简化支付处理逻辑，另一个好处是，可以独立针对红包链路单独做柔性降级处理，而不会影响商业支付的体验。
针对红包系统的支付下单请求，仅验证内部票据即可，原有的大量鉴权逻辑及支付渠道按规则选择逻辑可以全部裁剪，对周边系统的依赖几乎可以降为零；
针对红包的支付过程快的特点，将交易流程的上下文session数据换成高性能、低成本、低容灾级别的全内存服务集群处理，即使某台内存存储的机器故障，也只会影响极短时间的一小部分的用户支付；
针对红包是最简单的支付业务形态的特点，不记录交易单据，以红包业务单据来代替，红包业务系统直接和资金系统进行最终交易对账处理。如此进一步减少红包支付逻辑的复杂度，提高整体可用性。
建设超高可靠、超大队列容量、灵活控制消费频率的消息总线系统；
解除非核心模块在高压力业务路径中的调用耦合，对红包高峰涌来时产生的巨量内部非核心模块调用进行削峰，减少冲击导致过载。
支付系统内部接口敏感性高，需要确保接口使用的安全性；
在用户及商户鉴权的同时，生成不可伪造的票据，在业务过程中，由底层中间件系统全程携带票据到各个接口，并进行必要的接口请求合法性验证。
由于业务峰值高，容灾冗余的成本非常大，无法做到完全任意IDC故障不影响业务，容灾策略上有所权衡；
所有可以做到业务无IDC状态的服务，至少有两个地点的IDC服务集群；
每个服务的所有IDC服务集群中，最多只能有一个集群，如果发生故障，另外的集群无法全量接管请求量；
万一极端情况出现，降低设计容量，进行业务限流。
由于大量高频的群红包绝大比例是小额红包，所以但凡发现用户零钱够，就优先默认帮用户选择零钱来支付（用户也可以手工修改为其他支付方式）；
一方面大幅减少群里面小金额红包支付对可控性相对较差的银行渠道的压力，另一方面也降低了支付资金操作接口的耗时，进而降低系统服务处理的并发程度及负载，还可以提升用户的支付体验。按是否核心链路、重要程度做、是否明显影响用户体验几个方面，对接口作优先级分档排序；
当有高并发请求时，系统监控到有抖动时（服务队列满、系统错误突增、机器负载高、io高 等），自动从低优先级的接口开始做快速拒绝，逐步恢复系统。
前端调用支付流程如果出现非明确的异常（银行收款超时，系统内部抖动，网络异常等），此时扣款渠道有可能已经成功，也有可能未成功，着急的用户可能会连续支付多笔，而胆小的用户也许不敢再发起支付；
在高并发下，这种异常会更加频繁产生，因此需要全面提升支付异常下的体验：
在支付流程异常时，发布支付结果未明的事件到可靠消息总线；
可靠消息总线在一定的用户可接受的等待延迟后，进行扣款渠道的单据结果确认，如果尚未成功，则对当次扣款渠道单据进行锁定，保障后续一定不会再成，如果实际的资金已经发生，则还需要负责及时将资金退回；
在整个过程中，每一步确认及操作的结果均通过微信支付消息触达到用户来透明信息，减少用户的困惑及等待。由于在摇红包后或者发红包高峰时，大量用户会进入钱包首页查看零钱，此时对余额和绑卡数据的查询量会非常大，极可能影响收银台的相关功能稳定性；
针对首页查询设置固定的限流值来保护后端系统，在限流时，钱包首页的零钱将使用客户端的缓存数据，不会自动刷新，并且会挂出延迟公告，需要再进入下一级的零钱界面（大概是首页访问量的1/7），才会刷新。
通过上面的简单分享，相信大家对系统平台型网站的建设肯定有了更深的了解。普通的企业网站由于访问量低，每天不过几十，几百的流量，所以普通的企业网站基本上都是一些简单的服务器搭建的，所以费用也比较低。但是对于平台型的网站，消息队列，负载均衡，容灾等都是不得不考虑的。
转载请注明：好现场 » 看微信摇一摇平台系统的设计架构