qq秀2.0重构基于多层架构，旨在改进商城性能，提升服务可运营性，并引入Flash形象展示以满足用户需求。系统通过新的数据存储模块和容灾机制，实现了对核心数据的高效管理和负载均衡。同时，前台用户交互与数据逻辑分离，优化了用户体验和模块化管理，确保后续业务扩展的便利性。

1. QQShow2.0 重构历程 QQ 秀开发组

2. QQ 秀 1.0 的技术架构 存储层 DB/Files 接口层 数据存取、操作 API/ 接口 Server/File Server/ 流程 Server… 应用层 ITEM 显示 / 商城 / 用户换装 / 用户个人形象管理 /QQ Client 表现 /Chat Room 表现 /Web 表现 / 内部管理系统… 系统层 数据缓存 / 图片合成 Server/ 数据维护 Daemon…

3. 各层细化的结构图及数据流 系统 / 存储层 Web 应用 QQ Client 应用 Chat Room 应用 数据存取、操作 API UDP File Server HTTP File Server User DB Item Info DB Item/Image Files DB Cache Server File Cache Server 图片处理 Server 接口层 应用层 数据维护 Daemon

4. 只能提供 GIF 图片服务 , 限制了应用的进一步发展 QQ 秀服务抛开商城应用 , 简单而言其实就是给应用提供一套图片下载展示的系统 , 在互联网应用初期 , 由于带宽以及用户机器性能原因 , 我们只能提供 GIF 图片展示用户个性化的形象 , 而且也能吸引用户来玩 , 但是随着 QQ 秀业务的发展 , 用户也不再满足于简单的图形化形象的展示 . 商城应用性能存在一定的瓶颈 作为公司最早最成熟产品 , 原有的商城设计承受了大于设计容量很多倍的考验 , 存在重新规划的需求以满足后续业务的新生 . 服务可运营性不足 我们提供的服务在运行期缺少跟踪的手段 , 来了投诉也没有个清晰的渠道来获取相应的信息 , 在容灾建设方面也缺少快速恢复的手段 . 整个服务缺少必要的实时化监控 . IDC 分布等 . 运营的一些数据缺少数据支撑 不能满足业务精细化运行的需要 前台用户交互部分和用户数据逻辑部分耦合度过高 QQ 秀 1.0 技术架构的一些 " 困惑 "

5. QQ 秀 2.0 要解决的 " 困惑 " 在提供一套图形形象的基础上 , 提供基于 flash 的形象展示 , 并且把 flash 形象作为 QQ 秀形象的主要应用 , 为业务后续的发展提供更丰富的展示平台 在用户数快速增长的环境下解决商城性能问题 提高服务的可运营性 , 提高服务的质量 支撑业务发展所必需了解的运营数据 商城前后台逻辑实现用户交互以及数据逻辑的分离 , 方便后续业务的扩展以及简化开发

