1、腾讯游戏营销系统的十年架构演化互动娱乐事业群/增值服务部游戏营销系统架构师、道具仓库负责人系统概述与规模营销系统架构演进与优化总结与心得123什么是腾讯游戏营销系统？PCH5游戏内在游戏生命周期的各个阶段，支撑游戏的推广、拉新、活跃、营收、留存、回流等运营活动的系统平台。2.8w+同时在线活动数260+每天上线活动数600+服务业务数入口请求数十万，每天服务玩家上亿，每天发送道具数亿系统规模营销系统伴随腾讯游戏的发展阶段起步建立期（单打独斗）2003-2007年稳定探索期（小作坊）2008-2012年高速发展期（流水线）2013-2017年成熟应用期（协同共建）2018年至今架构：第二代架构(

2、动静分离与业务独立)QPS：上万规模：近100款游戏（QQ炫舞、地下城与勇士、英雄联盟、穿越火线等）耗时：一周以内架构：第三代架构（高并发配置一体化架构）QPS：数十万高并发规模：数百款游戏(王者荣耀、天天酷跑、全民突击、QQ飞车手游)耗时：最快半小时，配置率90%以上架构：第四代架构（PaaS与微服务架构）QPS：百万以上规模：服务全公司游戏渠道理念：协同共建架构：第一代架构(LAMP)QPS：上千规模：几款游戏（如：凯旋、QQ幻想，QQ宠物，QQ音速等）耗时：一周以上第一代架构-起步建立期业务特点：1、请求量小(QPS上千)2、活动需求简单3、一个人负责一个活动架构特点：1、LAMP2、数

3、十台Web-server3、程序耦合DBbrowserWeb-server架构可用性措施：动静分离业务独立部署公共开发库过载保护智能削峰第二代架构-稳定探索期CDNNginxSquidossweb-Web-serverServicebrowserDBWeb-serverServiceDB需求与特点：1.请求量较大(QPS上万)2.部分人负责一类活动(小作坊)3.访问速度要尽快4.业务之间不能相互影响过载保护之Nginx限流ngx_http_limit_conn_module模块：限制单一IP来源的连接数；限制单一服务器的总连接数；超过最大连接数时返回 503 错误；server.limit_c

4、onn perip 10;limit_conn perserver 1500;Web-server 1browser业务A业务BNginxNginx业务A集群业务B集群Web-server nWeb-server 1Web-server n智能削峰之Apache动态过载保护(mod_tprotect)Apache进程定期写入负载信息到共享内存；tprotect读取负载信息，如果超过阀值响应503系统过载；第三代架构设计业务场景与诉求：手游井喷活动铺天盖地 人力紧张需要高效运营 单个运营活动数十万QPS先扛住再优化高效率：配置化+可视化高并发：堆机器初期策略营销活动逻辑配置化(效率问题)前端功能

