一、项目背景
在用户量快速增长、业务场景不断创新的今天，金融行业也不断经受着高并发和海量数据的挑战。特别是在类似双11这种消费高峰，或在热点营销场景这种交易高峰时，瞬时的高并发流量，往往会对业务系统造成极大的压力，更甚至超过系统承载能力时，造成系统崩溃，大大降低系统的可用性和用户体验。
传统的限流方案主要依赖服务器配置和应用逻辑层面的控制，例如Nginx通过limit_req、limit_conn参数分别限制单个IP的请求频率和并发连接数，Tomcat通过maxThreads参数限制同时处理的请求数量，或者在应用开发时使用计数器、令牌桶等算法控制服务可接收的请求数。此类限流方案主要存在以下问题：
- 缺乏动态调整的能力：限流参数通常静态配置，无法根据实时系统负载动态调整；
- 入侵业务代码：在应用层面实现流量控制时，通常需要在业务前嵌入限流算法，会对原有的业务逻辑产生影响；
- 占用服务资源：业务高峰时，服务资源往往会被限流算法抢占，从而导致业务处理性能低下。
二、项目简介
基于以上痛点，中原银行适时建设了流量削峰平台。流量削峰平台为中原银行举办营销活动所建设的全行级支撑保障性平台，具有快速接入、轻量化及无状态等优点。其不但能平缓高并发流量，还能对过多流量、超时流量等无用流量快速拒绝，同时具备限流规则实时更新、实时生效的能力。通过流量削峰平台对营销系统的介入，能够极大地降低活动请求的响应时间，提升用户体验，保障业务始终在最优状态下平稳运行。
平台具有以下几点方面的特点：
- 流量整型和弹性控制：平台最核心的能力就是对洪峰流量进行整形，把瞬时洪峰流量通过技术手段缓存起来，然后再按后端服务处理能力下发流量；同时，平台可根据后端服务处理时长及失败率，动态调整下发流量速率，尽可能保证后端业务系统始终处在最优处理能力；
- 过多流量快速拒绝：支持设置最高流量和支持设置队列长度机制，保证在流量过大或者请求大量积压的情况下，对于超出最大流量或者超出任务队列长度之后到达的请求，快速拒绝，避免不必要的等待与资源占用；
- 超时请求快速响应：超时监控机制保证请求在队列中等待时间超过设置时间后，直接返回超时异常，不再进行不必要的后台服务调用；
- 支持多场景多队列：可按照业务规则配置多个队列，每个场景可设置一个队列，每个队列支持独立的限流规则；
- 支持多协议：支持HTTP及TCP两种协议；
- 支持优雅停机：当停服时，不接受新请求，队列存量请求处理完后，再停止服务；
- 多指标实时监控：平台具备多指标实时监控功能，方便业务系统直观的了解平台处理流量大小、实际调用后台服务请求数、后台服务平均响应时间、最大响应时间等重要内容。
三、技术方案
1. 基本原理
为追求更高性能，平台内部处理逻辑追求尽量精简、尽量减少性能损耗。在接收到上游发来的请求后，直接将请求存入任务队列中；并启动一定数量的工作线程从队列中获取请求再转发到下游系统，然后将后台返回的响应透传给上游系统。
2. 技术实现
上游接收请求，利用Netty强大的多线程模型和异步处理能力，保障单台流量削峰平台服务可应对上万TPS的流量洪峰；下游使用性能优异的LinkedBlockingQueue，保证消息的高效安全存取，然后再通过预先设定好的工作线程量将请求按照一定的并发速率转发给后台，从而实现了流量削峰的功能。具体设计如下：
- 服务入口设计
- Netty接收请求：使用Netty接收服务请求，保证请求的接收效率；
- Sentinel流量控制：依赖Sentinel实现流量TPS控制，具备默认、冷启动及匀速限流模式以适应多种服务场景，当请求被限流时，平台快速拒绝；
- 多缓冲队列：支持多队列转发，根据配置规则，实现不同功能或接口按规则存放到不同的队列，每个队列可设置优先级，队列之间相互隔离，提升了削峰服务资源的利用率和扩大削峰使用场景；
- 内存队列缓冲：经过限流后，把请求转发至缓冲队列，缓冲队列的长度，可快速拒绝多余的流量。
- 请求下发设计
- 缓冲队列超时监控：根据排队超时时间设置监控延迟任务，请求排队超时后返回相应响应；
- 弹性线程控制：依据业务请求响应监控提供负反馈机制，对活动线程数进行动态调整，以实现业务系统的自适应负载保护；
- 全局限流：若有全局限流需求（TPS限流、商品级限流），则使用Redis进行全局限流，否则直接向后转发，全局限流按照全局TPS或商品总数量等指标计算，并具备定时任务热更新和即时调整的能力。
3. 难点问题
3.1 弹性线程设计
弹性线程控制主要是依据过去一段时间内请求的慢响应比例控制转发线程数的增减。配置弹性线程功能时，需要预先设置最小请求数、慢响应时间阈值、慢响应比例阈值、线程减少比例、线程扩增比例等参数。弹性线程的启动时，会有一个滑动窗口收集时间窗口内的请求数、大于预设慢响应时间阈值的请求数，当时间窗口内的请求数大于最小请求数且慢响应数占总请求的比例大于慢响应阈值，则线程按照比例减少，反之则扩增线程数。
3.2 超时监控队列性能优化
每一个请求推送到缓冲队列后，都会再被推送到超时监控队列，在每个请求达到最大排队时间后再被处理，业务高峰时会导致内存占用过高和频繁的GC。此时分为两种情况处理，第一种情况，若请求还未被推送到内存队列就被转发线程处理，则需要再请求内部设置一个标志位，请求完成后此标志位设置为已完成，当要推送至超时队列时，首先判断标志位的状态，若已完成，则不推送；第二种情况，若请求被推送到内存队列时未转发线程处理，则在转发线程完成转发获取响应后，主动从超时队列中移除请求。
四、项目功能
流量削峰平台主要由流量削峰服务及流量削峰管理平台构成，其中流量削峰服务具有流量控制、快速响应、并发限制等功能，流量削峰平台的主要作用是对流量削峰服务的管理及监控，其有服务节点的注册与发现、服务节点配置、服务指标监控等功能。流量削峰平台的服务能力提供者是流量削峰服务，其直接对接业务系统。业务系统的请求首先会经过削峰服务，削峰服务对请求进行TPS流量控制，然后以业务服务提供方可承受的最优并发配置转发过去，同时削峰服务在整个请求处理过程中，可对服务指标进行采集，比如请求处理时间、请求排队时间、TPS。
五、项目成效
流量削峰平台在中原银行首先应用到了核心系统，后续又分别推广至行内的微信银行、手机银行、信鸽系统、中原美食城、综合商城、乡村在线、负债产品中心、综合理财、信用卡积分商城共10个系统，保障业务系统成功度过每次瞬时大流量场景，日均流量千万级。
流量削峰平台在中原银行行内红包活动中，稳定有效地支撑了微信银行及手机银行的抢红包活动，流量削峰节点最高扩展至92个，红包活动当天共计请求量45万余次。
但随着业务量的高速增长，也对平台提出了越来越高的要求。未来平台将从以下几个方面着手，不断优化和提升平台性能，以支撑更加庞大的流量洪峰和更加严苛的并发性能：
- 性能更高队列
当前平台内部使用LinkedBlockingQueue对请求进行缓存，该队列基于链表的形式，通过加锁的方式，来保证多线程情况下数据的安全；下一步计划使用Java开源框架Disruptor来解决高并发下队列锁的问题，在无锁的情况下实现队列的并发操作，以实现更加高效的队列控制。
- 节点弹性伸缩
计划实现服务节点数的弹性伸缩和智能控制能力，当突发业务高峰时，削峰服务可根据自身所能承载的最大量自动扩充节点数量，当流量趋于平稳或低谷时，削峰服务可自动缩减节点数量从而节省服务资源，在整个扩缩节点过程中，保证削峰集群转向业务系统的压力不变。