Download
1 / 19
190 likes | 377 Views
QQShow2.0 重构历程. QQ 秀开发组. 应用层 ITEM 显示 / 商城 / 用户换装 / 用户个人形象管理 /QQ Client 表现 /Chat Room 表现 /Web 表现 / 内部管理系统 …. 接口层 数据存取、操作 API/ 接口 Server/File Server/ 流程 Server…. 存储层 DB/Files. 系统层 数据缓存 / 图片合成 Server/ 数据维护 Daemon…. QQ 秀 1.0 的技术架构. Chat Room 应用. Web 应用. QQ Client 应用. 应用层.
E N D
QQShow2.0重构历程 QQ秀开发组
应用层 ITEM显示/商城/用户换装/用户个人形象管理/QQ Client表现/Chat Room表现/Web表现/内部管理系统… 接口层 数据存取、操作API/接口Server/File Server/流程Server… 存储层 DB/Files 系统层 数据缓存/图片合成Server/数据维护Daemon… QQ秀1.0的技术架构
Chat Room应用 Web应用 QQ Client应用 应用层 HTTP File Server UDP File Server 数据存取、操作API 接口层 DB Cache Server 图片处理 Server File Cache Server User DB Item Info DB Item/Image Files 数据维护Daemon 系统/存储层 各层细化的结构图及数据流
QQ秀1.0技术架构的一些"困惑" • 只能提供GIF图片服务, 限制了应用的进一步发展 QQ秀服务抛开商城应用, 简单而言其实就是给应用提供一套图片下载展示的系统, 在互联网应用初期, 由于带宽以及用户机器性能原因, 我们只能提供GIF图片展示用户个性化的形象, 而且也能吸引用户来玩, 但是随着QQ秀业务的发展, 用户也不再满足于简单的图形化形象的展示. • 商城应用性能存在一定的瓶颈 作为公司最早最成熟产品, 原有的商城设计承受了大于设计容量很多倍的考验, 存在重新规划的需求以满足后续业务的新生. • 服务可运营性不足 我们提供的服务在运行期缺少跟踪的手段, 来了投诉也没有个清晰的渠道来获取相应的信息, 在容灾建设方面也缺少快速恢复的手段. 整个服务缺少必要的实时化监控. IDC分布等. • 运营的一些数据缺少数据支撑 不能满足业务精细化运行的需要 • 前台用户交互部分和用户数据逻辑部分耦合度过高
QQ秀2.0要解决的"困惑" • 在提供一套图形形象的基础上, 提供基于flash的形象展示, 并且把flash形象作为QQ秀形象的主要应用, 为业务后续的发展提供更丰富的展示平台 • 在用户数快速增长的环境下解决商城性能问题 • 提高服务的可运营性, 提高服务的质量 • 支撑业务发展所必需了解的运营数据 • 商城前后台逻辑实现用户交互以及数据逻辑的分离, 方便后续业务的扩展以及简化开发
Web Server/CGI Web Server/CGI 通过Agent动态获取DBC服务接口信息 通过Agent动态获取DBC服务接口信息 通过Agent获取相应服务接口信息 通过Agent获取相应服务接口信息 通过Agent动态获取相应服务接口信息 通过Agent动态获取相应服务接口信息 {GD Server/ OIDB无状态逻辑层服务} 属于逻辑层服务, 应用容灾备份机制实现N+1互备 {GD Server/ OIDB/消息中转 Server//搜索引擎等无状态逻辑层服务} 属于逻辑层服务, 应用容灾备份机制实现N+1互备 {UIND/USD等非逻辑层并且有状态服务}应用容灾机制实现IP的可替换,但不能热备 {UIND/USD状态服务}应用容灾机制实现IP的可替换,但不能热备 {DataProxy} 属于逻辑层服务, 应用容灾备份机制实现N+1互备 {DataProxy} 属于逻辑层服务, 应用容灾备份机制实现N+1互备 TTC-cache TTC-cache TTC-cache TTC-cache TTC-cache TTC-cache 各类底层服务/TCP服务/UDP服务/文件储存服务/DB储存服务 底层服务/TCP服务/UDP服务/文件储存服务/DB储存服务 社区DB 社区DB 活动DB 活动DB 商城DB 商城DB 商城管理端/Daemons 商城管理端/Daemons 批价发货Server 批价发货Server QQ秀2.0商城子系统
QQ秀2.0商城子系统 • 面向QQ秀用户访问后台DB全部通过DBC/TTC层代理，DBC屏蔽TTC的分布，TTC屏蔽DB的分布，既有cache能力，又能有效的屏蔽后台DB物理分布信息，给后台数据的扩容以及迁移带来很大的便利。另外DBC按业务DB细分成10种类型（当前实际部署5种类型），部署在一台服务器上为一组，一共3组提供中转服务。 • 面向管理端/daemon，考虑到TTC对部分SQL功能的支持不能满足业务的需求，这部分时直连DB解决。后续持续对管理端/daemon部分功能直连DB部分做进一步改造，达到IP的全部配置化，进一步完善TTC等等。 • 对公司/部门的公共接口服务采用无状态逻辑server进行中转/避免用户接入层的频繁变更，采用N+1的方式进行热备 • 对文件存储的服务做到接口服务IP/PORT的可配置，可以方便的迁移这类服务部署到其他位置（类似TTC对DB的物理分布配置功能）
前台模块 • 采用Flash引擎，Flash负责交互，封装了独立的换装js库负责和Flash通讯 • 采用AJAX技术，用XML作为前后台的通讯媒介，方便调试和自动化测试 • 前台采用了统一的出错处理机制以及页面填充函数，简化了页面的开发 • 前台相关交互部分尽量都模块化，形成互补干扰的子模块， 比如换装系统、菜单模块、专区模块、一些业务线经常变更的特性做成可以管理的模块方便更新 • 前台模块的基本思路和Qzone的前台优化思路一致, 降低流量, 提高用户体验速度以及提高交互的感受
逻辑模块 采用三层架构，使得存储-通用逻辑-业务逻辑解藕。
数据储存模块 • QQShow2.0商城现在全部采用DBC+TTC的方式实现数据存储。 • 定义了5类DBC分别中转不同级别的TTC请求，避免非核心功能的频繁更改影响核心业务 • 每类DBC分别部署到5台不同机器，实现了负载均衡和容灾
数据储存模块 • 对于核心数据，例如用户信息和用户物品分布了在100个库10000表，这样可以减少DB写操作时的锁表情况，提高DB写效率 • 尽量将核心数据的TTC部署在其DB的同台服务器上，可以大大提高TTC的读写速度。
数据储存模块 • 数据存储模块定义了统一的接口基类，用模板的方式实现了分别针对Db、TTC、C4A的三个派生类，使得底层存储和上层逻辑独立。
容灾建设 • Configserver/Agent服务, 保证服务故障的时候能快速切换到正常提供服务的备用服务上（主要应用在逻辑层无状态服务上） • 数据层容灾主要靠BU公共组件提供支持 • 业务侧暂时保证对核心数据层服务提供N+M热备, 结合Configserver/Agent服务能快速恢复服务 • 对非核心数据层服务提供冷备服务, 结合冷备数据以及LOG恢复数据, 再借助Agent能快速恢复服务
日常运营监控模块 • 利用返回码系统实现了关键调用的情况以及调用时间的上报，而开发人员只需维护关键调用映射表。（模块间调用监控） • 返回码系统记录关键调用路径，并将错误和调用时间超过1s的调用集中以UDP的方式发送到logserver集中管理 • CGI服务的自动化测试监控 • 页面级测速监控 • 运营数据统计接入
QQ Client应用 Web商城 应用层 逻辑层 切CDN UDP 切CDN TCP FasSvr Ts_Server UDP 时间戳文件 UDP Tcp_Item http_ifsd Image_Exchange_Server nfs 系统/存储层 qqshow_nfsd Nfs_server Item后台 管理网站 TCP Fileserver 用户形象xml文件 商城 ITEM qqshow_gd tcp GD Server QQ秀2.0后台子系统
QQ秀2.0后台item系统 • 商城子系统中的展示84图, 换装flash文件的拉取都是通过qqshow2-item.qq.com来拉取 • Client应用中拉取flash文件来显示形象也是通过flash2-item.qq.com来拉取 • 这两个域名外包CDN实现分布, 内容部分是通过业务管理段实现上传和管理
QQ秀2.0后台GD系统 • GD服务是商城服务和后台服务的一个接口 • GD生成了用户形象的XML配置信息，供client来拉取，并由client来负责解析，在通过client主影片负责显示qqshow形象 • GD负责NFSD以及时间戳服务上相应数据的更新工作.
QQ秀2.0后台快照系统 • 负责生成flash形象对应的GIF形象 • 通过linux系统下的firefox进程挂载flash进程来生成快照 • GD负责通知快照服务 • 快照服务生成快照之后需要通知原有的GIF形象系统, 更新相应的接口, 保证GIF形象能正常显示出来
