AMS运营平台从百万到亿级成长之路--徐汉彬
2020-02-27 213浏览
- 1.
- 2.AMS运营平台从百万到亿级成长之路 ——Hansionxu（徐汉彬）
- 3.自我介绍 Hansionxu（徐汉彬） 腾讯高级工程师（SNG增值产品部），AMS运营平台技术负责人。 曾就职于阿里巴巴、小满科技。 技术博客：hansionxu.blog.163.com
- 4.内容目录 AMS的简单介绍 AMS平台的三次重构 开发效率与价值
- 5.AMS平台介绍 AMS：Activity Manger System 活动运营平台（PHP） 承载QQ会员的活动运营和推广，接入了众多业务。 网上营业厅 ......
- 6.AMS的容量 每日请求量：3.5-5亿 每个月上线：近400个推广活动
- 7.AMS的容量 2012年初 2015年5月 CGI日请求量 200-500万 3.5-5亿 月上线活动 20+ 近400个 业务使用者 1个小组 多个部门 1个活动的开发耗时 1周左右 1-2天/不需要开发 支持的推广业务 PC端游戏活动 各类业务
- 8.2012年初的老AMS部署 前端 CDN OZ上报 CGI入口 提示语 JS前端组件 TGW/10台实体机Apache 框架基础逻辑 逻辑层 TTC 活动常规检测 营销平台 MySQL/主备 存储层 OP/Rule Server IDIP互娱接口 模调监控 Bitmap 离线脚本 白名单 竞拍server 导数据 邀请好友 OIGW/OIDB 支付回滚 Portal 积分server …… ……
- 9.2012年初的老AMS
- 10.TTC&MySQL TTC&MySQL： （1）百库百表 （2）类似memcache的内存级热点数据缓存 （3）间隔N秒的批量写入
- 11.老AMS遇到的问题 1. 产品嫌我们上线活动太慢，1周的开发时间，需求堆积 2. 开发的烦恼，要开发1000-2000行的JS代码，还要写一些PHP 3. CGI代码凌乱，很多冗余和结构不合理（历史原因） 4. Web服务器日志打印在本地，日志和告警管理混乱
- 12.AMS第一次重构和优化 • • • • • 活动开发：我们不想写重复的代码 PHP代码，管理后台化 后端和前端Zero框架打通，前端组件化 按照设计模式分层，统一接口层 搭建独立日志管理机器，优化告警系统
- 13.AMS的设计 显示层(V) 控制层(C) 逻辑层(M) API ams.php 统一入口，通过url的get参数 路由，主要走ajax和前端交互。 分发，调 用Module，返 回View 根据功能分控制器处理，如：参与 活动、拉活动信息、查询信息 根据活动配置调用 相应规则、发货 规则、发货按文件独立，方便扩展 以及维护。目前已支持N种规则判 断和发货型功能 公共API 包含各种常用API，例如：TTC 、CMEM、HTTP代理、统一日志 、IDIP游戏接口（N款游戏）
- 14.PHP代码 PHP代码管理后台化，全部变为配置。（活动开发不写PHP）
- 15.前端JS代码 JS前端封装为zero组件 前端JS：代码从1000-2000行缩短为不足100行
- 16.活动开发效率升级 单活动项目 老AMS AMS1.0 前端JS代码量 1000-2000行 100-200行 PHP代码 少量代码 无/管理后台 开发耗时 1周左右 3-4天 结果： AMS逐渐推广到开发其他小组，使 用的人越来越多。
- 17.2012年7月的AMS1.0部署 前端 ZERO CDN CGI入口 逻辑层 提示语 Js组件 TGW/60台虚拟机,VC1（Apache） 框架基础逻辑 TTC 存储层 OZ上报 活动常规检测 营销平台 MySQL/主备 Bitmap OP/Rule 接口层 L5 Tmem IDIP互娱接口 模调监控 日志server 离线脚本 白名单 导数据 邀请好友 OIGW/OIDB 支付回滚 Portal 积分server …… 日志机器
- 18.AMS1.0架构
- 19.AMS1.0的问题 1. 更多的新项目接入，性能压力暴增 2. 礼包、会员等价金钱，稳定性和监控受到挑战 3. 使用人数增多，管理后台太过粗糙 新的问题，诞生于旧的解决方案。
- 20.AMS第二次重构和优化 • • • • 解决性能瓶颈 增强系统稳定性和健壮性 重构管理后台 增强平台安全
- 21.请求量的新挑战 2013年，原本架构瓶颈支持1000多万，我们接到一个项目， 一天6000万PV的推广项目（手机QQ的“天天爱消除”，手Q 第一个手游推广项目），怎么办？
- 22.扩容与优化 工作难点 1. 各个扩容和优化的技术点 2. 过载保护、容灾、监控 核心工作 1. 服务扩容 2. 去单点风险，保证健壮性 3. 解决性能瓶颈
- 23.去掉单点风险 解决方式 1. 建立热备服务，自动或者手动切换。（例如，建立TTC的热备） 2. 服务Server接入L5，不能只有1台机器
- 24.存储层优化 老的存储分布： 1. TTC，空节点查询问题，单点风险，内存cache太小。 2. tmem，接入机器需要接入L5，数量少。 3. bitmap，服务器是公用的，单点。
- 25.存储优化：空节点问题 TTC的空节点查询问题： 业务特点：每当有用户来参加活动，会先查询用户是否有活动参与记录。 导致问题：大访问量下造成大量空查询，数据不在TTC的cache层中，直接落 到MySQL，冲击MySQL。
- 26.存储优化：空节点问题 TTC的空节点查询解决方法： 用tmem再追加数据是否存在的标志位
- 27.存储优化：频繁写入 MySQL的同步问题： 业务高峰期，MySQL主库大量写入，从库追不上主库。（Binlog同步） 解决方案：直接替换为Tmem
- 28.MP抽奖接口问题 抽奖接口存在的问题： 1. 当超过1000/s，响应慢 2. 部分请求甚至超时
- 29.MP抽奖接口问题 问题的原因（堵车）： 1. 高峰期，中转server可用进程，被响应时间很长的抽奖请求耗 尽（100*3台），等待MP返回结果，Apache的进程也被挂住，被 迫启用更多的服务进程，容易陷入高负载。 2. 影响其他正常的业务。
- 30.MP抽奖接口问题 解决措施一： 1. “修路”----机器扩容，增加最大进程数目（200*5台） 2. 专线专用----读写分离（3台做读接口，2台写接口）
- 31.MP抽奖接口问题 解决措施二： 1. 业务层面规避，后端cgi层做请求过滤，直接返回不中奖。
- 32.MP中转Server微线程（协程）改造 原来的Server： 单机，开启200个服务进程。 资源浪费，占据大量内存，上下文切换。 改造后的Server： 单机，开启4个服务进程（复用虚拟机器核数），1个进程最多可 支持200个微线程，微线程处理。 机器负载，高峰期下降大概50%。
- 33.管理后台：问题 1. 管理后台界面粗糙，新人和其他组的同学操作容易出错 2. 多个管理后台，使用复杂 3. 产品同事看不懂，难用
- 34.管理后台：重构 简单易用，让产品和运营同学看懂，并且轻松使用 结果： 1. 新人和其他组的同学，快速上手，轻松操作 2. 开发效率进一步提升，大量活动开始走免测，耗时为1-2天 3. 模板化活动，运营同学独立配置，直接上线
- 35.AMS优化结果 单活动项目 AMS1.0 AMS2.0 性能瓶颈 1000多万 1亿 使用者 开发中心 整个部门 开发耗时 3-4天 1-2天 支持业务 PC游戏 PC/手游/手Q业务
- 36.2013年8月的AMS2.0 PC端 CDN ZERO CGI入口 OZ上报 提示语 TGW/25台虚拟机,VC4 逻辑层 PC端 逻辑层 移动端 AMS的PC端 TTC 存储层 移动端 营销平台 MySQL/主备 Bitmap 接口层 L5 Tmem 回流脚本 邀请好友 OIGW/OIDB IDIP互娱接口 模调监控 日志server 离线脚本 白名单 AMS移动端 …… Portal 积分server …… 日志机器
- 37.AMS2.0架构图
- 38.AMS2.0遇到的问题 1. 接入大量移动端推广活动，流量继续暴增 2. PC/移动端两个分支版本维护困难 3. 接入更多合作业务接口，安全性挑战更高
- 39.AMS第三次重构和优化 • • • • 再次提升平台的性能瓶颈 合并PC和移动端版本 解决安全风险 支持高并发业务
- 40.请求压力持续增长 AMS平台的每日访问量持续增长，突破亿级别： 1. 上线活动越来越多，移动端占比变大。 2. 接入手机QQ、游戏中心等新的移动端业务。
- 41.性能：升级&优化 1. 彻底告别TTC（MySQL），升级为Cmem，改进的接口， 测速显著提升。 2. 升级bitmap为Cbitmap，解决单点风险，Cbitmap是个 集群。 全面进入NoSQL存储时代
- 42.性能：降低CGI响应时间 对AMS的CGI的每个步骤，添加耗时监控，统计和分析，逐个优化。
- 43.支持高并发需求 剑灵秒杀活动：1分钟130万请求，平均2.1w/s，高峰5w+/s
- 44.实现秒杀保护机制 1. 队列服务。 2. 悲观锁：具有强烈的独占和排他特性。（mutex、rwlock等） 3. 乐观锁：不锁定，允许修改，通过“版本号控制”。
- 45.业务安全：Session重复问题 发货类等业务，同一个子活动号下： 在当前业务处理完毕之前，不再接受同一个QQ号的第二个请求。
- 46.安全：解决Session重复 单用户的Session重复解决方案：
- 47.安全：礼包超发风险 礼包的超发风险（2012年一些电商企业的促销）
- 48.安全：礼包超发风险 解决方案： 通过“乐观锁”的方式，控制资源余量的原子加操作。
- 49.监控与过载保护 1. 日志机器上的日志，成功率自动统计&告警，支持自动 暂停成功率低的子活动（例如某个礼包）。 2. 信号量控制单台Web机器的并发数目，通常用来控制 具体活动，保护一些特殊的后台服务接口。
- 50.异地部署 聚集与分散 （1）核心服务和部署成本大的聚集，走内网专线（30ms） （2）非核服务分散
- 51.AMS异地部署 手Q游戏中心：上海机房搭建中间Server，通过专线访问深 圳机房的AMS。
- 52.AMS优化结果 单活动项目 AMS2.0 AMS3.0（2014年6月） 单日请求量 日均5000万 1亿 性能瓶颈 1亿 3亿 使用者 自己部门 多个部门 支持业务 PC/手游/手Q业务 全面支持移动端/PC 月上线活动 50-80 100+
- 53.2014年5月的AMS3.0 前端 CDN ZERO PC端组件 CGI入口 逻辑层 移动端组件 TGW/30台虚拟机,VC4 框架基础逻辑 活动常规检测 OP/Rule MP/Curl CBitmap 存储层 接口层 IDIP/IEG发货 模调监控 Cmem/Ckv 日志server 离线脚本 其他组件 白名单 回流脚本 邀请好友 …… OIGW/OIDB SRF/Portal/Tips 积分server …… 日志机器
- 54.AMS的价值：解放开发人力 AMS发展阶段： 1. 第一个阶段：不写重复的代码，将代码变为配置。 2. 第二个阶段：将配置文件变为管理后台。 3. 第三个阶段：运营同学承担管理后台的配置工作，解放开发人力。
- 55.模板化生成
- 56.简化活动开发流程 设计 重构 开发 体验\测试 设计 组装 体验 发布 产品 模块开发 体验/测试 发布 开发 页面模块化 发布
- 57.
