- 1、本文档共43页,可阅读全部内容。
- 2、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
微博消息系统架构演进1.2-袁武林
ArchSummit全球架构师峰会深圳站2016微博消息系统架构演进关于我 微博研发中心技术专家,14年加入新浪微博,当前负责微博通讯平台的技术研发工作,曾参与微博消息箱整体架构设计、微博文件服务平台底层存储架构优化等核心项目、主导微博消息箱后端全链路架构优化改造等。推进微博消息箱整体服务高可用性和稳定性保障。本人目前致力于互联网大规模高并发场景服务架构实践,同时也关注研发效率提升等领域的探索。提纲微博消息系统业务介绍架构变迁的几个阶段高可用实时IM系统架构实践经验和教训总结内容大纲新浪微博消息系统介绍伴随着业务发展,消息系统的演进过程起步阶段快速成长稳定发展高可用服务化经验总结和踩坑心得微博消息系统介绍业务范围(典型场景)- 一对一私信- 粉丝群- 商业群发- 粉丝服务自动回复业务特征- 突发流量峰值 (明星空降粉丝群、热点事件私信传播)- 消息下发实时性苛刻 (商业群发和大V私信)目前消息系统承载能力同时在线连接数数千万级点对点消息日发送量数千万级商业群发消息日发送量数亿级实时消息推送能力百万/s大致经历的几个阶段起步阶段-简单的站内消息模式快速成长-长轮询+短连接的复合模式稳定发展-私有TCP协议、长短连接共存高可用服务化时代-全链路优化 + 后端服务化消息系统演进快速发展阶段起步阶段起步阶段起步阶段用户:千万级DAU:十万级用户:数千万级DAU:百万级用户:亿级DAU:千万级用户:百万级DAU:万级业务驱动下持续演进的系统起步阶段基于http短连接的客户端拉取模式。缺点:- 整体功能简单,简单的站内信功能。- 没有推送,消息实时性差。起始阶段-面临的问题业务层面商业群发、微博群等新功能的加入。“消息未读数不准”的顽疾。技术层面“大后端”方式不利于业务层的解耦。数据层Scale Out能力。消息到达及时性的刚需。消息系统演进起步阶段起步阶段快速发展阶段起步阶段用户:数千万级DAU:百万级用户:亿级DAU:千万级用户:百万级DAU:万级用户:千万级DAU:百万级业务驱动下持续演进的系统快速发展阶段主要改进点:后端业务拆分,各模块独立部署。基于http短连接的消息发送。基于http轮询实现消息推送。基于Lua和Redis改造的未读数方案。DB按业务分库分表。缺点:轮询效率低,浪费资源http协议的缺点(eg.数据安全、流量)快速发展阶段-未读数计数改造难点:总未读和会话未读的一致性。方案一:基于Redis内置的Lua支持能力实现。优点:- 内置的天然原子操作。- 不再受限于watch机制。缺点:- 对异常的处理不友好,需要自定义错误码- 主从复制Lua脚本带来的网络带宽成本。- 商业群发Push场景下性能达不到要求。方案二:未读逻辑集成到Redis的新命令中优点:- 性能强悍。- 内置命令使用方便。缺点:- 对Redis源码侵入修改带来的升级隐患。快速发展阶段-面临的问题业务层面移动端业务发展。“私信”发送传输安全性。突破复杂的运营商网络限制。技术层面消息实时推送。业务隔离。消息系统演进起步阶段快速发展阶段起步阶段稳定阶段用户:亿级DAU:千万级用户:百万级DAU:万级用户:千万级DAU:百万级用户:亿级DAU:千万级业务驱动下持续演进的系统稳定阶段主要改进点:基于(TCP/HTTP)私有协议的消息通道。长短连分离。缺点:链路过长。后端业务耦合较大。多端同步问题。稳定阶段-面临的问题业务层面商业群发、明星空降粉丝群带来的瞬时峰值压力。服务整体稳定性。比微信更复杂的多设备同时登陆场景。技术层面后端服务化改造。消息多端一致性保障。快速弹性调度能力。消息系统演进高可用服务化快速发展阶段起步阶段稳定阶段用户:百万级DAU:万级用户:千万级DAU:百万级用户:亿级DAU:千万级用户:数亿级DAU:数千万级业务驱动下持续演进的系统高可用服务化阶段几大方面的加强:架构层面 短链通道链路优化。 后端服务化改造。消息多端一致性同步。稳定性保障层面混合云弹性调度支撑。360°无死角监控和告警。完善SLA体系。为什么需要分层?最终连接层需要避免频繁变动。业务处理需要能同时处理手机端和PC的请求。分层带来的好处连接层与业务无关,可复用,变动少。分发层只根据规则分发请求,不处理业务。业务层不需关心网络细节,面向多终端。短连服务链路改造-分层为什么需要隔离?附件资源开销影响TCP通道的稳定性。私有协议的制约无法快速迁移后端存储。隔离带来的好处收发私信的核心业务不受附件网络开销的影响。上传模块统一化,复用于整个客户端上传请求。后端接入到文件服务平台屏蔽存储细节。短连服务链路改造-隔离非服务化的问题业务间强耦合,依赖升级之痛。异构问题。灵活性。服务化收益去除业务逻辑强依赖。统一服务访问标准。统一服务治理。分布式。短连服务链路改造-后端服务化主要
文档评论(0)