大流量下美团账号系统技术架构的设计与优化

如果无法正常显示，请先停止浏览器的去广告插件。

1. 大流量下美团账号系统技术架构的设计与优化演讲人：美团技术专家——杨宇晨美团平台事业部 1 1

2. 个人介绍教育经历 2013年 - 2017年哈尔滨工程大学工作履历 2017年至今美团美团成长经历 2017 至 2018 2018 至今美团平台美团内容用户账号组 2

3.  账号系统介绍  单体服务之痛  步步为营的性能优化  系统稳定性的超前建设  技术架构的未来展望 3

4. 二、账号系统（用户中心）简介 C端内部服务层数据层 PC 小程序 H5 Android iOS 到家优选金融到店 …… 登录注册绑定手机业务融合周边服务成长值用户信息密码管理会话管理客服接入 …… 美团用户信息点评用户信息 4

5. 二、账号系统（用户中心）简介 C端 服务范围面向全公司 C 端业务提供用户账号公共服务 流量集群日常 240万+ QPS 服务层 服务对象集团内近千个前后端服务 内部组成数据层 接口量 60+ 服务数百个 HTTP 及 RPC 接口 5

6.  账号系统介绍  单体服务之痛  步步为营的性能优化  系统稳定性的超前建设  技术架构的未来展望 6

7. 单体服务之痛单体项目代码层面问题 500+对外接口 API 层 • • • • • A 登录方式存在 8个同构接口 B 登录方式存在 4个同构接口 C 核心逻辑存在 5个同功能接口为多个对接方提供了同功能的不同接口 …… 400+Java类 Service业务逻辑共享代码包 DAL 层 • • • • • 代码耦合严重 30+ 个 Java 类存在循环调用全包代码量超 5 万行核心逻辑 Java 类平均代码量超过 1000 行超过 20 个方法被重复定义超过 2 次 …… n多张表与m多个缓存集群 • 所有 Service 逻辑及 API 逻辑均与 DB 模型耦合 • 多个 DB 表结构与操作逻辑被 15 个服务共享 • 3个核心缓存模型被服务间共享，存在序列化异常风险 • …… 7

8. 单体服务之痛单体项目服务层面问题核心服务资源使用情况 350 ❗ 单体服务占用 200+ 台 8 核 8G 机器，流量却仅占 10% 300 ❗ 完整发布单体服务服务需要 3.5 小时 ❗ 单体服务资源利用率仅约 13% 250 200 150 100 巨型单体应用不可取 50 0 单体服务核心读服务1 机器数利用率百分比核心读服务2 流量（比例） 8

9. 单体服务之痛 DDD 战术模式的应用展现层应用服务层整合接口公共组件重构重写 Service 领域层基础设施层 API 隔离持久层数据结构 DAL 代码复用公共服务 9

10. 单体服务之痛 DDD 战略模式的应用 ✅ 按领域拆分服务 ✅ 核心服务读写分离 ✅ 服务设计优先以事件驱动单体服务功能 A业务融合信息查询登录注册 B业务融合信息管理运营支持会话管理会话校验 …… 领域拆分微服务化登录注册领域第三方领域身份凭证领域 HTTP服务三方服务A 校验服务 RPC服务三方服务B 管理服务用户信息领域融合领域信息管理融合查询信息查询融合管理读写模型同步新业务适配运营支持管理后台内部工具服务业务公共服务 Ticket管理 Binlog处理日志中控 10

11. 单体服务之痛基于 Groovy 的动态代码分发平台微服务管理后台查看版本分布本地缓存动态配置代码动态代码中控服务周期性请求数据周期性上报版本 GroovyClassLoader 动态代码SDK 根据版本乐观锁决定是否加载或覆盖代码 KV DB 11