5、引擎管理端后端逻辑引擎前端逻辑描述文件后端逻辑描述文件按需加载功能活动基础校验大区角色选择请求安全校验活动基础校验大区角色校验执行活动逻辑用户参与活动抽奖 支付 爱秀 分享 报名 问卷 订阅 签到 邀请 充值 消费 包月 竞猜 点券 网吧 排行 积分 反馈 （34000+）API接口功能白模板规则1规则2规则N条件（26000+）资格(预扣/实扣/回滚）动作（8000+）活动逻辑组装（流程）支持一次性/周期性/动态资格支持多条件与或组合后端引擎前端引擎API仓库实例化零件组装半成品成品操作台引擎WebIDE可视化编程(效率问题)基于Serverless、FaaS，提供在线WebIDE可以快速拖

6、拽完成营销活动逻辑第三代架构初期问题与优化突出问题：单机性能低可用性低故障频现故障不能快速发现链路问题难定位解决方案：高性能框架优化重点模块容灾、过载保护与柔性可用全链路实时监控与告警问题可追溯体系建设优 化高性能协程框架替换CGI(单机性能问题)传统的Apache+CGI的方式调整为自写Server方式；单机处理能力提升10倍以上；整体服务器数量从数千台降到数百台；SPPSwoole+第三代架构与容灾监控基础条件游戏条件QQ属性条件业务模块积分条件自定义条件条件支付购买抽奖发货积分赠送分享邀请点券充值动作一致性保障资格DBRedisTDW其他存储组件接入层引擎层业务层存储层营销逻辑执行(流程

7、）规则1规则2规则N全链路数据化监控流量控制恶意防刷四层容灾负载均衡事务一致性活动流控数据一致性数据冷备离线处理补偿冲正幂等重试模块隔离质量保障压测系统自动构建Mock故障演练线上导流接口监控拓扑跟踪工单系统日志系统NOC道具监控对账监控陡升陡降告警系统TGW/Nginx用例管理过载预防和过载保护的措施(防雪崩)独立部署负载均衡灰度发布全局流控限制重试超时设置熔断机制单机保护高星级业务独立部署，避免局部的过载扩散到全局将负载进行平衡保证系统整体处理能力处在较好的状态按平台/渠道/小区/号段等方式灰度，缩小影响范围通过设置全局合理的流量控制，避免系统过载系统过载时，避免前后端不断重试造成服务器雪

8、崩合理设置超时时间，避免时延过长导致系统过载调用链路出现问题时，进行服务熔断降级处理队列等待超时丢弃，快速响应返回，保护单机不过载轻量级全局流控容灾方案ProcessAProcessBProcessC共享内存Redis配额状态配额时间key配额申请锁全局分配额配置化本地配额流控模块全局本地上报配额处理成功失败率拉取流控模块自适应配额keytimer1_keytimer2_keytimer3_key.timerN_key如超额返回限流流控配置0 拉配额方案要点：用key将计数和计时原子化 请求统计用拉取的方式替换上报 全局失效后启用单机流控关键服务柔性可用产品设计服务分级(核心和支撑服务重要性区

9、分，实时与可离线区分等)局部放弃(根据服务分级放弃一些局部体验）最终一致(局部放弃的有效补充）技术实现前端控制（防频繁点击、验证码、进度条、前端缓存等）延迟服务（同步调用替换成异步调用）服务降级（优先保证主要业务和功能）客户服务系统公告问题反馈用户补偿010203资源有限，只做容灾、过载保护还远远不够最终一致性用户大部分时候只关心能不能抽到或抢到奖励，不太在乎多久到账。游戏道具发送体验优化：1、尽快响应用户请求，通过异步、补发、对账机制确保发奖最终一致；2、发货模块利用唯一交易号(流水号)实现幂等，异常情况下补偿冲正；3、友好提示“恭喜你获得了XXX，但奖励会在24小时内送达。”用户参与抽奖发

10、奖模块游戏3、苦等发奖结果1、游戏异常或系统过载营销引擎2、网络异常或系统过载幂等的设计TRedis发货补偿冲正：利用接口的幂等性，重试解决数据不一致性问题 幂等的状态存储发货前设置成执行中，发货完成缓存响应结果，后续相同ID返回相同结果 幂等的有效期持久存储并无价值，过了有效期就不幂等Client请求GET keyKey存在响应(result)SET key running NXKey不存在执行发货逻辑SET key result EX seconds 响应(result)实时监控与拓扑的实现上游下游 UDP上报请求下游数据：上游信息(ID、IP、域名等)下游信息(ID、IP、域名等)请求结

11、果(正常、异常)请求耗时(消耗时间)部分请求信息(账号、流水号、业务、活动)前端组件条件A（set-name）资格（set-name）条件B（set-name）登录验证（set-name）营销系统（set-name）发奖模块（set-name）DB游戏微信（set-name）QQ（set-name）查询服务（按活动号拉取接口数据，构建拓扑图）接口监控服务（统计各关系链的数据）使用者上报上报查询查询查询查询落地落地数据存储（存储调用关系）服务微信红包游戏道具发货服务打包道具限额配置业务审批道具仓库Game 1Game 2Game NAPI 网关TGW VIPRouterWorkerGIDIP接入

12、层Game A Set 发货服务层数据接口层游戏道具信息同步礼包配置同步Game B Set 限量twemproxytwemproxyRedis(M)Redis(M)定制hash算法SlaveSlavetwemproxytwemproxyRedis(M)Redis(M)定制hash算法SlaveSlavePackage(Cache)User(SSD)L5L5方案要点：将查询、扣除、状态锁多个Redis操作集中到一个Lua脚本；Redis 会单线程原子性执行 Lua 脚本，保证数据的一致性；保障礼包限量(时日周月总)和用户限量(时日周月总)一致性礼包和用户一致性限量ClientRedis Ser

13、vereval scriptscript reply第四代架构设计理念业务场景与诉求：需要更多灵活性：复杂需求配置化难于实现；避免重复造轮子：积累大量接口和组件希望开放给全公司；独立开发独立部署小而专注故障隔离混合技术栈与微服务理念的契合第四代微服务架构设计ClientAPI 网关Service AService BService CService Dremote serviceMicroservices服务注册发现API网关 统一入口 统一鉴权 协议转换服务治理 防刷限流 负载均衡 熔断机制 自动扩缩容服务框架 SPP Swoole Golang监控和日志实时监控日志服务数据化运营调用链服务

14、依赖拓扑【服务发现】服务路由与负载均衡(L5)服务注册cluster_comm#公共集群ServiceA=ServiceID-01ServiceB=ServiceID-02ServiceC=ServiceID-03cluster_yxzj#王者集群ServiceA=ServiceID-04ServiceB=ServiceID-05cluster_lol#LOL集群ServiceC=ServiceID-06统一网关业务集群服务路由、负载均衡、动态权重调整业务进程L5 AgentL5 Server权重计算路由迭代反馈迭代L5 控制台配置库根据ServiceID获取路由IP:Port反馈结果Resu

15、ltService AService B故障节点熔断服务发现IP端口权重ipport50ipport50ServiceID【统一接入】协议转换、请求聚合、账号转换协议转换后台各种服务协议统一为批量协议和HTTP协议对外；请求聚合如果需要和多个服务交互，统一网关可以并发发出多个请求给后面的服务，然后汇总数据给到应用程序；API 网关Service 1账号转换统一网关可以把手Q和微信的账号转换成每个游戏需要的账号；API 网关（账号转换）手Q/微信账号游戏账号ServiceService 2Service 312323234Application服务自动扩缩容定时扩容手动扩容自动扩容扩容执行器可选

16、环境三方权限项目依赖测试系统数据采集自动扩容属性阈值毛刺5-3CPU60%MEM80%数量2自动扩容决策服务测试用例维护扩容实施拨测自检上线决策扩容知会NY协同共建数据营销生态（未来）协同共建开发者平台SaaS应用市场开发者控制台开发运维调试运营代码管理部署发布调用跟踪服务治理开发者管理容量管理Mock管理流量控制执行环境管理集群管理故障注入服务降级持续集成监控告警自动化测试日志管理微服务支撑工具链数据营销应用平台型应用工具型应用产品自助型应用PaaS服务中心业务型服务数据资产通用营销用户画像数据指标用户触达任务引擎组件型服务实时&离线计算数据存储实时触发调度服务通用队列FaaS函数基础设施服务器存储网络虚拟化用户开发的应用可以发布至应用市场给终端用户使用控制台包含从开发、运维、调试到运营全流程工具链，基于微服务化的架构组织形式让开发更具复用性服务中心提供多种大数据营销服务，控制台可以快速选取这些服务进行开发，亦可自己开发服务为其他一个用使用基础资源支持自建资源、云资源、docker资源等开发应用沉淀服务总结与心得好的架构？简单可依赖不断进化深度柔性