edagarli / java-route

Java technology route
https://edagarli.gitbooks.io/java-route/content/
66 stars 17 forks source link

红包架构 #18

Open edagarli opened 8 years ago

edagarli commented 8 years ago

红包架构

1.预资源下载

这些页面需要用到图片,视频或H5页面等资源。在活动期间,参与用户多,对资源的请求量很大,如果都通过实时在线访问,服务器的网络带宽会面临巨大压力,基本无法支撑;另外,资源的尺寸比较大,下载到手机需要较长时间,用户体验也会很差。因此,我们采用预先下载的方式, 在活动开始前几天把资源推送给客户端,客户端在需要使用时直接从本地 加载。

2.摇/拆红包

除夕的摇一摇子系统是专门为活动定制的,按时间轴进行各项活动,这里边最重要、同时也是请求量最大的是摇红包。从需求上看,系统需要完成两个事:用户可以通过摇一摇抢到红包,红包金额可以入到用户的支付账户。在除夕,系统需要在很短时间内将几十亿个红包发放下去,对性能和可用性要求很高。考虑到涉及资金的业务逻辑比较复杂,还有很多数据库事务处理,耗时会比较长,于是我们将抢红包(信息流)和红包的账务逻辑(业务流和资金流)异步化。将前一部分处理流程尽可能设计得轻量,让用户可以很快抢到红包,然后再异步完成剩下的账务逻辑。

  1. 零 RPC 调用

在微信后台系统中,一般情况下客户端发起的请求都是通过接入服务 转发给具体的业务服务处理的,会产生 RPC 调用。但对于摇一摇请求,我 们将摇一摇逻辑直接嵌入接入服务中,接入服务可以直接处理摇一摇请求, 派发红包。

  1. 零数据库存储

按一般的系统实现,用户看到的红包在系统中是数据库中的数据记录, 抢红包就是找出可用的红包记录,将该记录标识为属于某个用户。在这种 实现里,数据库是系统的瓶颈和主要成本开销。我们在这一过程完全不使 用数据库,可以达到几个数量级的性能提升,同时可靠性有了更好的保障。

支付系统将所有需要下发的红包生成红包票据文件 ; 一).将红包票据文件拆分后放到每一个接入服务实例中; 二).接收到客户端发起摇一摇请求后,接入服务里的摇一摇逻辑拿出一个红包票据,在本地生成一个跟用户绑定的加密票据,下发给客户端; 三).客户端拿加密票据到后台拆红包,后台的红包简化服务通过本地计算即可验证红包,完成抢红包过程。

3.异步化 用户抢到红包后不会同步进行后续的账务处理,请求会被放入红包异步队列,再通过异步队列转给微信支付后台,由微信支付后台完成后续业务逻辑。

二 . 大规模集群中保证数据一致性

1 . 服务性能

为提升各个服务模块的处理性能,我们通过压测和 Profiler 分析, 发现了不少性能瓶颈点,做了大量优化。

2 . 业务支撑能力

支持更加复杂的业务场景,并在客户端和服务器都加入了很多可以后 期灵活调整的预埋能力,以更好地服务产品运营。

  1. 可用性

不断提升系统可用性是我们一直努力的目标,以下 5 点很好地提高了 系统的可用性。

  1. 系统容量评估与配额 对系统的容量需要有个准确的评估与验证,并结合业务设计合理的配 额方案和降级方案,尽可能保障系统不会过载。例如,我们评估并验证完 系统每秒最大拆红包量后,就可以在处理用户摇一摇请求时,限制系统每 秒最大发放红包配额,这就间接保证了拆红包量不会超出处理能力。
  2. 过载保护 服务如果出现过载了,必须有能力自保,不被压垮,并且不扩散到系 统其他的服务。我们在后台的服务框架层面具备通用的过载保护能力:服 务如果处理不过来,就按请求的优先级尽快丢掉超出处理能力的请求,保 证服务的有效输出;上游调用端在部分服务实例过载时,能自动做负载均 衡调整,将请求调整到负载较低的服务实例中;上游调用端发现大部分服 务实例都出现过载,也可以主动丢掉部分请求,减轻后端服务器的负担。
  3. 减少关键路径 减少核心用户体验所涉及的步骤和模块,集中力量保证关键路径的可 用性,从而在整体上提高可用性。我们把活动红包的信息流和业务流进行 异步化,就是基于这个考虑。跟用户核心体验相关的抢红包操作,在信息 流中的接入服务、红包简化逻辑服务和红包异步队列(入队)这三个服务 模块参与下即可完成。这三个服务模块是可以比较容易用较低成本就做到 高可用的,可以较好地规避业务流和资金流中几十甚至上百个服务模块可 能出现的风险。
  4. 监控指标 我们需要对系统的真实负载情况有准确及时的了解,就必须要有一套 高效、可靠的监控系统,同时还要有一套有效的监控指标,监控指标不是 越多越好,太多了反而会影响判断,必须要有能准确反映问题的几个核心 指标。在我们系统里,这些核心指标一般在基础框架集成,根据经验来看, 其中一个很有用的指标是服务的最终系统失败。我们把服务的失败分为两 类:逻辑失败和系统失败。系统失败一般是服务暂时不可用导致,是可通 过重试来自动解决的,如果请求重试若干次仍然为系统失败,就产生最终 系统失败。通过最终系统失败通常可以快速定位到异常的服务,及时处置。
  5. 人工介入 我们在红包系统内预置了很多配置开关,当自动运作的过载保护无法 发挥预期作用时,可以通过人工介入,使用这些保底的手动开关迅速降低 负载、恢复服务。