12. 单体服务之痛 CQRS 架构的抉择写流量写流量读多写少读流量读逻辑性能要求高读流量 0 10 20 30 40 50 60 70 80 0 100 200 比例 300 400 500 600 TP9999最低要求(ms) 折衷选择 CQS 2021.1.1 15:00:00.000 注册 1. 应用层读写分离 2. 持久层保持聚合读写模型需毫秒级完全一致 C端用户业务方服务 CQRS 写服务 <50ms 查询服务一致性要求高 2021.1.1 15:00:00.050 查询 12

13. 单体服务之痛缓存的强一致性保证机制内部服务写入查询持久化数据管理服务异步同步Binlog Binlog分发服务主动同步关系型数据库 Binlog下发异步同步Binlog 外部服务查询数据查询服务异步同步读写模型同步服务 13

14.  账号系统介绍  单体服务之痛  步步为营的性能优化  系统稳定性的超前建设  技术架构的未来展望 14

15. 步步为营的性能优化性能问题的排查方案与挑战秒级分析对照实验 ❗️一二三方库依赖繁杂 ❗️Agent分析工具影响性能 ✅使用控制变量法对可疑路径进行对照试验并分析结果 ✅对系统指标异步采样获取秒级数据高频压测 15

16. 步步为营的性能优化单机容量增加50% Hystrix 与线程池隔离模式的性能问题现象原因复现排查解决 execute get queue toFuture execute 阅读源码 get TimerTi- cker toObservable 性能分析 Timer唤醒机制 ❌ CPU 与 load 居高不下 ❌ 单机 7000 QPS 后瞬间崩溃 Worker ThreadPool Worker ThreadPool ✅ 使用 Rhino 替换 Hystrix ✅ 非异步链路改用信号量隔离 16

17. 步步为营的性能优化单机容量增加60% 双缓存实现方式导致的性能问题现象原因解决 Thrift Worker Thrift Worker 双缓存并发请求含双缓存组件的业务： ❌ Load 持续高位 ❌ Thrift worker 吞吐降低复现排查 Wait&Notify Observe Lock subscribe 阅读源码 Late&Busy Redis Client Tair Client toObservable Timer ❌ 8000 QPS 后随机崩溃 Worker ThreadPool Wasted 性能分析 Redis ThreadPool Tair ThreadPool Redis&Tair ThreadPool 17

18. 步步为营的性能优化依赖报错服务无影响 Log4j 对异常类处理有误造成的性能问题现象原因解决 Logger Log4j 实际加载路径正确加载路径分析源码复现排查 AppClassLoader DelegatingClassLoader 栈过滤工具过滤生成类 ❌ 大量线程 Block ❌ CPU 瞬间打满 JVM优化生成类 createMemento 18

19. 步步为营的性能优化加解密及哈希功能的三方库锁竞争问题现象原因解决 Mac & MessageDigest Worker线程调用多线程并发请求复现排查 ❌ CPU 使用逐步增高 java.security.Provider 无锁调用分析源码 ThreadLocal缓存 Mac & MessageDigest ❌ 高 QPS 下出现线程Block CPU占用下降10% 阻塞于全局锁 Provider 仅新线程首次请求阻塞 19

20.  账号系统介绍  单体服务之痛  步步为营的性能优化  深化系统稳定性建设  技术架构的未来展望 20

21. 深化稳定性建设——稳定性问题的三个分类事前压测、故障演练和限流是评估自身性能和稳定性水平的重要手段。事中故障发生时刻对问题的应对能力，核心为架构缺陷填补和故障恢复能力的超前建设。事后对有损故障进行快速补偿减少损失，归纳复盘总结经验。 21

22. 深化稳定性建设——总体背景写接口压测困难 200+ 写接口的 Quake 数据构造难置信度低内部存储逻辑和链路复杂，无法直接录制流量，而构造的流量可到达的逻辑分支往往不到 70% 流量上涨迅猛登录注册领域第三方领域身份凭证领域 HTTP服务三方服务A Token校验 RPC服务三方服务B Token管理运营支持 Admin Tools 融合领域用户信息领域融合查询信息管理融合管理信息查询新业务适配读写模型同步 Binlog处理日志中控 2020 年 QPS 大幅度上涨秒杀活动频繁 TP 耗时及可用性要求严格业务方对 5ms 或 0.01% 以内的瞬时可用性恶化也十分敏感业务公共服务 Ticket管理数据层 MySQL Cellar Squirrel MySQL 容量有限集群的扩展和缓存容灾依赖 MySQL，但数据库本身的容量和连接数存在天花板，只能满足约 50% 的流量需求 22

