亿级用户下的新浪微博平台架构

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

Feed用户行为分析
用用户浏览⻚页数统计
微博曝光量日日志抽样分析:
97%用用户都是浏览5天内的微博
服务层
• RPC Server 队列处理机 (侧重CPU和 内存) • Hbase/MySQL • MC/MCQ/ Redis(侧重 内存与硬盘)
资源层
平台架构延伸
维度 平台团队 业务架构 • 业务架构师 和业务工程 师 技术架构 • 技术架构师 技术保障 • 平台运维团 队 • 服务保障 • 服务上线、 下线 • 业务监控与 报警
rpc2 rpc4
CR CR SS SS
节点E
节点C
系统架构设计
agent Web V4 Server agent Web V4 Client 1.1 1.2 标准化日志 (MC/Redis/资源 中间件/...) 1.3 agent RPC Client agent RPC Server 1.4 解决跨语言、跨框架的问题,微 博平台所有服务以及接口通过生 成标准的日志,支撑不同的接口 框架以及RPC服务框架。
Web(JS、CSS、HTML) Android iPhone
接入层
Web(php)
MAPI
Push 网关
后台
搜索
微博平台(Java)
大数据
平台架构演变
2009 - 2010
2011 - 2014
2014 – 将来
团队职责
• 业务模块化、 • 提供标准化 服务化 的技术框架 • 业务流程优 • 解决系统高 化 并发、高可 • 业务容量评 用、高可扩 估 展问题
1. 平台组织架构(物理)与技术体系(逻辑)从无缝结合,提 高了团队协作的效率,降低了沟通成本。 2. 12个区间分别聚焦于各自的侧重点,指明长期的发展方向。
Scriber Serer
Spark
HBase
UI
Feed多级分布式缓存设计
用用户访问模型驱动设计
模型建 立
模型摸 索
模型发 生变化
常见的模型指标: • 读写比 • 访问时长分布 • 访问时段分布 • 访问量分布 • 访问来源分布 • ……
亿级用户下的新浪微博平台架构
@卫向军_微博
Agenda
1. 微博的技术架构 2. 微博平台的技术挑战 3. 微博平台架构演变与第三代技术架构体系 4. Watchman-分布式服务追踪系统 5. Feed多级双机房缓存系统 6. 致谢
微博技术架构
客户端
分布式追踪系统
分布式服务痛点
• 同一个请求,处理时依赖多 个微服务。 • 各个服务之间互相隔离,导 致出问题时,排查特别困难。 • 不同服务的日志无法有效的 匹配。
WatchMan系统
解决的问题
• 生成完整的请求调用链,方便排查问题。 • 生成服务依赖关系图,查询线上服务的状态。 • 结合RPC框架,扩展服务治理功能。
节点B rpc1
SR SS
CS
SR
节点D rpc3
4节点模型: CS = Client Send SR = Server Receive SS = Server Send CR = Client Receive
数据量
bigger than bigger
用户体验
faster Hale Waihona Puke Baiduhan faster
业务
more and more
第三代技术体系
业务架构
1 接口层 2
Feed 关系 通讯 Feed 关系 通讯
技术架构
4
接口框架 基 础 组 件 + 分 布 式 追 踪 组 件
监控平台 7
SLA
服务治理 10
LAMP
面向SOA的架构
技术架构、业务架构、 技术保障多维度结合
平台技术挑战
10亿级PV,百万级的QPS,千亿级数据 4个9的可用性,150ms的SLA,线上故障5min内处理。 1.02亿DAU,6941万的总互动量,相关阅读数41.5亿(羊年除夕)。 百个微服务,2次/周的常规上线与不限次数的紧急上线
设计要点
• 生成唯一的RequestID标识,并逐级递归传递给调用的 HTTP与RPC服务。 • 对业务系统最低侵入原则,使用AOP方式织入平台中 间件。 • 对业务系统性能影响最小,采用1/1000的采样率。
调用链模型
User
CS
节点A
SR CS CR
流量切换
5
RPC MCQ 短链 用户 发号器 Config
8
服务状态
11
服务依赖
服务层
调用链
发布和灰度
3 资源层
MC HBase
6
Cache组件
9
Error
12
扩容与缩容
Redis
MySQL
对象库
异常
水平维度分析
层次 接口层 特点 • 无状态设计 • 支持HTTP/1.1协 议,JSON数据格 式 • 无状态设计 • 组合服务与原子 服务 • 数据可靠性要求 很高 • 容量与QPS规划 • 扩容方案 机器 • 前端(侧重 CPU和内存) 技术保障 • 高可扩展性 • 支持内外网两 种部署 • 高可扩展性 • 主要部署在内 网 • • • • 扩展性较差 数据迁移 服务扩容 安全性要求高
相关文档
最新文档