6. QQ 秀 2.0 商城子系统 Web Server/CGI TTC-cache 商城 DB TTC-cache 社区 DB TTC-cache 活动 DB 批价发货 Server 商城管理端 /Daemons {UIND/USD 等非逻辑层并且有状态服务 } 应用容灾机制实现 IP 的可替换 , 但不能热备 通过 Agent 动态获取 DBC 服务接口信息 {GD Server/ OIDB/ 消息中转 Server// 搜索引擎等无状态逻辑层服务 } 属于逻辑层服务 , 应用容灾备份机制实现 N+1 互备 { DataProxy} 属于逻辑层服务 , 应用容灾备份机制实现 N+1 互备 各类底层服务 /TCP 服务 /UDP 服务 / 文件储存服务 /DB 储存服务 通过 Agent 获取相应服务接口信息 通过 Agent 动态获取相应服务接口信息 Web Server/CGI TTC-cache 商城 DB TTC-cache 社区 DB TTC-cache 活动 DB 批价发货 Server 商城管理端 /Daemons {UIND/USD 状态服务 } 应用容灾机制实现 IP 的可替换 , 但不能热备 通过 Agent 动态获取 DBC 服务接口信息 {GD Server/ OIDB 无状态逻辑层服务 } 属于逻辑层服务 , 应用容灾备份机制实现 N+1 互备 { DataProxy} 属于逻辑层服务 , 应用容灾备份机制实现 N+1 互备 底层服务 /TCP 服务 /UDP 服务 / 文件储存服务 /DB 储存服务 通过 Agent 获取相应服务接口信息 通过 Agent 动态获取相应服务接口信息

7. 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 的物理分布配置功能）

8. 前台模块 采用 Flash 引擎， Flash 负责交互，封装了独立的换装 js 库负责和 Flash 通讯 采用 AJAX 技术，用 XML 作为前后台的通讯媒介，方便调试和自动化测试 前台采用了统一的出错处理机制以及页面填充函数，简化了页面的开发 前台相关交互部分尽量都模块化，形成互补干扰的子模块， 比如换装系统、菜单模块、专区模块、一些业务线经常变更的特性做成可以管理的模块方便更新 前台模块的基本思路和 Qzone 的前台优化思路一致 , 降低流量 , 提高用户体验速度以及提高交互的感受

9. 逻辑模块 采用三层架构，使得存储 - 通用逻辑 - 业务逻辑解藕。 CGI 逻辑 通用逻辑层 / 公共接口 存储层 DB TTC C4A

10. 数据储存模块 QQShow2.0 商城现在全部采用 DBC+TTC 的方式实现数据存储。 定义了 5 类 DBC 分别中转不同级别的 TTC 请求，避免非核心功能的频繁更改影响核心业务 每类 DBC 分别部署到 5 台不同机器，实现了负载均衡和容灾

11. 数据储存模块 对于核心数据，例如用户信息和用户物品分布了在 100 个库 10000 表，这样可以减少 DB 写操作时的锁表情况，提高 DB 写效率 尽量将核心数据的 TTC 部署在其 DB 的同台服务器上，可以大大提高 TTC 的读写速度。

12. 数据储存模块 数据存储模块定义了统一的接口基类，用模板的方式实现了分别针对 Db 、 TTC 、 C4A 的三个派生类，使得底层存储和上层逻辑独立。

13. 容灾建设 Configserver/Agent 服务 , 保证服务故障的时候能快速切换到正常提供服务的备用服务上（主要应用在逻辑层无状态服务上） 数据层容灾主要靠 BU 公共组件提供支持 业务侧暂时保证对核心数据层服务提供 N+M 热备 , 结合 Configserver/Agent 服务能快速恢复服务 对非核心数据层服务提供冷备服务 , 结合冷备数据以及 LOG 恢复数据 , 再借助 Agent 能快速恢复服务

14. 日常运营监控模块 利用返回码系统实现了关键调用的情况以及调用时间的上报，而开发人员只需维护关键调用映射表。（模块间调用监控） 返回码系统记录关键调用路径，并将错误和调用时间超过 1s 的调用集中以 UDP 的方式发送到 logserver 集中管理 CGI 服务的自动化测试监控 页面级测速监控 运营数据统计接入

15. QQ 秀 2.0 后台子系统 Web 商城 应用层 QQ Client 应用 逻辑层 系统 / 存储层 http_ifsd Item 后台 管理网站 tcp Fileserver 商城 ITEM Nfs_server qqshow_nfsd 用户形象 xml 文件 Ts_Server 时间戳文件 FasSvr Image_Exchange_Server UDP UDP UDP GD Server qqshow_gd TCP Tcp_Item TCP nfs 切 CDN 切 CDN

16. QQ 秀 2.0 后台 item 系统 商城子系统中的展示 84 图 , 换装 flash 文件的拉取都是通过 qqshow2-item.qq.com 来拉取 Client 应用中拉取 flash 文件来显示形象也是通过 flash2-item.qq.com 来拉取 这两个域名外包 CDN 实现分布 , 内容部分是通过业务管理段实现上传和管理

17. QQ 秀 2.0 后台 GD 系统 GD 服务是商城服务和后台服务的一个接口 GD 生成了用户形象的 XML 配置信息，供 client 来拉取，并由 client 来负责解析，在通过 client 主影片负责显示 qqshow 形象 GD 负责 NFSD 以及时间戳服务上相应数据的更新工作 .

18. QQ 秀 2.0 后台快照系统 负责生成 flash 形象对应的 GIF 形象 通过 linux 系统下的 firefox 进程挂载 flash 进程来生成快照 GD 负责通知快照服务 快照服务生成快照之后需要通知原有的 GIF 形象系统 , 更新相应的接口 , 保证 GIF 形象能正常显示出来

19. 谢谢