23. 深化稳定性建设——总体目标对整体架构的性能和稳定性问题进行周期化摸底全链路压测故障演练应用服务层增强应用层对大流量的应对能力快速扩容流量隔离 PaaS 层增强 PaaS 层故障处理能力持久层高可用由压测系统提供验证能力支持补偿机制强化 23

24. 深化稳定性建设——用户中心全链路压测面临的问题 200+ 写（含读）接口 30+ 依赖请求顺序的写接口 5～10 条链路内部逻辑 = 1000 ～ 2000 种元数据需构造 150+ 种相关元数据 = 4500+ 请求顺序排列组合需构造 PM 今天提了新需求，数据构造要从头再来？一位 RD 同学 007 地以 5min/条的速度构造仍需 14 天才可完成施压阶段构造流量难以手动执行 ❌ 上下游 mock 不全面导致预期链路没走完 ❌ 影子表里的数据没导全导致接口直接报错了 ❌ 只准备了几千条数据，还没调整到预期流量阈值压测就结束了 24

25. 深化稳定性建设——全链路压测能力建设解决思路问题解决思路方法步骤写流量难以手动构造支持写流量录制和回放构造的流量可信度存疑对压测流量进行校验流量可用性验证上下游 Mock 繁琐且易出错录制流量时保留上下游响应借助 Quake 施压录制流量时保留持久层响应以压测数据中记录的外部响应进行自动Mock 影子表数据难以保证完整录制真实流量的入参、上下游响应及持久层响应 25

26. 深化稳定性建设——事前建设：全链路压测与故障演练的实现 Quake平台用户施压影子 DB 访问流量回放 Servlet 应用逻辑故障注入流量录制服务间调用 Monkey平台真实流量 + 数据校验 ≈ 90%准确度流量录制流量处理 SDK 数据上传流量存储服务流量校验服务数据下发流量回放流量录制 ORM(Mybatis) 流量回放真实入参 + mock出参 = 0请求构造 NoSQL 存储集群 DB 持久层 26

27. 深化稳定性建设——用户中心流量管理面临的问题历史上的登录注册突发流量请求情况秒级突发流量达日常峰值的 60 倍 Jetty线程池 Nginx 扩容时按并发度交付，导致扩容的机器立刻被打挂常规扩容手段无法应对极端流量 Thread1 Thread2 Thread3 Thread4 Thread5 Thread6 Thread7 Thread8 ThreadN 线程池及 TCP 队列瞬间打满，应用层限流实际无效常规限流手段在极端流量下无法隔离不同流量间的影响 27

28. 深化稳定性建设——事中建设：快速扩容与流量隔离自动化整体扩容、整体交付 + 核心调用方应用层物理隔离 = 突发流量可管可控监测流量负载监测系统建立扩容专用隔离集群应用层流量隔离系统中心及常驻流量隔离集群整体交付执行扩容整体扩容完成中心一次性扩一个小集群，机器全部 Ready 再开启流量 BG2 隔离集群00 小流量业务A 隔离集群01 核心BG A 隔离集群02 活动流量隔离集群Retry 弹性缩扩容系统 BG1 … 其他小流量业务秒杀流量重试流量 …… 按流量、业务属性和耗时敏感度对调用方分级并实行物理隔离 28

29. 深化稳定性建设——持久层存在的潜在风险请求量与 DB 容量比例关系 DB连接数及串行建连总耗时 14000 12000 2.5n 万QPS 10000 8000 6000 n万QPS极限容量缓存 DB 4000 2000 0 正常状态扩容状态 DB连接数（个） ❗ 缓存击穿 ❗ 缓存降级 DB 集群被击垮极限扩容 DB连接建立耗时合计（分钟） ❌ 极限扩容时连接数影响 DB 稳定性 ❌ 发布时连接初始化拖长扩容时间 29

30. 深化稳定性建设——事中建设：持久层高可用核心读服务稳定机器异构备用数据源接管 DB 容量外流量 KV 缓存层流量低于阈值 DB ORM 动态代理 SDK 缓存被击穿或降级时仍99.99%可用流量高于阈值基于Cellar的异构数据源写入备用数据一致性校验主备数据一致性保障服务 Binlog同步数据 Binlog延迟消费 30

31. 深化稳定性建设——事中建设：持久层高可用 DB 击穿防护 + DB 连接数优化 = 持久层可用性与容灾能力提升核心读服务扩容机器稳定机器 KV 缓存层缓存正常时 DB 连接 80%为 IDLE 状态建立 DB 代理服务低损耗的 Thrift 连接高损耗的 DB 连接 5*n～20*n >= 3500个连接 DB 5*n～20*n >= 1000个连接 DB 代理服务少量 DB 连接即可支撑扩容机器请求 5*10～20*10 = 50 ～ 200个连接应用层大量扩容时无需瞬间创建大量 DB 连接 31

32. 深化稳定性建设——DB 主从切换带来的问题需用户重试主维度写入 Master MHA Manager 辅维度异步写入 1min 应用服务主辅维度数据不一致简易 MQ 异步补偿机制 Slave1 Slave2 ❗️ 补偿队列的执行情况需要人工介入 ❗️ 手动操作补偿开关造成不一致时间延长 ❗️ 主辅维度数据无法确定是否已最终一致目标：建立一套完善的自动化补偿机制 32

33. 深化稳定性建设——事后建设：DB 补偿机制强化主从切换写入旧主新主应用服务核心读服务A 辅维度补偿 MQ 核心读服务B 登录注册服务收集信息管理服务核心读服务C …… 分析 ✅ DB 切换期间 0 研发人力投入 ✅ DB 辅维度补偿 0 延迟 ✅ DB 主辅维度 100% 最终一致 DB切换稳定性保障服务补偿 DB监控报警聚合服务 DB数据校验服务 RD 33

34.  账号系统介绍  单体服务之痛  步步为营的性能优化  系统稳定性的超前建设  技术架构的未来展望 34

35. 未来展望——完全异步化 IO密集型的同步模型性能和吞吐量难以进一步优化解析入参获取关键数据A 解析入参B 获取和处理内部数据获取和处理关键数据B 根据判断逻辑情况返回错误读服务同步处理链路线程资源高占用负载高整体吞吐量低极限容量未压榨尽CPU算力容量低资源浪费 35

36. 未来展望——完全异步化采用回调实现读逻辑的全链路异步化异步上下文解析入参获取关键数据A 解析入参 B 获取和处理内部数据获取和处理关键数据B 根据判断逻辑情况返回错误读服务异步处理链路线程资源浪费负载高整体吞吐量高极限容量已压榨尽CPU算力容量高高资源利用率代码可读性极差回调地狱 36

37. 未来展望——完全异步化将异步方案改进为采用 Kotlin 协程回调Complete 回调Complete 回调Complete await await 回调Complete 回调Complete await await await 异步上下文解析入参获取关键数据A 解析入参B 获取和处理关键数据B 获取和处理核心内部数据根据判断逻辑情况返回错误读服务协程同步处理链路线程资源占用低协程开销极小整体吞吐量高极限容量已压榨尽CPU算力可读性与同步实现差异不大容量高高资源利用率语言级async/await支持 37

38. 38

39. 招聘&活水：后端研发工程师邮箱：yangyuchen03@meituan.com me@easonyang.com 更多技术干货欢迎关注“美团技术团队” 39